Re: Upstream Tarball Signature Files

[Osamu Aoki]

Hi,


On Fri, Aug 18, 2017 at 12:02:27PM +0200, Guillem Jover wrote:
..
> 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.

I just commited uscan/mk-origtargz support of these.

It will be nice dpkg can support both
 foo.tar.gz
 foo.tar.gz.asc
or 
 foo.tar.gz
 foo.tar.asc (signature on uncompressed)
combinations.

There are upstream releasing in these format.

More nasty one is releasing foo.tar.gz with "gpg -s" w/o -b as
foo.tar.gz.sig or "gpg -sa" as foo.tar.gz.asc.  I have no idea how to
extract signaturefile from non-detached signature.  That's remaining
task but a rare case.

Osamu

Re: Upstream Tarball Signature Files

[Osamu Aoki]

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  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
 

Re: Upstream Tarball Signature Files

[Daniel Kahn Gillmor]

On Fri 2017-08-18 14:43:58 +0200, Mattia Rizzolo wrote:
> I'd love if something did this for me, pretty much like I'd love
> something like that does a pretty output to debian/upstream/signing-key
> like
> https://sources.debian.net/src/inkscape/0.92.2-1/debian/upstream/signing-key.asc/

Interesting!  I worry about that, though, because the human-readable
header can go out-of-sync with the underlying b64-encoded data.

I think what we really need is an easier way to easily view an OpenPGP
certificate, in the same way that we might prefer to view a PNG with a
graphical viewer instead of hexdump ;)

  --dkg

Re: Upstream Tarball Signature Files

[Mattia Rizzolo]

On Fri, Aug 18, 2017 at 07:48:24AM -0400, Daniel Kahn Gillmor wrote:
> I confess that i've been taking the boring/silly/cheating way out and if
> upstream ships a detached binary signature as foo-1.2.3.tar.gz.sig, i've
> just been manually renaming it to foo_1.2.3.orig.tar.gz.asc (without
> even converting its contents to ASCII-armored form) and the rest of the
> toolchain seems to just happily accept it -- it'd be even nicer if dpkg
> and/or uscan was to normalize the contents to match the file extension.

That's because TTBOMK there is *nothing* atm actually validating that
file, and AFAIK (please correct me if I'm wrong) dpkg-source just picks
up whatever file, no matter the contents.

> Lastly, it's conceivable that we might want to take an already-armored
> .asc, and "launder" the armor, to stabilize it (e.g. stripping
> non-cryptographically-relevant comments, other weird OpenPGP packets,
> etc, which could all be stuffed into the detached signature).

I'd love if something did this for me, pretty much like I'd love
something like that does a pretty output to debian/upstream/signing-key
like
https://sources.debian.net/src/inkscape/0.92.2-1/debian/upstream/signing-key.asc/
(that's
https://anonscm.debian.org/git/reproducible/misc.git/tree/dump-gpg-keys.sh)

IOW: Guillem: I second merging that sig→asc converter into dpkg-source!
:)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Upstream Tarball Signature Files

[Daniel Kahn Gillmor]

On Fri 2017-08-18 12:08:02 +0200, Guillem Jover wrote:
> 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.

I've got no objection to this.

I confess that i've been taking the boring/silly/cheating way out and if
upstream ships a detached binary signature as foo-1.2.3.tar.gz.sig, i've
just been manually renaming it to foo_1.2.3.orig.tar.gz.asc (without
even converting its contents to ASCII-armored form) and the rest of the
toolchain seems to just happily accept it -- it'd be even nicer if dpkg
and/or uscan was to normalize the contents to match the file extension.

Note that it's possible that something named .sig is itself already
armored, though, we don't want to double-armor it.

Lastly, it's conceivable that we might want to take an already-armored
.asc, and "launder" the armor, to stabilize it (e.g. stripping
non-cryptographically-relevant comments, other weird OpenPGP packets,
etc, which could all be stuffed into the detached signature).  I am not
proposing this as a requirement, and i don't want the suggestion to
block the .sig→.asc fix, but if thinking about that part of the code, it
might be easy to do at the time.  Doing so would reduce the amount of
non-cryptographically-justified sidechannels that debian is willing to
cart around on behalf of upstream authors.  (of course, we're currently
willing to cart stuff around for upstream authors who don't make
cryptographic signatures at all today, so maybe it's too nit-picky to
obsess about sidechannels just for those who make signatures)

Thanks for working on this, Guillem!

 --dkg


signature.asc
Description: PGP signature

Re: Upstream Tarball Signature Files

[Guillem Jover]

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  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.

Thanks,
Guillem

Re: Upstream Tarball Signature Files

[Guillem Jover]

Hi!

[ Daniel CCed, please see the thread starting at
  . ]

On Sat, 2017-08-12 at 15:32:22 -0700, Paul Hardy wrote:
> On Tue, Aug 8, 2017 at 5:13 AM, Osamu Aoki  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

Re: Upstream Tarball Signature Files

[Paul Hardy]

Dear All,

On Tue, Aug 15, 2017 at 7:25 AM, Osamu Aoki  wrote:
>
> Hi,
>
> On Mon, Aug 14, 2017 at 10:13:10AM -0700, Russ Allbery wrote:
> > Henrique de Moraes Holschuh  writes:
> >
> > > May I humbly suggest that, *if* a change is going to be made, we switch
> > > to ".sig" (binary) and ".sig.asc" (armored), or .sig.gpg / sig.gpg.asc?
> > > As in "let's not overload .asc to mean armored signature, when it only
> > > means ASCII text"...
> >
> > [Russ Allbery] Note that I'm arguing for no change, just documenting the 
> > existing support
> > for *.asc upstream signatures.  This will imply that anyone who wants to
> > include an upstream signature that's provided in *.sig format will need to
> > convert it to *.asc, but that's not a *change*.  That's the current state
> > of the archive.
>
> Very good points.  I changed my mind a bit.
>
> Basically, its better to have uniform rules for format so all associated
> tools become simple.  Tools like uscan may accept any signature format,
> but the tools at the level of dpkg and archive maintenance tools should
> be simple.
>
> I like to use *.asc as signature file.  (Uscan may convert)
>
> Also, maybe policy just mandate debian/upstream/signing-key.asc for key
> ring.
>
> Osamu

I have put together "sig2asc" and "asc2sig" shell scripts.  Each
script takes two arguments: input signature file name and output
signature file name.  If an input file is the desired output format,
it is copied to the output file; otherwise it is converted.  I do a
grep for "BEGIN PGP SIGNATURE" to determine if the file is in ASCII
format.  Round-trip conversions work with the two scripts.  (Guilllem,
I put your name and my name as authors and gave them a GPL 2+
license.)

I think uscan will be able to invoke these scripts easily; it just
needs to come up with the output file name that it wants.  A
command-line script also will let people like me who *are* upstream
(and therefore do not use uscan to download the upstream version) to
make such conversions.

If either dpkg-dev or devscripts package maintainers will accept these
scripts, I will write man pages and forward them to the respective
package maintainers.  If you will accept them and want the names
changed, I can do that before sending them.  I am going on travel
after tomorrow, returning the middle of next week.  If I hear back and
don't get the man pages written before I leave, I will do so right
after I return.

With this being a long-term (as in forever) solution, I do think
".sig" would be a nicer extension to use if everybody only wants a
single extension (because ".sig" means "signature"), where a ".sig"
file would be allowed to contain the signature in the exact form of
upstream: binary or ASCII.  gpg doesn't care which format it is given;
it will figure out the right thing to do regardless.  But that would
involve a transition.  If everyone else wants ".asc" as the extension,
so be it.

At least by having one standard script in Debian for everyone who must
convert upstream binary signature files to ASCII, it will avoid all
those maintainers having to come up with individual solutions.

Thank you,


Paul Hardy

Re: Upstream Tarball Signature Files

[Paul Hardy]

Guillem,

On Tue, Aug 8, 2017 at 1:48 AM, Guillem Jover  wrote:

> Hi!
>
> 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.

So I would postpone adding mention of upstream signature file use in the
Policy Manual until those components are in place (shell script and
maintainer document updates).

Thank you,


Paul Hardy

Re: Upstream Tarball Signature Files

[Osamu Aoki]

Hi,

On Mon, Aug 14, 2017 at 10:13:10AM -0700, Russ Allbery wrote:
> Henrique de Moraes Holschuh  writes:
> 
> > We do when the binary sig is small enough to be stored along with the
> > inode, instead of requiring an entire filesystem block (4KiB), and the
> > armored signature is not small enough for that :-( Of course, this
> > really depends a lot on the filesystem, etc.
> 
> I'm not sure what signatures you're looking at.  Maybe ones with lots of
> separate signers?  A typical *.asc file with one signer is about 500
> bytes.
> 
> > May I humbly suggest that, *if* a change is going to be made, we switch
> > to ".sig" (binary) and ".sig.asc" (armored), or .sig.gpg / sig.gpg.asc?
> > As in "let's not overload .asc to mean armored signature, when it only
> > means ASCII text"...
> 
> Note that I'm arguing for no change, just documenting the existing support
> for *.asc upstream signatures.  This will imply that anyone who wants to
> include an upstream signature that's provided in *.sig format will need to
> convert it to *.asc, but that's not a *change*.  That's the current state
> of the archive.

Very good points.  I changed my mind a bit.

Basically, its better to have uniform rules for format so all associated
tools become simple.  Tools like uscan may accept any signature format,
but the tools at the level of dpkg and archive maintenance tools should
be simple.

I like to use *.asc as signature file.  (Uscan may convert)

Also, maybe policy just mandate debian/upstream/signing-key.asc for key
ring.

Osamu

Re: Upstream Tarball Signature Files

[Paul Hardy]

Russ,

On Sat, Aug 12, 2017 at 7:59 PM, Russ Allbery  wrote:

>
> Hi Paul,
>
> This isn't a debian-policy matter...
>

My thinking was it would be beneficial for Debian Policy to suggest (but
not require) use of upstream OpenPGP signatures when available, because
such signature file use will help ensure the integrity of the Debian
archive.

However, I don't think it's a good idea to support multiple file names for
> the same thing...
>
> It's almost never a good idea to introduce synonyms into any sort of
> standard.  It adds a lot of complexity that has to be maintained forever,
> to very little benefit.


In this case, it is a trade-off between Debian packaging tools accepting
both ASCII and binary signature files forever, versus Debian maintainers
who repackage upstream sources with binary signatures having to convert
those signatures with each new upstream release forever.

The GNU FTP repository files are accompanied by binary ".sig" signatures
during upload to that site, and are listed with the accompanying files
(which is why I need to generate binary ".sig" files for upstream).  The
benefit at least would be for Debian maintainers who re-package those GNU
Project files.

However, I can propose additions for the Policy Manual in Chapter 4 and the
Files and Checksums sections that only describe the ".asc" format.  At
least that will document the current situation.

Thanks,


Paul Hardy

Re: Upstream Tarball Signature Files

[Russ Allbery]

Henrique de Moraes Holschuh  writes:

> We do when the binary sig is small enough to be stored along with the
> inode, instead of requiring an entire filesystem block (4KiB), and the
> armored signature is not small enough for that :-( Of course, this
> really depends a lot on the filesystem, etc.

I'm not sure what signatures you're looking at.  Maybe ones with lots of
separate signers?  A typical *.asc file with one signer is about 500
bytes.

> May I humbly suggest that, *if* a change is going to be made, we switch
> to ".sig" (binary) and ".sig.asc" (armored), or .sig.gpg / sig.gpg.asc?
> As in "let's not overload .asc to mean armored signature, when it only
> means ASCII text"...

Note that I'm arguing for no change, just documenting the existing support
for *.asc upstream signatures.  This will imply that anyone who wants to
include an upstream signature that's provided in *.sig format will need to
convert it to *.asc, but that's not a *change*.  That's the current state
of the archive.

-- 
Russ Allbery (r...@debian.org)   

Re: Upstream Tarball Signature Files

[Henrique de Moraes Holschuh]

On Mon, 14 Aug 2017, Russ Allbery wrote:
> Henrique de Moraes Holschuh  writes:
> > On Sun, 13 Aug 2017, Russ Allbery wrote:
> >> it can't just move the file -- it has to ASCII-armor it.  But still, I
> >> think that's the right thing for the tools to do, not add another file.
> >> (The ASCII format is completely equivalent to the binary format; the
> >> conversion shouldn't lose or change any data.)
> 
> > The armor just wastes space, and will do so for every signature in the
> > archive.
> 
> I very much doubt we will ever notice such a tiny amount of overhead.

We do when the binary sig is small enough to be stored along with the
inode, instead of requiring an entire filesystem block (4KiB), and the
armored signature is not small enough for that :-(   Of course, this
really depends a lot on the filesystem, etc.

It is not an extreme difference anyway even in the worst case, but it
might be a Good Idea to avoid technical debt on a feature we have not
even deployed to production (as in "started to use") yet, without at
least considering the alternatives.

> > Why are we not using binary signatures in the first place, if we're
> > going to mandate conversions?
> 
> We could go that route too, but I don't think the benefits are worth
> changing the existing code that supports *.asc files.  But I certainly
> wouldn't object if the folks doing the work wanted to change.  I just want
> to support only one or the other.

Then we should have gone with .sig :-(  At least it means "signature",
and not "ascii text".

May I humbly suggest that, *if* a change is going to be made, we switch
to ".sig" (binary) and ".sig.asc" (armored), or .sig.gpg / sig.gpg.asc?
As in "let's not overload .asc to mean armored signature, when it only
means ASCII text"...

-- 
  Henrique Holschuh

Re: Upstream Tarball Signature Files

[Russ Allbery]

Henrique de Moraes Holschuh  writes:
> On Sun, 13 Aug 2017, Russ Allbery wrote:

>> it can't just move the file -- it has to ASCII-armor it.  But still, I
>> think that's the right thing for the tools to do, not add another file.
>> (The ASCII format is completely equivalent to the binary format; the
>> conversion shouldn't lose or change any data.)

> The armor just wastes space, and will do so for every signature in the
> archive.

I very much doubt we will ever notice such a tiny amount of overhead.

> Why are we not using binary signatures in the first place, if we're
> going to mandate conversions?

We could go that route too, but I don't think the benefits are worth
changing the existing code that supports *.asc files.  But I certainly
wouldn't object if the folks doing the work wanted to change.  I just want
to support only one or the other.

-- 
Russ Allbery (r...@debian.org)   

Re: Upstream Tarball Signature Files

[Henrique de Moraes Holschuh]

On Sun, 13 Aug 2017, Russ Allbery wrote:
> it can't just move the file -- it has to ASCII-armor it.  But still, I
> think that's the right thing for the tools to do, not add another file.
> (The ASCII format is completely equivalent to the binary format; the
> conversion shouldn't lose or change any data.)

The armor just wastes space, and will do so for every signature in the
archive.

Why are we not using binary signatures in the first place, if we're
going to mandate conversions?

-- 
  Henrique Holschuh

Re: Upstream Tarball Signature Files

[Russ Allbery]

Paul Hardy  writes:

> If it is permissible to rename a ".sig" file as ".asc", I think that is
> the best solution because it copies the original signature file
> unmodified.  I tried it previously and it worked, but it seemed to me
> like masquerading (because a binary file obviously is not an
> ASCII-armored file) and not right.

Oh, sorry, I'd missed that it was the binary format.  Yeah, in that case
it can't just move the file -- it has to ASCII-armor it.  But still, I
think that's the right thing for the tools to do, not add another file.
(The ASCII format is completely equivalent to the binary format; the
conversion shouldn't lose or change any data.)

> The first part of my request was going to suggest adding ".asc" files in
> examples.  The Policy Manual gives sample lists of files that appear in
> the Files and Checksums sections (5.6.21 and 5.6.24) of ".dsc" and
> ".changes" files using "example_1.2.orig.tar.gz" and
> "example_1.0.orig.tar.gz".  Do you think it is appropriate to mention
> that those sections may contain signature files of the form
> "example_1.[02].orig.tar.gz.asc", showing that file name with the other
> files?  There seems to be no mention of such a file in the Policy
> Manual.  Sections 5.6.21 and 5.6.24 are where I thought of requesting
> changes.

I think it would be appropriate to document how to include upstream
signature files in a Debian source package, absolutely.  (That's quite a
bit more than just adding them to examples.)

-- 
Russ Allbery (r...@debian.org)   

Re: Upstream Tarball Signature Files

[Russ Allbery]

Paul Hardy  writes:

> 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 had not brought this up until the latest lintian check on a test build
> returned an error, but then Sean noted that the lintian error report is a
> bug.

> If there are no strong objections to this change, I will file a wishlist
> bug as an "issue" for debian-policy about this.  I will be away next
> weekend so I will try to put together something before then.

Hi Paul,

This isn't a debian-policy matter.  Support for ".sig" files in *.changes
and *.dsc would be a bug against dpkg and possibly also in DAK for the
archive to handle them, and in watch files would be a bug against
devscripts.

However, I don't think it's a good idea to support multiple file names for
the same thing.  Instead, package building tools should probably just
rename *.sig files to *.asc if upstream uses *.sig, the same way thhat
they rename upstream source tarballs to follow our naming convention
(which upstream almost never uses).  The bug may be best filed against
devscripts for uscan --download to rename the signature on download.

It's almost never a good idea to introduce synonyms into any sort of
standard.  It adds a lot of complexity that has to be maintained forever,
to very little benefit.

-- 
Russ Allbery (r...@debian.org)   

Re: Upstream Tarball Signature Files

[Paul Hardy]

On Tue, Aug 8, 2017 at 5:13 AM, Osamu Aoki  wrote:

> Hi,
>
> 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.

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 had not brought this up until the latest lintian check on a test build
returned an error, but then Sean noted that the lintian error report is a
bug.

If there are no strong objections to this change, I will file a wishlist
bug as an "issue" for debian-policy about this.  I will be away next
weekend so I will try to put together something before then.

Thanks,


Paul Hardy