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
