signing source code with gpg

Jason Harris jharris at widomaker.com
Wed Mar 14 22:32:14 CET 2007


On Wed, Mar 14, 2007 at 06:42:48PM +0100, Werner Koch wrote:
> On Wed, 14 Mar 2007 18:06, jbruni at mac.com said:

> > revision control system changes the content of the files it will
> > invalidate the signature.

I've read opinions that keyword expansion is deprecated, and seeing
things like:

  $MBSDlabs: portmk/bsd.ocaml.mk,v 1.18 2006/08/06 18:47:23 stas Exp $
  $FreeBSD: ports/Mk/bsd.ocaml.mk,v 1.1 2007/03/14 04:05:25 linimon Exp $

makes me tend to agree.  While this shows the origin of the file in
multiple repositories, does it really help the upstream author when
merging patches from downstream?

Also, CVS (and probably other systems) doesn't update keywords until
after a checkin+checkout cycle, so any signatures you [re]generate
before the next checkout will be[come] broken.  Thus, using keyword
expansion means you have to trust the server to give back your files
with hopefully only the keywords modified before you can [re-]sign
them.  Of course, this requires two checkins and is particularly
noticeable (i.e., ugly) and even more problematic (i.e., "The sigs
are broken in -r5, get -r6.")  on newer systems with atomic commits
that would otherwise prevent this (keyword-expansion-race) problem.

> FWIW, I use this with some files and Subversion:
> 
> # Note: The subversion copy of this file carries a gpg:signature
> # property with its OpenPGP signature.  Check this signature before
> # adding entries:
> #  f=foo; svn pg gpg:signature $f | gpg --verify - $f
> # to create a new signature:
> #  f=foo; gpg -sba $f && svn ps gpg:signature -F $f.asc $f

Finally!  :)

But (for those who may be unaware), unfortunately this will allow
valid sigs from _any key_ you happen to have in _any of the keyrings_
GPG accesses during this step.

Now seems like a good time to ask for an option like:

  --require-sig-from <fingerprint> [<fingerprint> ...]

to make sure sigs are only from particular signers.

As an add-on to the FreeBSD ports system, I've already had to employ
--status-fd to make sure I get a signature from an expected signer:

  ===> Verifying PGP signature gnupg-1.4.7.tar.bz2.sig
  gpg: assuming signed data in `/usr/ports/distfiles//gnupg-1.4.7.tar.bz2'
  gpg: Signature made Mon Mar  5 04:54:17 2007 EST using RSA key ID 1CE0C630
  gpg: please do a --check-trustdb
  gpg: Good signature from "Werner Koch (dist sig) <dd9jn at gnu.org>"
  Primary key fingerprint: 7B96 D396 E647 1601 754B  E4DB 53B6 20D0 1CE0 C630
  gpg: binary signature, digest algorithm SHA1
  ===> Valid sig. from expected ID 0x7B96D396E6471601754BE4DB53B620D01CE0C630.

versus a key ID that differs even by only one bit:

  ===> Verifying PGP signature gnupg-1.4.7.tar.bz2.sig
  gpg: assuming signed data in `/usr/ports/distfiles//gnupg-1.4.7.tar.bz2'
  gpg: Signature made Mon Mar  5 04:54:17 2007 EST using RSA key ID 1CE0C630
  gpg: please do a --check-trustdb
  gpg: Good signature from "Werner Koch (dist sig) <dd9jn at gnu.org>"
  Primary key fingerprint: 7B96 D396 E647 1601 754B  E4DB 53B6 20D0 1CE0 C630
  gpg: binary signature, digest algorithm SHA1
  => error:  File wasn't signed by ID 0x7B96D396E6471601754BE4DB53B620D01CE0C631.
  => error:  Make sure sigs. from  ID 0x7B96D396E6471601754BE4DB53B620D01CE0C630
  => error:  are legitimate before adjusting FP_SIG_000 in Makefile.csig
  *** Error code 1

or several expected signers:

  ===> Verifying PGP signature subversion-1.4.3.tar.bz2.asc
  gpg: armor header: Version: GnuPG v1.4.5 (Cygwin)
  gpg: armor header: Version: GnuPG v1.4.3 (GNU/Linux)
  gpg: armor header: Version: GnuPG v1.4.5 (GNU/Linux)
  gpg: armor header: Version: GnuPG v1.4.6 (GNU/Linux)
  gpg: armor header: Version: GnuPG v1.4.6 (Darwin)
  gpg: assuming signed data in `/usr/ports/distfiles/subversion/subversion-1.4.3.tar.bz2'
  [snip]
  ===> Valid sig. from expected ID 0x03341CF464A23E9416E76B1EA1FCE25133D38008 23885E64C64E981E4884834D7C535299C0F2C580 332480DA0F8CA37DAEE6D0840B03AE6E4E24517C 3C016F2B764621BB549C66B516A96495E2226795 AAFF6033364F02BB1239907567D9B249674F05E0.

(As implemented, this requires at least one VALIDSIG from every fingerprint
in the list.)

NB:  This facilitates [re]fetching the key(s) in advance of the signature
check to help catch any revocations _and_ removes the need to --[l]sign
keys to "memorize" them as "expected" signers and/or to juggle keyrings,
esp. with gpgv.

-- 
Jason Harris           |  NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
jharris at widomaker.com _|_ web:  http://keyserver.kjsl.com/~jharris/
          Got photons?   (TM), (C) 2004
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 313 bytes
Desc: not available
Url : /pipermail/attachments/20070314/72ee98a2/attachment.pgp 


More information about the Gnupg-users mailing list