Verifying distfiles with PGP signatures

Traditionally the integrity of third party software downloaded from the Internet has been verified with MD5. The MD5 sums are stored in the FreeBSD CVS Repository. This had been useful for discovering Trojans. A lot of Software vendors like e.g. Werner Koch of GnuPG sign their software with their PGP-key. Should the FreeBSD ports collection support automatic verification of these signatures?

It would increase security for FreeBSD users if these signatures could be verified during installation. I have started to add support for gpg-signatures to some of my ports (irc/bitchx, security/libgcrypt, security/libksba). Sergei Kolobov was inspired by this and submitted a patch for bsd.port.mk. Jason Harris started pushing changes into the ports tree, which resulted in some valuable feedback.

Summary: Using PGP just because it is hip, does not improve security. The following issues need to be resolved:

  • Where should the signature files be stored?
    • In the ports CVS Repository. Advantage: trusted. Disadvantage: Inodes wasted on every FreeBSD installation
    • On the Mastersite Advantage: Signatures can be easily updated by the vendor Disadvantage: untrusted
    • On the FreeBSD FTP mirrors. Advantage: trusted Disadvantage: Someone needs to upload the signatures to the mirrorservers
  • How do the necessary keys get into the keyring of the User installing software?
    • Fetch from the users favorites keyserver Disadvantage: Some PGP Servers are serious out of sync.
    • Distribute the Keys via the FreeBSD infrastructure either via cvsup of ftp. Disadvantage: requires additional resources from the FreeBSD project
    • Maintain a list of synced PGP Keyservers in the ports collection
  • Where on the users Harddisk should the keys be stored
    • In WRKDIR. Disadvantage: The keys have to be refechted everytime the port is updated
    • In the users default keyring Disadvantage: A keyring in /root/.gnupg is installed and problems with gnupg and sudo
    • In a central space in the Ports collection
  • How does the user get a trust path to the software vendors keys
    • Rely on the users Web of Trust. Disadvantage: Most users and some software vendors are not connected to the Web of Trust
    • Sign the keys with a FreeBSD.org key Disadvantage: Additional work for the FreeBSD Committers.
  • Since GnuPG is GPL Software, we should either make the PGP signature checking optional or support other OpenPGP-compatible Software

It looks like there is no easy solution, but I still hope that we will be able to support PGP sigs soon. I have probably forgotten some points, So I like to see feedback either here in this blog of on the freebsd-ports Mailinglist.

5 thoughts on “Verifying distfiles with PGP signatures”

  1. tla 1.2 supports PGP signature checking (for changeset in a repository, virtually verifying every single patch) and I like the idea.
    Where: in ports. The disadvantage is nonsense because if you sincerely worry about inodes you probably should not check out ports-all anyway. The disadvantage of using the mastersite can be overcome if ports would store which key may sign mastersite packages, but most mastersites do not not sign software (obviously, I do, so I’d prefer if that was the default with a fallback/double-check on Ports).
    How to get into keyring: PGP servers (listed in Ports or not), with a FreeBSD infrastructure fallback. The combo overcomes both disadvantages.
    Where the key should be stored: I suppose /usr/(local/)share/date/ports/ makes sense as a location, and although I prefer within a single keyring, that shouldn’t make much of a difference.
    Trust path: Signing the key with any kind of key the user has to get from FTP/cvsup/whereever completely removes the additional security over md5sums, because the user’s upstream router could be compromised. The whole security concept of PGP works only when a user has physically verified and/or trusted keys in a path. Adding another source of trust from a centralized location only obfuscates this. It would be far more effective to look for opportunities where FreeBSD users and vendors can expand their web of trust, for example by clearly promoting the possible uses of PGP and stimulating FreeBSD users and vendors to be present at trade shows and FBUGs with fingerprints and passports.

  2. Thanks for your comment. I like your idea about the fallback keyserver.
    ad Trust path. The idea was, that the port maintainer frequently corresponds with the vendor, so he knows which is his correct key, But the User has probably never heard of the Software vendor, so he does not know if this is 0xDEADBEEF is a trusted vendor key or not.
    So if the committer checks and signs the vendors key, there is already a short trust path (User->committer->vendor) to the key.
    I don’t think that this removes the additional security from PGP, although it is often not possible to do a face2face verification. But I think that it requires additional work for the committer, since he has to do the verification process.
    And I agree that having PGP Support in ports would make PGP more popular under FreeBSD users, since currently the FreeBSD WoT is poor compared to the debian one.

  3. If you think that frequent correspondence between user and committer, or committer and vendor, builds a trust path, you’re wrong. The whole point of the web of trust is that mere correspondence does *not* proof identity.
    On the other hand, government issued paper does not either, IMHO. 🙂

  4. Of course frequent correspondence between people does establish a trust path – it just has a lower level of trust than going through a regular keysigning party procedure, but openpgp DOES deal with different levels of trust, a fact that people continue to choose to ignore.
    Regarding the actual topic: I’ve seen more than one server automatically generating pgp-signatures, which degrades them to merely expensive and awkwardly handled hashes. 🙁

Comments are closed.