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

[Sam Vilain <sam@vilain.net>]

Shawn O. Pearce wrote:
>> Ok - but I think if the client is pushing a signed tag to the tagname
>> listed in the signed body of the tag, that no extra signature should be
>> necessary.  It's only commits that need the extra information.
> 
> Doh.  Of course the standard signed tag case is easily verified,
> without the new authentication extension.  But adding it around
> a signed tag push doesn't really hurt anything, except maybe the
> user who entered her passphrase yet again.
> 
> Signing a tag push is actually relevant in some cases.  For example
> when I mirror Junio's git.git tree into my local server at day-job.
> Junio signed the v1.5.4-rc5 tag.  I pushed it to the same location,
> and although we can validate Junio's signature, it may matter (to
> people who have too much free time on their hands but I digress)
> who at our organization put that v1.5.4-rc5 tag from Junio onto
> that particular system, and when they did that.  Was it me?
> Or another co-worker?

Ok, well if people want to sign those pushes then let them - but
allowing them to be pushed anonymously does have the nice side effect
that absolutely nothing needs to be done for the case of replicating
tagged releases of an existing project.  ie, projects that are just
tagging using existing tools and have no knowledge of this system.

>> And remember, for global replication of the data between untrusted nodes
>> to be possible, the signatures must be saved somewhere.  I have sketched
>> a simple design below.
> 
> Crap.  You mentioned this in your initial email, and I forgot
> about it when I posted the message you are responding to now.
> Its actually an interesting concept.  We can validate the entire
> chain of commits that led up to a signed tag, and we can validate
> that signature on that tag.  So why shouldn't we also be able to
> validate the changes to refs in a distributed fashion?

Yes, you could be lazy about it and throw away signatures that were
obsoleted.

>>    access-keys/
>>      - tree with one key per e-mail address
>>    access
>>      - maps reference globs to e-mail addresses permitted to change
>>        them - with a "+" if the address may rewind the ref
>>    owners
>>      - maps reference globs to e-mail addresses permitted to add entries
>>        to the "access" map above
> 
> This part I get.  Using only globs is a tad limited in my mind.
> I actually abuse regexes on refs at day-job in a few places to get
> the access list to work with just a handful of rules.

Extended POSIX or limited PCRE or something like that will do then.

>>    signatures/
>>      - stores any detached signatures.  only the signatures verifying
>>        updates since the last commit to the access meta-branch need to
>>        be stored
>>    packed-refs
>>      - the new list of references (the refs/access commitid is naturally
>>        absent or the same as the parent), or just the changed
>>        references.
> 
> This I'm not so sure.  Are you suggesting that we save the detached
> signature I described earlier that signed the push command set and
> store it here, in this access state branch?  And that we also store
> a copy of all refs (save this one) as a flat file?

On second thoughts, these are only of interest to the auditing and
replication side of things.

> Someone please stop the madness!  :-)

Ok, I think I see the simple beginning path.  Let's go back to the tree
state idea and not worry about replication and auditing yet.  I think it
should fit in smoothly anyway with the above basics.

This means we can nail down the rules for validating a single push/ref
change.  Handling ACL changes is the second level once this first level
works.  It can be manual initially.

You bring up an idea I didn't think of, which is setting up ACLs for
paths within a tree.  I guess quite a few people want that.

How about this syntax (and using globs for illustrative simplicity only):

  refs/heads/*:path/* = any(email email email)

Also, I think that the point about the debian keyrings requires some
consideration.  Maybe groups;

  access-keys/debian/

That way the debian/ access-keys sub-directory can be shared via
alternates across a number of repositories on a shared system.  Instead
of an email address, a group is listed.  But again I think should fall
into place later, once the basic idea is nailed down.

Sam.