lzip-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Statement about the maintenance of lzip


From: Steffen Nurpmeso
Subject: Re: Statement about the maintenance of lzip
Date: Thu, 11 Apr 2024 21:37:11 +0200
User-agent: s-nail v14.9.24-612-g7e3bfac540

Adam Tuja wrote in
 <476191712582717@mail.yandex.com>:
 ||In public discussions about the backdoor recently discovered in xz-utils, \
 ||I 
 ||have noticed that some people are considering a possible switch to \
 ||lzip but 
 ||are worried that the same social engineering techniques that made \
 ||possible 
 ||the insertion of the backdoor in xz might also be used against lzip. \
 ||I would 
 ||like to explain why I think this is not the case.
 |
 |Maybe it's a time to advert your product. Most products are popular \
 |thanks to advertising, not because they are better. And unpopular products \
 |die, or cease to exist. Simple as that.

How about malloc hookability?

git (at least an automated conversion to Savannah / xy)?

I think the BSDs refrain because of GPL; at least it is v2 not v3,
but still; zstd instead (i think: "then, later") changed to
BSD-style OR GPLv2 saying "You may select, at your option, one of
the above-listed licenses".

While CRC-32 is ok, i guess people (including me) doubt its
viability for long-term archiving, especially when compared with
other algorithms.  It is not so terrible as years ago, since most
people surely have lots of copies, and the filesystems use
checksumming.  But as a standalone archive, CRC-32 fails badly,
for example smhash says "insecure, 8590x collisions, distrib,
PerlinNoise":

  https://github.com/rurban/smhasher/tree/master
  https://github.com/rurban/smhasher/blob/master/doc/crc32.txt
  https://github.com/rurban/smhasher/blob/master/doc/xxHash32.txt

Having said that i am a zstd "fanatic" and jumped on that train
years ago, as soon as i became aware; it is my only boundary point
with Facebook.  It is either very fast, or compresses almost as
good as xz, at least for larger data.  Decompression always very
fast.  Ie if i compile a release ball it is 813KB, lzip is 798KB.
On a small simple text file where gzip -9 delivers ~31KB lzip is
however only 4KB and outperforms zstd by far.
I admire that lzlib is only a tenth of the size of zstd, and is
even an option for static linkage; i switched to lzip from xz for
a few things internally, and for my niche software releases which
provide balls beyond .gz.  (Would love .git repo automatization.)
Thank you!

 --End of <476191712582717@mail.yandex.com>

Ciao from Germany,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]