Re: Gnome Flatpak build system, descriptions and questions

[Alexander Larsson <alexl redhat com>]

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 
       alexl redhat com            alexander larsson gmail com 
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!