Hi, On Tue, Apr 12, 2016 at 09:19:41AM +0200, Ansgar Burchardt wrote: > Paul Wise <p...@debian.org> writes: > > On Tue, 22 Oct 2013 10:42:51 +0200 Ansgar Burchardt wrote: > >> uscan would store the signature for the upstream tarball as > >> obtained via pgpsigurlmangle=... in the debian/ directory > > > > ISTR another idea was to place the upstream signature alongside the > > upstream tarball instead of inside the debian/ directory. > > > > foo_0.1.2.orig.tar.gz > > foo_0.1.2.orig.tar.gz.<fingerprint>.asc > > > > AFAIR, there was some work in dak done already to allow this? > > Yes, but there was a bug and I somehow forgot about the patches in > #759401 that Guillem Jover provided. So dak should now accept upstream > signatures, dpkg in stable should ignore them (but not throw an error) > and dpkg in unstable/testing will hopefully start to include them in the > source package (.dsc) soon. > > For a given upstream tarball the upstream signature should go in a file > with the extension `.asc`. For example, for > dune-common_2.4.1.orig.tar.xz > the signature should be in > dune-common_2.4.1.orig.tar.xz.asc > > It should be safe for uscan to already create this file: older versions > of dpkg should just ignore it.
Sounds interesting... 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 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. Also if a new upstream package is signed by a new upstream key, uscan using old key will fail. ... I am a bit confused what kind of ecosystem will we bring and offer to the people. Osamu