Here is some info about OSX codesigning, courtesy of Mike Tigas. It sounds like undoing the codesigning to verify build (and signing machine) integrity will be tricky. If anyone has more info on how to do that, it would be appreciated.
----- Forwarded message from Mike Tigas mike@tig.as -----
Date: Fri, 10 Jul 2015 01:29:02 -0400 From: Mike Tigas mike@tig.as To: Mike Perry mikeperry@torproject.org Subject: Re: Apple developer account + codesigning
Hey Mike,
Cool seeing y'all at that CPJ thing briefly. Yeah, that account is what you'll need to get the Apple-signed certs that let you codesign an app & allow it to launch unimpeded -- regardless of App Store or not. Used to be separate accounts for Mac vs iOS, but looks like it's just one account for everything Apple. (More info in the middle below on how to get the cert you need, etc.)
On another open-source thing I work on http://tabula.technology/, we have a cross-platform JRuby program that we turn into a .app for Mac. We avoid the XCode IDE altogether (using a tool called `jarbundler` that turns our jar into a Mac .app bundle for us) and use the command-line "codesign" tool that comes with MacOSX or XCode (can't remember which).
The invocation is basically like:
codesign -f -s 'Developer ID Application: Mike Tigas (68QUP6KP2C)' /path/to/Foo.app
Where the `-s` argument is the ID of the certificate you end up with from Apple -- see my comment here about "For production builds...":
https://github.com/tabulapdf/tabula/blob/fe6b105ca4f84ea64975d8ddc876dce8d14...
Once you have your Apple Developer account, link 3 in that comment is where you'll get your cert. There's a little wizard for it that walks you through it. (You want to be in Mac Apps -> Certificates -> All, click + to add a certificate, and you want a Production -> Developer ID, for an Application.)
In our case we had to manually sign another OSX framework (Java) that we bundled with the app, so there's two invocations of the `codesign` command. We previously didn't do that (in https://github.com/tabulapdf/tabula/blob/c21b27c867ecdb578f97667310ea8b21e07... ), instead invoking `codesign` with the `--deep` flag, which tries to recursively sign all executable binaries inside the target (but there's some peculiarity with the Java OSX framework that prevented us from doing it). So just throwing that out there as another option to try. If this is for TBB or something else with a bunch of binaries inside, you'll have to keep this in mind.
I've also discovered that this is a bitch to test, since once you've bypassed codesigning to open an app (doing right-click and open instead of double-clicking shows a prompt that allows a user to bypass the warning https://support.apple.com/en-us/HT202491 ), the app's whitelisted on your system. So I've historically messed up quite a few releases by signing with the wrong key, missing some bundled framework, etc, since my own work opens up fine on my own computer.
I remember us vaguely talking about reproducible builds and verification, too. Guessing this ties in to the "removing signatures" part of what you said? Of course anything that happens during and after a codesign isn't reproducible for other users, but here are some notes about what `codesign` and the App Store do to built apps, particularly on iOS (but probably applicable to OSX too). https://github.com/OnionBrowser/iOS-OnionBrowser/issues/58 https://github.com/WhisperSystems/Signal-iOS/issues/641#issuecomment-7820274...
Essentially, codesign only touches executable binaries in the .app (see that second link for info on how the binary's segments get moved around) and also adds an SC_Info directory for codesign/DRM metadata. For App Store apps, only the SC_Info gets modified for different users for DRM. That makes it possible to actually verify an App Store app's integrity by removing that directory to check hashes -- https://github.com/OnionBrowser/iOS-OnionBrowser/releases/tag/v1.5.11 -- but you won't have this problem since you're not gonna go that route.
The design (per that comment) doesn't seem to allow reversing the signing process easily due to DRM encryption of parts of the binary -- though I'm not clear on which parts are due to `codesign` locally versus magic that Apple performs on App Store-submitted applications. If the `codesign` by itself doesn't encrypt the binary (i.e. if it just rearranges the binary's segments & adds metadata & creates the metadata/DRM directory), it might be possible to reverse it. Could be worth someone exploring segment sizes/positions with `size` and `otool` http://www.objc.io/issues/6-build-tools/mach-o-executables/ to determine this for real.
Ah holy shit, that is a LOT of words. But hope that helps and isn't too overwhelming. That's just about everything I know about this off the top of my head.
Let me know if something isn't clear or if you run into any issues with the Apple account or something like that.
Cheers,
Mike Tigas Reporter/News Applications Developer, ProPublica https://www.propublica.org/ @mtigas | https://mike.tig.as/ | 0x6E0E9923
----- End forwarded message -----