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