www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J├╝rgen Schmidt <jogischm...@googlemail.com>
Subject Re: Official code signing certificate
Date Fri, 13 Jul 2012 12:04:00 GMT
On 6/13/12 11:44 PM, Sam Ruby wrote:
> On Wed, Jun 13, 2012 at 5:18 PM, Dennis E. Hamilton
> <dennis.hamilton@acm.org> wrote:
>> Thanks Tony,
>> It is valuable to know that everyone's on the same page in a discussion such as this.
> Just so we are on the same page: for context there was an unscheduled
> outage today that affected quite a number of core infrastructure
> services.  So while this request is an important one, the primary job
> of the infrastructure contractors is keeping our machines up and
> running.
> Meanwhile, there are important things that need to be investigated,
> and not all of them need to be done by ASF infrastructure contractors.
>  For example, as Roy suggests, is there a third party who would be
> willing to do the signing, and would that be acceptable to the AOO
> Furthermore, can the AOO PPMC make a proposal along the lines of Roy's
> second email: "a secure build environment by which a person under
> contract with the ASF can produce a binary artifact, and then a
> process by which a distributed group of volunteers can adequately
> verify the binaries that were built."?
>> I think there are two matters that need to be dealt with beyond coming up with the
funding, <https://www.symantec.com/verisign/code-signing/microsoft-authenticode/buy>:
> If the price is as stated there: $499 US for one year for one
> certificate, if it looks to me like there is promising work to address
> the questions stated above, then I will authorize such a purchase.
> Clearly should this all work out, we likely will want to have more
> than one certificate for more than one year down the road, but we can
> worry about that in the next budget cycle.
>>  1. Designation of contacts and initial custody of the certificate.
> The infrastructure team has other certificates that they manage.  My
> initial take is that this is something that we will not hand out to
> PMC members, but would be managed by our existing contractors.  If
> that is not acceptable, please explain why.
>>  2. Creation of some custody arrangement for the private key and a way to accomplish
the signing at an appropriate place in the development of signed artifacts that go into a
release.  Getting a certificate is easy, apart from the chain of custody and who keeps them
safe.  Structuring the setup of release artifacts so that the code is signed as needed is
the biggest speed bump that I see.
> I like Roy's outline better.  The AOO PPMC designs a build environment
> that can be verified and implemented by ASF contractors.  The AOO PPMC
> validates the output of that process before distribution.
> Tell me that can be done, or why that is not possible, or describe
> something better.

I would like to follow up on this because we still need a solution ;-)

@sam: I think you have already figured out the how much such a
certificate would cost.

Taken into account that only paid ASF staff member can have access to
the certificate, I can provide 2 proposals that can work from my
perspective. If they are really useful and practical is a different
story and I can't answer it. They will definitely increase the workload
on some paid ASF members that of course is not in my interest.

Both proposals are very similar and only differ in the handling of the

AOO is very huge and the build process is much more complex than for
many other projects. This point is not optimal and we all know it but it
can be solved only long term (no further discussion on this topic
necessary and useful here. Interested people who want to help can join
the ooo-dev list).

To reduce errors or mistakes the most promising approach is to include
the signing 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.

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! I don't give comments if the machine is
accessible via network or not because this includes also some security

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

The information about the setup of such a dedicated Windows machine and
the AOO specific build requirements are documented and of course AOO
project members would help with the setup if they get temporary access
or would provide at least support.

I hope that is the information you are looking for.

Side note:
The other approach which is secure from my perspective as well is to
support project specific certificates and allow only a few trusted
people (e.g. release manager, project chair) access to the files.
Projects have to take care of their own dedicated build machines with
limited net access (to get the sources) for example.
It can be of course a mixed solution where projects with different
demand will be handled differently. A project where only a jar file have
to be signed can be handled of course different compared to AOO where we
have a complex multi step signing process with hundreds of files.

I am looking forward to feedback.


View raw message