I used to be confused as to why open source projects did things like this - targetting non-free operating systems, and putting a lot of effort into it.
Now I think I see the answer: commoditisation of the OS and hardware. It’s all about the free software; build it and run it wherever you like (Linux, *BSD, Windows, macOS). Open the walled gardens and users can move much more freely between platforms.
And this now has another twist (not a new one for folks around when 68k Linux was a popular thing): varying CPU architectures. ARM vs. amd64 vs. RISC-V. We live in interesting times, and I don’t mean that in a curse sense ;)
This is super cool but I’m not 100% on the use case—you still need to build on an Apple OS since you can’t legally cross-compile to macOS right¹? So why not do the signing/notarisation then?
You are expressly prohibited from separately using the Apple SDKs or attempting to run any
part of the Apple Software on non-Apple-branded hardware.
“Apple SDKs” means the macOS SDK, and the Apple-proprietary Software Development Kits (SDKs)
provided hereunder, including but not limited to header files, APIs, libraries, simulators, and software[..]
We have a pool of MacOS hardware to run builds / 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.
Yes, but you can also build software for macOS that doesn’t use Apple’s SDKs. For example CLI applications. I do know that for example in Go you can cross compile to darwin, which works, but you still need to “notarize” your binary before it can run.
I can’t stand Apple’s code signing. Their tooling seems to be designed to only upload from Xcode GUI to Mac App Store, and everything is else is left half-assed, buggy, and undocumented. There are tons of things that can go wrong with signing, but their error messages are vague and unhelpful. So I’m happy there’s another tool.
the Apple Uploader makes (on my uplink) ~350MB upstream traffic to upload a <50MB iOS ipa payload. Takes over an hour. I would be more than happy about an upload tool that would be not be as crappy in non high-end environments. So much about sustainability and double-standards.
The (swift) ipa for testing is ~15MB by the way and the previous ObjC version was 500K. This is how to ruin the planet with an upload obesity crisis.
I’m not sure: I haven’t seriously looked into the problem space on Windows. But I do believe the technical implementation on Windows is vastly simpler than on macOS. I’ve long wanted to implement this but I just haven’t had time to look into it.
I’d say “vastly simpler” is fair, though I might be tempted to add that the signatures are less useful as well. JSign is where I’d start if I needed this today.
Assuming you just mean Authenticode, it is close enough to the PKCS#7 CMS that it’s not hard to whip up something to do that. I did more than once a little over a decade back for internal build systems, but never won the arguments I needed to to get them released.
I used to be confused as to why open source projects did things like this - targetting non-free operating systems, and putting a lot of effort into it.
Now I think I see the answer: commoditisation of the OS and hardware. It’s all about the free software; build it and run it wherever you like (Linux, *BSD, Windows, macOS). Open the walled gardens and users can move much more freely between platforms.
And this now has another twist (not a new one for folks around when 68k Linux was a popular thing): varying CPU architectures. ARM vs. amd64 vs. RISC-V. We live in interesting times, and I don’t mean that in a curse sense ;)
This is such a wonderful experience. Congratulations.
I don’t get to work with Rust on a day-to-day basis, but following your Rust works has been very inspiring to me.
This is super cool but I’m not 100% on the use case—you still need to build on an Apple OS since you can’t legally cross-compile to macOS right¹? So why not do the signing/notarisation then?
¹ Xcode and Apple SDKs Agreement:
We have a pool of MacOS hardware to run builds / 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.
Ahh ok separate build vs sign envs makes sense. Thanks for the insight.
Yes, but you can also build software for macOS that doesn’t use Apple’s SDKs. For example CLI applications. I do know that for example in Go you can cross compile to
darwin, which works, but you still need to “notarize” your binary before it can run.I can’t stand Apple’s code signing. Their tooling seems to be designed to only upload from Xcode GUI to Mac App Store, and everything is else is left half-assed, buggy, and undocumented. There are tons of things that can go wrong with signing, but their error messages are vague and unhelpful. So I’m happy there’s another tool.
my usecase:
the Apple Uploader makes (on my uplink) ~350MB upstream traffic to upload a <50MB iOS ipa payload. Takes over an hour. I would be more than happy about an upload tool that would be not be as crappy in non high-end environments. So much about sustainability and double-standards.
The (swift) ipa for testing is ~15MB by the way and the previous ObjC version was 500K. This is how to ruin the planet with an upload obesity crisis.
Congratulations on this achievement. Is there already something similar for code-signing Windows executables?
I’m not sure: I haven’t seriously looked into the problem space on Windows. But I do believe the technical implementation on Windows is vastly simpler than on macOS. I’ve long wanted to implement this but I just haven’t had time to look into it.
I’d say “vastly simpler” is fair, though I might be tempted to add that the signatures are less useful as well. JSign is where I’d start if I needed this today.
Assuming you just mean Authenticode, it is close enough to the PKCS#7 CMS that it’s not hard to whip up something to do that. I did more than once a little over a decade back for internal build systems, but never won the arguments I needed to to get them released.
JSign is what I’d use if I needed that today.