Bug#610712: [devscripts] Allow to check cryptographic signatures

[Daniel Kahn Gillmor]

Control: tags 610712 + patch

On Fri 2011-01-21 11:25:27 -0500, Emil Langrock wrote:

> A more interesting approach is to make it possible to download the source
> tarball and a pgp/gnupg signature which is used to verify the the
> file.

This is i think the approach we want to pursue.  having a standard way
to do this would also help to encourage best practices from upstream.

> So we need to ensure that only a single (or multiple) predefined keys
> are accepted.

yep, agreed.

> I don't expect uscan to implement all that in the framework in a heavily
> configurable manner, but to allow to add some kind of verify hook that calls
> an external script. This script has to receive the url which was used to
> download the file and the location of the downloaded file. The return value
> can be used to in uscan to decide if the file is ok or was modified.

I think i actually disagree here.  I would prefer if uscan implemented
this directly, so that the maintainer only has to specify the bare
minimum:

 * where to find the matching signature (perhaps as a new opts= option
   in debian/watch, based on a set of mangling rules that apply
   subsequently to the upstream URL)

 * the key that should make the signature (perhaps in a keyring file
   like debian/upstream-signing-key.pgp)

The attached patch implements the above proposal, using (e.g.)
opts=pgpsigurlmangle=s/$/.asc/  and debian/upstream-signing-key.pgp.

One possible gotcha: since debian/upstream-signing-key.pgp is not likely
to be a plain text file, packages which use this will probably need to
be source format 3.0 (quilt) instead of using a diff.gz.  This doesn't
bother me (i think we should be transitioning packages to 3.0 (quilt)
anyway).

If this could be integrated into devscripts, then we could improve the
ability to check the cryptographic integrity of upstream files.

another possible gotcha: this approach doesn't prevent against replay
attacks that target the version string alone.  That is, if alice
releases FooSoft 0.7 (fixing a critical vulnerability in earlier
versions of FooSoft), and Eve can MITM the connection between the debian
developer and the FooSoft distribution server, there's nothing stopping
Eve from renaming FooSoft_0.6.tgz to FooSoft_0.8.tgz and
FooSoft_0.6.tgz.asc to FooSoft_0.8.tgz.asc.

In this case, uscan will accept the package as a new version (because
the signature checks out OK).  So we're still relying on the debian
package maintainer to at least do a sanity check based on the version of
the filename, which hopefully isn't too unreasonable.

We could mitigate this threat by requiring the user to store the
timestamp of the last signed version someplace like
debian/upstream-last-signed-time, assume that time is monotonically
increasing, and reject any signature older than
debian/upstream-last-signed-time.  I don't know that this is necessary
(and i'm not sure how to implement it with gpgv, the tool this patch
uses for signature verification).

Regards,

        --dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 965 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/devscripts-devel/attachments/20130504/9e89d39c/attachment.pgp>