Re: Upstream Tarball Signature Files
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
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
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, On Sat, Aug 12, 2017 at 7:59 PM, Russ Allbery wrote: > 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. > 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
Re: Upstream Tarball Signature Files
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
