Re: [RFC] Authenticate push via PGP signature, not SSH

["Shawn O. Pearce" <spearce@spearce.org>]

Sam Vilain <sam@vilain.net> wrote:
...
> The key idea is to reject pushes if the PGP signature cannot be verified.
...
> When heads are pushed, the signed tags that are moved from refs/heads/
> foo can be saved in an "archive" tag space, such as under refs/audit/
> KEYID/ - this will allow, in the case of a network of git servers, for
> servers to synchronise from each other, even when they
> don't trust each other.

This is certainly interesting.  It would benefit from the recursive
locking scheme we were talking about for the update hook, which
someone (Steven Grimm?) wanted so they could execute git-svn
transparently during push and have the update hook change the ref
instead of receive-pack.

The downside to this is you have to tag everything before you push
it, so you need some sort of wrapper around git-push.  That isn't
as hard as it sounds for the command line case, but it does make
things more difficult for a usage from say git-gui.  :)

I was also thinking about using GPG to sign the command packets
being sent between send-pack and receive-pack.  If the GPG signature
for that set of packets is good and a known key then the update is
allowed to continue.  This avoids the mess of needing to run git-tag
locally before push, and of needing to "unwrap" the temporary tag
in the receiving repository, but it adds yet another extension to
the send-pack/receive-pack protocol.
 
> This does force potential contributors to get PGP keys, and get them
> signed - but that seems to me to be a reasonable barrier of entry and
> may even help drive some PGP adoption.

In many cases today such contributers would have been forced to get
an SSH account on the server they want to push to.  Getting an SSH
account configured and a key installed may be more difficult than
generating a PGP key pair and emailing in the public key.

Of course the PGP based system is nicer in that the administrator
might get a public key that has been signed by others he trusts,
and thus is more readily able to verify that the contributor is
who they think it is.


To be perfectly honest, in a wide open source community I think
the truely distributed nature of development like the linux kernel
or git itself uses works very well.  Development schedules aren't
organized into "next 30 minutes", "next 4 hours", and "next week".

Peer review and community acceptance of changes is a very important
concept.  Blindly accepting changes into a tree because of a PGP
signature/SSL certificate/SSH key isn't really the norm, and is
far from the best solution.  We've all posted cr**p^Wless-than-
the-best-code to this list before, and yet many of us would have
"committer access" to the git tree under a centralized model.

I'm happy my changes aren't accepted just because I signed them.
Its better that Linus/Nico/Dscho/Junio/you/et.al. have looked at
them and also felt they were worthwhile.


But in a smaller business type setting, where there's under 100
employees working, odds are you've already created the user account
on systems, and physically passed the initial password via a sticky
note after checking the person's government issued IDs.  In such a
setting having yet another authentication system (PGP keys) is just
yet more work for the already over worked/under appreciated IT staff.

-- 
Shawn.