[Kde-scm-interest] Accountability, concrete suggestion

Thomas Zander Thomas.Zander at trolltech.com
Fri Aug 1 21:37:00 CEST 2008


On Friday 1. August 2008 20:55:32 Patrick Aljord wrote:
> On Fri, Aug 1, 2008 at 3:08 AM, Thomas Zander <zander at kde.org> wrote:
> > In the gitorious setup Dean can easily pull the changes from Carla and
> > modify some of them before pushing them to the kde-server. Making a
> > modification Dean made look like they came from Carla. And nobody would
> > ever be able to detect it was Dean who made that change.
>
> But Carla has her commit history in her own clone on gitorious so If
> Dean modifies her commits and pushes them to the mainline and a nasty
> bug was to be discovered in Dean's modification of Carla's commits,
> Carla could easily prove she is not guilty by pointing to her clone
> commit history on gitorious. 

This assumes all branches ever made of kde are going to be on one trusted 
server, this does not have to be the case.

> So why would Dean bother in the first 
> place putting the guilt on Carla if she can easily prove herself not
> guilty?

Imagine it takes a couple of weeks before the problem is found, and by then 
carla removed the branch from the server.
Truth is, if there is a malicious user he could easily make a commit in 
someone elses name and push it to gitorious without anyone knowing who 
actually made that commit.

And thats the bottom line that needs to be fixed if we want to have the 
hundreds of committers that KDE currently has.  This is accountability, see 
my initial mail for a reasoning why I think we need this.  To keep people 
honest.

> Even if we do the logging branch, this won't stop people from being
> falsely accused, it just put the responsability on the one that
> pushed.
The one that pushes takes responsiblity; just like when I commit a patch from 
someone I got in the mail.
If you push some anonymous commit into your tree without checking it, well, 
thats not very smart ;)
If you have a problem with proof reading everything, then use the second level 
of accountability that I suggested. So you have the choice of using the 
policy to not commit something that you didn't write unless its signed by the 
original author.

> Anyway, if you want to log every push, I think logging in the database
> could be easier than a git logging branch. We already have post-push
> hooks in our git-daemon (thanks again to the great David Cuadrado ;) )
> so that would be easy to add. Plus that would allow us on the web
> interface to have a "pushed by" field next to every commits.

You can still have that web interface in either way. You can even still have 
the database entries next to the logging branch.
Suggesting to put it in a database only forgets a big reason for using 
distributed SRM in the first place.  It again binds you to one server and one 
service-provider and their ability to provide access to the data.

It is so much more powerful to have an open specification for the log and a 
clear access to the log data (its in the same repo as the rest).

So, thats what I have against only putting it in the database, what exactly is 
the problem with having it in the git tree as well?

> Though I still do think that the network of trust is enough and all
> that is overkill. I mean if the kernel doesn't need that kind of stuff
> then why do we?

Because only Linus commits to his tree, in KDE several hundreds of people 
commit in one tree. So there needs to be a check that prevents evil-joe from 
using --author=aseigo *undetected* on a commit that removes all of krunner.
Note that we currently don't even have a network of trust.  Again, we have 
100ths of committers. I don't even know all KOffice committers.
-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20080801/997cdb4c/attachment.pgp 


More information about the Kde-scm-interest mailing list