indygreg / apple-platform-rs Goto Github PK

View Code? Open in Web Editor NEW

532.0 532.0 36.0 14.92 MB

Rust crates supporting Apple platform development

Rust 97.76% Makefile 0.04% Python 0.89% HCL 0.97% Just 0.34%

apple macos rust

apple-platform-rs's People

Contributors

Stargazers

Watchers

apple-platform-rs's Issues

support for writing car files

to upload an app to the appstore you need to add your icons to an asset bundle with .car extension. I'm currently using xcode to construct the Assets.car file, but this is only a temporary workaround.

Notarizing ZIP files not supported

I'm currently using gon to notorize my application, but would like to make it cross-platform with the help of rcodesign.
I used to notorize a cli binary after packaging it into a ZIP file.
But rcodesign mentions, that this file type is unsupported.

Apple's website mentions that notarizing ZIP files is supported:
https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/customizing_the_notarization_workflow:

While you can notarize a ZIP archive, you can’t staple to it directly. Instead, run stapler against each item that you added to the archive. Then create a new ZIP file containing the stapled items for distribution. Although tickets are created for standalone binaries, it’s not currently possible to staple tickets to them.

It would be great if ZIP files could be notarized as well.
GON mentions this as supported file types:

This must be one of Apple's supported file types for notarization: dmg, pkg, app, or zip.

Thank you!

--digest=sha256 doesn't replace sha1 signatures

I'm trying to fix broken (rejected by notarization) signatures on https://imageoptim.com/ImageOptim1.9.0.tar.xz

I've run:

rcodesign sign --digest=sha256 --p12-file cert.p12 ImageOptim.app

but it did not fix the signatures, and left a apparently a wrong digest algorithm:

rcodesign verify ImageOptim.app/Contents/MacOS/ImageOptim

@0: insecure digest algorithm used in code directory: Sha1
@1: insecure digest algorithm used in code directory: Sha1
Error: problems reported during verification

appstoreconnect: Unauthenticated

getting this error, is this a temporary apple server issue? does anyone else have this problem? I can't find anything wrong with the appstoreconnect jwt code.

rcodesign notary-submit --api-key-path ~/.apple/notarization.json dioxus-wallet.app
creating Notary API submission for dioxus-wallet.app.zip (sha256: 02f1752798354dad88244220f8361df9571d1c4356ee64dba38994ec88429592)
HTTP error from https://appstoreconnect.apple.com/notary/v2/submissions
Unauthenticated

    Request ID: ICM7THHI5RZTBKUQA3VWJCUECA.0.0

Error: error interacting with Notary API

Error: signature data too large (please report this issue)

While trying to sign a binary with p12 certificate and a plist file (somehow large), I'm getting the following error:
Error: signature data too large (please report this issue)

If I remove some keys from the plist file it seems to work. But on the other hand, while I evolved the rust code a bit more, it seems that I have to remove more data from the plist file now.

Is this an issue? Or I'm doing something wrong?

The command is: rcodesign sign --entitlements-xml-path rustswift.entitlements --p12-file Certificates.p12 --p12-password Certificate --runtime-version 12.3.0 ./target/debug/rustswift

Only make 1 unncessary request to time-stamp token server

Currently, each signing operation using a time-stamp token server may need to send a request to sign fake data so we can see the size of the resulting signature.

We should be able to reduce the lookups to a single request by caching the result.

Keychain Access does not allow exporting Developer ID like the docs say

The documentation suggests right-clicking a certificate and using Export.

https://gregoryszorc.com/docs/apple-codesign/main/apple_codesign_certificate_management.html#using-keychain-access

In Keychain Access (Version 11.0 (55300.40.2), Ventura) there is no such option when right-clicking the certificate:

There's "File -> Export Items…" option, but it doesn't allow using the .p12 format:

Code signing performance for projects at scale

Having a fully-implemented alternative codesign is a good opportunity to make it faster than Apple's. Code signing is a significant bottleneck for many projects at scale. Here are some ways it could be made fast (not sure if some of these are implemented already):

Provide a flag to use SHA-1 for signing (doable in codesign with a flag)
Provide a flag to only sign the binary, and not any of the resources (doable in codesign with a flag that points to a separate metadata file)
Compute hashes in parallel for the binary (not doable in codesign, and where the project could really shine)

If it can be made easily faster, and produce stable (ideally bit-for-bit identical to codesign) binaries, it would be a nice win for projects at scale.

Invalid magic number signing provisioning profile

(this might be a duplicate of #10)
I'm seeing the "invalid magic number" error when dealing with provisioning profiles.

$ rcodesign sign -v --p12-file /opt/cert/certs/prod.p12 --team-name [redacted] embedded.provisionprofile
Please enter password for p12 file: [hidden]
[2022-08-26T15:31:24Z WARN  rcodesign] registering signing key
[2022-08-26T15:31:24Z WARN  rcodesign] automatically registered Apple CA certificate: Developer ID Certification Authority
[2022-08-26T15:31:24Z WARN  rcodesign] automatically registered Apple CA certificate: Apple Root CA
[2022-08-26T15:31:24Z WARN  rcodesign] using time-stamp protocol server http://timestamp.apple.com/ts01
[2022-08-26T15:31:24Z WARN  rcodesign] automatically setting team ID from signing certificate: [redacted]
[2022-08-26T15:31:24Z WARN  rcodesign] signing embedded.provisionprofile in place
[2022-08-26T15:31:24Z WARN  rcodesign::signing] signing embedded.provisionprofile as a Mach-O binary
[2022-08-26T15:31:24Z INFO  rcodesign::signing_settings] inferring default signing settings from Mach-O binary
Error: binary parsing error: Invalid magic number: 0x30823224

I verified this happens with multiple provisioning profiles.
The problem also shows up when a bundle with an inner .app has a provisioning profile.

Apple's codesign is able to sign these standalone files, and the app bundle with inner profile.

Any way I can get more info on why this is happening? (adding RUST_BACKTRACE=full doesn't show anything extra info in my case)

Ps: Running on docker debian bullseye + rcodesign 0.17.0 (installed via cargo)

rcodesign corrupts go-made Mach-O binary after singing

rcodesign corrupts binary built with go. I am using release 0.17.0 of rcodesign and go 1.19.

To reproduce:

clone hello world onto a system with GoLang and build it.
https://github.com/go-training/helloworld
Run hello world to confirm it works.

./hello
Hello World!!

Sign the binary

% rcodesign sign --p12-file Certificates.p12 --p12-password mypass --code-signature-flags runtime hello
registering signing key
automatically registered Apple CA certificate: Developer ID Certification Authority
automatically registered Apple CA certificate: Apple Root CA
using time-stamp protocol server http://timestamp.apple.com/ts01
automatically setting team ID from signing certificate: XXXXXX
signing hello in place
signing hello as a Mach-O binary
inferring default signing settings from Mach-O binary
activating SHA-1 digests because minimum OS target 10.9.0 is not >=10.11.4
setting binary identifier to hello
parsing Mach-O
signing Mach-O binary at index 0
attempting to derive code requirements from signing certificate
code requirements: 0: (identifier "hello") and ((anchor apple generic) and ((certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */) and ((certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */) and (certificate leaf[subject.OU] = "XXXXXX"))));
binary targets macOS >= 10.9.0 with SDK 10.9.0
adding code signature flags from signing settings: RUNTIME
using hardened runtime version 10.9.0 derived from SDK version
code directory version: 132352
adding alternative code directory using digest Sha256
binary targets macOS >= 10.9.0 with SDK 10.9.0
adding code signature flags from signing settings: RUNTIME
using hardened runtime version 10.9.0 derived from SDK version
creating cryptographic signature with certificate Developer ID Application: XXXX 
Using time-stamp server http://timestamp.apple.com/ts01
total signature size: 34097 bytes
writing Mach-O to hello

4 Try to run the hello Program

./hello
[1]    4931 killed     ./hello

Using Apple's codesign to verify says it is not signed.

codesign -dvvv hello
hello: code object is not signed at all

Also using rcodesign verify also throws an error

rcodesign verify hello
insecure digest algorithm used in code directory: Sha1
Error: problems reported during verification

`codesign` compatible CLI

Over in #11 there was a suggestion long on my mind: having a CLI interface that is compatible with Apple's codesign tool.

The ultimate goal being someone could drop an alternative codesign binary onto a non-Apple system and get ~identical behavior to the official tooling. This would enable people to port to using this tool with minimal changes to existing scripts.

We could probably teach rcodesign to detect when its filename is codesign or codesign.exe and activate an alternative argument parser so it behaves like codesign. I think clap may even have a mechanism to do this natively now - but I'd have to double check. (It isn't hard to write logic to key off argv[0].) Then simply rename rcodesign to codesign and you get an Apple compatible CLI.

A blocker to doing this is not all features can be implemented today. For example, we don't yet have a parser for the code signing requirements language. We'd need that in order to implement --requirements and --test-requirements. I'm also not too keen on implementing the display functionality from codesign, as this will be a lot of complexity.

I'll definitely accept patches for any work to start implementing the codesign interface. We just need to set expectations that 100% functionality and behavior coverage is likely never achievable.

Remote code signing feature

I'm filing this issue to track design of a feature which I'm calling "remote code signing." The goal is to enable a process on a remote (possibly low-trust) machine to perform code signing using a code signing certificate on a local (high-trust, human operated) machine. The local machine holding the code certificate (possibly in an HSM or hardware key, like a YubiKey) would be able to produce cryptographic signatures from requests initiated in a remote environment. All of this would work with a high degree of confidence (read: using cryptography) that the entity requesting code signatures is authentic and that the possessor of a signing key can't be coerced into signing data from an unknown agent.

I think the primary use case for this feature is in CI environments, where you don't trust or even have control over the CI worker and you want CI to produce artifacts that are digitally signed with a signing certificate that is secure, in your physical possession.

Regarding CI environments, a current common practice is to expose your code signing key as a trusted secret in your CI jobs. I believe this proposal is strictly superior because:

Secrets in CI systems are easily exfiltrated. So a system that keeps the private signing key matter on a local machine is better for the protection of that private key.
It helps prevent unwanted signing. If someone compromises your CI and can trigger jobs, they may be prevented from obtaining signatures because local/manual processes must be employed to produce signatures.
It enables the use of HSMs and other hardware based signing keys from CI. You just can't do this with CI today. If you want to sign with say an EV code signing certificate that must be stored on a hardware device per Microsoft's issuance requirements, your recourse today is to do the build and signing locally, on a machine with physical access to the device holding the signing key.

This feature entails designing your own crypto and I'd very much like to get community feedback on a proposed technical solution before anything is implemented.

I'll use a subsequent comment to describe a potential solution I've thought of.

Implement decryption for macOS keychain keys

We have support for performing cryptographic signing using keys stored in macOS keychains. But we don't have support for decryption (needed for remote signing) because the Rust bindings to SecurityFramework.framework don't appear to have the APIs we need.

We'll likely need to teach the security-framework crate about the missing APIs in order to implement decryption.

As a workaround, you can export private keys from keychain to a PFX/.p12 file. This is probably less secure. But it will unblock using remote code signing with the keys.

signing is trying to sign a storyboard bundle, and is erroring out on the storyboard's info plist file

Log:

[2022-11-04T02:47:05Z WARN  re_sign::util] signing /tmp/i1/Payload/iOSTestApp.app to /var/folders/k1/fyztggjd12x7v_br1g23xxfh0000gn/T/.tmpqPvRzt
[2022-11-04T02:47:05Z WARN  apple_codesign::signing] signing bundle at /tmp/i1/Payload/iOSTestApp.app
[2022-11-04T02:49:11Z WARN  apple_codesign::bundle_signing] signing 2 nested bundles in the following order:
[2022-11-04T02:49:13Z WARN  apple_codesign::bundle_signing] Base.lproj/LaunchScreen.storyboardc
[2022-11-04T02:49:14Z WARN  apple_codesign::bundle_signing] Base.lproj/Main.storyboardc
[2022-11-04T02:52:13Z INFO  apple_codesign::bundle_signing] entering nested bundle /tmp/i1/Payload/iOSTestApp.app/Base.lproj/LaunchScreen.storyboardc
[2022-11-04T02:52:13Z WARN  apple_codesign::bundle_signing] signing bundle at /tmp/i1/Payload/iOSTestApp.app/Base.lproj/LaunchScreen.storyboardc into /var/folders/k1/fyztggjd12x7v_br1g23xxfh0000gn/T/.tmpqPvRzt/Base.lproj/LaunchScreen.storyboardc
Error: bundle Info.plist does not define CFBundleIdentifier: /tmp/i1/Payload/iOSTestApp.app/Base.lproj/LaunchScreen.storyboardc/Info.plist

If you give me a hint on how to fix, I can look at submitting a PR.

Support writing flat packages (`.pkg` installers)

We currently lack support for writing flat packages. This means we can't recursively sign .pkg installers. Nor can we create our own .pkg installers from scratch.

This issue tracks implementing support for writing flat packages / .pkg installers.

Main blocker to this is a working implementation of Apple's Bill of Materials (Bom files) file format. I have a partial implementation of this in an unpublished crate. But as of writing this comment it isn't compatible with Apple's so resulting .pkg are broken.

new release of apple-codesign

still need to [patch.crates-io] due to a dependency conflict that is resolved in master. would be nice to have a new release of apple-codesign so that I can make a new release of xbuild.

[apple-codesign] Error when PackageInfo includes preinstall and postinstall scripts

With a PackageInfo like this:

<?xml version="1.0" encoding="utf-8"?>
<pkg-info overwrite-permissions="true" relocatable="false" identifier="my-app" postinstall-action="none" version="1" format-version="2" generator-version="InstallCmds-807 (21D62)" install-location="/usr/bin/my-app" auth="root">
    <payload numberOfFiles="123" installKBytes="123"/>
    <bundle-version/>
    <upgrade-bundle/>
    <update-bundle/>
    <atomic-update-bundle/>
    <strict-identifier/>
    <relocate/>
    <scripts>
        <preinstall file="./preinstall"/>
        <postinstall file="./postinstall"/>
    </scripts>
</pkg-info>

When trying to notarize the package it throws this error:
Error: Apple flat package error: XML error: Expected token XmlEvent::EndElement { name, .. }, found StartElement(postinstall, {"": "", "xml": "http://www.w3.org/XML/1998/namespace", "xmlns": "http://www.w3.org/2000/xmlns/"}, [file -> ./postinstall])

Slight difference between the _CodeSignature/CodeResources file in the rules section for .lproj localized bundles.

The original from macOS codesign tool produced the output on the left side of the image, the one on the right was from this project.

IPA Signing Support

Per #29, it is apparent that we don't support signing IPAs directly.

We should implement support for signing IPAs.

I've never done iOS/iWatch/etc development and have never used IPAs. So if someone wants to chime in with what they think are a reasonable list of requirements and end-user workflows, please do so!

Support writing DMGs

A current limitation of DMG support in this repo is that we can't read the inner contents of DMGs nor write them.

If we could read and write DMGs, we could produce and sign DMGs outside macOS.

This issue tracks implementing this feature.

Testflight support

Is there any potential for support for uploading to TestFlight?

It is unfortunately not a part of the AppStore connect API as far as I can tell, so the API may have to be reverse engineered....

apple-flat-package doesn't support pbzx payloads

See https://github.com/nrosenstein-stuff/pbzx/blob/master/README.md

replacement for altool --validate-app/--upload-app

started reversing the protocol by setting up mitmproxy as a https proxy. looks like jsonrpc over http2. iTMSTransporter, altool and presumably xcode (I haven't checked this) use the same protocol.

How to sign zip archive ( or make zip correctly )

Hi, I found you project to sign Mac app bundle without Apple hardware and it so cool, thank you for this work.

I have some issues with signing zip that's created from app directory zip -r App.zip App.app .

When I run notarization command:
rcodesign notary-submit --wait --staple --api-key-path ./key.json App.zip

I got next errors:

creating Notary API submission for App.zip (sha256: <redacted>)
created submission ID: <redacted>
resolving AWS S3 configuration from Apple-provided credentials
uploading asset to s3://notary-submissions-prod/prod/<redacted>
(you may see additional log output from S3 client)
S3 upload completed successfully
waiting up to 600s for package upload <redacted> to finish processing
poll state after 0s: InProgress
poll state after 9s: InProgress
poll state after 14s: InProgress
poll state after 19s: InProgress
poll state after 24s: InProgress
poll state after 27s: InProgress
poll state after 33s: InProgress
poll state after 39s: Invalid
Notary API Server has finished processing the uploaded asset
fetching notarization log for <redacted>
notary log> {
notary log>   "archiveFilename": "App.zip",
notary log>   "issues": [
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature of the binary is invalid.",
notary log>       "path": "App.zip/App.app/Contents/MacOS/MainApp",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature does not include a secure timestamp.",
notary log>       "path": "App.zip/App.app/Contents/MacOS/MainApp",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "arm64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature of the binary is invalid.",
notary log>       "path": "App.zip/App.app/Contents/MacOS/MainApp",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "arm64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature does not include a secure timestamp.",
notary log>       "path": "App.zip/App.app/Contents/MacOS/MainApp",
notary log>       "severity": "error"
notary log>     },
..............................................
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature does not include a secure timestamp.",
notary log>       "path": "App.zip/App.app/Contents/Frameworks/libmonobdwgc-2.0.dylib",
notary log>       "severity": "error"
notary log>     },
...........................................
notary log>   ],
notary log>   "jobId": "<redacted>",
notary log>   "logFormatVersion": 1,
notary log>   "sha256": "f7fc8884b02407aaea4d004b84ed47ce11679efabde814d5b443fffbb0edb1f6",
notary log>   "status": "Invalid",
notary log>   "statusCode": 4000,
notary log>   "statusSummary": "Archive contains critical validation errors",
notary log>   "ticketContents": null,
notary log>   "uploadDate": "2022-10-07T08:23:56.917Z"
notary log> }
Error: notarization package is invalid

Maybe I have corrupted zip ?
I found some articles that contains information about zip that create archive with another UTF encoding such as https://marcosc.com/2008/12/zip-files-and-encoding-i-hate-you/

I found that your repository contains apple-flat-package but I don't found how to use this package

Feature request: allow multiple inputs for `rcodesign sign`

#28 tracks the issue where some native node_modules are not detected as files that should be signed, so the workaround is:

Sign bundle: sign Foo.app, then notary-submit
For every file in the error, sign Foo.app/path/to/that/file
Sign the whole bundle again: sign Foo.app

And this works. But when using remote-sign, instead of forming 1 session, there are N+2 times that the session joining string needs to copied. If there are 10 files missed, then that means copying strings 12 times from CI to local.

If multiple inputs are accepted, then I think a single shared connection can be used to sign all of them together?

Of course it's better to improve the detection so a single bundle sign doesn't miss files, but read somewhere that there are a lot of variety and is hard to make sure all are covered.

Multiple inputs can help not just here, but also when there are many apps to sign.

Add support for user/password in apple notarizations

Apple's notary tool supports username/password authentication for notarization, ideally the code signing notarization functionality this library provides would have a level of parity for that.

Never use real signing key for placeholder signatures

Currently, we often use the real signing key to produce a signature of fake data in order to estimate the size of the resulting signature.

This can be annoying because you may need to unlock the signing key on every use.

In theory we don't need to use the actual signing key for performing this simulation. We generally know the size of the resulting signature data based on the key format. We should be able to produce a simulated CMS signature without actually using the signing key.

apple-codesign notarization/stapling times out occasionally while talking to apple servers.

Typical error message:
Error: HTTP error: error sending request for url (AN URL): operation timed out

This just leads rcodesign to give up without even retrying in the middle of the notarization/stapling process.

`rcodesign verify` complains about SHA-1 digests too aggressively

I'm using rcodesign from apple-codesign-0.20.0-x86_64-apple-darwin.tar.gz

$ ./rcodesign verify rcodesign
insecure digest algorithm used in code directory: Sha1
Error: problems reported during verification

Meanwhile executable has both Sha1 and Sha256.

codesign -dvvv rcodesign
Executable=.../rcodesign
Identifier=rcodesign
Format=Mach-O thin (x86_64)
CodeDirectory v=20500 size=159573 flags=0x10000(runtime) hashes=4981+2 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=47332de323d9bed5128aa8b54e2d0e93a0945149
CandidateCDHashFull sha1=47332de323d9bed5128aa8b54e2d0e93a0945149
CandidateCDHash sha256=64b59ac235a217a6f192e294f32bac949a39ff8c
CandidateCDHashFull sha256=64b59ac235a217a6f192e294f32bac949a39ff8cd7f396643d450073681b509a
Hash choices=sha1,sha256
CMSDigest=9af4f134feff5ccd1fe1f3c6741b2b6b6c4eedf39b61b9149ca9fa7eefc019e1
CMSDigestType=2
CDHash=64b59ac235a217a6f192e294f32bac949a39ff8c
Signature size=9123
Authority=Developer ID Application: Gregory Szorc (MK22MZP987)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=2 Oct 2022, 21:45:48
Info.plist=not bound
TeamIdentifier=MK22MZP987
Runtime Version=12.1.0
Sealed Resources=none
Internal requirements count=1 size=172

Seems macho.code_signature() returns ony first signature? My knowledge of rust is subtle.
Probably verify_macho should check both code directories and not complain if one of them is using good enough algorithm (sha256).

PkgReader::component_packages doesn't work as advertized

The PkgReader::component_packages documentation says:

If this is a single component installer, only a single instance will be returned. For product installers, all components are returned.

The PkgReader::root_component documentation says:

This will only return a component of this is a single component installer, not a product installer.

My reading of this is that component_packages would at least return the same ComponentPackageReader as root_component and possibly others. But it doesn't (on a specific pkg I tried it on, it returned an empty Vec, while root_component returned something)

Removing signature/`--force`

There are some problems where re-signing an a binary will lead to a bad signature/unlaunchable app. It would be useful to have an operation that matches codesign's --remove-signature flag. Additionally, a flag --force or --overwrite for sign operations that first removes the signature would be useful when running into these bugs.

Currently I just run codesign --remove-signature before signing, but obviously this removes the benefit of not having to rely on apple tools.

unknown variant `SHA1`, expected one of `none`, `sha1`, `sha256`, `sha512`, `md5`

Hello,

I have a pkg that I created using this manual:
http://bomutils.dyndns.org/tutorial.html

it also includes a file that I already signed using rcodesign.

when I try to sign the pkg file, using the same certificate the I used for the other file, I am getting
Error: XAR error: XML error: custom: unknown variant SHA1, expected one of none, sha1, sha256, sha512, md5

is there a workaround or a fix?

thanks!

Signing a fat binary may result in different binary identifier in csreq

Hello,

When I sign an application bundle containing a single fat binary (x86_64 and arm64) with rcodesign, I end up with a fat binary whose slices have different binary identifier in their csreq:

The x86_64 slice (which comes first) has the correct bundle identifier, derived from the Info.plist
The aarch64 slice (which comes second) has a weird identifier that looks like <filename>-<hash>, which I suspect comes from the ad-hoc signature generated by the linker.

Here's a quick reproducer as a quick-n-dirty bash script:

echo "int main() { return 0; }" > test.c
clang -target x86_64-apple-darwin test.c -o test-x64
clang -target arm64-apple-darwin test.c -o test-arm64
lipo -create -output test test-x64 test-arm64

mkdir -p Test.app/Contents/MacOS
echo -n 'APPL????' > Test.app/Contents/PkgInfo
cp test Test.app/Contents/MacOS/test

cat > Test.app/Contents/Info.plist  << END
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>CFBundleExecutable</key>
	<string>test</string>
	<key>CFBundleIdentifier</key>
	<string>quick.test</string>
	<key>CFBundleInfoDictionaryVersion</key>
	<string>6.0</string>
	<key>CFBundleName</key>
	<string>test</string>
	<key>CFBundlePackageType</key>
	<string>APPL</string>
</dict>
</plist>
END

rcodesign sign Test.app
rcodesign print-signature-info Test.app | grep identifier

The final command has this output:

          identifier: quick.test
          identifier: test-arm64

Whereas I expect the following:

          identifier: quick.test
          identifier: quick.test

Given that's the identifier specified in the Info.plist.

Security audit of remote signing

I have an implementation of remote code signing almost ready to push.

I effectively implemented my own cryptosystem to implement this feature.

As I learned many years ago, one doesn't just roll their own cryptosystems.

So I'm filing this issue to track getting some kind of audit/review of the code so we have confidence in the soundness of the design and implementation.

The executable could not be re-signed for submission to the App Store

Built my app with xbuild which uses apple-codesign internally. Validated/uploaded the app with altool which completed successfully. Shortly after that I received an email from apple with the following contents:

Dear Developer,

We identified one or more issues with a recent delivery for your app, "***" 0.1.0 (0.1.0). Please
correct the following issues, then upload again.

ITMS-90135: The executable could not be re-signed for submission to the App Store. The app may
have been built or signed with non-compliant or pre-release tools.

Best regards,

The App Store Team

rcodesign verify doesn't like executables it has just signed

I'd expect that if I run rcodesign sign exe followed by rcodesign verify exe, then the verification will succeed. However, the tool reports conflicting information — signing seems to succeed, but its verification fails.

To reproduce: (tested on macOS Ventura 13.2)

cargo new --bin hello
cd hello
cargo build --release
rcodesign sign target/release/hello
rcodesign verify target/release/hello

$ rcodesign sign target/release/hello
signing target/release/hello in place
signing target/release/hello as a Mach-O binary
inferring default signing settings from Mach-O binary
preserving existing binary identifier in Mach-O
preserving code signature flags in existing Mach-O signature
setting binary identifier to hello
parsing Mach-O
signing Mach-O binary at index 0
binary targets macOS >= 11.0.0 with SDK 13.1.0
adding code signature flags from signing settings: ADHOC | LINKER_SIGNED
creating ad-hoc signature
removing linker signed flag from code signature (we're not a linker)
code directory version: 132096
total signature size: 3927 bytes
writing Mach-O to target/release/hello
$ rcodesign verify target/release/hello
no cryptographic signature present
Error: problems reported during verification

Even weirder that Apple's codesign does validate it okay:

$ codesign -vv target/release/hello
target/release/hello: valid on disk
target/release/hello: satisfies its Designated Requirement

notarization of Electron app fails due to code signing issues

First of all, I absolutely love what you have done here. I first heard about apple-codesign from HN when you posted it there and thought wow! What an amazing thing but I have no use for it. Little did I know that I'd have to compile, sign, notarize & push Notesnook to Mac App Store.

Unfortunately, the process around this is not simple at all and clearly not cross-platform. After multiple hours of fighting with macOS to get Notesnook signed & notarized properly, I was able to push it to the Mac App Store. The problem however is that I don't have a macOS based hardware. That is how I finally remembered about apple-codesign.

I was able to get the electron-builder to compile the app down to a Notesnook.app bundle. After that running rcodesign sign was also simple enough. No errors so far.

Here's the output from rcodesign sign --p12-file file.p12 --p12-password pwd --code-signature-flags runtime --entitlements-xml-path assets/entitlements.mas.plist:

registering signing key
automatically registered Apple CA certificate: Apple Worldwide Developer Relations Certification Authority
automatically registered Apple CA certificate: Apple Root CA
using time-stamp protocol server http://timestamp.apple.com/ts01
automatically setting team ID from signing certificate: 5**********C
setting entitlments XML for main signing target from path assets/entitlements.mas.plist
signing dist/mas/Notesnook.app in place
signing bundle at dist/mas/Notesnook.app
signing 7 nested bundles in the following order:
Contents/Frameworks/Electron Framework.framework/Versions/A
Contents/Library/LoginItems/Notesnook Login Helper.app
Contents/Frameworks/Notesnook Helper (Renderer).app
Contents/Frameworks/Notesnook Helper (Plugin).app
Contents/Frameworks/Electron Framework.framework
Contents/Frameworks/Notesnook Helper (GPU).app
Contents/Frameworks/Notesnook Helper.app
entering nested bundle dist/mas/Notesnook.app/Contents/Frameworks/Electron Framework.framework/Versions/A
signing bundle at dist/mas/Notesnook.app/Contents/Frameworks/Electron Framework.framework/Versions/A into dist/mas/Notesnook.app/Contents/Frameworks/Electron Framework.framework/Versions/A
found an unversioned framework; signing like normal
main executable targets OS requiring SHA-1 signatures; activating SHA-1 + SHA-256 signing
collecting code resources files
sealing regular file Libraries/libEGL.dylib
sealing regular file Libraries/libGLESv2.dylib
sealing regular file Libraries/libffmpeg.dylib
sealing regular file Libraries/libvk_swiftshader.dylib
sealing regular file Libraries/vk_swiftshader_icd.json
Resources/Info.plist is the Info.plist file; handling specially
sealing regular file Resources/Info.plist
sealing regular file Resources/MainMenu.nib/keyedobjects-101300.nib
sealing regular file Resources/MainMenu.nib/keyedobjects.nib
sealing regular file Resources/af.lproj/locale.pak
sealing regular file Resources/am.lproj/locale.pak
sealing regular file Resources/ar.lproj/locale.pak
sealing regular file Resources/bg.lproj/locale.pak
sealing regular file Resources/bn.lproj/locale.pak
sealing regular file Resources/ca.lproj/locale.pak
sealing regular file Resources/chrome_100_percent.pak
sealing regular file Resources/chrome_200_percent.pak
sealing regular file Resources/cs.lproj/locale.pak
sealing regular file Resources/da.lproj/locale.pak
sealing regular file Resources/de.lproj/locale.pak
sealing regular file Resources/el.lproj/locale.pak
sealing regular file Resources/en.lproj/locale.pak
sealing regular file Resources/en_GB.lproj/locale.pak
sealing regular file Resources/es.lproj/locale.pak
sealing regular file Resources/es_419.lproj/locale.pak
sealing regular file Resources/et.lproj/locale.pak
sealing regular file Resources/fa.lproj/locale.pak
sealing regular file Resources/fi.lproj/locale.pak
sealing regular file Resources/fil.lproj/locale.pak
sealing regular file Resources/fr.lproj/locale.pak
sealing regular file Resources/gu.lproj/locale.pak
sealing regular file Resources/he.lproj/locale.pak
sealing regular file Resources/hi.lproj/locale.pak
sealing regular file Resources/hr.lproj/locale.pak
sealing regular file Resources/hu.lproj/locale.pak
sealing regular file Resources/icudtl.dat
sealing regular file Resources/id.lproj/locale.pak
sealing regular file Resources/it.lproj/locale.pak
sealing regular file Resources/ja.lproj/locale.pak
sealing regular file Resources/kn.lproj/locale.pak
sealing regular file Resources/ko.lproj/locale.pak
sealing regular file Resources/lt.lproj/locale.pak
sealing regular file Resources/lv.lproj/locale.pak
sealing regular file Resources/ml.lproj/locale.pak
sealing regular file Resources/mr.lproj/locale.pak
sealing regular file Resources/ms.lproj/locale.pak
sealing regular file Resources/nb.lproj/locale.pak
sealing regular file Resources/nl.lproj/locale.pak
sealing regular file Resources/pl.lproj/locale.pak
sealing regular file Resources/pt_BR.lproj/locale.pak
sealing regular file Resources/pt_PT.lproj/locale.pak
sealing regular file Resources/resources.pak
sealing regular file Resources/ro.lproj/locale.pak
sealing regular file Resources/ru.lproj/locale.pak
sealing regular file Resources/sk.lproj/locale.pak
sealing regular file Resources/sl.lproj/locale.pak
sealing regular file Resources/sr.lproj/locale.pak
sealing regular file Resources/sv.lproj/locale.pak
sealing regular file Resources/sw.lproj/locale.pak
sealing regular file Resources/ta.lproj/locale.pak
sealing regular file Resources/te.lproj/locale.pak
sealing regular file Resources/th.lproj/locale.pak
sealing regular file Resources/tr.lproj/locale.pak
sealing regular file Resources/uk.lproj/locale.pak
sealing regular file Resources/ur.lproj/locale.pak
sealing regular file Resources/v8_context_snapshot.x86_64.bin
sealing regular file Resources/vi.lproj/locale.pak
sealing regular file Resources/zh_CN.lproj/locale.pak
sealing regular file Resources/zh_TW.lproj/locale.pak
writing sealed resources to dist/mas/Notesnook.app/Contents/Frameworks/Electron Framework.framework/Versions/A/_CodeSignature/CodeResources
signing main executable Electron Framework
inferring default signing settings from Mach-O binary
activating SHA-1 digests because minimum OS target 10.11.0 is not >=10.11.4
setting main executable binary identifier to com.github.Electron.framework (derived from CFBundleIdentifier in Info.plist)
signing Mach-O binary at index 0
attempting to derive code requirements from signing certificate
code requirements: 0: (identifier "com.github.Electron.framework") and ((anchor apple generic) and ((certificate leaf[subject.CN] = "Apple Distribution: Streetwriters (Private) Limited (5**********C)") and (certificate 1[field.1.2.840.113635.100.6.2.1] /* exists */)));
adding entitlements XML
binary targets macOS >= 10.11.0 with SDK 12.3.0
adding code signature flags from signing settings: RUNTIME
using hardened runtime version 12.3.0 derived from SDK version
code directory version: 132352
adding alternative code directory using digest Sha256
binary targets macOS >= 10.11.0 with SDK 12.3.0
adding code signature flags from signing settings: RUNTIME
using hardened runtime version 12.3.0 derived from SDK version
creating cryptographic signature with certificate Apple Distribution: Streetwriters (Private) Limited (5**********C)
Using time-stamp server http://timestamp.apple.com/ts01
total signature size: 1786135 bytes
writing signed main executable to dist/mas/Notesnook.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework
leaving nested bundle dist/mas/Notesnook.app/Contents/Frameworks/Electron Framework.framework/Versions/A
entering nested bundle dist/mas/Notesnook.app/Contents/Library/LoginItems/Notesnook Login Helper.app
signing bundle at dist/mas/Notesnook.app/Contents/Library/LoginItems/Notesnook Login Helper.app into dist/mas/Notesnook.app/Contents/Library/LoginItems/Notesnook Login Helper.app
main executable targets OS requiring SHA-1 signatures; activating SHA-1 + SHA-256 signing
collecting code resources files
Contents/Info.plist is the Info.plist file; handling specially
writing sealed resources to dist/mas/Notesnook.app/Contents/Library/LoginItems/Notesnook Login Helper.app/Contents/_CodeSignature/CodeResources
signing main executable Contents/MacOS/Notesnook Login Helper
inferring default signing settings from Mach-O binary
activating SHA-1 digests because minimum OS target 10.11.0 is not >=10.11.4
setting main executable binary identifier to org.streetwriters.notesnook.loginhelper (derived from CFBundleIdentifier in Info.plist)
signing Mach-O binary at index 0
attempting to derive code requirements from signing certificate
code requirements: 0: (identifier "org.streetwriters.notesnook.loginhelper") and ((anchor apple generic) and ((certificate leaf[subject.CN] = "Apple Distribution: Streetwriters (Private) Limited (5**********C)") and (certificate 1[field.1.2.840.113635.100.6.2.1] /* exists */)));
adding entitlements XML
adding entitlements DER
binary targets macOS >= 10.11.0 with SDK 12.3.0
adding code signature flags from signing settings: RUNTIME
using hardened runtime version 12.3.0 derived from SDK version
code directory version: 132352
adding alternative code directory using digest Sha256
binary targets macOS >= 10.11.0 with SDK 12.3.0
adding code signature flags from signing settings: RUNTIME
using hardened runtime version 12.3.0 derived from SDK version
creating cryptographic signature with certificate Apple Distribution: Streetwriters (Private) Limited (5**********C)
Using time-stamp server http://timestamp.apple.com/ts01
total signature size: 11955 bytes
writing signed main executable to dist/mas/Notesnook.app/Contents/Library/LoginItems/Notesnook Login Helper.app/Contents/MacOS/Notesnook Login Helper
leaving nested bundle dist/mas/Notesnook.app/Contents/Library/LoginItems/Notesnook Login Helper.app
entering nested bundle dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper (Renderer).app
signing bundle at dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper (Renderer).app into dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper (Renderer).app
main executable targets OS requiring SHA-1 signatures; activating SHA-1 + SHA-256 signing
collecting code resources files
Contents/Info.plist is the Info.plist file; handling specially
writing sealed resources to dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper (Renderer).app/Contents/_CodeSignature/CodeResources
signing main executable Contents/MacOS/Notesnook Helper (Renderer)
inferring default signing settings from Mach-O binary
activating SHA-1 digests because minimum OS target 10.11.0 is not >=10.11.4
setting main executable binary identifier to org.streetwriters.notesnook.helper.Renderer (derived from CFBundleIdentifier in Info.plist)
signing Mach-O binary at index 0
attempting to derive code requirements from signing certificate
code requirements: 0: (identifier "org.streetwriters.notesnook.helper.Renderer") and ((anchor apple generic) and ((certificate leaf[subject.CN] = "Apple Distribution: Streetwriters (Private) Limited (5**********C)") and (certificate 1[field.1.2.840.113635.100.6.2.1] /* exists */)));
adding entitlements XML
adding entitlements DER
binary targets macOS >= 10.11.0 with SDK 12.3.0
adding code signature flags from signing settings: RUNTIME
using hardened runtime version 12.3.0 derived from SDK version
code directory version: 132352
adding alternative code directory using digest Sha256
binary targets macOS >= 10.11.0 with SDK 12.3.0
adding code signature flags from signing settings: RUNTIME
using hardened runtime version 12.3.0 derived from SDK version
creating cryptographic signature with certificate Apple Distribution: Streetwriters (Private) Limited (5**********C)
Using time-stamp server http://timestamp.apple.com/ts01
total signature size: 11966 bytes
writing signed main executable to dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper (Renderer).app/Contents/MacOS/Notesnook Helper (Renderer)
leaving nested bundle dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper (Renderer).app
entering nested bundle dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper (Plugin).app
signing bundle at dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper (Plugin).app into dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper (Plugin).app
main executable targets OS requiring SHA-1 signatures; activating SHA-1 + SHA-256 signing
collecting code resources files
Contents/Info.plist is the Info.plist file; handling specially
writing sealed resources to dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper (Plugin).app/Contents/_CodeSignature/CodeResources
signing main executable Contents/MacOS/Notesnook Helper (Plugin)
inferring default signing settings from Mach-O binary
activating SHA-1 digests because minimum OS target 10.11.0 is not >=10.11.4
setting main executable binary identifier to org.streetwriters.notesnook.helper.Plugin (derived from CFBundleIdentifier in Info.plist)
signing Mach-O binary at index 0
attempting to derive code requirements from signing certificate
code requirements: 0: (identifier "org.streetwriters.notesnook.helper.Plugin") and ((anchor apple generic) and ((certificate leaf[subject.CN] = "Apple Distribution: Streetwriters (Private) Limited (5**********C)") and (certificate 1[field.1.2.840.113635.100.6.2.1] /* exists */)));
adding entitlements XML
adding entitlements DER
binary targets macOS >= 10.11.0 with SDK 12.3.0
adding code signature flags from signing settings: RUNTIME
using hardened runtime version 12.3.0 derived from SDK version
code directory version: 132352
adding alternative code directory using digest Sha256
binary targets macOS >= 10.11.0 with SDK 12.3.0
adding code signature flags from signing settings: RUNTIME
using hardened runtime version 12.3.0 derived from SDK version
creating cryptographic signature with certificate Apple Distribution: Streetwriters (Private) Limited (5**********C)
Using time-stamp server http://timestamp.apple.com/ts01
total signature size: 11962 bytes
writing signed main executable to dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper (Plugin).app/Contents/MacOS/Notesnook Helper (Plugin)
leaving nested bundle dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper (Plugin).app
entering nested bundle dist/mas/Notesnook.app/Contents/Frameworks/Electron Framework.framework
signing bundle at dist/mas/Notesnook.app/Contents/Frameworks/Electron Framework.framework into dist/mas/Notesnook.app/Contents/Frameworks/Electron Framework.framework
found a versioned framework; each version will be signed as its own bundle
leaving nested bundle dist/mas/Notesnook.app/Contents/Frameworks/Electron Framework.framework
entering nested bundle dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper (GPU).app
signing bundle at dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper (GPU).app into dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper (GPU).app
main executable targets OS requiring SHA-1 signatures; activating SHA-1 + SHA-256 signing
collecting code resources files
Contents/Info.plist is the Info.plist file; handling specially
writing sealed resources to dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper (GPU).app/Contents/_CodeSignature/CodeResources
signing main executable Contents/MacOS/Notesnook Helper (GPU)
inferring default signing settings from Mach-O binary
activating SHA-1 digests because minimum OS target 10.11.0 is not >=10.11.4
setting main executable binary identifier to org.streetwriters.notesnook.helper.GPU (derived from CFBundleIdentifier in Info.plist)
signing Mach-O binary at index 0
attempting to derive code requirements from signing certificate
code requirements: 0: (identifier "org.streetwriters.notesnook.helper.GPU") and ((anchor apple generic) and ((certificate leaf[subject.CN] = "Apple Distribution: Streetwriters (Private) Limited (5**********C)") and (certificate 1[field.1.2.840.113635.100.6.2.1] /* exists */)));
adding entitlements XML
adding entitlements DER
binary targets macOS >= 10.11.0 with SDK 12.3.0
adding code signature flags from signing settings: RUNTIME
using hardened runtime version 12.3.0 derived from SDK version
code directory version: 132352
adding alternative code directory using digest Sha256
binary targets macOS >= 10.11.0 with SDK 12.3.0
adding code signature flags from signing settings: RUNTIME
using hardened runtime version 12.3.0 derived from SDK version
creating cryptographic signature with certificate Apple Distribution: Streetwriters (Private) Limited (5**********C)
Using time-stamp server http://timestamp.apple.com/ts01
total signature size: 11953 bytes
writing signed main executable to dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper (GPU).app/Contents/MacOS/Notesnook Helper (GPU)
leaving nested bundle dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper (GPU).app
entering nested bundle dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper.app
signing bundle at dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper.app into dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper.app
main executable targets OS requiring SHA-1 signatures; activating SHA-1 + SHA-256 signing
collecting code resources files
Contents/Info.plist is the Info.plist file; handling specially
writing sealed resources to dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper.app/Contents/_CodeSignature/CodeResources
signing main executable Contents/MacOS/Notesnook Helper
inferring default signing settings from Mach-O binary
activating SHA-1 digests because minimum OS target 10.11.0 is not >=10.11.4
setting main executable binary identifier to org.streetwriters.notesnook.helper (derived from CFBundleIdentifier in Info.plist)
signing Mach-O binary at index 0
attempting to derive code requirements from signing certificate
code requirements: 0: (identifier "org.streetwriters.notesnook.helper") and ((anchor apple generic) and ((certificate leaf[subject.CN] = "Apple Distribution: Streetwriters (Private) Limited (5**********C)") and (certificate 1[field.1.2.840.113635.100.6.2.1] /* exists */)));
adding entitlements XML
adding entitlements DER
binary targets macOS >= 10.11.0 with SDK 12.3.0
adding code signature flags from signing settings: RUNTIME
using hardened runtime version 12.3.0 derived from SDK version
code directory version: 132352
adding alternative code directory using digest Sha256
binary targets macOS >= 10.11.0 with SDK 12.3.0
adding code signature flags from signing settings: RUNTIME
using hardened runtime version 12.3.0 derived from SDK version
creating cryptographic signature with certificate Apple Distribution: Streetwriters (Private) Limited (5**********C)
Using time-stamp server http://timestamp.apple.com/ts01
total signature size: 11940 bytes
writing signed main executable to dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper.app/Contents/MacOS/Notesnook Helper
leaving nested bundle dist/mas/Notesnook.app/Contents/Frameworks/Notesnook Helper.app
signing bundle at dist/mas/Notesnook.app into dist/mas/Notesnook.app
main executable targets OS requiring SHA-1 signatures; activating SHA-1 + SHA-256 signing
collecting code resources files
Contents/Info.plist is the Info.plist file; handling specially
sealing regular file Resources/app.asar
sealing regular file Resources/assets/entitlements.mac.plist
sealing regular file Resources/assets/entitlements.mas.inherit.plist
sealing regular file Resources/assets/entitlements.mas.loginhelper.plist
sealing regular file Resources/assets/entitlements.mas.plist
sealing regular file Resources/assets/icons/1024x1024.png
sealing regular file Resources/assets/icons/128x128.png
sealing regular file Resources/assets/icons/16x16.png
sealing regular file Resources/assets/icons/24x24.png
sealing regular file Resources/assets/icons/256x256.png
sealing regular file Resources/assets/icons/32x32.png
sealing regular file Resources/assets/icons/48x48.png
sealing regular file Resources/assets/icons/512x512.png
sealing regular file Resources/assets/icons/64x64.png
sealing regular file Resources/assets/icons/app.icns
sealing regular file Resources/assets/icons/app.ico
sealing regular file Resources/icon.icns
sealing nested bundle at Frameworks/Electron Framework.framework
sealing nested bundle at Frameworks/Notesnook Helper (GPU).app
sealing nested bundle at Frameworks/Notesnook Helper (Plugin).app
sealing nested bundle at Frameworks/Notesnook Helper (Renderer).app
sealing nested bundle at Frameworks/Notesnook Helper.app
sealing nested bundle at Library/LoginItems/Notesnook Login Helper.app
writing sealed resources to dist/mas/Notesnook.app/Contents/_CodeSignature/CodeResources
signing main executable Contents/MacOS/Notesnook
inferring default signing settings from Mach-O binary
activating SHA-1 digests because minimum OS target 10.11.0 is not >=10.11.4
setting main executable binary identifier to org.streetwriters.notesnook (derived from CFBundleIdentifier in Info.plist)
signing Mach-O binary at index 0
attempting to derive code requirements from signing certificate
code requirements: 0: (identifier "org.streetwriters.notesnook") and ((anchor apple generic) and ((certificate leaf[subject.CN] = "Apple Distribution: Streetwriters (Private) Limited (5**********C)") and (certificate 1[field.1.2.840.113635.100.6.2.1] /* exists */)));
adding entitlements XML
adding entitlements DER
binary targets macOS >= 10.11.0 with SDK 12.3.0
adding code signature flags from signing settings: RUNTIME
using hardened runtime version 12.3.0 derived from SDK version
code directory version: 132352
adding alternative code directory using digest Sha256
binary targets macOS >= 10.11.0 with SDK 12.3.0
adding code signature flags from signing settings: RUNTIME
using hardened runtime version 12.3.0 derived from SDK version
creating cryptographic signature with certificate Apple Distribution: Streetwriters (Private) Limited (5**********C)
Using time-stamp server http://timestamp.apple.com/ts01
total signature size: 11918 bytes
writing signed main executable to dist/mas/Notesnook.app/Contents/MacOS/Notesnook

As you can see nothing looks out of ordinary. The nested bundles get signed and so does the main app. The problem? Well, it looks like the Apple Notarization Server doesn't like the signatures.

Here's the output from rcodesign notary-submit --api-key-path appstoreconnect.key.json --wait dist/mas/Notesnook.app:

created submission ID: 3b5ac5b8-5543-4011-ad73-f0602dcdd68f
resolving AWS S3 configuration from Apple-provided credentials
uploading asset to s3://notary-submissions-prod/prod/AROARQRX7CZS3PRF6ZA5L:3b5ac5b8-5543-4011-ad73-f0602dcdd68f
(you may see additional log output from S3 client)
send_operation;
send_operation; operation="PutObject"
send_operation; service="s3"
send_operation; status="ok"
S3 upload completed successfully
waiting up to 600s for package upload 3b5ac5b8-5543-4011-ad73-f0602dcdd68f to finish processing
poll state after 1s: InProgress
poll state after 6s: InProgress
poll state after 11s: InProgress
poll state after 16s: InProgress
poll state after 21s: InProgress
poll state after 26s: InProgress
poll state after 30s: Invalid
Notary API Server has finished processing the uploaded asset
fetching notarization log for 3b5ac5b8-5543-4011-ad73-f0602dcdd68f
notary log> {
notary log>   "archiveFilename": "Notesnook.app.zip",
notary log>   "issues": [
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature of the binary is invalid.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/MacOS/Notesnook",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature does not include a secure timestamp.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/MacOS/Notesnook",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature of the binary is invalid.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/Library/LoginItems/Notesnook Login Helper.app/Contents/MacOS/Notesnook Login Helper",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature does not include a secure timestamp.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/Library/LoginItems/Notesnook Login Helper.app/Contents/MacOS/Notesnook Login Helper",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature of the binary is invalid.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature does not include a secure timestamp.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Electron Framework",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The binary is not signed.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libEGL.dylib",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature does not include a secure timestamp.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libEGL.dylib",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The binary is not signed.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libvk_swiftshader.dylib",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature does not include a secure timestamp.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libvk_swiftshader.dylib",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The binary is not signed.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libGLESv2.dylib",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature does not include a secure timestamp.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libGLESv2.dylib",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The binary is not signed.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libffmpeg.dylib",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature does not include a secure timestamp.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libffmpeg.dylib",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature of the binary is invalid.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/Frameworks/Notesnook Helper (Renderer).app/Contents/MacOS/Notesnook Helper (Renderer)",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature does not include a secure timestamp.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/Frameworks/Notesnook Helper (Renderer).app/Contents/MacOS/Notesnook Helper (Renderer)",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature of the binary is invalid.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/Frameworks/Notesnook Helper (GPU).app/Contents/MacOS/Notesnook Helper (GPU)",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature does not include a secure timestamp.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/Frameworks/Notesnook Helper (GPU).app/Contents/MacOS/Notesnook Helper (GPU)",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature of the binary is invalid.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/Frameworks/Notesnook Helper.app/Contents/MacOS/Notesnook Helper",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature does not include a secure timestamp.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/Frameworks/Notesnook Helper.app/Contents/MacOS/Notesnook Helper",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature of the binary is invalid.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/Frameworks/Notesnook Helper (Plugin).app/Contents/MacOS/Notesnook Helper (Plugin)",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": null,
notary log>       "message": "The signature does not include a secure timestamp.",
notary log>       "path": "Notesnook.app.zip/Notesnook.app/Contents/Frameworks/Notesnook Helper (Plugin).app/Contents/MacOS/Notesnook Helper (Plugin)",
notary log>       "severity": "error"
notary log>     }
notary log>   ],
notary log>   "jobId": "3b5ac5b8-5543-4011-ad73-f0602dcdd68f",
notary log>   "logFormatVersion": 1,
notary log>   "sha256": "4570c67c061892beee89bd812d72d3220a9595bd863232e230f524f8cc9b0aee",
notary log>   "status": "Invalid",
notary log>   "statusCode": 4000,
notary log>   "statusSummary": "Archive contains critical validation errors",
notary log>   "ticketContents": null,
notary log>   "uploadDate": "2022-09-25T16:50:03.680Z"
notary log> }
Error: notarization package is invalid

Any help would be appreciated. I am using a combined cert file exported from Keychain Access that contains Developer & Distribution certificates. This is also the file being used by @electron/osx-sign so I can confirm that it works.

Feature request: implement a digest caching layer instead of reading entire file into memory for the CodeResources.

It appears that the CodeResources logic is reading the entire file into memory then calling the appropriate digest. This will be very memory intensive for large applications with lots of resources.

One should just take a path to the file and compute and store the cached checksum vectors into the cache. In my implementation, I am computing both the SHA-1 and SHA-256 simultaneously, and I also copy the file into the target directory if needed, so I only read the file once.

Maybe hold off on implementing this. I will try to get clearance from my employer to submit my changes back to the project.

`rcodesign generate-certificate-signing-request` fails with error message "no private keys found"

https://gregoryszorc.com/docs/apple-codesign/main/apple_codesign_certificate_management.html mentions these instructions:

openssl genrsa -out private.pem 2048
rcodesign generate-certificate-signing-request --pem-source private.pem

But this fails with this output:

$ openssl genrsa -out private.pem 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
............+++++
..............+++++
e is 65537 (0x010001)

$ rcodesign generate-certificate-signing-request --pem-source private.pem 
reading PEM data from private.pem
(unhandled PEM tag RSA PRIVATE KEY; ignoring)
no private keys found; a private key is required to sign a certificate signing request
Error: bad argument

Does apple-xar need the dependency on reqwest?

Argument or environment variable for providing smartcard PIN

Currently, smartcard operations require the PIN to be provided by interactive keyboard input. This is fine for situations such as codesigning on a laptop or desktop, but makes signing with an HSM connected to a CI/CD worker quite difficult (if not impossible).

I propose a new command-line argument or environment variable that specifies the device PIN, so that it can be specified by the CI configuration how other secrets are specified.

macOS signs and notarizes without issue, Linux fails notarization.

Hi @indygreg, great work you've done on this.

I seem to have hit an odd issue when building gecko-dev and trying to notarize on Linux. It may hold clues to issues experienced in #28 and #35.

The toolchain used for building Gecko on both macOS and Linux is LLVM 14 directly from Mozilla (XCode is NOT used on macOS).

rcodesign 0.22.0 is used on both platforms, and identical commands are run.

Linux host, build targeting macOS, notarization fails.
Linux host, build made on macOS and moved to Linux host, notarization fails.
macOS host, build made on Linux and moved to macOS host, notarization fails.
macOS host, build targeting macOS, notarization succeeds.

You would expect the macOS built .app that signs and notarizes okay on macOS to also sign and notarize without issue on Linux, but it doesn't.

You would also expect the Linux built .app to notarize without issue on macOS, but it doesn't.

The script for signing and notarizing:

#!/bin/bash
#
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at https://mozilla.org/MPL/2.0/.
#

set -x

usage ()
{
  echo  "Usage: $0 "
  echo  "    -a <PATH-TO-BROWSER.app>"
  echo  "    -i <IDENTITY>"
  echo  "    -s <SECRET>"
  echo  "    -b <ENTITLEMENTS-FILE>"
  echo  "    -p <CHILD-ENTITLEMENTS-FILE>"
  exit 255
}

while getopts "a:i:s:b:p:" opt; do
  case ${opt} in
    a ) BUNDLE=$OPTARG ;;
    i ) IDENTITY=$OPTARG ;;
    s ) SECRET=$OPTARG ;;
    b ) BROWSER_ENTITLEMENTS_FILE=$OPTARG ;;
    p ) PLUGINCONTAINER_ENTITLEMENTS_FILE=$OPTARG ;;
    \? ) usage; exit 255 ;;
  esac
done

rcodesign sign --p12-file "$IDENTITY" --p12-password "$SECRET" --code-signature-flags runtime --team-name <RETRACTED> \
"${BUNDLE}/Contents/MacOS/XUL"

find "${BUNDLE}"/Contents/MacOS -name '*.dylib' -exec \
rcodesign sign --p12-file "$IDENTITY" --p12-password "$SECRET" --code-signature-flags runtime --team-name <RETRACTED> {} \;

rcodesign sign --p12-file "$IDENTITY" --p12-password "$SECRET" --code-signature-flags runtime --team-name <RETRACTED> \
"${BUNDLE}"/Contents/MacOS/updater.app

rcodesign sign --p12-file "$IDENTITY" --p12-password "$SECRET" --code-signature-flags runtime --team-name <RETRACTED> \
-e "${BROWSER_ENTITLEMENTS_FILE}" \
"${BUNDLE}"/Contents/MacOS/waterfox-bin

rcodesign sign --p12-file "$IDENTITY" --p12-password "$SECRET" --code-signature-flags runtime --team-name <RETRACTED> \
-e "${BROWSER_ENTITLEMENTS_FILE}" \
"${BUNDLE}"/Contents/MacOS/waterfox

rcodesign sign --p12-file "$IDENTITY" --p12-password "$SECRET" --code-signature-flags runtime --team-name <RETRACTED> \
-e "${BROWSER_ENTITLEMENTS_FILE}" \
"${BUNDLE}"/Contents/Library/LaunchServices/net.waterfox.updater

find "${BUNDLE}"/Contents/Resources/gmp-clearkey -type f -exec \
rcodesign sign --p12-file "$IDENTITY" --p12-password "$SECRET" --code-signature-flags runtime --team-name <RETRACTED> {} \;

rcodesign sign --p12-file "$IDENTITY" --p12-password "$SECRET" --code-signature-flags runtime --team-name <RETRACTED> \
-e "${BROWSER_ENTITLEMENTS_FILE}" "${BUNDLE}"

rcodesign sign --p12-file "$IDENTITY" --p12-password "$SECRET" --code-signature-flags runtime --team-name <RETRACTED> \
-e "${PLUGINCONTAINER_ENTITLEMENTS_FILE}" --exclude '**' \
"${BUNDLE}"/Contents/MacOS/plugin-container.app

# Notarise and staple the main bundle
rcodesign notary-submit \
  --api-key-path ./key.json \
  --staple \
  "${BUNDLE}"

Linux host, Linux built (FAIL).

notary log> {
notary log>   "archiveFilename": "Waterfox.app.zip",
notary log>   "issues": [
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087735",
notary log>       "message": "The signature of the binary is invalid.",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/waterfox",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087735",
notary log>       "message": "The signature of the binary is invalid.",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/updater.app/Contents/MacOS/net.waterfox.updater",
notary log>       "severity": "error"
notary log>     }
notary log>   ],
notary log>   "jobId": "9f311b7a-e5af-42f9-812c-27863042da6f",
notary log>   "logFormatVersion": 1,
notary log>   "sha256": "b83799b4a80573a7b3f47962f0b08f625500d64bbbf683492cd3bb60eb8be91b",
notary log>   "status": "Invalid",
notary log>   "statusCode": 4000,
notary log>   "statusSummary": "Archive contains critical validation errors",
notary log>   "ticketContents": null,
notary log>   "uploadDate": "2023-01-17T10:27:12.480Z"
notary log> }
Error: notarization invalid

Linux host, macOS built (FAIL).

notary log> {
notary log>   "archiveFilename": "Waterfox.app.zip",
notary log>   "issues": [
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087735",
notary log>       "message": "The signature of the binary is invalid.",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/waterfox",
notary log>       "severity": "error"
notary log>     },
notary log>     {
notary log>       "architecture": "x86_64",
notary log>       "code": null,
notary log>       "docUrl": "https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues#3087735",
notary log>       "message": "The signature of the binary is invalid.",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/updater.app/Contents/MacOS/com.waterfox.updater",
notary log>       "severity": "error"
notary log>     }
notary log>   ],
notary log>   "jobId": "c431a7ed-cf6c-4903-b183-d116f042f13f",
notary log>   "logFormatVersion": 1,
notary log>   "sha256": "bd7b87c2f5264dcd793847fbd5b07a731471068e31ecc2790575435b17a65115",
notary log>   "status": "Invalid",
notary log>   "statusCode": 4000,
notary log>   "statusSummary": "Archive contains critical validation errors",
notary log>   "ticketContents": null,
notary log>   "uploadDate": "2023-01-17T11:15:08.459Z"
notary log> }
Error: notarization invalid

macOS host, macOS built (SUCCESS):

notary log> {
notary log>   "archiveFilename": "Waterfox.app.zip",
notary log>   "issues": null,
notary log>   "jobId": "4a24235f-3cf4-4f10-a153-042b8bbe21f7",
notary log>   "logFormatVersion": 1,
notary log>   "sha256": "5191159260e1a240faf0fb786885b3f42fed32ea6bf30a601af5c881e7fbca0f",
notary log>   "status": "Accepted",
notary log>   "statusCode": 0,
notary log>   "statusSummary": "Ready for distribution",
notary log>   "ticketContents": [
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "5afefd05c4d7461f04b49cc4c572ce20dee7ca25",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/libmozavutil.dylib"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "44ee61204c8a21f84a6f9b8a0a9277a13a62acf1",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "aa1a48fd9c0dc7540e27d35100d43914a48b6f5e",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/libsoftokn3.dylib"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "010791805858be49bd2588e4b460c30357b622f9",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/libipcclientcerts.dylib"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "48bfb73b9eeb61dce88982953018551c72dafbe4",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/libfreebl3.dylib"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "4b33f87453c0a41aef399fc0301cb98598a9421f",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/libosclientcerts.dylib"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "231e6da005898ebe147c6a2d96652af2722c951e",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/libnss3.dylib"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "d0025599b475ce55bfe7cb9f2abc2f9f2cbcc6a2",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/waterfox-bin"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "c4d9bd9033a50c40a2a8054465e63c7c064447fd",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/liblgpllibs.dylib"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "2a12cfb718d4173f5179f379c920e7e82c656d70",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/XUL"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "eec1036b7d585b11a73e12fc94303cb27dc74939",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/plugin-container.app"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "4082ed5343a9b4d36f8492b06a8ad7980b18cf8a",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/libmozglue.dylib"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "73bd10aa9f424f559e4ff45f857e8f6be9816e98",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/libmozavcodec.dylib"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "a10a22e78278272f2b6ec1fece40dbf43ff2ba39",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/libnssckbi.dylib"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "48bfb73b9eeb61dce88982953018551c72dafbe4",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/libfreebl3.dylib"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "c4d9bd9033a50c40a2a8054465e63c7c064447fd",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/liblgpllibs.dylib"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "aa1a48fd9c0dc7540e27d35100d43914a48b6f5e",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/libsoftokn3.dylib"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "2a12cfb718d4173f5179f379c920e7e82c656d70",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/XUL"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "4b33f87453c0a41aef399fc0301cb98598a9421f",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/libosclientcerts.dylib"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "5afefd05c4d7461f04b49cc4c572ce20dee7ca25",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/libmozavutil.dylib"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "4082ed5343a9b4d36f8492b06a8ad7980b18cf8a",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/libmozglue.dylib"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "010791805858be49bd2588e4b460c30357b622f9",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/libipcclientcerts.dylib"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "73bd10aa9f424f559e4ff45f857e8f6be9816e98",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/libmozavcodec.dylib"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "44ee61204c8a21f84a6f9b8a0a9277a13a62acf1",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/waterfox"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "d0025599b475ce55bfe7cb9f2abc2f9f2cbcc6a2",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/waterfox-bin"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "a10a22e78278272f2b6ec1fece40dbf43ff2ba39",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/libnssckbi.dylib"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "231e6da005898ebe147c6a2d96652af2722c951e",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/libnss3.dylib"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "eec1036b7d585b11a73e12fc94303cb27dc74939",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/plugin-container.app"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "eec1036b7d585b11a73e12fc94303cb27dc74939",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/MacOS/plugin-container.app/Contents/MacOS/plugin-container"
notary log>     },
notary log>     {
notary log>       "arch": "arm64",
notary log>       "cdhash": "5c949e72d5befb9e3b2af0a084aff0eaafb89a82",
notary log>       "digestAlgorithm": "SHA-256",
notary log>       "path": "Waterfox.app.zip/Waterfox.app/Contents/Resources/gmp-clearkey/0.1/libclearkey.dylib"
notary log>     }
notary log>   ],
notary log>   "uploadDate": "2023-01-17T11:38:40.018Z"
notary log> }

[apple-codesign] Error: binary parsing error: Invalid magic number: on Linux

I'm testing apple-codesign on Linux, and encountered this error immediately:

Error: binary parsing error: Invalid magic number: 0x504b0304

I have an app bundle which contains Java application with JRE, native launcher and a bunch of jar files. So, I run the command:

rcodesign sign --pem-source  ~/path/to/self-signed-cert.pem -vv   sipmlejavaFX.app/

Relevant log output:

[2022-07-28T10:44:17Z WARN  rcodesign] reading PEM data from /[removed]/self-signed-cert.pem
[2022-07-28T10:44:17Z WARN  rcodesign] registering signing key
[2022-07-28T10:44:17Z WARN  rcodesign] using time-stamp protocol server http://timestamp.apple.com/ts01
[2022-07-28T10:44:17Z WARN  rcodesign] automatically setting team ID from signing certificate: unset
[2022-07-28T10:44:17Z WARN  rcodesign] signing siplejavaFX.app/ to simplejavafx.app/
[2022-07-28T10:44:17Z WARN  rcodesign::signing] signing bundle at siplejavaFX.app/
[2022-07-28T10:44:17Z WARN  rcodesign::bundle_signing] signing 0 nested bundles in the following order:
[2022-07-28T10:44:17Z WARN  rcodesign::bundle_signing] signing bundle at siplejavaFX.app/ into simplejavafx.app/
[2022-07-28T10:44:17Z DEBUG goblin::mach] Ctx: Ctx { container: Big, le: Little }
[2022-07-28T10:44:17Z DEBUG goblin::mach] Mach-o header: Header { magic: 0xfeedfacf, cputype: 16777223, cpusubtype: 0x3, filetype: "EXECUTE", ncmds: 11, sizeofcmds: 2360, flags: 0x0, reserved: 0x0 }
....................
[2022-07-28T10:44:17Z INFO  rcodesign::bundle_signing] main executable targets OS requiring SHA-1 signatures; activating SHA-1 + SHA-256 signing
[2022-07-28T10:44:17Z WARN  rcodesign::bundle_signing] collecting code resources files
[2022-07-28T10:44:17Z INFO  rcodesign::bundle_signing] Contents/Info.plist is the Info.plist file; handling specially
[2022-07-28T10:44:17Z DEBUG rcodesign::code_resources] Info.plist matches exclusion rule ^Info\.plist$
[2022-07-28T10:44:17Z INFO  rcodesign::bundle_signing] copying file siplejavaFX.app/Contents/Info.plist -> simplejavafx.app/Contents/Info.plist
[2022-07-28T10:44:17Z DEBUG rcodesign::code_resources] Info.plist doesn't match any rule
[2022-07-28T10:44:17Z DEBUG rcodesign::code_resources] MacOS/cp/045700bcabd5441a50964944f38babbee8fc2e8159179b8cb5e64d18274e3853.jar matches inclusion rule ^(Frameworks|SharedFrameworks|PlugIns|Plug-ins|XPCServices|Helpers|MacOS|Library/(Automator|Spotlight|LoginItems))/
[2022-07-28T10:44:17Z INFO  rcodesign::code_resources] sealing Mach-O file MacOS/cp/045700bcabd5441a50964944f38babbee8fc2e8159179b8cb5e64d18274e3853.jar
[2022-07-28T10:44:17Z INFO  rcodesign::bundle_signing] signing Mach-O file Contents/MacOS/cp/045700bcabd5441a50964944f38babbee8fc2e8159179b8cb5e64d18274e3853.jar
Error: binary parsing error: Invalid magic number: 0x504b0304

So, it seems rcodesign is trying to sign a jar file and fails with this magic number error. Running hexdump on that jar gives the following output:

0000000 4b50 0403 000a 0800 0008 a916 5350 0000
0000010 0000 0002 0000 0000 0000 0009 0000 454d
0000020 4154 492d 464e 032f 5000 034b 0a04 0000
0000030 0808 1600 50a9 e253 fb21 4469 0000 4200
0000040 0000 1400 0000 4d00 5445 2d41 4e49 2f46
0000050 414d 494e 4546 5453 4d2e f346 cc4d 4ccb
0000060 2d4b d12e 4b0d 2a2d ccce b3cf 3052 33d4
0000070 e5e0 2c72 c92d 4dcf c92c d64c cdf5 294f
0000080 49cd f5d5 cc4b b54d c852 2c4a 4c4b d0ab
0000090 4a4b 4e2c cd75 282d e4a9 e2e5 02e5 5000
00000a0 014b 1402 0a03 0000 0808 1600 50a9 0053
00000b0 0000 0200 0000 0000 0000 0900 0000 0000
00000c0 0000 0000 1000 ed00 0041 0000 4d00 5445
00000d0 2d41 4e49 2f46 4b50 0201 0314 000a 0800
00000e0 0008 a916 5350 21e2 69fb 0044 0000 0042
00000f0 0000 0014 0000 0000 0000 0000 0000 81a4
0000100 0029 0000 454d 4154 492d 464e 4d2f 4e41
0000110 4649 5345 2e54 464d 4b50 0605 0000 0000
0000120 0002 0002 0079 0000 009f 0000 0000     
000012e

The first two bytes look like they are in inverted order to what is reported by rcodesign. So, is it possible that this is some kind of endian-ness problem?
Any idea of what might be the problem?

In addition, when I try to sign only the native launcher, I get the following error:

RUST_BACKTRACE=1 rcodesign sign --pem-source ~/local/work/bitshift/xapps/self-signed-cert.pem --code-signature-flags runtime  simplejavafx 
reading PEM data from /home/vlada/local/work/bitshift/xapps/self-signed-cert.pem
registering signing key
using time-stamp protocol server http://timestamp.apple.com/ts01
automatically setting team ID from signing certificate: unset
signing simplejavafx in place
signing simplejavafx as a Mach-O binary
inferring default signing settings from Mach-O binary
activating SHA-1 digests because minimum OS target 10.9.0 is not >=10.11.4
setting binary identifier to simplejavafx
parsing Mach-O
signing Mach-O binary at index 0
thread 'main' panicked at 'assertion failed: segment.fileoff == 0 || segment.fileoff == cursor.position()', /home/vlada/.cargo/registry/src/github.com-1ecc6299db9ec823/apple-codesign-0.16.0/src/macho_signing.rs:166:9
stack backtrace:
   0: rust_begin_unwind
             at /build/rustc-60tkWq/rustc-1.59.0+dfsg1/library/std/src/panicking.rs:498:5
   1: core::panicking::panic_fmt
             at /build/rustc-60tkWq/rustc-1.59.0+dfsg1/library/core/src/panicking.rs:116:14
   2: core::panicking::panic
             at /build/rustc-60tkWq/rustc-1.59.0+dfsg1/library/core/src/panicking.rs:48:5
   3: rcodesign::macho_signing::create_macho_with_signature
   4: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::try_fold
   5: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
   6: core::iter::adapters::process_results
   7: rcodesign::macho_signing::MachOSigner::write_signed_binary
   8: rcodesign::signing::UnifiedSigner::sign_path_in_place
   9: rcodesign::command_sign
  10: rcodesign::main_impl
  11: rcodesign::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Not sure if the two problems are connected.

rcodesign does not work with go-made binaries that use cgo; getting __LINKEDIT isn't final Mach-O segment

rcodesign does not work on binaries, built with go, that use cgo.

To reproduce:

clone this simple cgo example and on macos, do GOOS=darwin GOARCH=arm64 go build

https://github.com/igor-hnizdo/cgo-example

get the binary from here

https://github.com/igor-hnizdo/cgo-example/releases/tag/v1

rcodesign sign --p12-file <file> --p12-password-file <password> --code-signature-flags runtime cgo-example

expected:

everything works.

What I got:

registering signing key
automatically registered Apple CA certificate: Developer ID Certification Authority
automatically registered Apple CA certificate: Apple Root CA
using time-stamp protocol server http://timestamp.apple.com/ts01
automatically setting team ID from signing certificate: <skip>
signing cgo-example in place
signing cgo-example as a Mach-O binary
inferring default signing settings from Mach-O binary
preserving existing binary identifier in Mach-O
using team ID from settings
using code signature flags from settings
setting binary identifier to cgo-example
parsing Mach-O
signing Mach-O binary at index 0
Error: __LINKEDIT isn't final Mach-O segment

Signing iOS app results in unbound Info.plist

Image on left was code signed by macOS codesign. Right side is from this tool.

Here is a diff of codesign -d -vvvv iOSTestApp.app

% diff ~/Desktop/macos.txt ~/Desktop/rust.txt 
< CandidateCDHash sha256=8459bf53a2729671241a130587db4d73ade1060f
> CandidateCDHash sha256=49201689372966eee371d4d03c2f85d58eebf610
< CandidateCDHashFull sha256=8459bf53a2729671241a130587db4d73ade1060fd1133e06793432e8a3025cd6
> CandidateCDHashFull sha256=49201689372966eee371d4d03c2f85d58eebf610008467dead019e2e47f75f46
< CMSDigest=8459bf53a2729671241a130587db4d73ade1060fd1133e06793432e8a3025cd6
> CMSDigest=49201689372966eee371d4d03c2f85d58eebf610008467dead019e2e47f75f46
< CDHash=8459bf53a2729671241a130587db4d73ade1060f
> CDHash=49201689372966eee371d4d03c2f85d58eebf610
< Signature size=4814
> Signature size=4812
< Signed Time=Oct 21, 2022 at 3:10:24 PM
< Info.plist=not bound
> Signed Time=Nov 5, 2022 at 5:32:44 PM
> Info.plist entries=29

Note: that Info.plist is not bound on the Mac codesign. The app is an iOS app if that may cause the difference.

% ls -al iOSTestApp.app/Info.plist
-rw-r--r-- 1 staff 1297 Nov 5 17:32 iOSTestApp.app/Info.plist

rcodesign insists on Info.plist having CFBundleIdentifier

I was trying out rcodesign sign on an iOS .app (a tweaked version of YouTube, 100+ MB) and it was working great until it ran into a deeply nested framework with an Info.plist with no bundle identifier. Turns out the bundle has a lot of these, and I actually got to fully signing bundle app, as I gave up on manually adding a dummy bundle identifier after a few frameworks.

I was wondering if there is any possibility of a command line option (or SignerSettings property as I plan to use apple-codesign as a library) to skip these bundles, or give it a dummy bundle identifier if it runs into that error. While we could do this beforehand, I think it would be more efficient to do it while signing.

I may be able to implement this (and possibly the optional features to reduce dependencies mentioned in #70) if you think it would be a good feature.

More minimal codesigning

Hi, thanks for the awesome project. We've started to use it in the rattler package manager where we only need self-signing.

Unfortunately, this crate has quite a lot of bells and whistles that we don't really need for just self-signing and I was wondering if it's possible to add a minimal feature that removes the dependency on AWS crates and similar.

Concurrent Yubikey access leads to PCSC Error

I am using rcodesign in a on-premises CI server, with the smartcard functionality backed by a Yubikey 5 token.

When two (or more) jobs attempt to sign executables simultaneously, at least one (sometimes all) of them will begin exiting unsuccessfully with the pcsc-rust error Error::ResetCard, which has the description "The smart card has been reset, so any shared state information is invalid".

It's unclear to me where this error is being raised (i.e. when first connecting to the token, or when the signing operation is attempted), but it seems like pcsc-rust resets the Card when dropped (https://github.com/bluetech/pcsc-rust/blob/master/pcsc/src/lib.rs#L1670-L1684) and yubikey-rs doesn't change this or attempt to reconnect to the card on reset, though it does specify that the card should reset on reconnect (https://github.com/iqlusioninc/yubikey.rs/blob/main/src/yubikey.rs#L220-L224) and it seems like the card should perhaps reconnect if there's an error when starting a transaction (https://github.com/iqlusioninc/yubikey.rs/blob/main/src/yubikey.rs#L241-L245).

I am unfamiliar with PCSC and smartcards as a whole, so I'm not sure what the best practices for all of this are.

Publish a GitHub Action for remote signing

This seems like it would be valuable for the broader community as it would lower the barrier to usage and help ensure a minimum security bar is kept.

Error: binary parsing error: Invalid magic number: 0x504b0304

root@debian:~/build# rcodesign sign --p12-file iphone_dev.p12 --code-signature-flags runtime /root/build/app.ipa
Please enter password for p12 file: [hidden]
registering signing key
automatically registered Apple CA certificate: Apple Worldwide Developer Relations Certification Authority
automatically registered Apple CA certificate: Apple Root CA
using time-stamp protocol server http://timestamp.apple.com/ts01
automatically setting team ID from signing certificate: 65MQZ3ZCVL
signing /root/build/app.ipa in place
signing /root/build/app.ipa as a Mach-O binary
inferring default signing settings from Mach-O binary
Error: binary parsing error: Invalid magic number: 0x504b0304
root@debian:~/build#

What am I doing wrong?

indygreg / apple-platform-rs Goto Github PK

apple-platform-rs's People

Contributors

Stargazers

Watchers

Forkers

apple-platform-rs's Issues

Recommend Projects

Recommend Topics

Recommend Org