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 <h...@debian.org> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1432572808.620926.277616689.2bf16...@webmail.messagingengine.com
