Respository vandalism by root at ...fd.o

[Eirik Byrkjeflot Anonsen]

Dave Airlie <airlied at gmail.com> writes:
Peter Hutterer <peter.hutterer at who-t.net> writes:
Alan Coopersmith <alan.coopersmith at 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