[bri3d]

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?

[indygreg2]

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

[ckatri]

> 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

[1] https://github.com/ProcursusTeam/ldid

[2] https://man.cameronkatri.com/ldid/ldid.1

[bogwog]

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

[thewebcount]

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.

[bogwog]

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.

[dwaite]

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

[90minuteAPI]

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

[halbersa]

We have a pool of MacOS hardware to run 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.

[jtdressel]

You could use this in addition to regular macOS machines. You can run tests from un-trusted branches, without worrying that something will expose the signing keys.

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_gipsy]

That doesn't justify the build part.

[TazeTSchnitzel]

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

[bouke]

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

[stormbrew]

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)

[adastra22]

Bitcoin Core signs it’s own binaries in a deterministic environment. Not sure if they use xar, or what.