How to find and verify a trust path?

Jason Harris jharris at
Fri Sep 20 04:26:54 CEST 2013

On Wed, Sep 18, 2013 at 07:55:45PM -0700, Doug Barton wrote:

> When I was a FreeBSD developer I tried to get the PTB interested in 
> adding standard (albeit opt-in) support for PGP signatures in our 
> ports/packages system. For the source side (ports) I wanted to include 
> the PGP signatures from the distributor of the tarball. On the 

BTW, I've kept the USE_GPG code alive in, even working
around projects like Apache that only distribute .asc files from
their master site.  For example, before building GPG 1.x, I will
get the following - or else the build stops with a "failed" checksum:

  %make checksum
  ===>  Found saved configuration for gnupg-1.4.14
  ===> Fetching all distfiles required by gnupg-1.4.14 for building
  => MD5 Checksum OK for gnupg-1.4.14.tar.bz2.
  => SHA1 Checksum OK for gnupg-1.4.14.tar.bz2.
  => RMD160 Checksum OK for gnupg-1.4.14.tar.bz2.
  => SHA256 Checksum OK for gnupg-1.4.14.tar.bz2.
  => No SHA512 checksum recorded for gnupg-1.4.14.tar.bz2.
  => MD5 Checksum OK for gnupg-1.4.14.tar.bz2.sig.
  => SHA1 Checksum OK for gnupg-1.4.14.tar.bz2.sig.
  => RMD160 Checksum OK for gnupg-1.4.14.tar.bz2.sig.
  => SHA256 Checksum OK for gnupg-1.4.14.tar.bz2.sig.
  => No SHA512 checksum recorded for gnupg-1.4.14.tar.bz2.sig.
  ===> Verifying PGP signature gnupg-1.4.14.tar.bz2.sig
  gpg: assuming signed data in `/usr/ports/distfiles//gnupg-1.4.14.tar.bz2'
  gpg: Signature made Thu Jul 25 04:56:52 2013 AST using RSA key ID 4F25E3B6
  gpg: please do a --check-trustdb
  gpg: Good signature from "Werner Koch (dist sig)"
  Primary key fingerprint: D869 2123 C406 5DEA 5E0F  3AB5 249B 39D2 4F25 E3B6
  gpg: binary signature, digest algorithm SHA256
  ===> Valid sig. from expected ID #1 D8692123C4065DEA5E0F3AB5249B39D24F25E3B6.

> pre-compiled packages side I wanted our package creation system to 
> create a signature for the package. I even included a POC for the former 
> in the ports I maintained. While the security conscious users liked it, 

I'm in this group.

> the general consensus was that the SHA-256 checksums we were already 
> using to verify the authenticity of the source tarballs was enough.

And I have total dissensus with that consensus.

> My counter-argument was that this is insufficient, since it relies on 
> the (volunteer) maintainer of the port to provide thorough review of new 
> source packages, which is something we had consistency problems with 
> even amongst those with the best of intentions. The Linux package 

Definitely, and I really dislike that the autotools create so many
gratuitious diffs.

> systems I'm familiar with (and admittedly that's not many) seem to share 
> the same "reliability" (pardon the pun) issue. If the maintainer is the 
> one who wants to pwn me, that would theoretically be possible, at least 
> for a time.

With signed tarballs, I really don't worry as long as the FreeBSD-
distributed patches (files/*) are small/easy enough to thoroughly
check.  Contributed patches from PATCH_SITES are more likely to be
a threat because they're almost always not signed.

I also [re]compute the SHA256 and other hashes ("make makesum"),
"svn diff distinfo" to make sure the "official" FreeBSD SHA256
hashes haven't changed, and might even check the other BSD and
Linux distributions' MD5/SHA-1/etc. hashes for the same tarball.

Even before a port/package is updated in FreeBSD, I can download
the new tarball and signature and easily make sure it was signed
by the same (or a previous) GPG key with a known fingerprint.

Jason Harris           |  PGP:  This _is_ PGP-signed, isn't it?
jharris at _|_ Got photons? (TM), (C) 2004
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 314 bytes
Desc: not available
URL: </pipermail/attachments/20130919/f7394a46/attachment.sig>

More information about the Gnupg-users mailing list