[Mesa-dev] Mesa master branch: forced update

[Chia-I Wu]

On Wed, Jul 11, 2012 at 7:15 AM, Kristian Høgsberg <krh at bitplanet.net> wrote:
> On Tue, Jul 10, 2012 at 4:54 PM, Kristian Høgsberg <krh at bitplanet.net> wrote:
>> On Tue, Jul 10, 2012 at 4:24 PM, Ferry Huberts <mailings at hupie.com> wrote:
>>>
>>> On 10-07-12 22:13, Kenneth Graunke wrote:
>>>>
>>>> On 07/10/2012 12:50 PM, Tom Stellard wrote:
>>>>>
>>>>>
>>>>> I just fetched from the master branch of the fdo mesa repo and was
>>>>> greeted with a "forced update" message, and the gitweb interface shows
>>>>> several days of history are missing from the master branch.
>>>>>
>>>>> olv appears to be the last user to modify the master branch:
>>>>>
>>>>> tstellar at annarchy:~$ ls -l /git/mesa/mesa.git/refs/heads/master
>>>>> -rw-rw-r-- 1 olv mesa 41 Jul 10 11:41
>>>>> /git/mesa/mesa.git/refs/heads/master
>>>>>
>>>>> Anyone know what happened?
>>>
>>>
>>> Login on the server, and look at the git logs.
>>> The commits are not lost, just not visible.
>>>
>>> logs are in:
>>> <repodir>/logs
>>>
>>> or do:
>>> cd <repodir>
>>> git reflog
>>
>> I already did that, there are no reflogs in the mesa git repo.  The
>> repo is older than the reflog feature.  The best we can do is to look
>> at the master ref.
>>
>> It's possible that this was an attack to alter history (sneak in a
>> backdoor, for example, the dri drivers run as root in aiglx in most
>> distros).  However, the commit that was pushed matches the older
>> commit (which is why Kenneth was able to pull and fast-forward) and
>> git fsck verifies that the history hasn't been tampered with.  That
>> is, it is possible to hand edit a commit object to include changes
>> that wasn't originally there and then just force the SHA1 to match
>> what is was before.  git fsck will catch that, but only in a new
>> clone, since when you pull from an existing repo, git won't fetch old
>> objects.  More unlikely, history was altered in a way such that code
>> was inserted but the sha1 was preserved (ie sha1 was compromised).
>> I'm on a bad connection right now, but I'll do a fresh clone of the
>> mesa repo and do a git fsck there as well as comparing the contents of
>> a recent commit with what I have locally to see if the contents has
>> been changed while preserving the sha1 validity.
>
> And the results are in: freshly cloned mesa repo goes through git fsck
> without problems and just to be completely paranoid I checked against
> compromised sha1sums (that is, attack by inserting code without
> affecting the sha1sums) by comparing the output of git archive of
> 40742fa6864000d431b81c3769a3136b7ff4a0d1 in both my previous checkout
> and the fresh clone and they match.  So while it's suspicious that
> Chia-I hasn't been active for a long time and the suddenly pushes a
> forced update of the repo, I don't think anything was compromised or
> any history lost.  The freedesktop.org account has been disabled until
> we hear back from Chia-I.
That was my fault.  I intended to "git push -f" mesa to my other
machine last night, but I forgot to specify the remote.   The command
was interrupted before completing, and I thought the changes were not
pushed.  I am sorry for the troubles...

I wonder if it is feasible to set receive.denyNonFastForwards to true
on the server to avoid such errors in the future?

-- 
olv at LunarG.com