On fre, 2016-08-26 at 18:44 -0400, Christophe Fergeau wrote: > Hey, > > On Fri, Aug 26, 2016 at 11:21:05AM -0500, Michael Catanzaro wrote: > > > > On Fri, 2016-08-26 at 11:48 -0400, Shaun McCance wrote: > > > > > > IIRC, git.gnome.org won't let you push an unsigned tag. > > I've been doing it for a while, so it most certainly does! I don't > > see > > value in signing our tags as (a) clearly nobody is checking the > > signatures, and (b) we don't currently have any centralized > > registry of > > trusted keys, so it's not possible to know which signatures to > > trust > > anyway. > For what it's worth, if all the tags are signed with the same GPG > key, that's imo better than no signature at all. You could also add a > line to your release email saying that the tag(/the release tarball) > have been signed with the GPG key with fingerprint xxx. Even if your > key is not in a centralized trust registry, this makes it harder to > mess with the tags after the fact for someone who don't have access > to your key.
Yes, some people sign tags for releases. I know I do. My signature is not in any trust registry though, so its less than ideal, although, as you say, better than nothing. For instance, you know the same person made all the releases. However, the problem is that we can't a-priori tell what key will sign a particular release tag (or if it indeed will be signed at all). That makes it very hard for a structural approach at origin verification. I would like to say "for the stable branch, build the latest tag in the the gnome-3-20 branch that has been signed with one of these keys". The set of keys could be a list of all the maintainers of the module, although even better would be a single key for "the release team". Actually, git tags just sign the tag hash value, which conceptually is just a sha1 of the contents, and sha1 is not considered super strong. This made walters create git evtag: https://github.com/cgwalters/git-evtag This is a separate tool that does a stronger deep checksum of a tag, storing this as a note. Such a note extends the commit without modifying it and can be added after the commit was made. So, in the ideal world, i think all developers should sign their tags, with a signature that is known to the release team. Then the release team verifies that the releases are signed by a maintainer, or otherwise trusted person, and then makes adds a git evtag for the release tag with a well-known release-team signature. That would make it pretty easy to verify to a decent degree the authenticity of the release. (I mean, anyone with commit-rights could sneak in some dubious commit during the development phase, but at least you can't do a MITM attack and replace the code post-release when you git pull.) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc [email protected] [email protected] He's a superhumanly strong drug-addicted paramedic with a passion for fast cars. She's a time-travelling Bolivian Hell's Angel living on borrowed time. They fight crime! _______________________________________________ gnome-os-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-os-list
