[Kde-scm-interest] Accountability (was: svn, git, bzr)

[Friedrich W. H. Kossebau]

Am Samstag, 26. Juli 2008, um 14:42 Uhr, schrieb Thiago Macieira:
> Friedrich W. H. Kossebau wrote:
> >I am especially interested how accountability (or what the term is) will
> > be treated if some code is developed off the central repository system.
> > With the current central system every commit is bound to one account,
> > checked by password. But how to handle the merge of a branch in another
> > repository with perhaps local accounts, not given by the KDE admins?
> > How should copyright assignment be handled? BTW, doesn't the same
> > problem already arise with subversion today when svnmerge is used, as
> > done e.g. in the merging of the PIM enterprise branch, which are
> > commited by one person and have no clear authorship (thus copyright
> > ownership) registered with the system, IIUC. Is this alright?
>
> I posted on a thread on this subject a while ago. Obviously I can't find
> it anymore.

Reason to cc: a wiki ;)

> So I'm going to try and reproduce here what I remember: 
>
> The scenario is the following:
> 1) contributor Thiago Macieira has a DVCS checkout of a KDE repository. He
> does the equivalent of:
>
> 	git commit --author "Aaron Seigo"
> 	git push
>
> How can we, after the fact, determine that it was Thiago who made that
> commit, not Aaron?
>
> Or, a more complex scenario:
> 1) contributor Thiago Macieira has a lot of his own commits as well as
> merges from other people, but among them he did:
>
> 	git commit --author "Aaron Seigo"
>
> 2) Thiago tricks contributor Friedrich Kossebau into merging from his
> branch
>
> 3) contributor Friedrich pushes upstream
>
> How can we, after the fact, determine that Aaron was not involved in the
> process?

Yes, thanks for giving the example.

> For Git, the answer is: we can't. The whole accountability with Git rests
> not on the tool, but on the social network and the trust between the
> parties. In other words, you can't detect it later, but the structure of
> the project should detect it before it happens.
>
> The first suggestion I came up with was to ensure that, every push you
> make to the server contains only commits whose author and committer are
> you, yourself. That way, you can't impersonate others.
>
> The problem with that suggestion is that it completely prevents merges
> from other people's code. That is, I can't take your ingenious code,
> merge into my main tree and push to the server.

Yes, this spoils all the fun with DVCS. But then I wonder: why would there be 
a need for that. Why don't branches on the official server do it for you?
Read as: I fear a big problem with DVCS will be the favouring of private 
developer circles, stealing a little of the Open from Open Source.

> So the second suggestion is to require only the committer name to be
> yours, but let author float free. That will however impose problems with
> commit rewritings, the need to rebase or use git-am, whereas a much
> simpler pull (merge) would be far easier.
>
> The third suggestion I came up with was to require every push to end in an
> annotated tag, whose author is you. In other words, you take
> responsibility for the integrity of every single commit between the last
> tag and yours.
>
> The problem arising with that is that someone could fake such a tag under
> your name, then add a trivial commit later and his own tag. After the
> fact, you see questionable changes from one author and trivial changes
> from another.
>
> We can make the suggestion then of using GPG-signed tags, for every single
> push. That way, the tags cannot be faked and you guarantee that, if the
> key verification succeeds, it comes from the right person.
>
> The obvious drawback is that setting up GnuPG and having trusted keys is a
> lot of work to require from contributors.
>
> A fifth suggestion is then to have the server log every push and include
> the account name of whoever did the push. This could even be done in the
> repository, by way of tagging every push. With clever hooks, the server
> can prevent your pushing of tags that would make the log ambiguous.

How does this help with the example you gave at the beginning?

> Of course, this boils down to trusting the server administrators, which we
> have to do right now anyways.
>
> Then I have to ask: how paranoid are we? What's our objective here? To
> give credit where credit is due? Or to wash our hands of any guilt should
> something catastrophic happen in the future (e.g., copyrighted, patented
> code is found on KDE in 2015 and someone wants to assign blame)?

Good questions :)

Cheers
Friedrich
-- 
Okteta - KDE Hex Editor, coming to you with KDE 4.1