[Kde-scm-interest] Accountability, concrete suggestion

[Thomas Zander]

On Thursday 31. July 2008 16:06:16 you wrote:
> On 31 jul 2008, at 15:07, Thomas Zander wrote:
> > When Diana makes several translations she does this on a git
> > checkout. She
> > then commits her changes and emails or pushes her changes to Carlos.
> > Making a commit in Git is something that is done in several steps
> > and the last
> > step is to create a commit message.  Diana will use a way of
> > committing[1]
> > that takes the commit message, the tree (including her changes) and
> > her email
> > address and it will gpg-sign that information.
> > This signature will be added to the logmessage, probably as a one-
> > liner of
> > ascii data.
>
> If you want to sign the tree that includes Diana's changes, you have
> to make
> sure that you also know on which tree the changes were applied.

Both this is present in the sha1 of the tree.
> and if you apply
> the patch
> on a different source tree, you will get another final tree, and the
> sha1 will
> not match

That is intended.
A patch does not stand on its own, a patch that changes a value from one thing 
to another depends heavily on the rest of the tree.  If you insert a 
not-so-random patch before the otherwise completely sane and correct fix 
would end up being a malicious one.

> Why not use a hash of Diana's patch instead of the final tree? That
> way the
> patch can be applied on every tree and still retain a valid sha1.

Because the signature is about the intended result, not about the change in 
itself.

> Don't you think all this signing off will make it harder for first-
> timers to
> send in a patch? Or is this purely optional, for people that don't
> have commit
> access but don't want to put the responsibility on the maintainer?

Indeed, it is purely optional. I can accept patches from known committers and 
not bother with this extra step.

> Why 
> not
> give them commit access?

Several reasons, gpg is much easier to get your hands on then getting a new 
account. So it lowers the barrier to entry.  Especially for first time 
contributors that need a mentor anyway.
Second reason is that in some countries the connectivity is much lower then it 
is here.  And having a way to email your patches instead of having a stable 
ssh connection to push your changes is just the only thing that is practical 
for them.
But, please be clear, this is just an *extra* way of allowing people to work 
in KDE and making sure we are ready for it.
The direct connection method we use currently will most likely be the 
preferred way for all current contributors.

> > Ok, back to our Carlos usecase;  Diana created the patch, she signed
> > it and
> > then pushes it to Carlos.  Carlos checks the signature using some
> > custom
> > script to make sure the commit really is from Diana and he merges it
> > into his
> > tree.
> > At a later point he pushes all the changes he has, including the one
> > from
> > Diana, to the kde-server.
> > The commit is registered by the kde-server as being made by Carlos,
> > but Carlos
> > can point to the signature to indicate that, really, Diana was the
> > one that
> > made this commit.
>
> Have you thought about using person-specific branches? For example,
> let's take
> the previous use case with Diana. Diana does not have push access to a
> specifc
> project, but she does have push access to her own namespace (branches/
> diana/*
> perhaps). She pushes her change to her own branch, and asks Carlos to
> pull it.
> Carlos merges the branch, and pushes it. The server-side hook can see
> that the
> patch originated from diana's namespace, and give accountability to her.

The server side hook is based on the concept that we trust the server. And by 
extension we trust the person that pushes to indeed be whom he authenticates 
to be (using ssh for example).

This trust only works on a server that the kde sysadmins host. So the question 
you post balances on the server actually used by Diana.
If she uses a kde server, then yes, we can have a logging branch for her 
project.
If she doesn't use a kde server then the logging branch solution is useless, 
signing is the only way to get accountability for her.

What Thaigo and me discussed for this usecase resulted in two answers;
* we can have a button on a webform 'integrate' and the server will be able to 
merge from Dianas' repo to the release repo and keep the logging history.
This however is very scary due to the fact that auto-merges can go wrong, even 
if no merge conflicts appear. So having a server do this automatically sounds 
wrong.
Just to state the obvious; we can't pull from the server, merge locally and 
then push and then expect logging info to not be lost. There is an untrusted 
step in the process (user doing local mergin).

* When Carlos pushes a branch of changes, from Diana or anyone else, Carlos to 
takes responsibility for all those patches by pushing. This is similar to you 
committing a patch that someone emailed you.

I think there are some possibilities to retain accountability of commits that 
come from a forked repo on the kde-server. But its ongoing research ;)

-- 
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/20080731/a7ecdbb6/attachment.pgp