On Sun, May 24, 2015, at 11:12, Iain R. Learmonth wrote: > On Sun, May 24, 2015 at 01:02:38PM +0200, Thomas Koch wrote: > > Git supports signing of commits since version 1.7.9. Everybody should sign > > git > > commits always. > > What is the overhead on this?
As far as git metadata goes, it is small enough not to matter: the size overhead is the same of a detached gpg signature (ascii armored) plus a few bytes, so it will usually be less than one extra kilobyte per signed commit. It is stored in the commit object itself as an extra internal header, so it does not increase the number of objects in the repository. Signed tags must be a tag object instead of just a reference, but this is already the case of any tag that has a comment. The signature overhead itself on a tag object is about the same as the one for the signature in a commit. As far as the procedure goes, one most likely will need to use a gpg key agent so that she won't have to type a passphrase unlock the key once per signature. I always configure the agent to request confirmation on every use of the key (which takes considerable less effort than typing the full passphrase at every use of the key): if one doesn't do this, a rogue program could easily connect to the agent's socket and sign or decript things without his approval. A reasonable amount of examples and possible workflows related to distributed development using signed commits, merges and pull requests should be available through google searches (in English). One will benefit from the much newer git available in Debian Jessie for workflows with signed merge/pull requests. One must properly use gnupg subkeys and safe master key handling procedures though, to keep key exposure risk under control. This is nothing new in Debian: you are already expected to do it like that anyway. > I sign tags when I remember (which isn't often I'll admit) but signing > every commit is maybe a bit much? Actually, not even signing tags properly is more than just a bit too *little* for the more common cases. That said, one doesn't have to sign every commit: it really depends on the workflow. It is enough to sign the top commit of every branch (this is, evidently, not needed when the top commit is itself tagged with a signed tag) which could have been tampered with. For example: in my workflows, I always do a line-by-line review of the diff for the entire branch content *right before* publishing it, and that includes a "git log -p" review of every patch and commit log message, not just the complete diff. Because of that, I can get away with signing just the top commit of the branch using "git commit --amend -S" at that point in time. > My local git copy that I do development on is trusted, and by signing a > tag you can verify every commit up to that tag. Does your workflow ensure no rogue changes (however they came into being) are ever pushed/merged? How do you ensure that every branch which doesn't have a signed tag for their top commits are trusted, especially in remote copies? -- "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/1432557698.572263.277409465.481e2...@webmail.messagingengine.com