Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Achieving an open-source implementation of Apple Code Signing and notarization

gregoryszorc.com

Post reply on HN
Print view View original

41–50 of 56 posts

Re: Achieving an open-source implementation of Apple Code Signing and notarization

#41

Post by indygreg2 »

infotogivenm wrote: post #24

I’ve always used gon ( https://github.com/mitchellh/gon ) for this, which is open source golang, but I don’t think it supports mach-o embedding. I’ll have to try this tool out.

Note that gon is a glorified front-end for executing processes like `codesign`, `altool`, and even `ditto` for zip file generation.

This Rust implementation, by contrast, has all the functionality implemented in pure Rust: there is no calling out to external processes for anything. You could drop the statically linked `rcodesign` executable into a Linux container with no other files and it would work.

That's not to discredit gon or its authors: it is a fantastic tool for streamlining common functionality. But the mechanism is completely different.

Re: Achieving an open-source implementation of Apple Code Signing and notarization

#42

Post by indygreg2 »

ridiculous_fish wrote: post #5

I think Apple's official code signing tool is also open source? https://github.com/Apple-FOSS-Mirror/security_systemkeychain... xar is another tool for codesigning Mac installer packages, which runs on Linux. I've used it successfully in the past. https://users.wfu.edu/cottrell/productsign/productsign_linux...

Some of Apple's code signing is open source (mostly in SecurityFramework). But not enough is open source to be able to build a modern `codesign`. The source you linked is ~10 years old and woefully out of date, for example!

I don't believe there are any Apple open source references for how notarization works (at least none before it was a public App Store Connect API).

There are even times when Apple's open source releases trail functionality they are shipping in macOS. For example, Apple recently added an alternative DER encoding of entitlements, which are expressed as a plist. I don't believe Apple ever published code for how the DER encoding works. Instead, we needed to use Apple's tooling as an oracle to incrementally derive the encoding.

Re: Achieving an open-source implementation of Apple Code Signing and notarization

#43

Post by denkmoon »

xer0x wrote: post #37

I came here to whine about Apple Code signing, and how this seems like a terrible thing to reproduce, until I realized this breaks free of Apple, and is hopefully much more sane! Well done!

It's only good when it's not Apple doing it?

You know you can go disable code signing verification on macos with a reboot and a single command right?

Re: Achieving an open-source implementation of Apple Code Signing and notarization

#44

Post by ckatri »

indygreg2 wrote: post #23
bri3d wrote: post #8

Earlier quoted context omitted.

Good pointers indeed - Apple's code signing tool is open source, but heavily dependent on Cocoa/OSX libraries like CoreFoundation. I'm not sure if it works with any of the open-source reimplementations of these libraries, although I kind of want to try now, just for fun - has anyone done this already? Plus, it's not Written in Rust (TM)! `xar` only signs packages, not Mach-O binaries, at least as far as I know?

XAR signing is effectively just an RFC 5652 CMS signature plus some minimal data structure manipulation. Code at https://github.com/indygreg/PyOxidizer/blob/faa7dfcea5d66bf5... . Mach-O and bundles, by contrast, require a myriad of additional data structures requiring thousands of lines of code to support. To my knowledge, nobody else has implemented signing of these far-more-complicated primitives. (Existing Mach-O…

> Existing Mach-O signing solutions just do ad-hoc signing and/or don't handle Mach-O in the context of a bundle.

I can assure you that saurik's ldid[0] does. Or the updated fork that I maintain at ProcursusTeam/ldid[1]. You can use -K to sign with a cert. You can find full documentation in the manpage[2].

[0] http://git.saurik.com/ldid.git

[1] https://github.com/ProcursusTeam/ldid

[2] https://man.cameronkatri.com/ldid/ldid.1

Re: Achieving an open-source implementation of Apple Code Signing and notarization

#46

Post by the_gipsy »

dwaite wrote: post #39
bogwog wrote: post #38

Earlier quoted context omitted.

There are a lot of different reasons a project would want something like this. In general though, I think the most common is CI and build automation. Currently, build automation for Mac requires doing some shady stuff with VMs, or renting or buying and maintaining a physical Mac. Being able to do everything on Linux vastly simplifies the infrastructure needed to support that. Even if you're just writing standard nati…

> I think the most common is CI and build automation Common practice for CI is to actually run tests, though. How would you validate your macOS/iOS builds are functional without still requiring VMs or real hardware?

That doesn't justify the build part.

Re: Achieving an open-source implementation of Apple Code Signing and notarization

#47

Post by pmontra »

I have a customer that runs a dynamic analysis service. They add a library to the IPA and create a new one. They need to to sign it. It's automated on a Mac but they won't need a Mac anymore if they could run code signing on a Linux VM like the rest of their infrastructure. No more sending files and messages back and forth between the two environments. A huge win.

Re: Achieving an open-source implementation of Apple Code Signing and notarization

#48

Post by jtdressel »

dwaite wrote: post #39
bogwog wrote: post #38

Earlier quoted context omitted.

There are a lot of different reasons a project would want something like this. In general though, I think the most common is CI and build automation. Currently, build automation for Mac requires doing some shady stuff with VMs, or renting or buying and maintaining a physical Mac. Being able to do everything on Linux vastly simplifies the infrastructure needed to support that. Even if you're just writing standard nati…

> I think the most common is CI and build automation Common practice for CI is to actually run tests, though. How would you validate your macOS/iOS builds are functional without still requiring VMs or real hardware?

You could use this in addition to regular macOS machines. You can run tests from un-trusted branches, without worrying that something will expose the signing keys.

Then after merging, you have a second machine / set of machines that only does signing. It increases the difficulty of an accidental or intentional leakage of your sensitive keys.

(Note: I have not tested this yet)

Re: Achieving an open-source implementation of Apple Code Signing and notarization

#49

Post by Diti »

denkmoon wrote: post #43
xer0x wrote: post #37

I came here to whine about Apple Code signing, and how this seems like a terrible thing to reproduce, until I realized this breaks free of Apple, and is hopefully much more sane! Well done!

It's only good when it's not Apple doing it? You know you can go disable code signing verification on macos with a reboot and a single command right?

The comment you replied to means "reproduce" as in reproducible-builds[.org]. Needing to be on macOS to sign Mach-O binaries makes builds less reproducible than also having a Linux way of signing the builds.

Re: Achieving an open-source implementation of Apple Code Signing and notarization

#50

Post by halbersa »

dwaite wrote: post #39
bogwog wrote: post #38

Earlier quoted context omitted.

There are a lot of different reasons a project would want something like this. In general though, I think the most common is CI and build automation. Currently, build automation for Mac requires doing some shady stuff with VMs, or renting or buying and maintaining a physical Mac. Being able to do everything on Linux vastly simplifies the infrastructure needed to support that. Even if you're just writing standard nati…

> I think the most common is CI and build automation Common practice for CI is to actually run tests, though. How would you validate your macOS/iOS builds are functional without still requiring VMs or real hardware?

We have a pool of MacOS hardware to run tests, and another pool to perform signing. The latter is a security risk so very tightly controlled and locked down. They are a pita to maintain.

Being able to sign on Linux will allow us to re-use the existing signing infrastructure we use for literally every other platform other than MacOS. It'll be more secure and much less maintenance.

Post reply on HN