community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: Automated ASF GPG signing
Date Thu, 25 Feb 2016 19:57:30 GMT
On Thu, Feb 25, 2016 at 2:10 PM Shane Curcuru <> wrote:

> Christopher wrote on 2/25/16 1:47 PM:
> > I'm not sure where exactly this discussion should fit, but I know people
> > have brought up questions about ASF-wide signing of artifacts before, so
> > I'll just mention it on this list.
> >
> > Fedora infrastructure has built a project called sigul:
> >
> > which they use as part of their infrastructure to automate signing of
> RPMs
> > and ISOs and such.
> >
> > ASF could set up a similar service for ASF-wide release signing.
> >
> > This particular project looks like it has a GPL2 license on it, and I'm
> not
> > sure what the policy is for Fedora infrastructure, but for Fedora
> > packagers, contributions (under their ICLA) are MIT, so it's possible
> that
> > if we wanted to use this, and provide ASF-wide release signing, the
> Fedora
> > community would be willing to re-license under MIT if that were necessary
> > for us to consider using it.
> >
> Interesting point.  The first question is: what Apache projects want to
> do something like this?  While volunteers can work on whatever new ideas
> people like working on, we don't tend to build officially supported
> services (especially security-related ones!) unless there are some
> specific PMCs that ask for it.
I think the main reason why we would want to use something like this has
been expounded before, but in short, the idea is that it makes it easier
for downstream users to trust ASF releases, rather than being required to
trust individual developers's code-signing key. This would improve user
confidence in a release.

On the other hand, using centralized keys would increase the impact of a
key compromise if such a thing were to occur. But, at least we could
mitigate and prevent key compromise a bit better than what most users are
probably doing today.

> Once there's some interest from projects, it's a question of figuring
> out a draft plan and seeing if the security and maintenance are
> something the ASF and our small but awesome infrastructure team would be
> willing to host.
> Also, have you read through the Apache release policy and signing
> details to see exactly how this would fit?
I think the idea would be that if we were to do something like this, it
would run as an authenticated service, and return a signature for files
uploaded to it upon request. It would replace the need for individuals to
generate and use their own GPG keys.

The tricky part would be to establish policy and enforcement of its use for
ASF-releases only. It would probably have to be used for release candidates
also. It would obviously have to be locked down to release managers, but
who are the authorized release managers (PMC, committers, other?), and how
does one tell what is an authorized release artifact? Trust of the system
might have to rely on audit logs and policy, rather than strict
enforcement, which isn't idea.

A related service could possibly be set up, so instead of pushing directly
to the mirrors, uploading to dist would trigger signing? We'd also probably
need to address uploading to the Maven Central staging repositories. For
Maven projects, a maven plugin could easily be written which uses this
service and replaces the maven-gpg-plugin. It could also be done on deploy,
en route to the staging repositories.

An alternative implementation would be that this service would escrow keys
not just for ASF-wide, but also for per-project(PMC), so there could be a
single trusted key per project.

The ASF does have a central code signing service for Windows binaries
> and JARs supported by Symantec, although it's not widely used yet:
This would wouldn't replace those, but it would provide a similar
centralized trust mechanism for GPG signatures which would be suitable to
replace the existing release-signing practices. It'd probably be cheaper to
provide than the Symantec service, and would perhaps limit the number of
users who have an interest (but not an essential requirement) for that

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message