Achieving an open-source implementation of Apple Code Signing and notarization
gregoryszorc.com
gregoryszorc.com
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...
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?
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)
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?
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)
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.
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
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.
That’s relatively easy to do, with the only questionable/legally gray area being access to the iOS/Mac SDKs. I’m not a lawyer, but it’s my understanding that the Google v Oracle case established that APIs aren’t protected by copyright. So if we can use the headers from e.g. the iOS SDK on Linux wtohout worrying about copyright issues (Apple developer agreements may be an issue though), it should be possible to autogenerate stub libraries for linking purposes.
With that, you can compile and link a binary for iOS or Mac on Linux.
Next, you’ll need to implement the packaging and signing portion. Packaging (generating an app bundle) is easy, but codesigning requires Apple’s codesign utility, which doesn’t work outside of Mac, even with a project like Darling (last I checked, anyways).
But if the OP does implement a working codesign alternative, then that means it should be possible to create an iOS/Mac app that can be distributed on the App Store entirely from Linux with no Xcode, virtual machines, cloud macs, etc.
The only gate left then is the Apple tax/signing certificate you need to buy for $99/year. But that might change with all of the antitrust pressure Apple is facing, including the recent EU law that would force Apple to allow competing app stores.
I'm no lawyer either but I have read the Supreme Court's decision in the case. It doesn't address whether APIs are protected by copyright. The Supreme Court generally makes the most limited ruling needed in order to resolve a case. In this case there were two issues at play.
-Are API's copyrightable? -If so, was Google's use of the APIs fair use under copyright law as a jury had previously ruled?
In order to make the most limited ruling needed to decide the case the Supreme Court first addressed the fair use question with an assumption that APIs could be copyrighted. The Court decided that Google's use did fall under fair use and so the case could be decided by the fair use question alone. They therefore didn't bother to address the question of whether APIs can be copyrighted.
As it stands right now there is a U.S. Court of Appeals ruling in the Oracle case that APIs are copyrightable which until the Supreme Court does address the issue means they are as far as the courts are concerned. Fair use is a case-by-case defense and the Supreme Court's decision doesn't mean that all use of an API is fair use. This is all very much still all up in the air and any use of the headers from the iOS SDK should be concerned about copyright issues.
We were already building our own clang binaries for various reasons, so it was mostly a matter of making an SDK available and ensuring that the right compiler options were passed in (since running clang on macOS sets a bunch of defaults that you don't get even if you pass -target x86_64-apple-darwin).
You know you can go disable code signing verification on macos with a reboot and a single command right?
If I can do a small derail: I and some contributors had this mostly working a few iOS versions ago with isign (https://github.com/isignpy/isign). This is befor notarization. Announced several times to HN but didn’t seem to be interesting to many people.
This was a spin-off from our work at a testing company. I’m not an iOS developer. (That may be why I could never see what to do with this.)
I tried to make it into something, but I could never figure out who actually wanted this. What potential uses are foreseen for rcodedesign?
- Weird custom signing. We did a project for a large financial company to make it compatible with hardware security module signing, but they never implemented it due to the pandemic changing priorities, and then someone discovered there was a little-known MacOS API to do something similar anyway, so our project was shelved. (We got paid though).
- “Alternative” app distribution. From time to time I am contacted by people who run alternative app stores, either distributing hacked versions of paid apps, or who run app store in countries under embargo from Western countries. (They have banks, their customers have iPhones, they want a way to distribute iOS apps). The ethical issues and legal risks seemed significant so I never pursued that. If someone wants to go do that, I guess that’s a use case.
- Build pipeline. Maybe, but you can’t fully build a iOS app on Linux so it didn’t seem like a win.
- Mass app production. I am aware of some app white-labeling concepts that used isign back in the day. There was a guy who had a generic app for local news outlets, and essentially uploaded it to the App Store dozens of times under different names, for new versions. isign was more scriptable (and I wrote a multi-resign option for this use case) but I didn’t see a way to turn this into a business.
- Testing on real devices. Even the original use case (re-signing apps to run on local device labs) has been mostly obviated. Hosting and scripting on MacOS has gotten better.
- ??? something else? I even reached out to saurik about this at a conference. Cydia worked on jailbroken devices, so it didn’t need signing. To my surprise saurik was angry with me. He said that many, many companies had figured this out internally so he was skeptical we would ever release it. (We did!)
So… again kudos, but what can we do with this? I’m not dissing it, I’m genuinely baffled. I also thought this would be important and useful but couldn’t figure it out.
It could certainly be useful for macOS CLI tools. Languages like Go and Zig can cross-compile seamlessly from linux (and Rust is nearly but not quite there). With this you could compile, sign and notarize a ready-to-publish binary without ever touching a macOS machine.
Mac/iOS app bundles need to be signed, but so does the actual compiled binary within the bundle. The signing process, among other things, embeds entitlement information into the binary (permissions for using certain APIs). Can isignpy do this? Or does it only do app bundle signing?
From the perspective of app development, a tool that can perform full code signing on Linux is huge. Imagine how much of a pain (and expense) it is to maintain a CI pipeline when you need a physical Mac (since you can't legally run MacOS in a VM). There are more than a few cloud companies that offer dedicated Macs pretty much just for this purpose.
This is my use case (I implemented notarization API support in rcodesign).
I build MacOS apps entirely from Linux using my own bespoke toolchain, based on osxcross. It can potentially be used to build iOS apps too (I tested it in jest some time ago, but I don't use it for anything serious). This is all done without any of the apple binaries. The toolchain uses nix to pull everything together, clang and other llvm utilities as a compiler, lld as a linker, rcodesign for signing and notarization, and the macOS/iOS SDK for headers and tbd files used for linking. And a bit of custom glue code in bash to hold it all together.
The reason I do this is simple: My CI is entirely Linux-based. I already cross-build windows binary from Linux. This makes CI so much easier, as everything can be containerized, and thus run on most standard CI offerings. I only need to bring Windows and macOS VMs to run test suites. Because VM bringup is slow and somewhat fragile, pushing everything to run in Linux containers is a huge win.
It also gives me a lot more control when things inevitably break. Being open source, rcodesign can be trivially changed, be it to add more logging, or add new features. For instance, rcodesign has a remote signing mechanism! This isn't something that exists in the normal codesign implementation.
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.
I'm not sure the existence/popularity of fastlane supports the non-macOS operating systems argument since its primary purpose is as a wrapper around Apple's clunky/undocumented build and upload tools on macOS.
permission _at any stage_, and then sideload these apps onto my personal iphone/ipad?
(assuming as mentioned elsewhere that I can develop such apps on linux, without needing MacOS)
Can this notarize apps made with other programming languages?
# From a Git checkout
$ cargo run --bin rcodesign -- --help
$ cargo install --bin rcodesign
# Remote install.
$ cargo install --git https://github.com/indygreg/PyOxidizer --branch main --bin rcodesign apple-codesign