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 Mar 2013 16:06:13 GMT
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> wrote:
>> > 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>
wrote:
>> >> > 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 company
>> >> > 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 to
>> >> 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?

Perhaps the flow is like this:

1) RC built by buildbot and that records the SVN revision.

2) Three PMC members sign the RC

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


> 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

Mime
View raw message