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.