Andy Parkins <andyparkins@xxxxxxxxx> wrote:
> I was just talking to another developer in my office about version control.
> He's working with Windows so has chosen Monotone for a version control
> system. I didn't have any huge objections, as I'm sure monotone can be
> migrated to git without much trouble (they look to support the same features
> from my brief reading).
>
> Of course my favourite is git, but we were talking about the certificates
> needed by monotone for each developer. I assume that monotone therefore
> signs every commit. It obviously crossed my mind as to how one would do that
> with git? We obviously already have the ability to sign a tag, but is there
> a way in which one could sign every commit.
>
> The more I think about it, the more it could be a reasonable question. In my
> own repository I can obviously create whatever commits i like, claiming them
> to be from whomever I like just by altering a few config settings. If I put
> a few of those in my own repository and then managed to persuade Junio to
> pull from me - wouldn't I have faked commits from another developer?
> However, I wouldn't be able to fake a gpg signature.
You could sign the content of the raw commit and include the signature
in the payload, much like we do with tags. E.g.:
tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
parent 5064201cfd47822e567456fb1d6a76a5e81da800
parent e6987d056595deace8cba91ce0a2524bb91770a9
author Shawn O. Pearce <spearce.org> 1168855184 -0400
committer Shawn O. Pearce <spearce.org> 1168855184 -0400
Merge branch 'branch' into 'master'.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQBFiY2zwMbZpPMRm5oRAll0AJ0ZR+Bu8zjMVe8eEKR8Xr+3QMtndACcC2Kl
aWSkKLptN0LAOpDinq+aqOc=
=dZlu
-----END PGP SIGNATURE-----
But that's horribly ugly and probably vast overkill. Plus the only
way to really verify each commit is to have the complete database of
PGP public keys handy. A commit-msg hook could probably implement
the signing.
What I'm actually doing in one particular environment is checking
the committer string against a database of known committer strings
associated with the current UNIX uid. My update hook[*1*] performs
a `git log --pretty=raw $3 --not --all` query to determine any
commits which are coming in as part of this push and which are not
already referenced by an existing head or tag in this repository.
For each of those the committer line *must* match one stored in
the allowed-committers file for the current user, as these are
brand new commits being introduced to the repository.
This works well as everyone has a UNIX account on the same system
and logs in via SSH. The easiest way for us to share changes is to
just push them to a single central repository. That repository is
performing the checking. And since every commit signs the entire
chain of commits which came before it, we're in effect implicitly
signing our commits by pushing them to that server. And other
developers are agreeing by building on top of that work.
[*1*] If anyone wants the hook, let me know. I'd be happy to
share it. But since its undocumented I haven't offered it
up as a contrib in git.git yet.
--
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html