Adding a signing key to RPM [LWN.net]

Over at "orc_orc's sharp edge" blog, there is a good description of RPM signing keys, including how to verify keys before importing them. "The RPM package manager has long had the ability (similar to GnuPG) to receive GPG public keys into its trusted store, and then to test assertions about the presence, absence, and validity of a given signing. It can retrieve a remote key with the usual RPM network retrieval capabilities, or perhaps better to avoid MitM ('Man in the Middle') compromises across a network, from the local filesystem, or a local piece of immutable media, such as a CD which has had its md5sum verified."

to post comments

Universal signing of source code and source packages

Posted Sep 15, 2008 12:06 UTC (Mon) by epa (subscriber, #39769) [Link] (3 responses)

How long will it be until it becomes de rigeur to check signatures on all source code before building it? It's still very common to download a tarball with no signature and blithely type 'make'. But with version control systems such as git and hg that compute a secure hash of all content, you won't be downloading foo-1.5.2.tar.gz but instead revision 5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03.

Even when linking to a source tarball you can use the convention of putting a checksum in the #thingy part of the URI, as foo-1.5.2.tar.gz#sha256=71573b922a87abc3fd1a957f2cfa09d9e16998567dd878a85e12166112751806. It would be a good idea for all user-agents like Firefox and wget to check this, and have an option to add the #sha256= gunk to the URI automatically when you copy and paste it.

A collaborative checksum system, where 'make' automatically uploads checksums to a central server saying 'I built source with checksum abc into an object file with checksum xyz' might also catch potential trojaning, or at least spot build errors. (If the source package is designed for Fooboo Linux 5.5, then building it on that system should generate an exact binary package, and it would be interesting to see in what cases it does not.)

Universal signing of source code and source packages

Posted Sep 15, 2008 12:33 UTC (Mon) by AndyBurns (guest, #27521) [Link] (1 responses)

I doubt building the same package, on the same machine twice would generate the exact same binary (timestamps would be included from __TIME__ macros) let alone building by different compilers/linkers, with different libraries installed.

Universal signing of source code and source packages

Posted Sep 15, 2008 16:55 UTC (Mon) by jreiser (subscriber, #11027) [Link]

building the same package ... different compilers/linkers ... libraries In the late 1980's Apollo Computer had DSEE (Domain Software Engineering Environment) which tracked not only source code but also tools and build scripts. DSEE did guarantee bit-identical outputs because it tracked and could re-generate everything that affected a build. An executable file had exactly one timestamp, in a designated field of the header. (There was no __TIME__.)

Universal signing of source code and source packages

Posted Sep 15, 2008 21:40 UTC (Mon) by Nelson (subscriber, #21712) [Link]

Probably once people stop responding to spam, start encrypting email, stop falling for phishing scams, etc..

Truth be told, I check all the signatures can, maybe 20% of the time, it's a hassle to even find a public key. Then once you get a couple thousand keys in to GPG, it starts to slow down a bit on some operations. If you have it programmed to try an automatically fetch keys from a key server sometimes it just hangs out and chills for a while as it tries to rectify things as it pulls a new key in.

This seems like an ideal problem for google or someone to contribute to the solution of. It'd be nice to associate a PGP/GPG key with an openid and it'd be nice of gmail could maybe somehow indicate to other gmail users that we'd like encrypted mail if possible. Someone big needs to step in and give this kind of technology kind of the push it needs.

Validity checking - should be mandatory?

Posted Sep 15, 2008 13:00 UTC (Mon) by kripkenstein (guest, #43281) [Link] (5 responses)

It seems to me that proper validity checking should be mandatory in installing packages on any system. In my experience how this is handled on Ubuntu (and I guess Debian) leaves something to be desired, or perhaps I don't understand the rationale.

The reason I became aware of this is I was running a machine with some sort of hardware problem, that caused large downloaded files to be corrupt sometimes (rarely, but enough to be a problem). What then happens with large updates in 'apt-get update' is packages are installed until the corrupt package causes dpkg to fail, halting the process with some error about decompression of the file failing. But previous packages were already installed, sometimes leaving the system in an unusable state.

It seems to me that the simplest approach would be to download all files, then verify them (md5, key signing, etc.), and if even one fails then abort the process with an appropriate error message. A more complicated approach would install some packages even if others are corrupt, but only if there is no dependency. However, as I said before, perhaps I don't understand the rationale for the current method?

Validity checking - should be mandatory?

Posted Sep 15, 2008 15:07 UTC (Mon) by epa (subscriber, #39769) [Link] (2 responses)

The more scary thing is that if someone MITM'd your http connection they could change the contents of the packages and as long as the new data decompresses without error it would silently be installed! At least, that's my deduction from what you said, that dpkg goes as far as decompressing the package without checking any signature. Perhaps it does GPG verification on the uncompressed data and everything is safe after all?

I agree with your main point: get everything downloaded, check the signatures before going any further, and only then start the last-minute validation of dependencies etc. and install the packages. This also protects you from possible buffer overruns in zlib or other packaging software that could be exploited by a malicious deb file.

Validity checking - should be mandatory?

Posted Sep 15, 2008 15:32 UTC (Mon) by SEMW (guest, #52697) [Link] (1 responses)

The Debian and Ubuntu versions of Tiger, the security auditor (http://www.nongnu.org/tiger/) have a module for checksumming installed packages and comparing the result to what they should be (which is stored in /var/lib/dpkg/info/).

Worryingly, on my system, a good 14 packages fail this test; including several Linux kernel modules (which really shouldn't have changed since I installed them). Synaptic shows them as fine, and "apt-get check" doesn't report any problems; so apparently, yes, the normal tools aren't checking properly.

(Of course, this isn't a valid way to check for rootkits, since if someone has root access they could just change the checksums to match the compromised packages).

Validity checking - should be mandatory?

Posted Sep 18, 2008 2:34 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]

debsums is the usual tool for checking installed package integrity. "apt-get check" just checks the database.

Validity checking - should be mandatory?

Posted Sep 18, 2008 2:39 UTC (Thu) by BenHutchings (subscriber, #37955) [Link] (1 responses)

There are signatures on release files, which include checksums of the package lists, which include checksums of the packages. apt-get verifies the signature and checksums as it downloads files, before calling dpkg. But if you have a hardware problem that causes files to be corrupted between memory and disk then it may well pass a corrupt file to dpkg. There's little that can be done about this in software.

Validity checking - should be mandatory?

Posted Sep 18, 2008 4:51 UTC (Thu) by kripkenstein (guest, #43281) [Link]

That makes sense, but I think I saw installation begin after a few of the downloaded files were corrupt. That is, apt-get might verify the signatures after downloading, but it doesn't first verify them all and only if they all pass then actually begin installation (or, at least verify that all dependents have been verified ).

That, or I really misanalyzed what was going on in that system - could be. But I did see the actual downloaded files were corrupt, and that installation did begin and only halted somewhere during that process.