On Wed, Apr 15, 2009 at 8:54 AM, Matthew Toseland
<toad at amphibian.dyndns.org> wrote:
> On Tuesday 14 April 2009 15:33:04 Daniel Cheng wrote:
>> On Tue, Apr 14, 2009 at 10:23 PM, Matthew Toseland
>> <toad at amphibian.dyndns.org> wrote:
>> > On Sunday 12 April 2009 12:31:55 Daniel Cheng wrote:
>> >> On Sun, Apr 12, 2009 at 8:27 AM, Ian Clarke <ian at locut.us> wrote:
>> >> > On Sat, Apr 11, 2009 at 12:00 PM, Matthew Toseland
>> >> > <toad at amphibian.dyndns.org> wrote:
>> >> >> On Saturday 11 April 2009 15:39:54 Daniel Cheng wrote:
>> >> >>> Hi all,
>> >> >>>
>> >> >>> I have just checked, GitHub allow "non-fast forward" update, and
> there
>> >> >>> is no option to disable it. This means anybody have write access to
> it
>> >> >>> might overwrite the whole repository, keeping no history behind. (for
>> >> >>> those who are curious, google the 'git push --force').
>> >> >>
>> >> >> Would that be propagated when devs update their local trees via pull?
>> >> >
>> >> > No, apparently it would be trivial for a developer to push the history
>> >> > back to the repository, since everyone will have a copy of the entire
>> >> > repo history (unlike with svn).
>> >> >
>> >> > I think it basically means that if a developer is determined to be
>> >> > malicious, they can definitely be a nuisance - but not cause any
>> >> > significant loss of data. ?This is probably also the case with
>> >> > subversion, and any other source control system.
>> >> >
>> >>
>> >> If any developer do this in git, he will be discovered when next
> developer
>> >> try to push any changes.
>> >
>> > Well yes, but the more subtle attack of deleting history??
>> >
>>
>> Deleteing / Rewriting the history without being discover require
>> finding a meaningful SHA-1 hash collision. Although SHA-1 is not that
>> strong, collision attack on SHA-1 is still far from realistic.
>>
>> In any other cases, the attack will be discovered in the next push.
>
> They will be discovered *automatically* ?

The push will fail.



>> The question is: can the attacker do anything harmful in that time gap?
>>
>> [[ I don't think we should take this risk. ]]

Reply via email to