Re: please use signed git commits (and tags)
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 <hmh@debian.org>
Reply to: