Hello,
What is the proper way to verify the kernel source before compiling?
There have been too many trojans of late in open source and free
software and I, for one, am getting paranoid.
Thank you,
Brad
* Richard B. Tilley (Brad) ([email protected]) wrote:
> Hello,
>
> What is the proper way to verify the kernel source before compiling?
> There have been too many trojans of late in open source and free
> software and I, for one, am getting paranoid.
>
> Thank you,
> Brad
>
For each kernel and patch on kernel.org there is a corresponding .sign
file. This is a detached signature file that can be used to verify
that the kernel came from the kernel maintainers and that it has not
been modified since signing. The process for verifying these
signatures is quite easy.
On a valid kernel you will see something like this:
.::jasonc@panacea::.~> gpg --verify linux-2.4.18.tar.gz.sign linux-2.4.18.tar.gz
gpg: Signature made Mon Feb 25 14:42:44 2002 EST using DSA key ID 517D0F0E
gpg: Good signature from "Linux Kernel Archives Verification Key <[email protected]>"
On a bad signature:
.::jasonc@panacea::.~> gpg --verify linux-2.4.18.tar.gz.sign linux-2.4.18.tar.gz
gpg: Signature made Mon Feb 25 14:42:44 2002 EST using DSA key ID 517D0F0E
gpg: BAD signature from "Linux Kernel Archives Verification Key <[email protected]>"
--
Jason Cook | GnuPG Fingerprint: D531 F4F4 BDBF 41D1 514D
GNU/Linux Engineering Lead | F930 FD03 262E 5120 BEDD
evolServ Technology | Home page: http://reinit.org
SMB sucks! *Really* *really* sucks
--Jeremy Allison
> What is the proper way to verify the kernel source before compiling?
> There have been too many trojans of late in open source and free
> software and I, for one, am getting paranoid.
If it's in BK you can be pretty sure that it is what was checked in,
BK checksums every diff in every file. It's not at all impossible
to fool the checksum but it is very unlikely that you can cause
semantic differences in the form of a trojan horse and still fool
the checksums.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Wed, 27 Nov 2002, Larry McVoy wrote:
> > What is the proper way to verify the kernel source before compiling?
> > There have been too many trojans of late in open source and free
> > software and I, for one, am getting paranoid.
>
> If it's in BK you can be pretty sure that it is what was checked in,
> BK checksums every diff in every file. It's not at all impossible
> to fool the checksum but it is very unlikely that you can cause
> semantic differences in the form of a trojan horse and still fool
> the checksums.
It depends on the checksum algorithm. If it's not `strong' (e.g. simple crc32),
I can easily add some specially tailored unused data to the code of which the
sole purpose is to make the checksum still match.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Wed, Nov 27, 2002 at 11:29:27PM +0100, Geert Uytterhoeven wrote:
> On Wed, 27 Nov 2002, Larry McVoy wrote:
> > > What is the proper way to verify the kernel source before compiling?
> > > There have been too many trojans of late in open source and free
> > > software and I, for one, am getting paranoid.
> >
> > If it's in BK you can be pretty sure that it is what was checked in,
> > BK checksums every diff in every file. It's not at all impossible
> > to fool the checksum but it is very unlikely that you can cause
> > semantic differences in the form of a trojan horse and still fool
> > the checksums.
>
> It depends on the checksum algorithm. If it's not `strong' (e.g. simple crc32),
> I can easily add some specially tailored unused data to the code of which the
> sole purpose is to make the checksum still match.
Oh, sure, you could, but you'd have to go edit the SCCS files by hand,
which is certainly doable, but it raises the bar past most of the
script kiddies who do this sort of thing.
Ted T'so and I have discussed the idea of adding strong signatures to BK
several times. It would be easy to do and it would completely defeat any
attempt to stick a trojan into an existing changeset. So we could and will
if it ever becomes a real problem.
On the other hand, bkbits.net is updated by Linus directly and we've never
had a breakin there (knock on wood) so you are relatively safe if you are
tracking the tree from there. Now that I've said that some slashdot
kiddie with more balls than brains will happily beat their brains out
to break in, but we'll fix it if it happens.
The bottom line is that, so far, the BK tree is safe. I'll personally
commit to providing strong crypto based signatures for changesets within
1 week of the date when someone sticks a trojan in a BK tree. It's not
that hard, but it's also a problem that doesn't exist (yet). And we have
lots of things to do, just ask any BK user...
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Larry McVoy wrote:
> > > If it's in BK you can be pretty sure that it is what was checked in,
> > > BK checksums every diff in every file. It's not at all impossible
> > > to fool the checksum but it is very unlikely that you can cause
> > > semantic differences in the form of a trojan horse and still fool
> > > the checksums.
> The bottom line is that, so far, the BK tree is safe.
Sure, it is hard to _fake_ bk, but how about someone cracking
a machine? Couldn't they check in a trojan using
the normal check-in procedures?
Helge Hafting