Respository vandalism by root at ...fd.o

[Peter Hutterer]

On 24/11/10 19:38 , Luc Verhaegen wrote:
> On Wed, Nov 24, 2010 at 06:33:19PM +1000, Peter Hutterer wrote:
>> On 24/11/10 18:00 , Eirik Byrkjeflot Anonsen wrote:
>>> 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?
>>>
>>> 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?
>>
>> git is designed to not be screwed with easily, so the chance of bad
>> commits being detected is quite high.
>> for well-maintained repositories, we tend to notice quite quickly. I'm
>> sure keith would notice whenever he can't push to xserver because no-one
>> else is supposed to commit to it.
>>
>> The same is true for other repositories, so the best safeguard here is
>> "active maintainership".
>>
>>> 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?
>>
>> 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.
>>
>> I don't think we have any official processes right now and certainly
>> none documented. Sending emails to the list to raise awareness is a good
>> approach IMO and Luc's first few emails were informative. The later part
>> of the thread somewhat lost usefulness when it descended to the usual
>> fights, conspiracy theories and name-calling. Staying on-topic should be
>> an essential part of any official process...
>
> Conspiracy theories?

I did not imply that you were the one starting with the conspiracy 
theories, and I think strictly speaking there was no name-calling in 
that thread either so I have overshot the target and I apologise. 
Correct the above to "the usual fights", that at least is obvious.

Anyway, the best approach to solving issues like this is to go to the 
list and say "hey guys, this isn't funny, it raises trust issues when 
that happens." Which is exactly what your first email did, and the first 
subsequent ones. The thread then went haywire quickly, initiated by a 
number of people, and that is unnecessary.

At this point we have found the guilty parties, we have a publicly 
expressed regret, the consequences of removed root access, and we should 
move on to the more on-topic questions Eirik raised.

If you want to raise the issue of how the radeonhd project was treated 
or the methods of said hardware vendor, I suggest starting a new thread 
because I don't think this one will go anywhere useful at this point.

Cheers,
   Peter

>
> Come on man, Daniel Stone and Adam Jackson, known, over the years, for
> liking radeonhd, sit down, after most likely some alcohol and maybe even
> other substances, and pull this. According to irc, Adam, who had root
> access himself, used Daniel his account to do this, in a targetted and
> efficient manner. If i remember the timestamps right, the update script
> was moved back within 5 minutes of the commit.
>
> Then 3 weeks ensued where nothing happened, where Adam and Daniel
> could've fixed their "spur of the moment" "mistake", without anyone
> noticing, but clearly, they did not come back on their steps.
>
> It was a completely unnecessary event, and it only serves to show how
> certain projects, not suited to a certain group are being treated.
> And
> two former X.org board, two people who joined the X.org fork from
> xfree86 very early on, but who, as far as i can tell, were little or not
> involved with xfree86 at the time, and who got these access rights from
> very early on too, abused their power to trash existing but
> unmaintained free software project.
>
> Now, of course everyone ties this in with my history with X.org, from
> unichrome, to modesetting, to radeonhd, to fosdem, to graphics driver
> stacks.
>
> But you also might want to consider that i was at a hardware vendor two
> weeks ago, and i had to listen to their main engineer calling
> contributing directly to X a waste of time, and that they rather fix
> the versions their customers ship, and hand the patches to their
> customers directly, never bothering to submit to X directly. They rather
> implement stuff, hand it to their customers, as they know that their
> code will not be accepted, and that it will be reinvented a few weeks or
> months later. Then they go and use the reimplementation afterwards, and
> save a lot of manpower and frustration in the process. Despite all my
> personal feelings about free software and the likes, I had absolutely
> nothing to counter, anything i could even try to throw up against that
> would either be completely irrelevant and meek, or a lie.
>
> _This_ is how the world works with an X.org that works like that.
>
> Someone just mailed it "i find it surprising that the person exposing
> the evildoing is getting more flack than the person(s) doing it".
>
> Luc Verhaegen