[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Upstream Tarball Signature Files


On Wed, 2017-08-16 at 00:22:43 -0700, Paul Hardy wrote:
> On Tue, Aug 8, 2017 at 1:48 AM, Guillem Jover <guillem@debian.org> wrote:
> > On Mon, 2017-08-07 at 20:26:41 -0700, Paul Hardy wrote:
> > > Also, where signature files are desired, I think it would be beneficial
> > > to also accept binary ".sig" files...
> >
> > There is no need for that, you can convert from ASCII armored to
> > binary signatures and the other way around easily. For example to
> > convert from .sig to .asc you can do the following:
> >
> >   $ gpg --output - --enarmor unifont_upper-10.0.05.ttf.sig | \
> >     sed -e 's/ARMORED FILE/SIGNATURE/;/^Comment:/d' > \
> >     unifont_upper-10.0.05.ttf.asc
> >   ...
> >
> > This could be done automatically as part of uscan, so you'd not even
> > need to do it manually!

> Would you consider doing this conversion in a separate shell script as part
> of dpkg-dev (for example, named "sig2asc")?  Then the script could be run
> from the command line, and uscan also could invoke it.  If you would accept
> that, I could write a proposed shell script with a man page for you and
> file them as patches in a bug against dpkg-dev or mail them to you
> privately.
> I am the GNU Project maintainer for Unifont.  I build the GNU upstream
> version and the Debian version with one higher-level "make" command at the
> same time.  So I would not use uscan for OpenPGP format conversion; I only
> use it in my debian/watch file.
> With a separate shell script in place, maintainer documentation could be
> updated to mention it.  After that, wording for a Policy change concerning
> upstream signatures could be crafted that would refer to that capability.

Hmmm, I've been thinking about this a bit, and perhaps it would be
better if dpkg-source auto-converted any .sig binary signature into
an .asc ASCII armored one when generating the source package (as long
as there is no pre-existing .asc file). This has the advantage of not
requiring devscripts to be installed, preserves compatibility with
stable dpkg-source and DAK so it can be used right away, and allows
us to keep using a single signature format. I've got code doing that
now, which I can merged for 1.19.0, I guess the only possibly
contentious point is that this might seem like doing too much magic
from within dpkg-source?

If people are comfortable with this, I'm happy to merge it.


Reply to: