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
Joerg Jaspert jo...@debian.org writes:
On 14026 March 1977, Vincent Lefevre wrote:
contents that match in size and sum(1). I did it just with an
editor, ddrescue and data from /dev/urandom, by brute force, without
any knowledge about the algorithm of sum. And I did it not once, but
On 14026 March 1977, Vincent Lefevre wrote:
contents that match in size and sum(1). I did it just with an
editor, ddrescue and data from /dev/urandom, by brute force, without
any knowledge about the algorithm of sum. And I did it not once, but
twice.
sum(1) just gives a 16-bit checksum!
On 2015-08-07 15:54:26 +0200, Antonio Diaz Diaz wrote:
I have no experience at all rigging tarballs, but it took me just
minutes to obtain two xz compressed tarballs with very different
contents that match in size and sum(1). I did it just with an
editor, ddrescue and data from /dev/urandom,
On 2015-08-07 21:27:03 +0200, Vincent Lefevre wrote:
On 2015-08-07 15:54:26 +0200, Antonio Diaz Diaz wrote:
I have no experience at all rigging tarballs, but it took me just
minutes to obtain two xz compressed tarballs with very different
contents that match in size and sum(1). I did it
* Philipp Kern pk...@debian.org, 2015-08-06, 21:31:
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
On Sun, Aug 02, 2015 at 10:47:44PM +0200, Vincent Lefevre wrote:
The purpose of adding garbage could be to make a modified tarball
match the signature.
Which is why we also supply the length.
Kind regards
Philipp Kern
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
On Sun, Aug 02, 2015 at 10:47:44PM +0200, Vincent Lefevre wrote:
On 2015-08-02 11:45:38 -0700, Russ Allbery wrote:
There were a few long messages to this thread that I didn't absorb in
their entirety, so apologies if this is a repeat. But another angle of
this is that the discussion is
* Antonio Diaz Diaz anto...@gnu.org, 2015-07-27, 19:11:
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
On 2015-07-29 00:21:54 +0200, Antonio Diaz Diaz wrote:
A compressed file is like an envelope with a message inside. The objective
of the decompressor is to extract the message and deliver it intact to the
user.
The problem is that data could have been appended to a compressed file
(thanks
Vincent Lefevre vinc...@vinc17.net writes:
On 2015-07-29 00:21:54 +0200, Antonio Diaz Diaz wrote:
A compressed file is like an envelope with a message inside. The
objective of the decompressor is to extract the message and deliver it
intact to the user.
The problem is that data could have
On Fri, Jul 31, 2015 at 12:30:12AM +0200, Svante Signell wrote:
Incredible, Debian does no longer adopt to the world of free software
(not opensource) :( I wonder how RMS feels about this?
Regardless of whether the removed quote was correctly representing the
opinion of the Debian project, I
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
On 2015-08-02 11:45:38 -0700, Russ Allbery wrote:
There were a few long messages to this thread that I didn't absorb in
their entirety, so apologies if this is a repeat. But another angle of
this is that the discussion is about using lzip *for Debian packages*. In
that context, being
Hallo,
* Andrew Shadura [Fri, Jul 31 2015, 12:32:15AM]:
On 31 July 2015 at 00:30, Svante Signell svante.sign...@gmail.com wrote:
Incredible, Debian does no longer adopt to the world of free software
(not opensource) :( I wonder how RMS feels about this?
Open source is free software. Free
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.
On Thu, Jul 30, 2015 at 6:28 AM, Antonio Diaz Diaz anto...@gnu.org wrote:
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
On 06/13/2015 10:23 AM, Thomas Goirand wrote:
We use git archive within the PKG OpenStack team to generate this
tarball (which is more or less the same as pristine-tar, except we use
upstream tags rather than a pristine-tar branch). The fact that xz
produces a different result makes it not
On Thu, 2015-07-30 at 11:47 -0700, Steve Langasek wrote:
On Thu, Jul 30, 2015 at 05:48:25PM +0200, Antonio Diaz Diaz wrote:
Aggressive statement? I guess your community should change its own
documentation. I merely copied the description from there:
http://www.debian.org/intro/free
Svante Signell writes (Re: Adding support for LZIP to dpkg, using that instead
of xz, archive wide):
On Thu, 2015-07-30 at 11:47 -0700, Steve Langasek wrote:
http://www.debian.org/intro/free
Truly free software is always free. Software that is placed in the public
domain can be snapped
On Thu, Jul 30, 2015 at 05:48:25PM +0200, Antonio Diaz Diaz wrote:
Russ Allbery wrote:
That doesn't mean your objections are wrong, and I certainly haven't
looked at it in detail. But they don't seem to be widely shared.
It is software, a branch of mathematics, what is being discussed here.
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
On Wed, Jul 29, 2015 at 12:21:54AM +0200, Antonio Diaz Diaz 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
Antonio Diaz Diaz anto...@gnu.org writes:
IMHO, if two options are equally good for the Debian use case but one of
them is better for most of the users, Debian should choose the one that
is better for most of the users. Else, what is the use of the social
contract?
That may be a worthwhile
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.
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
On Mon, Jul 27, 2015 at 07:11:15PM +0200, Antonio Diaz Diaz 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.
BTW, telling a user that
Antonio Diaz Diaz anto...@gnu.org writes:
I am not discussing a concrete use case. I understand that the defects
in xz are usually not a big problem for Debian packages that can be
easily downloaded again in case of corruption.
What I find wrong here is that by using xz in its packaging
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
On Mon, Jul 27, 2015 at 09:20:33PM +0200, Antonio Diaz Diaz 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
On Sun, Jul 26, 2015 at 02:10:10PM +0200, Antonio Diaz Diaz 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
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
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
On 2015-07-26 14:10:10 +0200, Antonio Diaz Diaz wrote:
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
* Thomas Goirand:
As a friend puts it:
This is a fundamental problem/defect with xz. This (and a lot of other
such defects, e.g. non-robustness of xz archives that easily lead to
file corruption etc)
Corruption breaks signatures, making the file unusable, so that's not
really an issue for
On 2015-06-18 02:31:57 + (+), Clint Adams wrote:
No, in this particular case, upstream IS releasing source tarballs
and the packagers are refusing to use them for reasons I find
incomprehensible.
Well, for some of the packages in question where I'm involved
upstream, we still aren't
On Wed, Jun 17, 2015 at 12:58:55AM +0200, Guillem Jover wrote:
From where I'm sitting it all pretty much looks like a self-inflicted
problem. Upstream does not believe in releasing source tarballs (so
each user has to generate them from git-archive, which should be
considered inherently
On 2015-06-15 05:04:46 +0200, Guillem Jover wrote:
On Sun, 2015-06-14 at 16:48:21 +0200, Vincent Lefevre wrote:
(this example is a postfix mail log) and uses much less memory for
compression:
$ sh -c 'ulimit -v 20; lzip -9 mail.log /dev/null'
$ sh -c 'ulimit -v 80; xz -9
On 06/16/2015 04:26 PM, Vincent Lefevre wrote:
And AFAIK, the request is not to drop xz support, just to add lzip
support (though the instead of in the subject could be ambiguous).
Correct. I never thought lzip should replace xz completely, just an
option instead of xz... :)
Thomas
--
To
On Sun, 2015-06-14 at 14:08:24 +0200, Thomas Goirand wrote:
On 06/14/2015 05:46 AM, Guillem Jover wrote:
Well if you want reproducible output, then use the same tool version.
That's not possible: Jessie, Sid and Trusty don't have the same version,
and we need to generate the orig.tar file
On Mon, Jun 15, 2015 at 5:04 PM, Thomas Goirand z...@debian.org wrote:
On 06/14/2015 05:10 PM, Don Armstrong wrote:
On Sun, 14 Jun 2015, Thomas Goirand wrote:
Therefore, I'm tempted to raise this to the technical committee
(putting their list as Cc). Does anyone see a reason why I am
On 06/14/2015 05:10 PM, Don Armstrong wrote:
On Sun, 14 Jun 2015, Thomas Goirand wrote:
Therefore, I'm tempted to raise this to the technical committee
(putting their list as Cc). Does anyone see a reason why I am
mistaking here?
Does a patch exist which can enable lz for orig.tar?
Isn't
On Sun, Jun 14, 2015 at 01:08:29AM +0200, Thomas Goirand wrote:
Therefore, I'm tempted to raise this to the technical committee (putting
their list as Cc). Does anyone see a reason why I am mistaking here?
Well, both bugs are over 5 years old. It would be probably wise to have a
more modern
On Monday, June 15, 2015 6:04:46 AM EEST, Guillem Jover wrote:
So the comparison does not seem entirely fair. And it seems to me to be
a matter of tradeoffs?
Since both lzip and xz are implementations of same LZMA algorithm, it seems
lzip is just parametrized different. For some usecases,
Aron == Aron Xu a...@debian.org writes:
Aron I don't hold a view on whether we want lz support in dpkg/dak,
Aron but it could be a pity if we really involve CTTE for such an
Aron issue. To me, it's sorta abusing the escalation process if
Aron every individual developer raise an
On Mon, 15 Jun 2015 10:07:18 +0200, Thomas Goirand wrote:
On 06/14/2015 04:08 PM, Felipe Sateler wrote:
On Sun, 14 Jun 2015 14:08:24 +0200, Thomas Goirand wrote:
And by the way, xz wouldn't be usable with pristine-tar for the same
reason.
Ehm. pristine-xz(1) would beg to disagree.
In
On Jun 15, Thomas Goirand z...@debian.org wrote:
I'm not at a stage where I want to involve the CTTE right now. I still
would prefer to gather opinions and see where it goes.
My opinion is that you have not proved either that lz is widely used or
that it is better than xz.
--
ciao,
Marco
On 06/15/2015 11:15 AM, Jonathan Dowland wrote:
On Sun, Jun 14, 2015 at 01:08:29AM +0200, Thomas Goirand wrote:
Therefore, I'm tempted to raise this to the technical committee (putting
their list as Cc). Does anyone see a reason why I am mistaking here?
Well, both bugs are over 5 years old.
Thomas Goirand z...@debian.org writes:
Did you try using the same pristine-tar xz thing but with a different
version of xz-utils, for example the one in Trusty vs the one in Sid?
Yup, I do this all the time.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
Fabian Greffrath fab...@debian.org writes:
This is often the case when few enlightened people tell all the
others what they skould prefer by now.
I have found another opinion by a Gentoo dev that might shed some light
on the topic, or maybe not.
Also many GNU projects do not release lzip tarballs, but do release bzip
or xz ones and there are very few that exclusively release lzip tarballs.
If that's the equivalent of bazaar being the official GNU VCS that most
of the GNU projects do not use, well
This is often the case when few
On 06/14/2015 04:08 PM, Felipe Sateler wrote:
On Sun, 14 Jun 2015 14:08:24 +0200, Thomas Goirand wrote:
And by the way, xz wouldn't be usable with pristine-tar for the same
reason.
Ehm. pristine-xz(1) would beg to disagree.
In the multimedia team, we use it for over 40 packages (where
On 06/15/2015 05:04 AM, Guillem Jover wrote:
In addition lzip seems to be
substantially slower (at least) when compressing compared to xz using the
same preset levels.
I understand that some may care about it, but as for me, I couldn't care
less about the time taken for compressing. What I
On 06/15/15 22:03, Fabian Greffrath wrote:
https://blogs.gentoo.org/mgorny/2014/02/22/a-few-words-on-lzip
-compressor/
i remember this has been discussed on the lzip mailinglist/irc when it
popped up and was mainly put down as FUD. a quick search didn't reveal
the debunking reply that was
[ jftr: i'm not involved/related to this thread other than to comment on
a few things since i'm using lzip since a while and happen to maintain
it in debian; also, i have no interest in any CTTE involvement at all
and trust the dpkg maintainers to add lzip eventually when they think
it's right to
Guillem,
First, thanks for your reply and taking the time to reply on every
point. This really is helpful.
While I believe all of your argumentation is correct, I am still not
convince about the reproducibility, which is my main issue here. Could
you please reply to that point, and that one
On Sun, 14 Jun 2015 14:08:24 +0200, Thomas Goirand wrote:
And by the way, xz wouldn't be usable with pristine-tar for the same
reason.
Ehm. pristine-xz(1) would beg to disagree.
In the multimedia team, we use it for over 40 packages (where upstream
provides an xz file of course).
I guess
I'm currently using xz for my own files, but...
On 2015-06-14 05:46:00 +0200, Guillem Jover wrote:
On Sun, 2015-06-14 at 01:08:29 +0200, Thomas Goirand wrote:
On 06/13/2015 10:55 AM, Paul Wise wrote:
On Sat, Jun 13, 2015 at 4:23 PM, Thomas Goirand wrote:
As a friend puts it:
This
On Sun, 14 Jun 2015, Thomas Goirand wrote:
Therefore, I'm tempted to raise this to the technical committee
(putting their list as Cc). Does anyone see a reason why I am
mistaking here?
Does a patch exist which can enable lz for orig.tar?
Otherwise, I guess some of us could be involved to
Hi!
On Sun, 2015-06-14 at 16:48:21 +0200, Vincent Lefevre wrote:
On 2015-06-14 05:46:00 +0200, Guillem Jover wrote:
On Sun, 2015-06-14 at 01:08:29 +0200, Thomas Goirand wrote:
On 06/13/2015 10:55 AM, Paul Wise wrote:
On Sat, Jun 13, 2015 at 4:23 PM, Thomas Goirand wrote:
As a friend
On 06/13/2015 10:55 AM, Paul Wise wrote:
On Sat, Jun 13, 2015 at 4:23 PM, Thomas Goirand wrote:
I've been using xz compression for a long time, but I see a big defect
which is today pushing me to turn it off for the .orig.tar file. The
issue is that depending on the version of xz-utils, it
On Sun, Jun 14, 2015 at 7:08 AM, Thomas Goirand wrote:
Reading these bugs, am I right that the archive already supports lzip
for the orig.tar file?
AFAICT, there is no mention of .lz or lzip in the dak source code.
--
bye,
pabs
https://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to
Hi,
On Sun, 2015-06-14 at 01:08:29 +0200, Thomas Goirand wrote:
On 06/13/2015 10:55 AM, Paul Wise wrote:
On Sat, Jun 13, 2015 at 4:23 PM, Thomas Goirand wrote:
I've been using xz compression for a long time, but I see a big defect
which is today pushing me to turn it off for the .orig.tar
Dear friends,
I've been using xz compression for a long time, but I see a big defect
which is today pushing me to turn it off for the .orig.tar file. The
issue is that depending on the version of xz-utils, it produces a
different output.
We use git archive within the PKG OpenStack team to
On Sat, Jun 13, 2015 at 4:23 PM, Thomas Goirand wrote:
Is there any reason why we wouldn't do that?
It was already rejected by the dpkg maintainers twice.
https://bugs.debian.org/600094
https://bugs.debian.org/556960
--
bye,
pabs
https://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email
65 matches
Mail list logo
