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

[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. 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?


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.

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.

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)?

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20080726/7c773e45/attachment.pgp