Re: Upstream Tarball Signature Files

[Guillem Jover <guillem@debian.org>]

Hi!

[ Daniel CCed, please see the thread starting at
  <https://lists.debian.org/debian-policy/2017/08/msg00201.html>. ]

On Sat, 2017-08-12 at 15:32:22 -0700, Paul Hardy wrote:
> On Tue, Aug 8, 2017 at 5:13 AM, Osamu Aoki <osamu@debian.org> wrote:
> > On Tue, Aug 08, 2017 at 10:48:08AM +0200, Guillem Jover 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 as an alternative to ".asc" files, for
> > > > example as produced with "gpg -b".
> > >
> > > There is no need for that, you can convert from ASCII armored to
> > > binary signatures and the other way around easily.
> 
> Guillem: I will use the workaround that you posted for now.  My thinking
> was to preserve the timestamp of the original signature file, and what you
> posted does accomplish that.  I think using a sed script is not as clean as
> also someday allowing a ".sig" file in ".changes" and ".dsc" files though.
> Do you think it will be hard to add that ability to dpkg?  It looks like
> the V1 and V2 Perl modules could add a ".orig.tar.*.sig" to the list of
> acceptable $tarsign string assignments.  It seems that the $tarsign
> signature file must be getting returned by the get_files calls, for example
> in dpkg-genchanges.pl, but I did not see how with a quick look at the dpkg
> code.

Adding support for more signature formats or filename variations is
not hard, but it increases the amount of those extensions and perhaps
the additional sanity checks we have to support and perform on them on
multiple tools, etc. It would also require waiting at least once more
release cycle until they can be used.

> > True.  But why you want to limit to one format between .sig and .asc?
> 
> Osamu: I did not mean just accept one format--I meant accept both ".asc"
> and ".sig" files for ".changes", ".dsc", and uscan files.  I suppose all
> three manuals you mentioned could be modified to document this.

I have a faint memory of bringing this up when Daniel proposed adding
support for this, but I cannot find references now, perhaps it was
in person at DebConf15(?). Also from memory (which I might have
totally made up after the fact), one/the reason Daniel gave was exactly
what I wrote above, that the files can be very easily converted. In
addition using ASCII armored signatures makes them easier to transport
over mail and similar, and they are perhaps more resistant against
transport damage, given that they are delimited by the armored header
lines, base64 encoded, and in addition contain a CRC. But Daniel will
correct me if I'm wrong.

I also have to agree with the complain that .asc is not a very good
name, but that's what is commonly used, and I don't think it's used
elsewhere for other stuff(?), such as generic ASCII text files. Also
.asc signatures are in common use, perhaps more than binary ones? In
any case, if there's consensus that we'd rather use binary signatures
in .sig files, I'll happily add support for that.

Thanks,
Guillem