[Cryptech Core] git, again

[Rob Austein]

At Mon, 13 Jan 2014 11:44:15 +0400, Basil Dolmatov wrote:
> 
> I now cannot imagine why key used for signing commits will be more
> secure than ssh-key used to get access to repository under given
> username.

One certainly could choose to do this via sneakernet: do one's
development on a machine which is not and never has been connected to
the Internet, sign commits there with a key that never leaves that
machine, convey the signed result to some other machine (on CD-R or
whatever makes you happy) for upload to the repository.  While
obviously somewhat painful, this is not particularly fanciful: leaving
pgp and git out of it, I've had customers who were defense contractors
and had to resort to similar procedures just to get bug reports out of
their development labs and patches back in, and in this crowd I'd be
surprised if I were the only one who had seen this sort of thing.

Whether anyone would choose this methodology for this project is
another matter entirely, and one on which I have no strong opinion.

> I equally cannot see crucial difference between https and ssh
> access, demanding presence of latter one.

Offline signing capability aside, the difference is simple: audit.
Channel security (eg, ssh) can't usefully be audited once the channel
has gone away.  Object security (eg, pgp) can.

Note that audit for this project almost certainly includes people
outside our circle, that's part of the point of the exercise.  How
many people will bother to check commit signatures is something I
can't predict, but we probably want to have them available.

Checking both ssh and pgp doesn't bother me, that's just defense in
depth.  I expect that primary defense of "the" (this is DVCS)
repository will be the ssh authorization check, but adding a pgp check
seems harmless, with one caveat:

The one part of this that does bother me is that the mechanics of
checking pgp signatures in a git server commit hook look to be a bit
fragile.  We can probably make it work, I'm just not sure whether
automating this adds enough value to be worth holding things up until
we have a working version of it in place.