Re: Upstream Tarball Signature Files
Hi,
On Mon, Aug 14, 2017 at 10:13:10AM -0700, Russ Allbery wrote:
> Henrique de Moraes Holschuh <hmh@debian.org> 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 to: