From kde-scm-interest Thu Jul 31 15:25:57 2008 From: Thomas Zander Date: Thu, 31 Jul 2008 15:25:57 +0000 To: kde-scm-interest Subject: Re: [Kde-scm-interest] Accountability, concrete suggestion Message-Id: <200807311726.01150.zander () kde ! org> X-MARC-Message: https://marc.info/?l=kde-scm-interest&m=121751799616871 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============2037507596==" --===============2037507596== Content-Type: multipart/signed; boundary="nextPart3223716.dQNbMKPTme"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart3223716.dQNbMKPTme Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 th= ing=20 to another depends heavily on the rest of the tree. If you insert a=20 not-so-random patch before the otherwise completely sane and correct fix=20 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= =20 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 a= nd=20 not bother with this extra step. > Why=20 > not > give them commit access? Several reasons, gpg is much easier to get your hands on then getting a new= =20 account. So it lowers the barrier to entry. Especially for first time=20 contributors that need a mentor anyway. Second reason is that in some countries the connectivity is much lower then= it=20 is here. And having a way to email your patches instead of having a stable= =20 ssh connection to push your changes is just the only thing that is practica= l=20 for them. But, please be clear, this is just an *extra* way of allowing people to wor= k=20 in KDE and making sure we are ready for it. The direct connection method we use currently will most likely be the=20 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=20 extension we trust the person that pushes to indeed be whom he authenticate= s=20 to be (using ssh for example). This trust only works on a server that the kde sysadmins host. So the quest= ion=20 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=20 project. If she doesn't use a kde server then the logging branch solution is useless= ,=20 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=20 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, e= ven=20 if no merge conflicts appear. So having a server do this automatically soun= ds=20 wrong. Just to state the obvious; we can't pull from the server, merge locally and= =20 then push and then expect logging info to not be lost. There is an untruste= d=20 step in the process (user doing local mergin). * When Carlos pushes a branch of changes, from Diana or anyone else, Carlos= to=20 takes responsibility for all those patches by pushing. This is similar to y= ou=20 committing a patch that someone emailed you. I think there are some possibilities to retain accountability of commits th= at=20 come from a forked repo on the kde-server. But its ongoing research ;) =2D-=20 Thomas Zander --nextPart3223716.dQNbMKPTme Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkiR2YUACgkQCojCW6H2z/SmTACg3Rwdk980cco1F2HgGX9Sndrx h6wAn0iqTKXev02JpJFg9EMMIfmOJhWB =+3ba -----END PGP SIGNATURE----- --nextPart3223716.dQNbMKPTme-- --===============2037507596== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest --===============2037507596==--