5 ms·

That is just technical disagreements and sour grapes by someone involved in a competing format (Lzip). There’s no evidence Lasse did anything “wrong” beyond lo

That is just technical disagreements and sour grapes by someone involved in a competing format (Lzip). There’s no evidence Lasse did anything “wrong” beyond looking for / accepting co-maintainers, something package authors are taken to task for not doing every time they have life catching up or get fed up and can’t / won’t spend as much time on the thing.

jnxx 3y ago
[flagged]
- matsemann 3y ago
  > But is this appropiate here? Yes, nothing points to the inventor of the format and maintainer for decades has done anything with the format to make it suspect. If so, the recent backdoor wouldn't be needed. It's good to be skeptic, but don't drag people through the mud without anything to back it up.
  - jnxx 3y ago
    If a project targets a high-profile, very security sensitive project like the linux kernel from the start, as the archived tukaani web site linked above shows, it is justified to ask questions. Also, the exploit shows a high effort, and a high level of competence, and a very obvious willingness to play a long game. These are not circumstances for applying Hanlon's razor.
    - matsemann 3y ago
      Are you raising the same concerns and targeting individuals behind all other sensitive projects? No, because that would be insane. It's weird to have one set of standards to a maintainer since 2009 or so, and different standards for others. This witch hunt is just post-hoc smartassery.
      - jnxx 3y ago
        Yes, I think if a project has backdoors and its old maintainers are unable to review them, I am more critical than with normal projects. As said, compression is used everywhere and in embedded systems, it touches a lot of critical stuff. And the project went straight for that since the beginning. And this is in part because I can not even tell for sure that he even exists. If I had met him a few times in a bar, I would be more inclined to believe he is not involved.
        saagarjha 3y ago
        > As said, compression is used everywhere and in embedded systems, it touches a lot of critical stuff. And the project went straight for that since the beginning. Uh, because it's a compression library?
        ljahier 3y ago
        From the project readme: > XZ Utils provide a general-purpose data-compression library plus 21 command-line tools. https://git.tukaani.org/?p=xz.git;a=blob;f=README;h=ac812ff150ca12bece1c266c5f4efe8e860be752;hb=HEAD https://git.tukaani.org/?p=xz.git;a=blob;f=README;h=ac812ff1...
        UncleEntity 3y ago
        I'm inclined to believe that whatever state actor was involved sent a memo to their sockpuppets to do whatever they can to deflect blame away. See what I did there?
  - xghryro 3y ago
    [flagged]
- masklinn 3y ago
  > You appeal to trust people and give them the benefit of doubt which is normally a good thing. But is this appropiate here? Yes. Without evidence to the contrary there is no reason to believe Lasse has been anything other than genuine so all you're doing is insulting and slandering them out of personal satisfaction. And conspiratorial witch hunts are actively counter-productive, through that mode of thinking it doesn't take much imagination to figure out you are part of the conspiracy for instance.
  - w4ffl35 3y ago
    [flagged]
    - w4ffl35 3y ago
      [flagged]
      - w4ffl35 3y ago
        [flagged]
        rmast 3y ago
        Recall that the original maintainer had mental health issues and other things that likely led to the perceived need to bring on someone to help maintain xz. This brings up some integrity questions about you and other people bringing forth accusations in order to make the original maintainer feel pressure to bring on someone else to replace the one that inserted a backdoor after several years of ostensibly legitimate commits. Hopefully this helps you see that these sorts of accusations are a slippery slope and unproductive. Heck, you could then turnaround and accuse me of doing something nefarious by accusing you.
        thinkingemote 3y ago
        It's possible that he was intentionally pressured and his mental health made bad or worse by the adversary to increase stress. The adversary would then propose to help them reduce the stress. It's probably straight out of many playbooks.
voidz 3y ago
It argues the topic pretty well: xz is unsuitable for long-term archival. The arguments are in-depth and well worded. Do you have any argument to the contrary beyond "sour grapes"?
- matsemann 3y ago
  It's not relevant to the current issue at hand.
  - showdeadplease 3y ago
    [dead]
  - evrial 3y ago
    If you say "sour grapes", then back down your bold statement or don't say at all.
    - masklinn 3y ago
      What are you talking about? Do you understand multiple people use this site? Also do you mean back up? Antonio literally used to go around mailing lists asking for lzip support and complaining about xz: - https://gcc.gnu.org/legacy-ml/gcc/2017-06/msg00044.html https://gcc.gnu.org/legacy-ml/gcc/2017-06/msg00044.html - https://lists.debian.org/debian-devel/2017/06/msg00433.html https://lists.debian.org/debian-devel/2017/06/msg00433.html Also, https://web.archive.org/web/20190605225651/http://octave.1599824.n4.nabble.com/opinion-bring-back-Octave-xz-source-release-td4683705.html https://web.archive.org/web/20190605225651/http://octave.159... I can understand wanting your project to succeed, it's pretty natural and human, but it's flagrant Antonio had a lot of feels about the uptake of xz compared to lzip, as both are container formats around raw lzma data streams and lzip predates xz by 6 months. His complaint article about xz is literally one of the "Introductory links" of lzip.
- account42 3y ago
  > xz is unsuitable for long-term archival Neither is lzip since it doesn't contain error correction codes. You can add those with an additional file (to any archive) e.g. via par2 but then most of the points in the linked rant become irrelevant.
goodpoint 3y ago
> That is just technical disagreements and sour grapes Care to provide some evidence to back this statement?

jnxx 3y ago

[flagged]

matsemann 3y ago
> But is this appropiate here? Yes, nothing points to the inventor of the format and maintainer for decades has done anything with the format to make it suspect. If so, the recent backdoor wouldn't be needed. It's good to be skeptic, but don't drag people through the mud without anything to back it up.
- jnxx 3y ago
  If a project targets a high-profile, very security sensitive project like the linux kernel from the start, as the archived tukaani web site linked above shows, it is justified to ask questions. Also, the exploit shows a high effort, and a high level of competence, and a very obvious willingness to play a long game. These are not circumstances for applying Hanlon's razor.
  - matsemann 3y ago
    Are you raising the same concerns and targeting individuals behind all other sensitive projects? No, because that would be insane. It's weird to have one set of standards to a maintainer since 2009 or so, and different standards for others. This witch hunt is just post-hoc smartassery.
    - jnxx 3y ago
      Yes, I think if a project has backdoors and its old maintainers are unable to review them, I am more critical than with normal projects. As said, compression is used everywhere and in embedded systems, it touches a lot of critical stuff. And the project went straight for that since the beginning. And this is in part because I can not even tell for sure that he even exists. If I had met him a few times in a bar, I would be more inclined to believe he is not involved.
      - saagarjha 3y ago
        > As said, compression is used everywhere and in embedded systems, it touches a lot of critical stuff. And the project went straight for that since the beginning. Uh, because it's a compression library?
        ljahier 3y ago
        From the project readme: > XZ Utils provide a general-purpose data-compression library plus 21 command-line tools. https://git.tukaani.org/?p=xz.git;a=blob;f=README;h=ac812ff150ca12bece1c266c5f4efe8e860be752;hb=HEAD https://git.tukaani.org/?p=xz.git;a=blob;f=README;h=ac812ff1...
      - UncleEntity 3y ago
        I'm inclined to believe that whatever state actor was involved sent a memo to their sockpuppets to do whatever they can to deflect blame away. See what I did there?
- xghryro 3y ago
  [flagged]
masklinn 3y ago
> You appeal to trust people and give them the benefit of doubt which is normally a good thing. But is this appropiate here? Yes. Without evidence to the contrary there is no reason to believe Lasse has been anything other than genuine so all you're doing is insulting and slandering them out of personal satisfaction. And conspiratorial witch hunts are actively counter-productive, through that mode of thinking it doesn't take much imagination to figure out you are part of the conspiracy for instance.
- w4ffl35 3y ago
  [flagged]
  - w4ffl35 3y ago
    [flagged]
    - w4ffl35 3y ago
      [flagged]
      - rmast 3y ago
        Recall that the original maintainer had mental health issues and other things that likely led to the perceived need to bring on someone to help maintain xz. This brings up some integrity questions about you and other people bringing forth accusations in order to make the original maintainer feel pressure to bring on someone else to replace the one that inserted a backdoor after several years of ostensibly legitimate commits. Hopefully this helps you see that these sorts of accusations are a slippery slope and unproductive. Heck, you could then turnaround and accuse me of doing something nefarious by accusing you.
        thinkingemote 3y ago
        It's possible that he was intentionally pressured and his mental health made bad or worse by the adversary to increase stress. The adversary would then propose to help them reduce the stress. It's probably straight out of many playbooks.

voidz 3y ago

It argues the topic pretty well: xz is unsuitable for long-term archival. The arguments are in-depth and well worded. Do you have any argument to the contrary beyond "sour grapes"?

matsemann 3y ago
It's not relevant to the current issue at hand.
- showdeadplease 3y ago
  [dead]
- evrial 3y ago
  If you say "sour grapes", then back down your bold statement or don't say at all.
  - masklinn 3y ago
    What are you talking about? Do you understand multiple people use this site? Also do you mean back up? Antonio literally used to go around mailing lists asking for lzip support and complaining about xz: - https://gcc.gnu.org/legacy-ml/gcc/2017-06/msg00044.html https://gcc.gnu.org/legacy-ml/gcc/2017-06/msg00044.html - https://lists.debian.org/debian-devel/2017/06/msg00433.html https://lists.debian.org/debian-devel/2017/06/msg00433.html Also, https://web.archive.org/web/20190605225651/http://octave.1599824.n4.nabble.com/opinion-bring-back-Octave-xz-source-release-td4683705.html https://web.archive.org/web/20190605225651/http://octave.159... I can understand wanting your project to succeed, it's pretty natural and human, but it's flagrant Antonio had a lot of feels about the uptake of xz compared to lzip, as both are container formats around raw lzma data streams and lzip predates xz by 6 months. His complaint article about xz is literally one of the "Introductory links" of lzip.
account42 3y ago
> xz is unsuitable for long-term archival Neither is lzip since it doesn't contain error correction codes. You can add those with an additional file (to any archive) e.g. via par2 but then most of the points in the linked rant become irrelevant.

goodpoint 3y ago

> That is just technical disagreements and sour grapes Care to provide some evidence to back this statement?