macdeploytqt fix: avoid potential codesign verification or codesign signing errors. #125
Conversation
…ot binaries path. This avoids a codesign verification error that may appear as "nested code is modified or invalid".
|
|
|
I can have a look. Anyhow, do you have insights on the root issue?Why does it matter in which order the binaries inside Contents/MacOS are signed? |
My only insight is the two error messages I quoted above, and their absence when I changed the order. https://developer.apple.com/documentation/xcode/creating-distribution-signed-code-for-the-mac#Determine-the-signing-order discusses the signing order but implies either order is acceptable if the two executables are independent. In my case GPSBabelFE starts gpsbabel as a process but I don't see how codesign could know that. codesign can see that GPSBabelFE is the CFBundleExecutable in Info.plist. I do see that gpsbabel appears in _CodeSignatures/CodeResources, while GPSBabelFE does not. |
|
I replaced the standalone app "gpsbabel" in Contents/MacOS with another standalone app "aprog" that doesn't have any dependencies. Furthermore, the bundle executable "GPSBabelFE" doesn't know anything about "aprog". I dropped the executable option from macdeployqt. I can still create the errors, and I can change the build to get the two variations on the failure based on building universal binary or an apple binary. If I name the extra binary "zprog" instead of "aprog" no errors are generated as one might expect from the unsorted directory list. I suspect the app bundle executable needs to be signed last to "seal" the bundle. The difference between the two error messages has to do with what architectures are targeted. If I just target arm64: |
|
There is a very simple testcase here: https://github.com/tsteven4/csbug |
From the codesign man page There is also a definition of nested code. In this PR we are only addressing Contents/MacOS. |
|
Thanks for the detailed investigation! With the example application, it was indeed easy to verify that macOS considers all binaries inside the Contents/MacOS folder as 'inner dependencies' ... We don't use github for development of qt, but codereview.qt-project.org. I created now a proposed patch there: Anyhow, I couldn't keep your authorship in the git metadata, as our system doesn't like pseudonymous github.com addresses. If you want to be properly attributed, you therefore need to log into codereview.qt-project.org with your Qt account, and amend /resubmit the patch yourself. Please let me know what you prefer. |
|
@kkoehne Please proceed with your authorship of the patch. thanks. |
This avoids a codesign verification error that may appear as
"nested code is modified or invalid".
This commit was originally created by
https://github.com/tsteven4
#125
Pick-to: 6.5 6.8 6.10
Change-Id: Ifa0b4ed9da1d7b36cb54f9d2fa6aee48c1fe519c
Reviewed-by: Alexandru Croitor <[email protected]>
Reviewed-by: Tor Arne Vestbø <[email protected]>
|
Change in qtbase has been merged. Thanks ! |
|
I see it in dev, but not 6.10. It appears https://codereview.qt-project.org/c/qt/qtbase/+/691413 may need some intervention. |
2 participants
codesign verification or codesign signing errors can occur with macdeployqt. The errors can only occur if multiple executables exist in the root binary path (../MacOS/Contents) as one would expect if the -executables option is used. Furthermore, the errors depend on the unsorted order of the binaries returned by QDir.
To avoid these errors this PR ensures that the app binary is signed after any other binaries in the root binaries path.
This avoids a potential codesign verification error, e.g.
This was observed with Qt 6.10.0, System Version: macOS 26.1 (25B78), Model Name: Mac mini, Model Identifier: Macmini9,1, Model Number: MGNR3LL/A, Chip: Apple M1
Alternatively, a potential codesign signing error should be avoided as well, e.g.
This was observed on github with Qt 6.10.0, macOS 26.0.1 (25A362), Image: macos-26-arm64, Version: 20251103.0095
It is not clear to me why I see the first locally and the second on github actions. I have verified the fix locally but not on github actions.
These errors can only occur when there are multiple binaries in the rootBinariesPath (.../Contents/MacOS/). Multiple binaries can be expected if the --executables option is used, although the value of that option is not used in codesignBundle.
Note that the appBinaryName may or may not be first in the unsorted foundRootBinaries. In existing code the occurrence of the error will depend on the order of foundRootBinaries, so some test cases could fail and other pass.