User masquerading - audit trail?

[Kurt Granroth]

Dirkjan Ochtman wrote:
> Kurt Granroth wrote:
>> So in this case, we could have a hook (or similar) on selenic.com/hg
>> that appended a "Authenticated User: kurt" to all patches that I pushed.
>> You could clone that off and change it to whatever you want on your
>> local copy... but unless you had sufficient privileges on selenic.com,
>> you *wouldn't* be able to do it on the one repository that actually
>> mattered.
> 
> Well, surely you could check that authenticated users only push changes
> authored by themselves. This might even work in a corporate setting or
> so. But in Open Source, people with push privs are going to be pushing
> other people's patches, so that doesn't work anymore...
> 
> For that case, you're either going to rely on some users to push to
> certain 'master' repositories, in which case you're going to have to
> trust those users to verify the identity of the author. Or you're going
> with a pull model, and you yourself (the one integrating csets from
> other repositories) have to decide whose repositories you trust to have
> only changesets with username equal to the real patch author. (Or some
> combination of the above scenarios, as we have with Mercurial.)
> 
> In either case, it ends up being about a trust network, suggesting that
> this is a social problem that can either be solved with the gpg ext
> (using an 'external' technical trust network) or with implicit trust...

You hit the nail on the head that this is a trust issue!  I completely
agree.

Slight digression: I am actually approaching this issue from a corporate
standpoint.  My R&D group is moving from CVS to either Subversion,
Perforce, or Hg and we're working through all the issues that surface.
An audit trail is the current "show stopper" for Hg.  I have been using
OSS projects for all my examples, though, which shows (to me) that this
can apply to OSS as well.

I'm thinking now that I could create an 'incoming' hook on a central
repo that compares a list of "semi-trusted" users against whatever user
is running the hook (presumably the one authenticated via ssh).  If the
authenticated user and userlist don't match, then the patch is rejected.

This could still work even in the scenario you listed.  In your trust
network, you can have the following:

Level 1: Untrusted developers.  They must email all patches to a Trusted
Developer
Level 2: Semi-trusted developers.  They can push patches, but their
usernames must match their authenticated username
Level 3: Trusted developers.  These are core developers that can push
their own patches or push other people's patches.  No checking is done
to verify that they are who they say they are since they are fully trusted.

You could argue that the Trusted developers break the trust model
normally associated with a "true" central repository... but that's not
really true.  Somebody with admin/root access on  CVS or Subversion repo
could just as easily mess with the usernames of commits.  *Somebody* is
always going to have to be trusted.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 257 bytes
Desc: OpenPGP digital signature
Url : http://selenic.com/pipermail/mercurial/attachments/20081004/50b15560/attachment.pgp