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...
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.
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?
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 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
It could be co-authored by Xi Jinping and Mark Zuckerberg in COBOL and hosted on NPM, and that wouldn’t stop me from using an open source codesign alternative that runs on Linux.
Even if you're just writing standard native apps with Xcode, being able to build, test, and deploy your app every time you push to the production branch in your Gitlab/Github repo is valuable. With codesign on Linux, you can build that on top of a simple, ~5mb alpine linux container.
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?
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.
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)
The "original" CF can be found here in various revisions tied to macos versions, complete with theoretically useful Linux makefiles and apple public source license files: https://opensource.apple.com/source/CF/
Compare, for example, these two versions of CFBase.c:
https://opensource.apple.com/source/CF/CF-1153.18/CFBase.c.a...
https://github.com/apple/swift-corelibs-foundation/blob/main...
(Credentials: I worked on the swift Linux port and made an effort to use these very libraries before the swift project itself took on the task of porting CF to swift. While I was working on it we mostly just ifdef'd out everything to do with foundation when targeting Linux)