bitcoin/bitcoin — pull request #5363 by theuni (2014-11-25 05:02:45+00:00)
Title: Osx detached sign

As discussed a few times in the past, this introduces the notion of a detached OSX signature for release binaries. This produces a final dmg with a signature spliced in. I believe this is as close to determinism as we can get while still signing with a protected key. It also removes almost all margin for error in the build process, since the only variable (the signature) is obviously verifiable.

From the updated readme:
As of OSX Mavericks (10.9), using an Apple-blessed key to sign binaries is a
requirement in order to satisfy the new Gatekeeper requirements. Because this
private key cannot be shared, we'll have to be a bit creative in order for the
build process to remain somewhat deterministic. Here's how it works:
- Builders use gitian to create an unsigned release. This outputs an unsigned
dmg which users may choose to bless and run. It also outputs an unsigned app
structure in the form of a tarball, which also contains all of the tools
that have been previously (deterministically) built in order to create a
final dmg.
- The Apple keyholder uses this unsigned app to create a detached signature,
using the script that is also included there.
- Builders feed the unsigned app + detached signature back into gitian. It
uses the pre-built tools to recombine the pieces into a deterministic dmg.

@gavinandresen has tested and verified that the output dmg's have valid signatures, and run on OSX 10.0.1.

The process to create the key is easy to follow, as is the auditing of the reattachment. It relies on the tools "pagestuff" and "codesign_allocate" which are built from source as part of our standard build process. These tools pad and update the binary as necessary in preparation for the signature. Then, a dumb "dd" is invoked to patch it in.

I've changed the release-process to reflect a possible workflow using this detached signature. I suspect we'll probably have to run a real (beta) release to see where the kinks are and what could be improved.