www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Official code signing certificate
Date Mon, 25 Jun 2012 16:47:21 GMT
On Sat, Jun 23, 2012 at 11:08 PM, Dave Fisher <dave2wave@comcast.net> wrote:
>
> On Jun 14, 2012, at 1:57 AM, Jürgen Schmidt wrote:
>
>> On 6/13/12 10:35 PM, Sam Ruby wrote:
>>> On Wed, Jun 13, 2012 at 3:52 AM, Jürgen Schmidt
>>> <jogischmidt@googlemail.com> wrote:
>>>>>
>>>>> The questions are
>>>>> 1. how can we get an official valid Apache code signing certificate
>>>>> 1.1 which steps are necessary because it is not for free
>>>>>
>>>>> 2. how can we use it in our build process or better how can we make it
>>>>> useable for a limited group of users (I would say at least 3 PMC members
>>>>> to have enough fall backs) to sign the final releases.
>>>
>>> Before spending any more time on this, Jürgen would it be possible for
>>> you to find answers to this outside of an ASF context?  Specifically,
>>> is there somebody who knows how to get such a certificate and what it
>>> would cost, and what it would take to use it?
>>>
>>> Note: the final solution may not be that it is PMC members that are
>>> the ones doing the signing.
>>
>> many emails over night and many speculation how easy or complicate it
>> would be to do the signing in a reliable build process without too much
>> manual work.
>>
>> As I mentioned we did code signing before and we did it during our build
>> process. Only few people at Sun/Oracle had access to the certificate
>> private data.
>>
>> I m trying to figure out how exactly the technical process worked with a
>> test certificate and based on this information it will be potentially
>> easier to define a possible workflow.
>>
>> I will come back with further information.
>>
>> Juergen
>>
>> Site note: AOO binaries are essential for our broader user base, they
>> are not interested in source releases and they are not able to build an
>> office on their own. Keep in mind that AOO is an end user oriented
>> application. It's a new kind of application here at Apache but the
>> number of downloads are telling enough about it.
>
> AOO does have buildbots in place. Certainly these can be adapted to add the correct "signtool.exe"
commands at the correct locations in the build. At least that's how it worked for an Excel
Add-in that my team at work produced in VisualStudio 2008 a few years ago. Execution of that
step could somehow take into account whether or not an Apache Infra contractor was initiating
this cycle of the build. In other cases for "non-offical" builds certificates with less authority
could be used.
>

And how do we know we're signing the right stuff?

The weakest link here is that any commiter can upload a patch that
changes the make file to sign something else.  This could be something
inserted into the main exe of the project, but also new exe's added by
the patch.   Of course, Apache committers don't do these sorts of
things, but those who buy stolen laptops, or hack into LinkedIn and
grab password hashes, or guess what your pet name is, those kinds of
people might do this.

Of course, we have an audit trail in the form of commit logs.  That is
one level of protection.

But this still seems like just a more complicated version of a signing
service where any committer can upload a EXE and get a signed version
back.  We could have an audit trail there as well.  But it is still a
black box.

So you would need some additional protection, like signing-enabled
builds only occur against specific tags or revision numbers where
someone (a committer?  Release Manager?) requests it.  But if I
already have your LDAP password I can also send emails on your
behalf....

So, you would need a confirmation from Infra sent to the project dev
list, stating the request, as well as giving sufficient time for
someone in the PMC to confirm that the request is proper, review
recent check ins, etc.  Or some equivalent ACK.

Another level of protection would be to not return the signed code
immediately, but to hold it in some guaranteed location for a period
of time, for the PMC to confirm it was requested.  If it were totally
up to me, I wouldn't release any signed code until I had it guaranteed
for a week to make sure it was not infected in some new zero-day virus
exploit.  Wait for the next anti-virus signatures to come down.

I don't have all the answers here, but I hope the issue is clear;
when a PMC votes on a Release Candidate, that is when they typically
do their last round of checks;  are all the recent check-ins kosher,
is anything found on anti-virus scans, etc.  If we do the code signing
before those checks, then we have some additional risks.

Finally, consider that it is common for security patches to be checked
in last-minute before a Release Candidate is built.  This is to avoid
premature disclosure.  So we should expect last-minute checkins in
security-sensitive areas of the code right before someone requests a
signed build.  Are these legit?  Or has someone gained a committer
login and just put a trojan into the code and requested a
signed-build?

Does anyone see a way of solving this other than by adding a 72-hour
delay?  Either 72 hours between proposing a signed build and Infra
building it, or between Infra building it and released a quarantined
file?

-Rob



> Regards,
> Dave
>
>
>>
>>
>>
>

Mime
View raw message