News for hackers. Stuff that matters.
Re:Why the Linux kernel is hardly at risk by extension on Thursday September 01, 2011 @05:05AM (#2949219)
If they could slip something into the git source then from there, they could tamper with any git project undetected. But since git is presumably self-hosted, it would still be profoundly difficult to get everyone to upgrade to the evil git without noticing the attack. It would require some devilishly underhanded code: http://underhanded.xcott.com/
Re:Why the Linux kernel is hardly at risk by tonfa on Thursday September 01, 2011 @07:59AM (#2949604)
Given the number of changes coming in every release, and since some people rebase, a hash change might not be detected...
Re:Why the Linux kernel is hardly at risk by Xurinos on Thursday September 01, 2011 @08:59AM (#2949807)
Speaking as a regular git user, I assure you that a hash change would be noticeable. Rebase would look for a common hash between your history and the remote history you just fetched and rebase your commits on top of it. When there is a mismatch, you experience a twilight zone where there are attempted merges of code that your changes had nothing to do with. At this point, it is apparent the remote history has changed, and in the process of trying to figure out how to rebase cleanly, your eyes will be on that foreign code.

Given the number of changes coming in every release, more twilight zone experiences increases the number of eyes on the discrepancy.

I am confident in the sanctity of the git-sourced code, thanks to there being multiple version of the same repository around that people are actively working on. I am more worried about all the stuff I might rely on that is not git-sourced.

Re:Why the Linux kernel is hardly at risk by tonfa on Thursday September 01, 2011 @10:58AM (#2950262)
If the history is tampered during a rebase how would you notice?

Suppose a tree well known for rebasing frequently is rebased on kernel.org, and the dev doing it works from the k.org servers (might be possible, since they give shell access).

Then downstream would just see it as yet another rebase, no?

Re:Why the Linux kernel is hardly at risk by Xurinos on Thursday September 01, 2011 @02:11PM (#2951109)
Is this the hypothetical situation of someone doing an interactive rebase on public/published branches and making changes midway through? My current understanding is that, although it is possible, the community avoids doing that (policy: published code history set in stone). That style requires strong communication between developers. It makes people do extra investigation and work, and we all hate doing extra work, right? :)

I cannot speak for what they really do over at kernel.org, but if they do rebase their public repositories often (which will break people doing pushes and fetch/merges without some regular communication), yes, it is possible to sneak something in because the public rebase will not be as exceptional.

This is where you tell me that's what they do there and make me scared again. ;)