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 Wed, 18 Jul 2012 07:47:27 GMT
On 7/16/12 8:18 AM, Jürgen Schmidt wrote:
> On 7/13/12 2:04 PM, Jürgen Schmidt wrote:
>> 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
>>> PPMC?
>>>
>>> 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
>> certificate.
>>
>> 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.
>>
>> Proposal:
>> 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
>> 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.
>>
>> #1
>> The certificate including the private key is installed on this machine
>> and any signing process can get access on the certificate.
>>
>> #2
>> 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.
> 
> any opinions or general feedback?

I know that whatever process we will choose (if we choose one at all) it
will cause some work and I am willing to help where I can. But I am
really interested in bringing this forward and need some feedback or
opinions to continue.

Juergen


Mime
View raw message