Jakub Wilk wrote:
The purpose of adding garbage could be to make a modified tarball
match the signature.
Which is why we also supply the length.
I thought the idea was to create a smaller malicious tarball, then
append "garbage" until the size and the hash match.
With xz you don't need trai
Jakub Wilk wrote:
"Lzip will correctly decompress a file which is the concatenation
of two or more compressed files. The result is the concatenation of
the corresponding uncompressed files. Integrity testing of
concatenated compressed files is also supported."
Whatever follows a file that is not
Steve Langasek wrote:
No. Computer science is mathematics. Algorithms are mathematics. Software
is something else. You cannot "prove" that a customer's priorities are
wrong.
Debian is not the customer, but the developer. It is compelled by its
social contract to provide high-quality materi
Nicholas Breen wrote:
If there is just the excrement of a fly adhered to a corner of the
envelope (a null byte appended to an otherwise intact file, for
example), xz will report that the data is corrupt and will not
deliver the message. This test is inescapable.
^^
Thanks for the detailed explanations.
Russ Allbery wrote:
Inversely, by not accepting .lz source tarballs Debian is sending the
message that lzip is not a good format to use,
While it's possible that people may decide to read such messages into our
decisions, that's not really something we hav
Vincent Lefevre wrote:
the xz format is objectively more fragile than the other three.
I completely disagree. IMHO, a decompressor should be very strict and
detect any suspicious modification.
Agreed, but I'll try to make it clear how much the "strictness" of the
xz format is brain damaged.
Andrey Rahmatullin wrote:
I guess we are thinking about different use cases here: verifying a package
that can be easily downloaded again in case of corruption, vs decompressing
the only copy of an irreplaceable file.
Indeed.
So you agree that xz is a bad format but you don't mind because it d
Vincent Lefevre wrote:
the xz format is objectively more fragile than the other three.
I completely disagree. IMHO, a decompressor should be very strict and
detect any suspicious modification.
(In the following response I'll assume that by "modification" you mean
"corruption" (accidental mod
Dear Andrew,
Andrew Shadura wrote:
Why haven't you just fixed dd_rescue instead of creating one more tool?
I wrote ddrescue instead of fixing dd_rescue because the algorithm of
ddrescue is orders of magnitude more complex than the simple linear read
performed by dd_rescue. Treating failing d
Hello Guillem,
Guillem Jover wrote:
TBH this smells like FUD. For example I've never heard of corruption in
.xz files due to non-robustness, I'd expect that corruption to come from
external forces, and that integrity would help or not detect it.
Sure it comes from external forces, but xz does
Hello Mika et all,
Michael Prokop wrote:
I'm the maintainer of the ddrescue and gddrescue packages.
I plan to drop the ddrescue package.
IMHO dropping the gddrescue package and moving GNU ddrescue to the
ddrescue package (replacing dd_rescue) is the least confusing solution
for the users in
I don't think we should be adding more programs to the archive that
can't handle multibyte encodings. I believe the default character
encoding for new installations is UTF-8.
GNU Moe is a console text editor written to be stable, compact and
powerful. It is the middle point between GNU Ed and
12 matches
Mail list logo
