Re: Official code signing certificate

[Jürgen Schmidt <jo...@gmail.com>]

Hi,

it's time to come back to this and I noticed the wiki page

http://wiki.apache.org/general/ASFCodeSigning

which is more or less empty but seems to be the place to collect the
requirements and everything that is related to this topic in a central
place.

I would like to add some content on this page but need editing
permission to this page. Can anybody grant me the necessary permission,
user "JuergenSchmidt"

Thanks

Juergen


On 6/26/12 1:13 AM, Dave Fisher wrote:
> 
> On Jun 25, 2012, at 9:47 AM, Rob Weir wrote:
> 
>> On Sat, Jun 23, 2012 at 11:08 PM, Dave Fisher <da...@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
>>>>> <jo...@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?
> 
> I think that you are seeing more problems than what we are trying to solve here.
> 
> I think some of what Sam Ruby has written here applies:
> 
> On Jun 23, 2012, at 7:08 PM, Sam Ruby wrote:
> 
>> On Sat, Jun 23, 2012 at 10:03 PM, Scott Deboy <sc...@gmail.com> wrote:
>>> I am making the assumption that Infra are generally busy folk and are
>>> generally focused on keeping machines running and putting out fires, and
>>> would rather not be pestered by those wanting release candidates
>>> generated.  I can tell you from my limited personal experience in dealing
>>> with infra folk that I would rather not be the one pestering Infra to get
>>> anything done.
>>
>> I'll simply state that there is a huge difference between "here is a
>> vague and undefined problem, please solve it for me" and "here is a
>> well defined task which needs to be performed".
>>
>> - Sam Ruby
> 
> I would suggest that using our buildbot with self-signed certs as Jürgen is working towards will allow Infrastructure to see a well defined problem.
> 
> In the end your conclusion that there might be some delay for world spinning and global issues to be a fact. This just adds to the world spinning required to populate the Apache mirrors on a release.
> 
> Another similar nugget from Sam:
> 
> On Jun 23, 2012, at 6:45 PM, Sam Ruby wrote:
> 
>> On Sat, Jun 23, 2012 at 9:36 PM, Scott Deboy <sc...@gmail.com> wrote:
>>>  - I don't think Infra wants to be pulled in every time a release candidate
>>> is requested
>>
>> There undoubtedly is a reason why you are making that assumption, but
>> I can't see anything that has been said to date which would lead you
>> to that conclusion.
>>
>> My experience is that build environments may take a bit of work to set
>> up, but the marginal effort to produce an nth+1 build is small.
>>
>> But we are probably well past the point of diminishing returns for
>> discussing this problem in the abstract.
> 
> Can we please go step by step?
> 
> Here are the points:
> 
> 1) What to sign.
> 2) When to sign.
> 3) How to sign.
> 
> 1 and 2 are something that the project must determine and they are both clearly part of the build.
> 3 is for Infrastructure to determine.
> 
> I would suggest that part of voting for a release ought to include building for yourself. If you do that you'll decrease your concern about "gremlin" committers.
> 
> Thanks & Regards,
> Dave
> 
> 
> 
>>
>> -Rob
>>
>>
>>
>>> Regards,
>>> Dave
>>>
>>>
>>>>
>>>>
>>>>
>>>
> 

Re: Official code signing certificate

[Bertrand Delacretaz <bd...@apache.org>]

On Fri, Oct 5, 2012 at 11:32 AM, Jürgen Schmidt <jo...@gmail.com> wrote:
> ...it's time to come back to this and I noticed the wiki page
>
> http://wiki.apache.org/general/ASFCodeSigning
>
> which is more or less empty but seems to be the place to collect the
> requirements and everything that is related to this topic in a central
> place....

Yes, that was the idea - I created that page, prompted by discussions
between (mainly) OpenOffice and Flex people and infra, but apparently
no one took the bait yet.

-Bertrand

Re: Official code signing certificate

[Daniel Shahaf <d....@daniel.shahaf.name>]

Jürgen Schmidt wrote on Fri, Oct 05, 2012 at 11:32:10 +0200:
> user "JuergenSchmidt"

done