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

[Lunar]

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.

-- 
Lunar 


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Mike Perry]

teor:
> 
> On 27 Oct 2015, at 05:41, Conrad Kramer  wrote:
> 
> >> On Oct 26, 2015, at 11:22 AM, Spencer  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#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?

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


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Nima Fatemi]

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,
-- 
Nima
0XC009DB191C92A77B | @mrphs

"I disapprove of what you say, but I will defend to the death your right
to say it" --Evelyn Beatrice Hall



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Tim Wilson-Brown - teor]

> On 27 Oct 2015, at 20:27, Nima Fatemi  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_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 


Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Tim Wilson-Brown - teor]

> On 27 Oct 2015, at 21:13, Lunar  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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Mike Perry]

Tim Wilson-Brown - teor:
> 
> > On 27 Oct 2015, at 20:06, Mike Perry  wrote:
> > 
> > teor:
> >> 
> >> On 27 Oct 2015, at 05:41, Conrad Kramer  wrote:
> >> 
>  On Oct 26, 2015, at 11:22 AM, Spencer  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#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_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_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://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-signatures-from-binaries/

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 

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

[Conrad Kramer]

> On Oct 27, 2015, at 5:32 AM, Mike Perry  wrote:
> 
> Tim Wilson-Brown - teor:
>> 
>>> On 27 Oct 2015, at 20:06, Mike Perry  wrote:
>>> 
>>> teor:
 
 On 27 Oct 2015, at 05:41, Conrad Kramer  wrote:
 
>> On Oct 26, 2015, at 11:22 AM, Spencer  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#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_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_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://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-signatures-from-binaries/
> 
> 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 

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

[Conrad Kramer]

> On Oct 27, 2015, at 3:03 PM, Conrad Kramer  wrote:
> 
>> 
>> On Oct 27, 2015, at 5:32 AM, Mike Perry  wrote:
>> 
>> Tim Wilson-Brown - teor:
>>> 
 On 27 Oct 2015, at 20:06, Mike Perry  wrote:
 
 teor:
> 
> On 27 Oct 2015, at 05:41, Conrad Kramer  wrote:
> 
>>> On Oct 26, 2015, at 11:22 AM, Spencer  
>>> 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#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_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_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://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-signatures-from-binaries/
>> 
>> In general, I think external tools are fine, if we can get 

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

[teor]

On 27 Oct 2015, at 05:41, Conrad Kramer  wrote:

>> On Oct 26, 2015, at 11:22 AM, Spencer  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
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Conrad Kramer]

> On Oct 26, 2015, at 11:22 AM, Spencer  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


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

Date: Fri, 10 Jul 2015 01:29:02 -0400
From: Mike Tigas 
To: Mike Perry 
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 , 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 

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

[Conrad Kramer]

> On Oct 26, 2015, at 10:23 AM, Ian Goldberg  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/CodeSigningGuide/AboutCS/AboutCS.html#//apple_ref/doc/uid/TP40005929-CH3-SW1


Conrad


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[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?
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Spencer]

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?

Wordlife,
Spencer

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev