www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J├╝rgen Schmidt <jogischm...@gmail.com>
Subject Re: Official code signing certificate
Date Tue, 26 Mar 2013 09:40:57 GMT
On 3/25/13 11:56 PM, Daniel Shahaf wrote:
> Rob Weir wrote on Mon, Mar 25, 2013 at 12:06:13 -0400:
>> On Fri, Mar 22, 2013 at 12:57 PM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>>> Rob Weir wrote on Fri, Mar 22, 2013 at 10:44:45 -0400:
>>>> On Thu, Mar 21, 2013 at 6:18 PM, Daniel Shahaf <d.s@daniel.shahaf.name>
>>>>> Rob Weir wrote on Thu, Mar 21, 2013 at 11:35:21 -0400:
>>>>>> On Thu, Mar 21, 2013 at 9:09 AM, Daniel Shahaf <d.s@daniel.shahaf.name>
>>>>>>> For example: does releasing software under a certificate Microsoft
>>>>>>> pre-trusts (or into an app store Apple moderates) subject ASF
to an
>>>>>>> indemnification clause towards that company?  Does it grant the
>>>>>>> a license to use our trademarks in advertising?  Does it compel
ASF to
>>>>>>> offer warranty to end-users?
>>>>>> I believe that we'd be required to make some sort of assertion that
>>>>>> our code does not contain intentionally malicious software, but I
>>>>>> don't know the details of that statement.
>>>>>> In any case, if possible, let's focus on the Infra side of this here.
>>>>>> We should separately review the language of any agreements we need
>>>>>> sign with Legal Affairs and/or the Board.
>>>>> Technically I don't imagine there's much question here.  You guys
>>>>> already have code that builds+signs, the ONLY thing it's missing is a
>>>>> file containing an X509 signing cert signed by somebody whom Windows
>>>>> trusts by default, right?  Once we obtain such a file, is there any
>>>>> reason we won't be able to put it on a VM and run your code inside that
>>>>> VM against that file?  I expect not, so I'm moving on to the legal
>>>>> sides.
>>>> The remaining question would be if we need any safeguards against
>>>> hypothetical compromised committer accounts.
>>>> I think we want to avoid something like this:
>>>> 1) Someone acquires login credentials for a committer, e.g., they use
>>>> the same password at Apache as they use for some other web service
>>>> that is hacked.
>>>> 2) They check-in a backdoor into the code
>>>> 3) Before CTR finds the problem the buildbots have built and signed
>>>> the executables and the hacker has downloaded them.
>>>> 4) We have malicious code now distributed signed with the Apache certificate.
>>>> So from a process view, we might want to have routine builds be signed
>>>> with a placeholder test certificate (essentially self-signed) and this
>>>> test certificate is in SVN.    The real signing certificate would only
>>>> be applied on Release Candidates and with additional safeguards.
>>>> Maybe the request needs to come from the PMC Chair or the Release
>>>> Manager?  Or some time must elapse between the date of the SVN
>>>> revision and the signing?
>>> How about only signing with the real certificate once three PMC members
>>> PGP-signed the binaries-built-against-the-self-signed-certificate.
>> I like the idea of having multiple PMC members attest to the RC, by
>> signing or whatever.  But we still would need to tie that back to a
>> SVN revision number somehow.   In other words, how we do prove the
>> revision number that was used to build the RC?
> Can't we just keep the working copy that built the original binaries
> around (for say four weeks) and run 'make' in it again, pointing the
> build to a different certificate?
> Maybe we should umount the build tree while the human verification is
> happenning.
>> Perhaps the flow is like this:
>> 1) RC built by buildbot and that records the SVN revision.
>> 2) Three PMC members sign the RC
> For clarity: PGP-sign.
>> 3) Comparison of the MD5 hashes for the signed RC and the buildbot
>> output confirms the revision that was used.
>> 4) Infra then releases the signing cert for use by buildbot automation
>> to rebuild the same revision
> Well that works but it has more moving parts: the artifacts need to
> encode the path@rev they were built from and then the build process has
> to extract those.  Also the build process uses a new working copy so
> it'll rebuild everything from scratch: that (a) takes longer,
> (b) subjects you to the risk of upgraded system dependencies (libc, gcc,
> etc.) used in the new build.

the baseline of the dedicated build machines should be maintained
carefully. We for example build on special Linux systems to ensure that
our binaries are worked on as many as possible Linux distros.

We in AOO retrieve already the svn revision during the build process and
put this information in the about dialog for reference. And we retrieve
"Last Changed Rev: *******" in our AOO related tree to avoid confusion.

> Can you write this all down somewhere?  A wiki page maybe, or a *.txt
> file under (a new dir under)
> https://svn.apache.org/repos/infra/infrastructure/trunk/projects/
> (world-readable subtree).

everybody is free to extend additional information on the already
started wiki page http://wiki.apache.org/general/ASFCodeSigning

I don't think we need a further one. By the way this page is not new and
was proposed weeks ago to collect requirements and general information.
One reason why I have restarted the discussion in this thread.


> Cheers
> Daniel
>>> I follow the rest of your logic, makes sense.
>>>> You might think that we'd vote on the RC and only sign it after that.
>>>> But that doesn't work because the signature is applied at multiple
>>>> levels of the packaging.  So the individual EXE and DLL's are signed,
>>>> as well as the installer and the outermost archive packaging.
>>>> One option would be to vote to approve the RC and then rebuild the
>>>> exact same revision that was approved, with no other changes than
>>>> replacing the test cert with the real signing cert.
>>>>> And yes, I do need to at least think of the legal side before I start:
>>>>> if, say, Company X's terms include a use-in-advertising license and VP
>>>>> Brand vetoes that, then there's no point in burning Infra cycles on
>>>>> thinking of how to make it work with Company X.
>>>> Dennis gave a link to the Symantec agreement.  I don't see any
>>>> trademark or advertising related clause.  But we obviously need to
>>> Oh, thanks.  I missed that in his email.
>>>> make a thorough review.  There are other CA's as well who might offer
>>>> different terms.
>>>> Regards,
>>>> -Rob
>>>>>> Regards,
>>>>>> -Rob

View raw message