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 Sat, 23 Jun 2012 13:48:35 GMT
On Fri, Jun 22, 2012 at 1:27 PM, Scott Deboy <scott.deboy@gmail.com> wrote:
> I would like to point out that the Chainsaw project in Logging Services
> also has a need for a code signing certificate in order to be deployable as
> a Web Start application.
> I filed https://issues.apache.org/jira/browse/INFRA-3991 last October to
> request this support, but there has been no response to the issue.

IMHO the question is not if, but when we start signing code this way.
As we all know Apache releases already come with detached PGP/GPG
signatures.   We already acknowledge the importance of this, both for
source and for binary packages.

And operating platforms also have seen the value of digital
signatures, to improve security.  For end users, however, instead of
being based on a "web of trust" model like we have traditionally done
at Apache, the platform vendors have adopted hierarchical approaches,
using root CA's, etc.  This is not wrong, it is just different.  But
that is the way it is done on Windows, in browsers, in virus scanners,
etc.  If you want decent platform integration in the Windows world
then you need code signing.

Three basic ways we could go about this:

1) Certificates acquired and managed by each PMC individually.  They
generally have the means to keep the certificate reasonable private
(store in PMC's private SVN, with a passcode known only to Chair and
Release Manager, for example).  This also limits the exposure if
control of the certificate is lost.  In other words, revoking the cert
would only harm that one project.  It would not spill over to other
projects.  Process-wise, normal builds could be done with a test
certificate, and then the Release Candidate could be signed with the
real signature.  So essentially same process as we do today with
detached signature, just adding a code signing step before generating
the detached signatures on the Release Candidate.

2) Do certification at ASF-level, with cert controlled by Infra.
This could be done, e.g., with a signing web service or command line
service available via ssh.   Access controls are limited to
PMC-designated Release Managers.  (Web service would be easier to
integrate into a build).  Log everything, send signing actions to
appropriate Infra or project commit lists, etc.

3) A variation on #2:  Have the ASF become a CA so it can issue its
own certificates.  Authenticode certs are not cheap == USD 400 or so
per year.  If every project needed one, that adds up.    Or maybe it
would make sense to collaborate on this among other OSS foundations
and have a common CA for open source projects, controlled by, say,

> Scott

View raw message