Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support writing flat packages (.pkg installers) #3

Open
indygreg opened this issue Apr 2, 2022 · 5 comments
Open

Support writing flat packages (.pkg installers) #3

indygreg opened this issue Apr 2, 2022 · 5 comments
Labels
apple-codesign apple-codesign crate and rcodesign CLI tool enhancement New feature or request

Comments

@indygreg
Copy link
Owner

indygreg commented Apr 2, 2022

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.

@indygreg indygreg added enhancement New feature or request apple-codesign apple-codesign crate and rcodesign CLI tool labels Apr 2, 2022
@mappu
Copy link

mappu commented Apr 3, 2022

You mentioned very clearly in the latest docs change 080f9e3 -

So if you want to sign .pkg files that themselves containable signable entities, you need to sign files going into the .pkg before creating the .pkg. Then you need to create the .pkg and invoke this tool to sign the .pkg. For installers that contained nested .pkg installers, this process will be quite tedious. Invoking componentbuild and productbuild will likely be much simpler.

It is my recollection that this doesn't work with official macOS signing toolchain neither. In my experience I had to call codesign --deep on the bundle directory and also productsign --sign on the flat .xar afterwards.

But, maybe things had changed since first writing my CI scripts, it would be nicer if a single top-level recursive sign could work fully.

@mappu
Copy link

mappu commented Apr 3, 2022

In my experience I had to call codesign --deep on the bundle directory and also productsign --sign on the flat .xar afterwards.

This is also in part because the bundle should be signed with the Developer ID Application certificate, and the flat xar should be signed with the Developer ID Installer certificate.

@indygreg
Copy link
Owner Author

If the docs I wrote are incorrect, please submit a PR to fix them! I actually haven't signed installers that much and the docs I wrote related to installer signing may be horribly wrong!

Regarding the requirements to sign with different certificates, this is very much a solvable problem! apple-codesign doesn't have it yet, but it is very possible to automatically choose the best signing certificate given a bucket of potential signing certificates. We can easily identify whether a signing certificate is e.g. Developer ID Application vs Developer ID Installer. If we had support for recursively signing flat packages, I would definitely see the utility in implementing this support.

@indygreg indygreg transferred this issue from indygreg/PyOxidizer Sep 18, 2022
@wrl
Copy link
Contributor

wrl commented Oct 2, 2022

There's also https://github.com/hogliux/bomutils which hasn't been updated in a while but could be useful nonetheless.

@indygreg
Copy link
Owner Author

indygreg commented Oct 2, 2022

I just pushed my unfinished apple-bom crate to this repository. At this time, I have no plans to continue work on it nor publish it to crates.io. But perhaps the code is useful for somebody.

I think reading support is semi-solid. But there are gaps in understanding of the file format.

Writing support is known to be broken. My recollection is there is something exceptionally low-level causing a few bits and crc32's to disagree compared with Apple's tooling. I remember attempting to brute force the crc32 to figure out which input bytes were wrong. That's how desperate I was at the time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
apple-codesign apple-codesign crate and rcodesign CLI tool enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants