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

this feels like a job for lemur and smallstep

https://smallstep.com/docs/step-ca

https://github.com/Netflix/lemur

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 signing solutions just do ad-hoc signing and/or don't handle Mach-O in the context of a bundle.)

Kudos to these developers. I wish them success.

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.

Realistically? It's an additional static analysis hoop to jump through and another brick in Apple's walled garden in terms of trying to lock-out generic programs written by anyone who can't be arsed to fiddle with cryptography.

"I’m not a lawyer, but it’s my understanding that the Google v Oracle case established that APIs aren’t protected by copyright."

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.