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