Re:'s crypto infrastructure


* 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 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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]