On Wed, 1 Feb 2023 at 11:26, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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/"
