RFC: automatically verify GnuPG signatures

[Sergei Kolobov]

(cc'd to freebsd-ports for broader discussion)

Some background for the list subscribers:
I have recently submitted a patch for bsd.port.mk to enable automatic
verification of GnuPG signatures (for those ports that provide them) at
'make checksum' phase.
See http://www.freebsd.org/cgi/query-pr.cgi?pr=60558 for details.

Jason Harris commented (privately) that .asc suffix is much more
common these days. (My patch defaults to .sig suffix).

On 2003-12-28 at 16:07 -0500, Jason Harris wrote:
> OK, I just finished a (crude) survey and found that
> ~4% of FreeBSD's ports' distfiles are PGP-signed:
> 
> 	databases	8
> 	devel		25
> 	ftp		7
> 	mail		46
> 	misc		19
> 	net		39
> 	security	59
> 	sysutils	26
> 	www		24
> 	all others	135
> 	----------	---
> 	total		388
> 
> 
> 245 have .asc extensions, 136 have .sig extensions, one (web) server
> returned .sign when asked for .sig:

I have also seen .sig.asc suffix. ;)

In any case, if .asc is indeed much more common suffix for detached
signatures, it is trivial to modify the patch to change that default.

> Whether all these signers have their keys on the keyservers
> (ports/security is 100% but I haven't checked the others) and
> all these signatures verify is still unknown, but I'll likely
> try to determine that next.

That shouldn't really matter. The patch just makes a best-effort to
check a signature, but failure to do so is *NOT* catastrophic.
After all, it does NOT replace the current MD5 checksum mechanism,
but is *in addition* to it.

Moreover, if a lot of people believe that automatically fetching public
keys from a keyserver will create a security risk, then I can add a knob
to disable that behavior by default (even though I think it would make
the whole mechanism a lot less useful).

By the way, my choice of pgp.mit.edu as the default keyserver
(overridable) is also open for discussion.

Now, there was another opinion on the subject in general:

On 2003-12-28 at 16:49 -0500, Jose Nazario wrote:
> i'm against it for the following reasons:
> 
> 	- the ease with which the system can be subverted
> 	- the continual quality issues in gnupg

These two points may have some value in them ;) but remember - we still
have MD5 checksum as I just mentioned above. GPG signatures are just an
additional level of verification.

> 	- the license on gnupg and the aims of the bsd project

Not applicable - we are not bringing GPG into the base system. 8-)

> 	- yet another dependency

It does *NOT* add GPG as a dependency. It does signature verification 
if (and only if) GPG is *ALREADY* present on your system.
If GPG is not found, it just displays a harmless warning message.

> all of those alone are enough reason for me to dislike it, and together
> they just completely nullify any value for my for this capability.

I like the patch. 8-) 
YMMV ;)

> i'm far more pleased with the current mechanisms we use in bsd with
> cryptographic hashes, this caught a number of incidents in the past two
> years. while we lack any mechanism of verifying them beyond "this is what
> i think was supposed to be downloaded" and "this is what everyone else has
> for a hash", it's worked very well.

I am fine with MD5 checksums, too. I am not saying GPG signatures should
replace them. 

On 2003-12-28 at 19:08 -0500, Jason Harris wrote:
> The prime value of automatically checking PGP signatures is so people
> who know enough about a software distribution, its author, and/or its
> author's PGP key(s) can more easily spot discrepancies in the form of
> newer signatures on existing revisions (stolen key, trojaned distfile),
> signatures made by unexpected keys (bogus key, trojaned distfile),
> and signatures made by untrusted keys (legitimate key that needs more
> signatures).  Also, having even unfamiliar people looking at the GPG
> output as they fetch the tarballs, signatures, and keys anew is quite
> valuable.  With more eyes on the ball, even the newbie who signs all
> keys on their keyring and then notices a signature by a new, untrusted
> key during a port upgrade will have the potential to stop trojans.

Exactly my point! Being able to confirm the authenticity of the
tarball(s) by another mean in addition to the MD5 checksum should give
more confidence to the admin installing the port, IMHO.

Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20031229/107173dc/attachment.bin