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 -----
On Mon, Oct 26, 2015 at 06:06:36AM -0700, Mike Perry wrote:
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.
Wait; does that mean that things like configuration files, plugins, etc. are *not* signed?
On Oct 26, 2015, at 10:23 AM, Ian Goldberg iang@cs.uwaterloo.ca wrote:
On Mon, Oct 26, 2015 at 06:06:36AM -0700, Mike Perry wrote:
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.
Wait; does that mean that things like configuration files, plugins, etc. are *not* signed?
They are signed. All resources in a bundle (e.g. an app or framework) are signed and the signatures are stored in a file named "CodeResources”:
https://developer.apple.com/library/mac/documentation/Security/Conceptual/Co...
Conrad
On Oct 26, 2015, at 11:22 AM, Spencer spencerone@openmailbox.org wrote:
Hi,
Conrad Kramer: All resources in a bundle (e.g. an app or framework) are signed and the signatures are stored in a file named "CodeResources”:
Then what is in 'CodeSignature', Apple's signing stuff?
The `_CodeSignature` folder currently only contains the `CodeResources` file. The `CodeResources` file is simple XML.
The executables have their own signature in the `LC_CODE_SIGNATURE` load command in the Mach-O binary.
Conrad
On 27 Oct 2015, at 05:41, Conrad Kramer ckrames1234@gmail.com wrote:
On Oct 26, 2015, at 11:22 AM, Spencer spencerone@openmailbox.org wrote:
Hi,
Conrad Kramer: All resources in a bundle (e.g. an app or framework) are signed and the signatures are stored in a file named "CodeResources”:
Then what is in 'CodeSignature', Apple's signing stuff?
The `_CodeSignature` folder currently only contains the `CodeResources` file. The `CodeResources` file is simple XML.
The executables have their own signature in the `LC_CODE_SIGNATURE` load command in the Mach-O binary.
Reproducible builds will be much easier if the executable signatures are also placed in a separate file, rather than modifying the executable.
I'm guessing there's no option for detached executable signatures?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
teor:
On 27 Oct 2015, at 05:41, Conrad Kramer ckrames1234@gmail.com wrote:
On Oct 26, 2015, at 11:22 AM, Spencer spencerone@openmailbox.org wrote:
Hi,
Conrad Kramer: All resources in a bundle (e.g. an app or framework) are signed and the signatures are stored in a file named "CodeResources”:
Then what is in 'CodeSignature', Apple's signing stuff?
The `_CodeSignature` folder currently only contains the `CodeResources` file. The `CodeResources` file is simple XML.
The executables have their own signature in the `LC_CODE_SIGNATURE` load command in the Mach-O binary.
Reproducible builds will be much easier if the executable signatures are also placed in a separate file, rather than modifying the executable.
I'm guessing there's no option for detached executable signatures?
Likely not, based on the description of the system. This is also the case for Windows signatures, btw, which we have been already doing for some time.
What we have done on Windows is to provide instructions for users to use osslsigncode to remove the signatures if they wish to check what they downloaded against a reproduced build. When the Windows signatures are removed, the resulting de-signed files will have the same sha256sums as the official builds: https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerificati...
We want to do this for MacOSX as well. Does anyone happen to know if we can use otool in some way to remove these LC_CODE_SIGNATURE sections easily, and get the same exact binary as before signing?
We won't be doing this for iOS any time soon, nor will we be using the App Store. I think this means we can ignore the more complicated DRM encryption/decryption jailbreaking steps in the docs that Mike Tigas linked to, as DRM encryption should not be involved for us. Hopefully this makes it easier?
Mike Perry:
We want to do this for MacOSX as well. Does anyone happen to know if we can use otool in some way to remove these LC_CODE_SIGNATURE sections easily, and get the same exact binary as before signing?
I don't know if it helps in the case but problem can also be approached the other way around: if Tor distributes the signatures, is there I way to stick them in the binaries I just built so that the signature is valid and the bytes are the same as the ones distributed by Tor.
On 27 Oct 2015, at 21:13, Lunar lunar@torproject.org wrote:
Mike Perry:
We want to do this for MacOSX as well. Does anyone happen to know if we can use otool in some way to remove these LC_CODE_SIGNATURE sections easily, and get the same exact binary as before signing?
I don't know if it helps in the case but problem can also be approached the other way around: if Tor distributes the signatures, is there I way to stick them in the binaries I just built so that the signature is valid and the bytes are the same as the ones distributed by Tor.
codesign has a -D option that produces and verifies a detached signature:
-D, --detached filename When signing, designates that a detached signature should be written to the specified file. The code being signed is not modi- fied and need not be writable. When verifying, designates a file containing a detached signature to be used for verification. Any embedded signature in the code is ignored.
But do the GateKeeper checks use detached signatures for code with no LC_CODE_SIGNATURE? And what filename is required for the detached signature to be used to verify an executable?
Normally, I could use spctl to work out how GateKeeper might behave. But I don't have an App Store / Identified Developers signing certificate, so spctl is pretty useless. It rejects anything that doesn't have an App Store signature, so it's not reporting what GateKeeper will actually do on my system (I have App Store + Identified Developers set).
In short, we could distribute a detached signature that could be manually verified, but I can't see how to get GateKeeper to verify it automatically. So that reduces us to the current state, where we distribute detached PGP signatures next to downloads.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
On 27 Oct 2015, at 20:06, Mike Perry mikeperry@torproject.org wrote:
teor:
On 27 Oct 2015, at 05:41, Conrad Kramer ckrames1234@gmail.com wrote:
On Oct 26, 2015, at 11:22 AM, Spencer spencerone@openmailbox.org wrote:
Hi,
Conrad Kramer: All resources in a bundle (e.g. an app or framework) are signed and the signatures are stored in a file named "CodeResources”:
Then what is in 'CodeSignature', Apple's signing stuff?
The `_CodeSignature` folder currently only contains the `CodeResources` file. The `CodeResources` file is simple XML.
The executables have their own signature in the `LC_CODE_SIGNATURE` load command in the Mach-O binary.
...
What we have done on Windows is to provide instructions for users to use osslsigncode to remove the signatures if they wish to check what they downloaded against a reproduced build. When the Windows signatures are removed, the resulting de-signed files will have the same sha256sums as the official builds: https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerificati... https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerification
We want to do this for MacOSX as well. Does anyone happen to know if we can use otool in some way to remove these LC_CODE_SIGNATURE sections easily, and get the same exact binary as before signing?
...
otool will display sections, but it won’t modify the binary.
strip -no_uuid strips the UUID section, and strip -c creates a stub library by stripping the code signature and all section (code) contents. But it can't strip LC_CODE_SIGNATURE sections without stripping all the code as well.
There's no documented Apple tool to strip code signatures. But the codesign tool itself has an undocumented option to remove signatures:
codesign has several operations and options that are purposely left undocumented in this manual page because they are either experimental (and subject to change at any time), or unadvised to the unwary. The interminably curious are referred to the published source code.
https://opensource.apple.com/source/security_systemkeychain/security_systemk... https://opensource.apple.com/source/security_systemkeychain/security_systemkeychain-39457/src/codesign.cpp
{ "remove-signature", no_argument, NULL, optRemoveSignature }, case optRemoveSignature: signerName = NULL; operation = doSign; // well, un-sign
Unfortunately, I can't seem to get that option to work - perhaps others will have better luck:
$ codesign --remove-signature /.../TestSignature.app/Contents/MacOS/TestSignature /.../TestSignature.app/Contents/MacOS/TestSignature: unsupported type or version of signature $ codesign --remove-signature /.../TestSignature.app /.../TestSignature.app: unsupported type or version of signature $ codesign --remove-signature /.../TestSignature.app/Contents/_CodeSignature/CodeResources (Prints nothing, leaves CodeResources unchanged.)
TestSignature is the OS X Objective C app template signed by "-" (local, default identity).
I wonder if it only strips v1 signatures, and hasn't been updated for v2 signatures? (I'm on 10.10.5 with Xcode 7.1, perhaps other versions of codesign will work.)
I've been working off this Apple code signing documentation: https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple... https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG211
Mozilla has solved a related problem by adding striptease (an enhanced strip command) to their build process: https://bugzilla.mozilla.org/show_bug.cgi?id=411954 https://bugzilla.mozilla.org/show_bug.cgi?id=411954 https://github.com/mackyle/striptease https://github.com/mackyle/striptease
striptease will strip code signatures, but it's an external tool, so that's not an ideal dependency.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Tim Wilson-Brown - teor:
On 27 Oct 2015, at 20:06, Mike Perry mikeperry@torproject.org wrote:
teor:
On 27 Oct 2015, at 05:41, Conrad Kramer ckrames1234@gmail.com wrote:
On Oct 26, 2015, at 11:22 AM, Spencer spencerone@openmailbox.org wrote:
Hi,
Conrad Kramer: All resources in a bundle (e.g. an app or framework) are signed and the signatures are stored in a file named "CodeResources”:
Then what is in 'CodeSignature', Apple's signing stuff?
The `_CodeSignature` folder currently only contains the `CodeResources` file. The `CodeResources` file is simple XML.
The executables have their own signature in the `LC_CODE_SIGNATURE` load command in the Mach-O binary.
...
What we have done on Windows is to provide instructions for users to use osslsigncode to remove the signatures if they wish to check what they downloaded against a reproduced build. When the Windows signatures are removed, the resulting de-signed files will have the same sha256sums as the official builds: https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerificati... https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerification
We want to do this for MacOSX as well. Does anyone happen to know if we can use otool in some way to remove these LC_CODE_SIGNATURE sections easily, and get the same exact binary as before signing?
...
otool will display sections, but it won’t modify the binary.
strip -no_uuid strips the UUID section, and strip -c creates a stub library by stripping the code signature and all section (code) contents. But it can't strip LC_CODE_SIGNATURE sections without stripping all the code as well.
There's no documented Apple tool to strip code signatures. But the codesign tool itself has an undocumented option to remove signatures:
codesign has several operations and options that are purposely left undocumented in this manual page because they are either experimental (and subject to change at any time), or unadvised to the unwary. The interminably curious are referred to the published source code.
https://opensource.apple.com/source/security_systemkeychain/security_systemk... https://opensource.apple.com/source/security_systemkeychain/security_systemkeychain-39457/src/codesign.cpp
{ "remove-signature", no_argument, NULL, optRemoveSignature }, case optRemoveSignature: signerName = NULL; operation = doSign; // well, un-sign
Unfortunately, I can't seem to get that option to work - perhaps others will have better luck:
$ codesign --remove-signature /.../TestSignature.app/Contents/MacOS/TestSignature /.../TestSignature.app/Contents/MacOS/TestSignature: unsupported type or version of signature $ codesign --remove-signature /.../TestSignature.app /.../TestSignature.app: unsupported type or version of signature $ codesign --remove-signature /.../TestSignature.app/Contents/_CodeSignature/CodeResources (Prints nothing, leaves CodeResources unchanged.)
TestSignature is the OS X Objective C app template signed by "-" (local, default identity).
I wonder if it only strips v1 signatures, and hasn't been updated for v2 signatures? (I'm on 10.10.5 with Xcode 7.1, perhaps other versions of codesign will work.)
I've been working off this Apple code signing documentation: https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple... https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG211
Mozilla has solved a related problem by adding striptease (an enhanced strip command) to their build process: https://bugzilla.mozilla.org/show_bug.cgi?id=411954 https://bugzilla.mozilla.org/show_bug.cgi?id=411954 https://github.com/mackyle/striptease https://github.com/mackyle/striptease
striptease will strip code signatures, but it's an external tool, so that's not an ideal dependency.
Ah, nice. While looking today, I also found: https://github.com/Tyilo/insert_dylib#removing-code-signature
And another, far more sketchy tool: http://www.insanelymac.com/forum/topic/293359-tool-to-remove-apple-code-sign...
In general, I think external tools are fine, if we can get them to work reproducibly (in either the removal direction, or in the addition direction that Lunar suggested).
I'm also wondering if we can add detached code signatures from codesign to a plist or other XML property inside the .app folder. That would make all of this better, if it works. Then performing the check is as simple as removing the detached sigs and altering metadata.
On Oct 27, 2015, at 5:32 AM, Mike Perry mikeperry@torproject.org wrote:
Tim Wilson-Brown - teor:
On 27 Oct 2015, at 20:06, Mike Perry mikeperry@torproject.org wrote:
teor:
On 27 Oct 2015, at 05:41, Conrad Kramer ckrames1234@gmail.com wrote:
On Oct 26, 2015, at 11:22 AM, Spencer spencerone@openmailbox.org wrote:
Hi,
> Conrad Kramer: > All resources in a bundle (e.g. an app or framework) are > signed and the signatures are stored in a file named "CodeResources”:
Then what is in 'CodeSignature', Apple's signing stuff?
The `_CodeSignature` folder currently only contains the `CodeResources` file. The `CodeResources` file is simple XML.
The executables have their own signature in the `LC_CODE_SIGNATURE` load command in the Mach-O binary.
...
What we have done on Windows is to provide instructions for users to use osslsigncode to remove the signatures if they wish to check what they downloaded against a reproduced build. When the Windows signatures are removed, the resulting de-signed files will have the same sha256sums as the official builds: https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerificati... https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerification
We want to do this for MacOSX as well. Does anyone happen to know if we can use otool in some way to remove these LC_CODE_SIGNATURE sections easily, and get the same exact binary as before signing?
...
otool will display sections, but it won’t modify the binary.
strip -no_uuid strips the UUID section, and strip -c creates a stub library by stripping the code signature and all section (code) contents. But it can't strip LC_CODE_SIGNATURE sections without stripping all the code as well.
There's no documented Apple tool to strip code signatures. But the codesign tool itself has an undocumented option to remove signatures:
codesign has several operations and options that are purposely left undocumented in this manual page because they are either experimental (and subject to change at any time), or unadvised to the unwary. The interminably curious are referred to the published source code.
https://opensource.apple.com/source/security_systemkeychain/security_systemk...https://opensource.apple.com/source/security_systemkeychain/security_systemkeychain-39457/src/codesign.cpp
{ "remove-signature", no_argument, NULL, optRemoveSignature }, case optRemoveSignature: signerName = NULL; operation = doSign; // well, un-sign
Unfortunately, I can't seem to get that option to work - perhaps others will have better luck:
$ codesign --remove-signature /.../TestSignature.app/Contents/MacOS/TestSignature /.../TestSignature.app/Contents/MacOS/TestSignature: unsupported type or version of signature $ codesign --remove-signature /.../TestSignature.app /.../TestSignature.app: unsupported type or version of signature $ codesign --remove-signature /.../TestSignature.app/Contents/_CodeSignature/CodeResources (Prints nothing, leaves CodeResources unchanged.)
TestSignature is the OS X Objective C app template signed by "-" (local, default identity).
I wonder if it only strips v1 signatures, and hasn't been updated for v2 signatures? (I'm on 10.10.5 with Xcode 7.1, perhaps other versions of codesign will work.)
I've been working off this Apple code signing documentation: https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple...https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG211
Mozilla has solved a related problem by adding striptease (an enhanced strip command) to their build process: https://bugzilla.mozilla.org/show_bug.cgi?id=411954 https://bugzilla.mozilla.org/show_bug.cgi?id=411954 https://github.com/mackyle/striptease https://github.com/mackyle/striptease
striptease will strip code signatures, but it's an external tool, so that's not an ideal dependency.
Ah, nice. While looking today, I also found: https://github.com/Tyilo/insert_dylib#removing-code-signature
And another, far more sketchy tool: http://www.insanelymac.com/forum/topic/293359-tool-to-remove-apple-code-sign...
In general, I think external tools are fine, if we can get them to work reproducibly (in either the removal direction, or in the addition direction that Lunar suggested).
I think it makes sense to ship the binary with the signature in it (and remove it to test reproducibility) if that’s the only way for Gatekeeper to validate the app.
I’ve written code to manually extract the entitlements from a binary before, so I am familiar with how to go about making a tool to remove the code signature. The signature format is documented in the code of Jay Freeman’s cross-platform `ldid` tool, which is used to “fakesign” binaries for jailbroken devices: http://gitweb.saurik.com/ldid.git, http://www.saurik.com/id/8
The code is a solid base to work with, and I could probably add functionality to remove the signature. If it’s as simple as axing the entire `LC_CODE_SIGNATURE` command, then that’s relatively straightforward.
I’ve been personally meaning to add Mach-O support to diffoscope as well, so I should probably do that, as it would be extremely helpful for this endeavor.
I will also investigate the possibility of using detached signatures.
Conrad
I'm also wondering if we can add detached code signatures from codesign to a plist or other XML property inside the .app folder. That would make all of this better, if it works. Then performing the check is as simple as removing the detached sigs and altering metadata.
-- Mike Perry _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Oct 27, 2015, at 3:03 PM, Conrad Kramer ckrames1234@gmail.com wrote:
On Oct 27, 2015, at 5:32 AM, Mike Perry mikeperry@torproject.org wrote:
Tim Wilson-Brown - teor:
On 27 Oct 2015, at 20:06, Mike Perry mikeperry@torproject.org wrote:
teor:
On 27 Oct 2015, at 05:41, Conrad Kramer ckrames1234@gmail.com wrote:
> On Oct 26, 2015, at 11:22 AM, Spencer spencerone@openmailbox.org wrote: > > Hi, > >> Conrad Kramer: >> All resources in a bundle (e.g. an app or framework) are >> signed and the signatures are stored in a file named "CodeResources”: > > Then what is in 'CodeSignature', Apple's signing stuff?
The `_CodeSignature` folder currently only contains the `CodeResources` file. The `CodeResources` file is simple XML.
The executables have their own signature in the `LC_CODE_SIGNATURE` load command in the Mach-O binary.
...
What we have done on Windows is to provide instructions for users to use osslsigncode to remove the signatures if they wish to check what they downloaded against a reproduced build. When the Windows signatures are removed, the resulting de-signed files will have the same sha256sums as the official builds: https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerificati... https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerification
We want to do this for MacOSX as well. Does anyone happen to know if we can use otool in some way to remove these LC_CODE_SIGNATURE sections easily, and get the same exact binary as before signing?
...
otool will display sections, but it won’t modify the binary.
strip -no_uuid strips the UUID section, and strip -c creates a stub library by stripping the code signature and all section (code) contents. But it can't strip LC_CODE_SIGNATURE sections without stripping all the code as well.
There's no documented Apple tool to strip code signatures. But the codesign tool itself has an undocumented option to remove signatures:
codesign has several operations and options that are purposely left undocumented in this manual page because they are either experimental (and subject to change at any time), or unadvised to the unwary. The interminably curious are referred to the published source code.
https://opensource.apple.com/source/security_systemkeychain/security_systemk...https://opensource.apple.com/source/security_systemkeychain/security_systemkeychain-39457/src/codesign.cpp
{ "remove-signature", no_argument, NULL, optRemoveSignature }, case optRemoveSignature: signerName = NULL; operation = doSign; // well, un-sign
Unfortunately, I can't seem to get that option to work - perhaps others will have better luck:
$ codesign --remove-signature /.../TestSignature.app/Contents/MacOS/TestSignature /.../TestSignature.app/Contents/MacOS/TestSignature: unsupported type or version of signature $ codesign --remove-signature /.../TestSignature.app /.../TestSignature.app: unsupported type or version of signature $ codesign --remove-signature /.../TestSignature.app/Contents/_CodeSignature/CodeResources (Prints nothing, leaves CodeResources unchanged.)
TestSignature is the OS X Objective C app template signed by "-" (local, default identity).
I wonder if it only strips v1 signatures, and hasn't been updated for v2 signatures? (I'm on 10.10.5 with Xcode 7.1, perhaps other versions of codesign will work.)
I've been working off this Apple code signing documentation: https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple...https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG211
Mozilla has solved a related problem by adding striptease (an enhanced strip command) to their build process: https://bugzilla.mozilla.org/show_bug.cgi?id=411954 https://bugzilla.mozilla.org/show_bug.cgi?id=411954 https://github.com/mackyle/striptease https://github.com/mackyle/striptease
striptease will strip code signatures, but it's an external tool, so that's not an ideal dependency.
Ah, nice. While looking today, I also found: https://github.com/Tyilo/insert_dylib#removing-code-signature
And another, far more sketchy tool: http://www.insanelymac.com/forum/topic/293359-tool-to-remove-apple-code-sign...
In general, I think external tools are fine, if we can get them to work reproducibly (in either the removal direction, or in the addition direction that Lunar suggested).
I think it makes sense to ship the binary with the signature in it (and remove it to test reproducibility) if that’s the only way for Gatekeeper to validate the app.
I’ve written code to manually extract the entitlements from a binary before, so I am familiar with how to go about making a tool to remove the code signature. The signature format is documented in the code of Jay Freeman’s cross-platform `ldid` tool, which is used to “fakesign” binaries for jailbroken devices: http://gitweb.saurik.com/ldid.git, http://www.saurik.com/id/8
Sorry to double post, but I stand corrected: ldid already supports stripping code signatures, and Jay made it “really really good” in the last few months. He knows a lot about codesigning, so I am getting his feedback on a good approach.
Conrad
The code is a solid base to work with, and I could probably add functionality to remove the signature. If it’s as simple as axing the entire `LC_CODE_SIGNATURE` command, then that’s relatively straightforward.
I’ve been personally meaning to add Mach-O support to diffoscope as well, so I should probably do that, as it would be extremely helpful for this endeavor.
I will also investigate the possibility of using detached signatures.
Conrad
I'm also wondering if we can add detached code signatures from codesign to a plist or other XML property inside the .app folder. That would make all of this better, if it works. Then performing the check is as simple as removing the detached sigs and altering metadata.
-- Mike Perry _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Ian Goldberg:
On Mon, Oct 26, 2015 at 06:06:36AM -0700, Mike Perry wrote:
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.
Wait; does that mean that things like configuration files, plugins, etc. are *not* signed?
There's a --deep option in `codesign` for this purpose.
From the man page:
When signing a bundle, specifies that nested code content such as helpers, frameworks, and plug-ins, should be recursively signed in turn. Beware that all signing options you specify will apply, in turn, to such nested content.
Best,
On 27 Oct 2015, at 20:27, Nima Fatemi nima@riseup.net wrote:
Ian Goldberg:
On Mon, Oct 26, 2015 at 06:06:36AM -0700, Mike Perry wrote:
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.
Wait; does that mean that things like configuration files, plugins, etc. are *not* signed?
There's a --deep option in `codesign` for this purpose.
From the man page:
When signing a bundle, specifies that nested code content such as helpers, frameworks, and plug-ins, should be recursively signed in turn. Beware that all signing options you specify will apply, in turn, to such nested content.
Apple recommends against signing with --deep, it's designed for verification: https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple... https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG404 (Quoting the entire entry because Apple blocks Tor Exit nodes:)
Using the codesign Tool's --deep Option Correctly
When verifying signatures, add --deep to perform recursive validation of nested code. Without --deep, validation will be shallow: it will check the immediate nested content but not check that fully. Note that Gatekeeper always performs --deep style validation.
<>Important: While the --deep option can be applied to a signing operation, this is not recommended. We recommend that you sign code inside out in individual stages (as Xcode does automatically). Signing with --deep is for emergency repairs and temporary adjustments only.
Note that signing with the combination --deep --force will forcibly re-sign all code in a bundle.
Mozilla have also had issues with signing with --deep: https://bugzilla.mozilla.org/show_bug.cgi?id=989189 https://bugzilla.mozilla.org/show_bug.cgi?id=989189
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
-
Conrad Kramer -
Ian Goldberg -
Lunar -
Mike Perry -
Nima Fatemi -
Spencer -
teor -
Tim Wilson-Brown - teor