[tor-dev] [FWD: Re: Apple developer account + codesigning]

[Mike Perry]

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 at tig.as> -----

Date: Fri, 10 Jul 2015 01:29:02 -0400
From: Mike Tigas <mike at tig.as>
To: Mike Perry <mikeperry at 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/fe6b105ca4f84ea64975d8ddc876dce8d14b62a1/build.xml#L45-65

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/c21b27c867ecdb578f97667310ea8b21e0751a68/build.xml#L45-59
), 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-78202740

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

-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151026/22ccd25f/attachment.sig>