Closed kornelski closed 10 months ago
First, rcodesign verify
has a lot of bugs and sometimes misleading behavior. It's code is somewhat old and doesn't reflect everything I've learned about Apple code signing. I wouldn't trust it that much. Always use Apple's codesign
for canonical verification testing!
Regarding SHA-1, Mach-O binaries support embedding multiple versions of the signatures for compatibility with older OS versions. e.g. SHA-1 can be the primary signature but there can be a supplemental SHA-256 version that is used by newer OS versions that know how to read it.
Our implementation looks at the OS targeting info in the Mach-O binary and attempts to do the right things automatically. See logic at https://github.com/indygreg/apple-platform-rs/blob/2be2f9c76625409272e83e86c1a56a2158077424/apple-codesign/src/signing_settings.rs#L755.
Generally, having the SHA-1 signature around isn't harmless as long as it is joined by a SHA-256 signature. Stripping the SHA-1 signature completely could render the binary unrunnable on older OS versions, which is why we always write SHA-1 + SHA-256 if the binary says it targets older OS not supporting SHA-256.
I've also thought about removing the --digest
algorithm because IMO it doesn't need to be exposed since in most cases we can infer defaults from the targeting metadata embedded in Mach-O.
Does this answer your questions? Do you think there is a bug or missing feature you'd like to see implemented?
Commit 9c3b942e494c66ad483cc76d558c843a45203a8d also shored up SHA-1 handling.
In the absence of proof showing that SHA-1/SHA-256 digests are the problem with Apple rejecting notarization, I'm closing this issue. Please reopen or file a new issue with steps to reproduce if you disagree things are in an acceptable state.
I'm trying to fix broken (rejected by notarization) signatures on https://imageoptim.com/ImageOptim1.9.0.tar.xz
I've run:
but it did not fix the signatures, and left a apparently a wrong digest algorithm: