Re: [gentoo-dev] signatures in git work flow

[Rich Freeman]

On Sun, Jul 5, 2015 at 4:01 PM, William Hubbs <williamh@g.o> wrote:
>
> I've been hearing lately that the newest versions of git allow you to
> sign pushes.
>
> Once we have a version of git stable that allows this, can someone fill
> me in on why we would need to sign commits if we sign pushes? If we have
> a signature on the push, we know where that came from, so it seems to be
> overkill to sign the commits as well.
>

Those push signatures aren't actually exposed to users, and I'm not
sure if they're really even a part of the repository, but more like a
log item.

This is a bit like saying "why do we need signed manifests when devs
already need an ssh key to commit to cvs?"  Push signatures are just
another form of authentication for pushing.  Commit signatures are
bound to the specific changes, and follow the code around if it gets
branched/merged/etc (but not rebased).  Pushing and committing aren't
really the same thing in git, though our single-master workflow tends
to make them seem interchangeable.

That's my general sense of it.

All the gpg stuff really exposes the weakness of git being based on
sha1 though.  I wouldn't think that it would be that hard to change
git's hash function, with the caveat that the resulting repositories
might not be backwards-compatible.  Just change the various headers
from "blob" to "blob-sha256" and so on - the compacted file formats
might require a tweak and should have a field added for hash type
anytime a hash is used.  The old commits with signatures/etc would
still be valid - they'd continue to be named by their sha1 hashes and
references to them would use a blob/tree/parent/etc header instead of
a blob-sha256/tree-sha256/parent-sha256 header and so on.  For
compatibility make the default to stick with sha1 and the old file
formats on an old repository unless a setting is set on it, and
deprecate the format.

-- 
Rich