Bug#727096: uscan: store signature for upstream tarball in debian/

[Daniel Kahn Gillmor]

On Tue 2016-04-12 10:00:09 -0400, Osamu Aoki wrote:
> I assume "create" means "create a copy of the upstream-generated
> signature" as foo_0.1.2.orig.tar.gz.<fingerprint>.asc which can be
> verified by the keyring debian/upstream/signing-key.pgp in the older
> package.

I'm not sure that we need the <fingerprint> in that specification.

> I am a bit confused what kind of assurance it brings to the end user.
>
> The Debian packager can put his random public key in
> debian/upstream/signing-key.pgp and sign a package with his secret key to
> generate foo_0.1.2.orig.tar.gz.<fingerprint>.asc.  The end-user gets
> false sense of security of checking signature but it really does not
> offer much.

I agree that this isn't a magic fix for any kind of cryptographic
provenance checking; it is as much 

However, it establishes more links in the chain that can be inspected,
automated, and in :

 * non-debian systems now have a specific location to look for the key
   that debian thinks is appropriate for upstream (this is debian
   collectively acting as a sort of corroborative certificate authority
   for software signatures)

 * If problems are found with certain kinds of keys for software
   signing, there is an easy way to do a rapid scan of the archive to
   detect which keys might be vulnerable and encourage upstreams to fix
   their practices

 * If a package is team-maintained, or changing maintainers, there is a
   chain-of-custody with respect to the upstream software signatures.

 * It could be used to detect *other* signatures made by the same
   signing key, in a sort of "certificate transparency" overview (this
   would require a lot of extra instrumentation)

> Also if a new upstream package is signed by a new upstream key, uscan
> using old key will fail. ...

sure -- this is something that a debian maintainer should notice and
verify via some other channel.  automating detection of these events and
helping the maintainer by calling attention to them is a good thing.

The point is that this is baseline data about cryptographic provenance,
and it's stuff that should be part of the standard software distribution
process that affects how people ship and update code.  It's at least as
relevant as the exact upstream tarball, so we should be recording it.

         --dkg