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 Mon, 25 Mar 2013 22:56:06 GMT
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>
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?
> 

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.

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).

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

Mime
View raw message