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

Upstream Tarball Signature Files

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