Bug#841910: uscan behaviour on multiple signatures

[Bernhard Schmidt]

On Wed, Oct 26, 2016 at 06:08:28PM -0400, James McCoy wrote:

Hi,

> > IMHO this behaviour does not make any sense. You need to check the
> > authenticity of any additional key upstream might use before adding it
> > to the repo,
> 
> Of course you do.  Why wouldn't you verify the authenticity of a key
> before adding it to signing-key.asc?  Adding the key is indicating that
> you trust it's a valid key to be used to sign the archive you're going
> to use to create a new version of the Debian package.

Indeed. So I have to check every key very carefully, because
> 
> > you cannot just use one known-good key and ignore the rest.
> > This even makes an attack a bit more likely, since control over just one
> > key in the set is enough to build and sign an accepted tarball.
> How so?  Every signature on the archive needs to be verified for gpgv to
> return success.  gpgv is already return a failing exit code in your
> scenario because you have weren't able to verify one of the 4 signatures
> on the archive.  uscan just needs to propagate gpgv failure to its own
> exit code.

as soon as I add it to the keyring every single key in there is
sufficient to properly (in the eyes of uscan/gpgv) sign a new release
alone.

See my answer to Osamu as well.

Say a hypothetical upstream allows everyone to publish additional
signatures for a release (i.e. every developer in the project or even
everyone in the world, because additional signatures don't hurt). I'd
have to check everyone, add everyone to the keyring and every single key
in there would be sufficient to sign a new release.

But this part of the report is rather theoretical, my main issue was
that uscan stops processing the tarball (no repack etc) without a clear
error message.

uscan warn: OpenPGP signature did not verify.

as last message on the console does not really tell me that the
processing has bailed out at this point. I had not used the dfsg
repacking feature of uscan before and was scratching my head quite a bit
until I realized that the warning and the missing dfsg tarball were
related.

Bernhard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/devscripts-devel/attachments/20161028/c1895ffe/attachment.sig>