codesign用来签名和检查签名
1. 关于--options=runtime之前文章已经有介绍
2. 关于entitlements参数，这里暂时未发现entitlement和内容不符，会出问题，可能以后会有问题
我们签QtWebEngineCore.framework下面的Helpers下的QtWebEngineProcess.app时，用自己工程的entitlements替换了
QtWebEngineCore.framework/Versions/A/Helpers/QtWebEngineProcess.app/Contents/Resources/QtWebEngineProcess.entitlements
com.apple.security.cs.allow-unsigned-executable-memory
com.apple.security.cs.disable-library-validation
com.apple.security.cs.allow-jit
这里面的值和我们的不太一样，也没发现报错，特别是allow-jit删掉以后，也没发现报错。这是一个可疑的点，可能会有坑。
3. -dvvv和-vvv
-dvvv显示有没有签名，它不保险，显示有,但签名可能不合法
-vvv验证签名，它会检查签名，但是当签名是adhoc或者未认证帐号，它也会报正常。
所以这两个要结合用，昨天发现的问题就是-vvv不报错，是adhoc签名，在spctl的时候报错。
spctl用来验证app合法性，相当于验证守门员是不是工作，能不能过守门员的检查。
1. 它用来检查某个app合法性，当用在framework上时
conanchen@ConanChen client-delivery % spctl -a -v
/Users/conanchen/client-delivery/Output/AppBundle/Test/Autodesk\
Fusion\
360.app/Contents/Frameworks/Qt/QtWebEngineCore.framework
/Users/conanchen/client-delivery/Output/AppBundle/Test/Autodesk
Fusion 360.app/Contents/Frameworks/Qt/QtWebEngineCore.framework:
rejected (the code is valid but does not seem to be an app)
当应用在App时
onanchen@ConanChen client-delivery % spctl -v -a
/Users/conanchen/client-delivery/Output/AppBundle/Test/Autodesk\
Fusion\
360.app/Contents/Frameworks/Qt/QtWebEngineCore.framework/Versions/A/Helpers/QtWebEngineProcess.app
/Users/conanchen/client-delivery/Output/AppBundle/Test/Autodesk
Fusion
360.app/Contents/Frameworks/Qt/QtWebEngineCore.framework/Versions/A/Helpers/QtWebEngineProcess.app:
accepted
source=Developer ID
conanchen@ConanChen client-delivery % spctl -v -a
/Users/conanchen/client-delivery/Output/AppBundle/Test/Autodesk\
Fusion\
360.app/Contents/Frameworks/Qt/QtWebEngineCore.framework/Versions/A/Helpers/QtWebEngineProcess_debug.app
/Users/conanchen/client-delivery/Output/AppBundle/Test/Autodesk
Fusion
360.app/Contents/Frameworks/Qt/QtWebEngineCore.framework/Versions/A/Helpers/QtWebEngineProcess_debug.app:
rejected (the code is valid but does not seem to be an app)
可以看到，它能检查出是不是合规的app。它一般有括号，会报出问题，这种问题好解决。
项目遇到的问题就是它报rejected，但没有明确错误。一开始猜测是下面有其他app被rejected，它外层就rejected，最后实测它只考虑自己这个app，Nested的app需要
单独运行spctl -v
-a来显示。像上面的QtWebEngineProcess_debug.app（spctl报错的）被包括的时候依然外层能被accepted。
项目中运用的是
spctl -vvvvvv --assess --type exec --continue pathofApp
当没有明确错误的时候，其实还是codesign的原因，因为我清楚前后只改了签名，但具体哪个不清楚。后来发现一个好方法。把怀疑的目录全删了，然后
codesign -f -s codesingIndentity --options=runtime
--entitlements pathOfEntitlements pathofApp
再spctl -v -a pathofApp,当没有干扰项的时候，它应该报成功，然后慢慢从回收站put
back。重复上面步骤，看哪个出错就是哪个有问题，再慢慢查。
最后发现的原因就是上面，用-vvv验证是成功的，但是-dvvv显示其实是adhoc的，也就是说spctl可以检查出adhoc的签名是不对的。
理论上签名在同一个app中应该可以不一样。
比如你用了第三方的库，只要库本身签名合法就行，外层你签上自己的签名就好。
特别注意上面检查步骤中codesign的时候没有--deep参数，因为如果加了--deep，它自动帮你解决所有问题，你不清楚--deep覆盖了哪些地方。
目前确定的是MacOS Frameworks (只有dylib, 其他不会覆盖) Helpers
应该还有Plugins，Resources会不会没有验证过。
所以这次目标就是去掉--deep参数，手动签名下面所有的依赖，最后在app上直接codesign不带--deep参数。
目前已经本地试成功了。
特别注明的是，不管codesign
-vvv还是spctl它们只保证自己的检查正确，并不能保证过Notary，Notary的要求更高，需要所有的二进制都已经有合法签名。
在上面两步中，如果在一些特殊目录里，没有签名也是不报错的。
codesign和spctl的区别
codesign用来签名和检查签名
1. 关于--options=runtime之前文章已经有介绍
2. 关于entitlements参数，这里暂时未发现entitlement和内容不符，会出问题，可能以后会有问题
我们签QtWebEngineCore.framework下面的Helpers下的QtWebEngineProcess.app时，用自己工程的entitlements替换了
QtWebEngineCore.framework/Versions/A/Helpers/QtWebEngineProcess.app/Contents/Resources/QtWebEngineProcess.entitlements
com.apple.security.cs.allow-unsigned-executable-memory
com.apple.security.cs.disable-library-validation
com.apple.security.cs.allow-jit
这里面的值和我们的不太一样，也没发现报错，特别是allow-jit删掉以后，也没发现报错。这是一个可疑的点，可能会有坑。
3. -dvvv和-vvv
-dvvv显示有没有签名，它不保险，显示有,但签名可能不合法
-vvv验证签名，它会检查签名，但是当签名是adhoc或者未认证帐号，它也会报正常。
所以这两个要结合用，昨天发现的问题就是-vvv不报错，是adhoc签名，在spctl的时候报错。
spctl用来验证app合法性，相当于验证守门员是不是工作，能不能过守门员的检查。
1. 它用来检查某个app合法性，当用在framework上时
conanchen@ConanChen client-delivery % spctl -a -v /Users/conanchen/client-delivery/Output/AppBundle/Test/Autodesk\ Fusion\ 360.app/Contents/Frameworks/Qt/QtWebEngineCore.framework
/Users/conanchen/client-delivery/Output/AppBundle/Test/Autodesk Fusion 360.app/Contents/Frameworks/Qt/QtWebEngineCore.framework: rejected (the code is valid but does not seem to be an app)
当应用在App时
onanchen@ConanChen client-delivery % spctl -v -a /Users/conanchen/client-delivery/Output/AppBundle/Test/Autodesk\ Fusion\ 360.app/Contents/Frameworks/Qt/QtWebEngineCore.framework/Versions/A/Helpers/QtWebEngineProcess.app
/Users/conanchen/client-delivery/Output/AppBundle/Test/Autodesk Fusion 360.app/Contents/Frameworks/Qt/QtWebEngineCore.framework/Versions/A/Helpers/QtWebEngineProcess.app: accepted
source=Developer ID
conanchen@ConanChen client-delivery % spctl -v -a /Users/conanchen/client-delivery/Output/AppBundle/Test/Autodesk\ Fusion\ 360.app/Contents/Frameworks/Qt/QtWebEngineCore.framework/Versions/A/Helpers/QtWebEngineProcess_debug.app
/Users/conanchen/client-delivery/Output/AppBundle/Test/Autodesk Fusion 360.app/Contents/Frameworks/Qt/QtWebEngineCore.framework/Versions/A/Helpers/QtWebEngineProcess_debug.app: rejected (the code is valid but does not seem to be an app)
可以看到，它能检查出是不是合规的app。它一般有括号，会报出问题，这种问题好解决。
项目遇到的问题就是它报rejected，但没有明确错误。一开始猜测是下面有其他app被rejected，它外层就rejected，最后实测它只考虑自己这个app，Nested的app需要
单独运行spctl -v -a来显示。像上面的QtWebEngineProcess_debug.app（spctl报错的）被包括的时候依然外层能被accepted。
项目中运用的是
spctl -vvvvvv --assess --type exec --continue pathofApp
当没有明确错误的时候，其实还是codesign的原因，因为我清楚前后只改了签名，但具体哪个不清楚。后来发现一个好方法。把怀疑的目录全删了，然后
codesign -f -s codesingIndentity --options=runtime --entitlements pathOfEntitlements pathofApp
再spctl -v -a pathofApp,当没有干扰项的时候，它应该报成功，然后慢慢从回收站put back。重复上面步骤，看哪个出错就是哪个有问题，再慢慢查。
最后发现的原因就是上面，用-vvv验证是成功的，但是-dvvv显示其实是adhoc的，也就是说spctl可以检查出adhoc的签名是不对的。
理论上签名在同一个app中应该可以不一样。
比如你用了第三方的库，只要库本身签名合法就行，外层你签上自己的签名就好。
特别注意上面检查步骤中codesign的时候没有--deep参数，因为如果加了--deep，它自动帮你解决所有问题，你不清楚--deep覆盖了哪些地方。
目前确定的是MacOS Frameworks (只有dylib, 其他不会覆盖) Helpers 应该还有Plugins，Resources会不会没有验证过。
所以这次目标就是去掉--deep参数，手动签名下面所有的依赖，最后在app上直接codesign不带--deep参数。
目前已经本地试成功了。
特别注明的是，不管codesign -vvv还是spctl它们只保证自己的检查正确，并不能保证过Notary，Notary的要求更高，需要所有的二进制都已经有合法签名。
在上面两步中，如果在一些特殊目录里，没有签名也是不报错的。