|Deletions are marked like this.||Additions are marked like this.|
|Line 7:||Line 7:|
|See also discussions at http://markmail.org/message/563pqolcpclbb5tx||See also:
* Discussions at http://markmail.org/message/563pqolcpclbb5tx
Several projects need to be able to sign binaries, this page is meant to collect requirements and discuss potential solutions.
See also http://www.apache.org/dev/release-signing for currently used tools and processes.
See [ContributorsGroup] for how to request write access to this page.
Discussions at http://markmail.org/message/563pqolcpclbb5tx
It would be good to focus on actual requirements here, without mentioning tools at first if possible: why do we need to sign binaries, and what are the core requirements.
Please include your name/project name in parentheses if needed, to clarify who needs what. Or maybe start with one sub-section per project and compare/merge later.
New versions of operating systems (eg. Gatekeeper on MacOS Mountain Lion, Windows 8) introduce new features to check against malicious software. Or the distribution of software for these systems moved more and more in closed app stores. Public distribution or the distribution via app stores requires nowadays often that the binaries (or binary artifacts) are signed by a trusted source. If the binaries are not signed proper the user gets anoyed with unexpected dialog boxes asking for trusting the application, add exceptions or something similar. The typical end-user is often unable to cope with these things.
On Windows you need a code signing certificate that is based or contains a trusted certifcate chain or a trusted root certificate. On MacOS Mountain Lion you need developer ID certificates for public distribution and distribution certificates for submitting to the Mac App Store. It looked that Apple is requiring special Apple certificates, this has to be evaluated exactly. An interesting article how Moziall faces the code signing requirement on MacOS can be found under . General information about the Gatekeeper and Developer IDs under  and code signing for MacOS under 
Project specfic requirements
Apache OpenOffice (AOO)
AOO is an end-user oriented product and the project provides besides the offical code release binary releases for convenience of their huge user base (~28 million downloads since April 2012 until Dec. 13th, 2012) where the majority is not able to build the office on thier own. Code signing for example for Windows is done in in a multiple step process, that means libraries are signed first and packaged in cab files, cab files are signed and packaged in a self extracting setup that is signed finally. We talk here about many, many files that are signed in the first step and the signing is deeply integrated in the build process.
Existing solution in Apache OpenOffice today
Based on the more complex and multi-step signing process in AOO the signing is included in the build process directly. Currently the AOO build process have support for signing using a certificate *.pfx + a pass code. A process that worked in the past and was used by Oracle internally when the released bits were created. But this process can be adapted to use a specific certificate store on a dedicated build machine.
One proposal by example of Windows and AOO
The proposal will be described by the example of AOO. But can be applied on other projects who have demand for code signing as well!
Set up a dedicated Windows build machine that has all the AOO build requirements installed and AOO can be build like on a build bot. It can be of course a special build bot. Only specific and authorized people have access to this machine! No further comments if the machine is accessible via network or not because this includes also some security risks.
When AOO plan to release a new version the project will request an official build based on revision XY. The code version will be checked out and build in the same way as on the build bots + some special switches to enable code signing. The final bits will be verified by AOO project members and as final step they will be signed by the release manager as always (sha, asc, md5) and uploaded. Potentially several iterations are necessary depending on the voting process on the RC's.
- The certificate including the private key is installed on this machine and any signing process can get access on the certificate.
- The certificate is provided as a *.pfx file + pass code and is made accessible to any signing process. The pfx file can be stored in a secure place on this machine or on an external cryptographic device