--===============2007918109== Content-Type: multipart/signed; boundary="nextPart2774326.lSaySzxWxt"; protocol="application/pgp-signature"; micalg=pgp-sha1 --nextPart2774326.lSaySzxWxt Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 1. August 2008 20:55:32 Patrick Aljord wrote: > On Fri, Aug 1, 2008 at 3:08 AM, Thomas Zander 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.=20 This assumes all branches ever made of kde are going to be on one trusted=20 server, this does not have to be the case. > So why would Dean bother in the first=20 > 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= =20 carla removed the branch from the server. Truth is, if there is a malicious user he could easily make a commit in=20 someone elses name and push it to gitorious without anyone knowing who=20 actually made that commit. And thats the bottom line that needs to be fixed if we want to have the=20 hundreds of committers that KDE currently has. This is accountability, see= =20 my initial mail for a reasoning why I think we need this. To keep people=20 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 fr= om=20 someone I got in the mail. If you push some anonymous commit into your tree without checking it, well,= =20 thats not very smart ;) If you have a problem with proof reading everything, then use the second le= vel=20 of accountability that I suggested. So you have the choice of using the=20 policy to not commit something that you didn't write unless its signed by t= he=20 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 hav= e=20 the database entries next to the logging branch. Suggesting to put it in a database only forgets a big reason for using=20 distributed SRM in the first place. It again binds you to one server and o= ne=20 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= =20 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=20 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=20 commit in one tree. So there needs to be a check that prevents evil-joe fro= m=20 using --author=3Daseigo *undetected* on a commit that removes all of krunne= r. Note that we currently don't even have a network of trust. Again, we have= =20 100ths of committers. I don't even know all KOffice committers. =2D-=20 Thomas Zander --nextPart2774326.lSaySzxWxt 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) iEYEABECAAYFAkiTZdwACgkQCojCW6H2z/R5VQCffRVHgjFC29Wj7UTvX550qKtk 1E0AoPArNb0zy2vr/Ka8JfC2wqHG7vF0 =fxxD -----END PGP SIGNATURE----- --nextPart2774326.lSaySzxWxt-- --===============2007918109== 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 --===============2007918109==--