Automated ASF GPG signing

[Christopher <ct...@apache.org>]

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:
https://fedorahosted.org/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.

Re: Automated ASF GPG signing

[Daniel Ruggeri <DR...@primary.net>]

It seems reasonable to me to tack code signing onto the end of CI builds
from the likes of buildbot and Jenkins. You can then restrict your code
signing service to the robots and avoid the pesky problems humans
introduce into the process.

-- 
Daniel Ruggeri

On 2/25/2016 1:57 PM, Christopher wrote:
> 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

Re: Automated ASF GPG signing

[Christopher <ct...@apache.org>]

On Thu, Feb 25, 2016 at 2:10 PM Shane Curcuru <as...@shanecurcuru.org> 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:
> > https://fedorahosted.org/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?
>
>   http://www.apache.org/dev/release.html
>   http://www.apache.org/dev/release-signing.html
>
>
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:
>
>   https://reference.apache.org/pmc/codesigning
>
>
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
service.

Re: Automated ASF GPG signing

[Shane Curcuru <as...@shanecurcuru.org>]

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:
> https://fedorahosted.org/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.

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?

  http://www.apache.org/dev/release.html
  http://www.apache.org/dev/release-signing.html

The ASF does have a central code signing service for Windows binaries
and JARs supported by Symantec, although it's not widely used yet:

  https://reference.apache.org/pmc/codesigning

- Shane