On Sun, Jul 5, 2015 at 4:01 PM, William Hubbs <willi...@gentoo.org> 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