On Wed, 1 Feb 2023 at 11:26, Ævar Arnfjörð Bjarmason [off-list ref] wrote:

That would be going above & beyond what's needed IMO, but still a lot
easier than the daunting task of writing a specification that exactly
described GNU gzip's current behavior, to the point where you could
clean-room implement it and be guaranteed byte-for-byte compatibility.

Why does it have to be gzip? It is not that hard to come up with a
relatively good compression algorithm that is stable if you aren't
expecting super fast performance or super good compression. If all you
need is good enough but stability is a hard requirement then
algorithms like LZW are available (it has been out of patent since
~2003), and produce reasonable results. If people want a stable
archive then they might have to use some tool that git provides to
decompress and they might not get the best compression ratios, nor
speed, but they would get stability. You can write a decent LZW
implementation in a few hundred lines of code. With a bit of care you
could implement it in a way that allows you to compute the true hash
digest of the compressed data without actually decompressing it as
well, which would address some of the concerns that brian raised with
regard to security I think.

Why does this email remind me of that old canard that any sufficiently
advanced piece of software gains the ability to send emails? :-)

cheers,
Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"