Re: please use signed git commits (and tags)
On Mon, May 25, 2015, at 09:54, Tzafrir Cohen wrote:
> On Mon, May 25, 2015 at 10:33:06AM +0200, Bastian Blank wrote:
> > On Mon, May 25, 2015 at 09:51:41AM +0200, Thomas Koch wrote:
> > > On Sunday 24 May 2015 13:02:38 Thomas Koch wrote:
> > > > Git supports signing of commits since version 1.7.9. Everybody should sign
> > > > git commits always.
> > > There is however the argument that by signing every commit by default one may
> > > accidentally publish a signature on some unverified code and somebody else may
> > > trust this code because of this.
>
> What's wrong with that? The signature means that you wrote it. It
> doesn't mean that it is perfect.
Indeed. And it doesn't even mean you authored it, it just mean you are
the commiter. Whether this mean you even read what you were commiting or
not depends entirely on the workflow...
> > Much worse, do you trust all your development machines with your private
> > key? I clearly don't, as I neither have sole control over them, nor are
> > all of them located in jurisdictions I can expect any help against
> > seizure.
>
> With Debian packages I upload I can use debsign to sign a build after it
> was built. Can I sign git commits / annotated tags in retrospect?
Commits: trying to change the signature will change the commit hash.
So, it works just like amending the commit. In fact, "git commit
--amend -S" will sign/re-sign the commit by creating a new commit, just
like any other "ammending" of commits works.
Note that rebase (or anything that changes the commit itself) will cause
it to lose the signature, and I don't think git will ask you to sign
them again.
Tags: you have to delete the old tag, and create a new one. However,
git refuses to modify an already existing tag during fetches, so anyone
that already has the old tag must do a "git tag -d <tag name>" to remove
it, and then fetch again to get the new tag.
Note that references are not signed (signed tags can be renamed being
the less obvious result of this, as people tend to keep in mind that
branches can be moved to point to something else and validade),
ancillary data (such as notes) are not covered by the signature on
commit (and tag) objects, so you can change the notes attached to a
signed object without invalidating that object's signature, etc.
This means that you can rename (or duplicate) a tag without losing the
signature. This _can_ have a security impact: when doing dumb
validation (e.g. in a script), you cannot trust signed tag names, just
contents (such as the tag message).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique de Moraes Holschuh <hmh@debian.org>
Reply to: