[svlug] kernel.org breach, four years later

Karen Shaeffer shaeffer at neuralscape.com
Fri Nov 20 16:50:17 PST 2015

On Fri, Nov 20, 2015 at 04:11:30PM -0800, Chaiken, Alison wrote:
> Karen Schaeffer writes:
> > One interesting detail
> > is that the kernel source code itself was not cracked. The source code
> > distribution system was compromized as you aptly document. Linus 
> > Torvalds holds
> > the gold copy of the kernel source code tree, and he keeps it 
> > air-gapped. And
> > he uses git hash codes to verify the integrity of the source code 
> > against his
> > golden copy.
> There is no need for air-gap security when source code is managed with 
> git.

Hi Alison,
I'm simply repeating comments made by Linus Torvalds, which I believe he made
on a linux kernel development email list soon after this event happened. And
I don't believe anyone spoke up to tell him he was wasting his time.

Thanks for your comments. I always enjoy reading your astute point of view!
I agree. I don't think the risk was to developers, who use git. The risk
was to everyday users who don't use git. I remember there was a large notice
associated with the download server for quite a while after this event, warning
folks who downloaded kernel source code from that server, while it was in a
compromised state, that their download may have been tainted.

I'm out of time. Very busy. Please feel invited to continue the discussion...

Adapt and thrive,

>   The reason is that all up-to-date copies of a git repository are 
> identical, and all patches submitted to the kernel are signed with the 
> developer's cryptographic key, as well usually with the keys of the 
> maintainer who merged the patch.   Thus copies of a git repository are 
> verifiably correct and there is no need for special safeguards.   That 
> is part of the beauty of git, and yes, I really do think git is 
> beautiful in its economy and design (if not its UI).
> The hitch is that very often a developer has a 'dirty' working directory 
> that includes changes that are not committed to his/her local 
> repository.   These changes are not in any way safeguarded.   In 
> addition, a developer who has committed locally but not pushed changes 
> to any remote will suffer loss should the local storage medium be lost.  
>   Undoubtedly Linus does not keep his local development repository at 
> kernel.org.   There is no reason to do so: that is the point.
> > Bottom line, folks were downloading distributed kernel software from a
> > compromised server for 17 days. Ouch!
> There was little potential for harm, as outlined above.   Anyone working 
> on the project (and I do mean *anyone*) could easily determine if the 
> repository was compromised.   An intellectually ambitious perpetrator 
> could merge his/her own patches into kernel.org's tree, but he/she would 
> have no way of signing them with a maintainer private key.
> Note that bitcoin and other digital currencies employ distribution and 
> verification mechanisms similar to git.   While the history of digital 
> currencies has shown that these mechanisms can be hacked, doing so 
> requires tremendous sophistication.
> None of this is to say that the kernel.org breach may not have been 
> serious.  Certainly if people's private keys were compromised, that 
> could potentially cause problems.   Plus, the server may have held other 
> sensitive information.
> By the way, Rick, good work holding Linux Foundation's feet to the fire.
> Best wishes,
> Alison
> ---
> Alison Chaiken                      alison at she-devel.com, 650-279-5600
> http://{ she-devel.com, exerciseforthereader.org }
> "There is expressive potential in not being together." -- Mark Volkert,
> Assistant Concertmaster, San Francisco Symphony
> _______________________________________________
> svlug mailing list
> svlug at lists.svlug.org
> http://lists.svlug.org/lists/listinfo/svlug
--- end quoted text ---

Karen Shaeffer                 Be aware: If you see an obstacle in your path,
Neuralscape Services           that obstacle is your path.        Zen proverb

More information about the svlug mailing list