Dave Airlie <airl...@gmail.com> writes: Peter Hutterer <peter.hutte...@who-t.net> writes: Alan Coopersmith <alan.coopersm...@oracle.com> writes:
[ Paraphrasing heavily. Apologies in advance for any (perceived) misinterpretations ] >> 1. What systems do we have in place that enables us to detect when a >> "trusted admin" acts in "bad judgement" or with "evil intent"? What >> is the probability that such actions will be noticed? Can we do >> anything to increase this probability? The answers given so far are: - Any tampering with the history of active branches will be flagged by git (at least on push), so no tampering can go undetected. - Integrity of old releases can be checked by widely distributed, cryptographically signed checksums. >> 2. What systems do we have in place that enables us to detect "evil >> commits" once they actually make their way into the repository? What >> is the probability that they will be noticed? Can we do anything to >> increase this probability? The answers given so far are: - We hope there are enough people reading the code that suspicious segments will be discovered quickly. >> 3. When incidents are detected (break-ins, abuse of admin rights, evil >> commits, what have you...), what processes are in place to deal with >> this? What information is published, and in which fora, and when? >> What investigations are performed, and what actions are carried out >> as a result of such investigations? Where are these processes >> documented? The answers given so far are: - It seems we haven't thought much about this / not our problem. In writing the summary above I notice that I forgot to include the question about "how do we keep bad commits from making it into the repositories in the first place", but based on the answers given so far, I feel pretty confident that the answer is: - We hope that enough people are looking at new commits that suspicious segments will be noticed quickly. This is pretty much the answers I was expecting. All in all, I'm not too unhappy about them. As some answers say, the primary branches on the main repositories probably have enough people watching them and playing with them that it is a non-trivial job to sneak in a really bad commit, as well as keeping it there once it is in. The same assurance is obviously missing from branches that see little activity from few people. Can we do better? Of course. Can we do significantly better with a realistic level of effort? Maybe not. Question 3 is probably the one with the most scope for low-cost improvements. And also quite possibly the one that really needs it the most. > We could probably better define this sort of things, again fd.o has > been a pretty haphazard setup based on volunteer time and effort, but > again hopefully we can get some escalation procedures in place that > are less public. > > Dave. Yes, proper (and well-documented) contact points seems to be a missing piece of the puzzle, as Luc points out. This should also include some clear description of what kind of actions can be expected and what kind of feedback (both to the reporter and publically) can be expected. In particular, there must be some way for the reporter to check that the report has been properly handled. > I think in this particular case, a large number of insiders likely > assumed a prank before it was called out. There is a history of > disagreements between some of the X.Org developers and Luc and the > radeonhd project, so having this happen to this particular repository > is not that surprising after all (Note, this does not excuse the > action, merely explain some of the reactions). I'd have been more > worried if that had happened to e.g. the xserver repo. > > Cheers, > Peter This may be a point to learn from directly. If it is true that several insiders had noticed this "prank" and not taken any action, I think a certain amount of attitude adjustment is called for. In particular, precisely because of the friction between the groups. Playing pranks among friends is not a big deal, as everyone involved knows there are no hard feelings. Playing pranks on people that you are already having conflicts with IS a big deal. It only serves to create hostility and deepen conflicts. It is particularly important that friends of the prankster reacts quickly in such situations, precisely to avoid an escalation of the conflict, and retain such trust as still remains between the groups. > Those would be questions for our hosting provider, freedesktop.org. > X.Org does not control the freedesktop.org machines. There is a large > overlap in the groups, but we do not have the authority to speak for them. That's only partially true. These questions directly affect X.Org, and so should be of concern to X.Org. Any processes must of course be carried out by fd.o, but the X.Org community should participate in evaluating the current and proposed processes, as well as proposing improvements to such processes. Individuals can of course claim that they personally does not want to invest time and effort in thinking about such matters. But the community as a whole should not take such a stance. eirik _______________________________________________ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com