Re: Gnome.org's crypto infrastructure

[Ray Strode <halfline gmail com>]

Hi,

> * GNOME releases tarballs of source code.  Maintainers regularly post
> checksums of their tarballs along with their announcement emails.  Until
> now, I'm not sure if we have had the need to *guarantee* that a
> particular release of code is authentic.  For example, we don't actually
> crypto-sign tarballs like the Tor project would --- in their case,
> whoever downloads the code *really* wants to ensure that it hasn't been
> tampered with.  Again, I'm not sure if we have such kind of
> security-conscious code, but maybe we could start crypto-signing our
> tarballs.  Which brings me to...

One thing that would be really neat (imo) is if instead of maintainers
pushing tarballs to master.gnome.org and running ftpadmin manually,
they instead pushed a "git-tag -s" GPG signed tag of a specific naming
scheme (maybe an rc suffix, e.g., "3.13.4-rc1"), and then an automated
release-team VM would notice the tag, check out the tarball, run "make
distcheck" and if it all passed muster, push a final tag (e.g.,
"3.13.4") signed with a release-team key, and then push the tarball to
master.gnome.org.

A few downsides:

1) make distcheck often fails, and this model sort of encourages
maintainers to "fire-and-forget" when making a release instead of baby
sitting it to the end

2) The system would have to be implemented, and it's a non-trivial
amount of work to implement

3) It might mean keeping a release-team private key with no password
on a VM connected directly to the internet.

a few upsides:

1) tarballs would be generated with a standardized set of autotools,
instead of whatever the maintainer happens to have installed

2) "make distcheck" would be run on a fresh checkout of the source, so
it would eliminate a failure mode where some left over bits in the
maintainers working tree made things work even when the pushed git
tree itself is missing files.

3) all the tarballs would be signed with an "official" key

--Ray