www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: Official code signing certificate
Date Fri, 22 Mar 2013 16:57:13 GMT
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 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