Live data from Hacker News

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

gregoryszorc.com

31–40 of 56 posts

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

#31
post #25

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…

I'm kind of confused by what you mean by "re-sign". The repo you linked to says that it's a tool to "re-sign" apps. Does that mean it requires an already-signed app to function?

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.

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

#32
post #25

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…

> - Build pipeline. Maybe, but you can’t fully build a iOS app on Linux so it didn’t seem like a win.

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.

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

#33
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?

CoreFoundation is (partially?) open-source and cross-platform now: https://github.com/apple/swift-corelibs-foundation

That’s not CoreFoundation, a C library, but a Swift reimplementation of that library, only to be consumed by Swift (import Foundation).

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

#34
> There are probably thousands of companies and individuals who have wanted to release Apple software from non-macOS operating systems. (The existence and popularity of tools like fastlane seems to confirm this.)

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.

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

#35
post #33

Earlier quoted context omitted.

CoreFoundation is (partially?) open-source and cross-platform now: https://github.com/apple/swift-corelibs-foundation

That’s not CoreFoundation, a C library, but a Swift reimplementation of that library, only to be consumed by Swift (import Foundation).

CF was always (approximately) a multiplatform and open source subset of foundation (which is the thing this isn't). I think this is a superset and extension of the original core foundation under more favorable license terms though.

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)

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

#36
post #18
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?

> Plus, it's not Written in Rust (TM)! 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.

Can you elaborate? Since I mostly work on macOS stuff, I don't understand the workflow that leads to needing this sort of tool. What's the process of writing software for either macOS or iOS that doesn't involve needing macOS or iOS at some point? Like you probably need to test on those systems if you're supporting software for them, right? Is it because development is done on Linux, and only testing is done on, say, macOS? Sorry if this is a stupid question. I just haven't run into this sort of situation before and am trying to better understand it.

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

#38
post #18

Earlier quoted context omitted.

> Plus, it's not Written in Rust (TM)! 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.

Can you elaborate? Since I mostly work on macOS stuff, I don't understand the workflow that leads to needing this sort of tool. What's the process of writing software for either macOS or iOS that doesn't involve needing macOS or iOS at some point? Like you probably need to test on those systems if you're supporting software for them, right? Is it because development is done on Linux, and only testing is done on, say,…

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 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.

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

#39
post #38

Earlier quoted context omitted.

Can you elaborate? Since I mostly work on macOS stuff, I don't understand the workflow that leads to needing this sort of tool. What's the process of writing software for either macOS or iOS that doesn't involve needing macOS or iOS at some point? Like you probably need to test on those systems if you're supporting software for them, right? Is it because development is done on Linux, and only testing is done on, say,…

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?

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

#40
post #39
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?

If those instances are only for tests/validation it could simplify some overall pipelines quite a bit.
Post reply on HN