On Source Signing

Brian Gough (a gentleman with whom I’ve stood in a room at one point, but I don’t think we’ve ever spoken) points out that KDE (that is, the release team for KDE) doesn’t GPG sign the source packages that it releases. Hm, interesting, as it’s true that the recent KDE SC 4.4 source tarballs don’t come with an MD5SUMS file or anything else. Going back in history, I find Attic/3.5.9/src which has an MD5SUMS file or the older Attic/3.5/src directory which has an MD5SUMS and an .asc file. Hunh, come to think of it I don’t even know how to check if the .asc file matches the MD5SUMS.

So clearly the source-signing and integrity-checking has decreased over the years. Not sure why — are we (KDE) relying on the packagers to (re-)host the sources and sign them themselves? Have we realized that no-one except the core of the gpg web of trust is checking these things and that it’s not worth spending release team time on? I don’t know.

I do know that the last time I posted a KPilot source tarball — we’re talking five years ago here, at least — I did gpg sign it with the KPilot key. Goodness knows where that thing has gotten to.

And on a related note, I wandered off to look at the OpenSolaris packages to see if they are signed in a meaningful way. The manifests include hashes of all the files in a package, but I don’t see the manifest itself protected or signed in any way. That leads to the same issues that Brian points out again — but it’ll be an interesting day wrt. porcine aviation when Oracle starts using a well-connected gpg key, methinks.

As far as KDE goes: I’ll ask the sysadmins; it might just be an oversight.

[ade] — bridging planetkde and planet.fsfe since 2009.

4 thoughts on “On Source Signing

  1. one thing we try to do with metalink is make integrity checking and file signatures automatic. these can be included in a metalink (and I believe are for things like all openSUSE downloads from their re-director) which KGet/Kgpg should be able to use.

  2. Please, don’t use md5. md5 & sha1 are to be considered broken & deprecated.

    sha256, sha512 & whirlpool are viable alternatives.

    As those hashes are not checked, or typed, by hand anyway, the old argument that they are too long does not hold water, either.

  3. There are SHA1 checksums of the tarballs on the SC download pages, eg http://www.kde.org/info/4.4.2.php . Is this adequate, or should we have SHA1SUMS in the ftp download directories and available via any other media that we use to publish tarballs?

    As a packager I try to check the checksum of tarballs, but I notice that many projects we package (eg shared-desktop-ontologies and attica to name some important ones that all of KDE depends on, popular 3rd party apps like Krusader, don’t mention kde-apps.org releases) don’t provide these. We need a security re-education camp for our release managers.

    • @will: I don’t quite know what Brian would expect. I tend to trust whatever comes down the pipeline from a KDE server, but that’s probably just me. Having the checksums published separately is actually a pretty good idea, but it would be convenient to repeat them *and* to point explicitly to the other known-good location. In any case, there’s still no GPG-signature for the tarballs, which I imagine what the security-conscious would like.