Upstream Tarball Signature Files

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Upstream Tarball Signature Files

Paul Hardy

The version of lintian now in testing, 2.5.52, introduces a new error (not just a warning) for missing ".asc" signature files.  The relevant changelog entry is
     + Added:
           ...
           - orig-tarball-missing-upstream-signature
A missing ".orig.tar.*.asc" file now produces a lintian error (not just a warning).

debian-policy does not require such signature files in a ".changes" file for the Checksums-Sha1, Checksums-Sha256, or Files sections.  I think for lintian to report this as an error, it should be a policy violation.

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

This is especially beneficial if any requirement for a signature file is a goal for upstream sources.  As one example, GNU Project files on the GNU FTP repository are uploaded with corresponding ".sig" files.  It would be redundant to also require ".asc" signature files for those packages.

It is possible to fake out lintian by taking a binary ".sig" file and changing its extension to ".asc", but I think that is sub-optimal.

Making changes to debian-policy (if deemed appropriate) to allow upstream binary signature files would affect at least lintian, dpkg-dev, uscan, and Debian maintainer guides.

Such signature files are discussed in bug #870069 for lintian and #727096 for uscan.

For dpkg, it looks like the Perl variable "$tarsign" stores the name of the signature file in some Perl scripts.  There are patterns that allow ".asc" filenames in "$tarsign" in V1.pm and V2.pm, which reside in scripts/Dpkg/Source/Package.

In summary, if ".orig.tar.*" signature files are deemed important enough to make part of Debian policy, I think at least GNU Project upstream maintainers would benefit from Debian recognizing the binary ".sig" signature format in addition to the ".asc" format.  On the other hand, if such signature files are not required for ".changes" files, then I do not think lintian should be treating this case as an error.

No matter what, lintian behavior and Debian policy should be in agreement with what is a real error versus what should only be treated as a warning.

Thank you,


Paul Hardy

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upstream Tarball Signature Files

Sean Whitton
Hello,

On Mon, Aug 07 2017, Paul Hardy wrote:

> The version of lintian now in testing, 2.5.52, introduces a new error
> (not just a warning) for missing ".asc" signature files.  The relevant
> changelog entry is
>
>      + Added:
>            ...  - orig-tarball-missing-upstream-signature
>
> A missing ".orig.tar.*.asc" file now produces a lintian error (not
> just a warning).

This is a known bug in the current version of Lintian.

> 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".
>
> This is especially beneficial if any requirement for a signature file
> is a goal for upstream sources.  As one example, GNU Project files on
> the GNU FTP repository are uploaded with corresponding ".sig" files.
> It would be redundant to also require ".asc" signature files for those
> packages.
>
> It is possible to fake out lintian by taking a binary ".sig" file and
> changing its extension to ".asc", but I think that is sub-optimal.
>
> Making changes to debian-policy (if deemed appropriate) to allow
> upstream binary signature files would affect at least lintian,
> dpkg-dev, uscan, and Debian maintainer guides.
This sounds like a new policy bug to be filed :)

--
Sean Whitton

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upstream Tarball Signature Files

Osamu Aoki
In reply to this post by Paul Hardy
Hi,

On Mon, Aug 07, 2017 at 08:26:41PM -0700, Paul Hardy wrote:
...
> Making changes to debian-policy (if deemed appropriate) to allow upstream
> binary signature files would affect at least lintian, dpkg-dev, uscan, and
> Debian maintainer guides.

You should mean one of:
 Debian Developer's Reference
 Debian New Maintainers' Guide
 Guide for Debian Maintainers
 
> Such signature files are discussed in bug #870069 for lintian and #727096 for
> uscan.

Now I understand the context/motivation behind the new #870281 uscan bug
report.

Osamu

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upstream Tarball Signature Files

Guillem Jover
In reply to this post by Paul Hardy
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 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. 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
  $ gpg --verify unifont_upper-10.0.05.ttf.asc
  gpg: assuming signed data in 'unifont_upper-10.0.05.ttf'
  gpg: Signature made Wed Jul 12 13:05:45 2017 CEST
  gpg:                using RSA key 95D2E9AB8740D8046387FD151A09227B1F435A33
  gpg: Can't check signature: No public key

This could be done automatically as part of uscan, so you'd not even
need to do it manually!

> This is especially beneficial if any requirement for a signature file is a
> goal for upstream sources.  As one example, GNU Project files on the GNU
> FTP repository are uploaded with corresponding ".sig" files.  It would be
> redundant to also require ".asc" signature files for those packages.

Although, some of those .sig files on the GNU site are actually ASCII
armored signatures (c.f. hello).

Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upstream Tarball Signature Files

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

True.  But why you want to limit to one format between .sig and .asc?

For example, uscan accepts either one when it downloads and verifies the
downloaded tarball and signaturefile.{asc,pgp,gpg,sgn,sign} with the
keyring stored in debian/upstream/signing-key.{pgp,asc}.  Why not do the
same?

If you accepts, uscan's job is creating symlink only to fix the newly
requested bug.

Please note we are more relaxed on what upstream does but what packager
does is limited to debian/*.pgp only (no gpg, sgn sign) at this moment.
(Maybe I can relax it if someone requests it with good reason.)

> Although, some of those .sig files on the GNU site are actually ASCII
> armored signatures (c.f. hello).

The uscan manpage says it accepts 4 extensions while it is accepting 5
extensions now.  I will fix it.

Osamu

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upstream Tarball Signature Files

Paul Hardy

On Tue, Aug 8, 2017 at 5:13 AM, Osamu Aoki <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upstream Tarball Signature Files

Russ Allbery-2
Paul Hardy <[hidden email]> 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 ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upstream Tarball Signature Files

Paul Hardy
Russ,

On Sat, Aug 12, 2017 at 7:59 PM, Russ Allbery <[hidden email]> wrote:
Paul Hardy <[hidden email]> 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.

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.

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.

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.

Yes.  My thinking was to maintain the integrity of an upstream signature when applicable.  Changing the extension of a binary ".sig" file to ".asc" will do that.

Thank you,


Paul Hardy

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upstream Tarball Signature Files

Russ Allbery-2
Paul Hardy <[hidden email]> 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 ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upstream Tarball Signature Files

Russ Allbery-2
Henrique de Moraes Holschuh <[hidden email]> 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 ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upstream Tarball Signature Files

Henrique de Moraes Holschuh
On Mon, 14 Aug 2017, Russ Allbery wrote:

> Henrique de Moraes Holschuh <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upstream Tarball Signature Files

Russ Allbery-2
Henrique de Moraes Holschuh <[hidden email]> 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 ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upstream Tarball Signature Files

Paul Hardy
In reply to this post by Russ Allbery-2
Russ,

On Sat, Aug 12, 2017 at 7:59 PM, Russ Allbery <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upstream Tarball Signature Files

Osamu Aoki
In reply to this post by Russ Allbery-2
Hi,

On Mon, Aug 14, 2017 at 10:13:10AM -0700, Russ Allbery wrote:

> Henrique de Moraes Holschuh <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upstream Tarball Signature Files

Paul Hardy
In reply to this post by Guillem Jover
Guillem,

On Tue, Aug 8, 2017 at 1:48 AM, Guillem Jover <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upstream Tarball Signature Files

Paul Hardy
In reply to this post by Osamu Aoki
Dear All,

On Tue, Aug 15, 2017 at 7:25 AM, Osamu Aoki <[hidden email]> wrote:

>
> Hi,
>
> On Mon, Aug 14, 2017 at 10:13:10AM -0700, Russ Allbery wrote:
> > Henrique de Moraes Holschuh <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upstream Tarball Signature Files

Guillem Jover
In reply to this post by Paul Hardy
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Upstream Tarball Signature Files

Guillem Jover
In reply to this post by Paul Hardy
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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 (847 bytes) Download Attachment
12
Loading...