kernel.org compromised

Posted Sep 2, 2011 4:43 UTC (Fri) by rickmoen (subscriber, #6943)
In reply to: kernel.org compromised by BenHutchings
Parent article: kernel.org compromised

My thanks to you and Duncan for that.

What I've basically been hearing amounts to: 'Silly sysadmin, don't download kernel tarballs from kernel.org and expect to authenticate them by checking the accompanying .sign file using the published gpg key. If you must authenticate a tarball, pull down the sources from the git repo thereby ensuring the sources' integrity, and then tar it up.'

I might now do that, but the point is that many of us have been accustomed to ftp'ing (etc.) Linux kernel tarballs since pre-1.0 days, and many people will naturally interpret the presence alongside those tarballs of .sign files plus the published gpg key as suggesting a means for the public to verify code signature that had been made using a carefully guarded private key. Given that that is not the case, I would humbly suggest that the kernel.org operators, at some point, see if that perceptual pitfall can be eliminated.

Rick Moen
rick@linuxmafia.com

to post comments

kernel.org compromised

Posted Sep 2, 2011 6:43 UTC (Fri) by pebolle (guest, #35204) [Link] (5 responses)

> What I've basically been hearing amounts to: 'Silly sysadmin,
> don't download kernel tarballs from kernel.org [...]

0) Does anyone know what the major distributions use as a base for their kernel packages: kernel.org tarballs or tarballs created from their copy of a git repository? (As far as I know the Fedora kernel packages have a tarball as their primary source.)

1) What means of verification were there in the pre git era?

2) Anyhow, it turns out it this is all spelled out in detail at http://kernel.org/signature.html . Note:

> This signature does not guarantee that the Linux Kernel Archives
> master site itself has not been compromised. However, if we suffer
> an intrusion we will revoke the key and post information here as
> quickly as possible.

(I assume these lines predate this incident.) So I guess we'll have to wait for a revocation of their key. Not that their key matters much to me any more ...

kernel.org compromised

Posted Sep 2, 2011 7:36 UTC (Fri) by pebolle (guest, #35204) [Link] (3 responses)

> 0) Does anyone know what the major distributions use as a base for their
> kernel packages: kernel.org tarballs or tarballs created from their copy
> of a git repository? (As far as I know the Fedora kernel packages have a
> tarball as their primary source.)

Well, to answer my own question, if I look at kernel-2.6.40.3-0.fc15.src.rpm (which seems to be the latest kernel pushed for F15) I see it's v.2.6.39 based. And doing a simple md5sum on the copy of linux-2.6.39.tar.bz2 enclosed in that source package shows that is identical to the copy of linux-2.6.39.tar.bz2 I just downloaded for a kernel.org mirror.

Creating bzipped tarballs with identical checksums is rather hard, isn't it? I assume Fedora uses kernel.org tarballs for its packages.

Perhaps someone from the Fedora kernel team could confirm (or deny) that.

kernel.org compromised

Posted Sep 2, 2011 8:09 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (2 responses)

Yes, Fedora uses kernel.org tarballs. I am a Fedora contributor although not in the kernel team.

kernel.org compromised

Posted Sep 3, 2011 19:31 UTC (Sat) by pebolle (guest, #35204) [Link] (1 responses)

0) Thanks.

1) Note my idea that creating "bzipped tarballs with identical checksums is rather hard" turned out to be entirely incorrect.

2) I was able to create identical bzipped tarballs of linux-2.6.39 and linux-3.0. I also was able to create identical bzip2 versions of a few recent -rc and -stable patches. So it seems the tar an bzip2 formats are more likely to generate reproducible results than I expected. Ditto for the git commands I used to generate their input.

(3) Boring details: for linux-2.6.39 I only needed to add "-c tar.umask=0022" to "git archive" to create an identical tarfile. For the -rc patches I needed to edit one git diff index line (ie, an "index <hash>..<hash> <mode>" line) because one hash abbreviation changed due to, in short, recent additions to the repository. Trivial changes, really. Other files I could easily recreate with rather obvious command lines, like "git diff v3.0..v3.0.4 | bzip2 -9".)

kernel.org compromised

Posted Sep 4, 2011 17:58 UTC (Sun) by joey (guest, #328) [Link]

While this is thuroughly offtopic, if you're interested in recreating original tarballs, gz files, and bz files, see pristine-tar. It's not "easy" in the general case, but it's possible. :)

kernel.org compromised

Posted Sep 2, 2011 8:56 UTC (Fri) by rickmoen (subscriber, #6943) [Link]

Pebole wrote:

Note: "This signature does not guarantee that the Linux Kernel Archives master site itself has not been compromised."

Well, no code signature ever guarantees that the hosting site hasn't been compromised.

A sentence higher up, immediately after the bit about the signing being automated, is actually quite a bit more significant: "This signature can be used to prove that a file, which may have been obtained from a mirror site or other location, really originated at the Linux Kernel Archives."

A truly careful parsing of that sentence might catch the implication that the signature proves only that the file really originated at kernel.org. However, it'd be really nice if this were more apparent upon casual browsing of tarballs.

Rick Moen
rick@linuxmafia.com