Re: Upstream Tarball Signature Files
Hi,
On Fri, Aug 18, 2017 at 12:08:02PM +0200, Guillem Jover wrote:
> Hi!
>
> 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).
If uscan/uupdate can off-load this task to dpkg-source, it's great for
me. They are already too much functionalities in them.
Important thing is (as I already changed my mind as I posted) to keep
this signature file format of the source package to be as uniform as
possible. Tools such as DAK can support this new source file format
addition with least work.
> 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?
Wherever we make conversion, it's a magic. We need to get things
simple across system somehow.
No objection from me.
Anyway gnupg is recommends for dpkg-dev (dpkg-source) already. So if
gnupg is missing, just spit out warning.
Osamu
Reply to: