10 ms·

If this is a conspiracy or a state-sponsored attack, they might have gone specifically for embedded devices and the linux kernel. Here archived from tukaani.org

• jnxx 3y ago
  [flagged]
  • masklinn 3y ago
    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...
      • 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?
  • shzhdbi09gv8ioi 3y ago
    This link is opinion piece about the file format and has nothing to do with today's news. Also, Lasse has not been accused of any wrong-doings.
    • jnxx 3y ago
      [flagged]
      • shzhdbi09gv8ioi 3y ago
        No. I mean that the link you shared is a opinion piece about the xz file format, and those opinions are fully unrelated to today's news and only serve to further discredit Lasse Collin who for all we know have been duped and tricked by a nation state, banned by github and is having a generally shitty time. Why are you trying to discredit Lasse?
        • jnxx 3y ago
          That critique adresses security aspects.
          • shzhdbi09gv8ioi 3y ago
            You seem to be rather determined in continuing to badmouth Lasse, ignoring me and others questioning your motives. Here are recent examples: 1. https://news.ycombinator.com/item?id=39872919 https://news.ycombinator.com/item?id=39872919 2. https://news.ycombinator.com/item?id=39873552 https://news.ycombinator.com/item?id=39873552 3. https://news.ycombinator.com/item?id=39873133 https://news.ycombinator.com/item?id=39873133 4. https://news.ycombinator.com/item?id=39872770 https://news.ycombinator.com/item?id=39872770
            • showdeadplease 3y ago
              [dead]
          • 3y ago
• jnxx 3y ago
  One scenario for malicious code in embedded devices would be a kind of killswitch which listens to a specific byte sequence and crashes when encountering it. For a state actor, having such an exploit would be gold.
  • HankB99 3y ago
    That's an "interesting" thought. One of my complaints about so many SciFi stories is the use of seemingly conventional weapons. I always thought that with so much advanced technology that weapons would be much more sophisticated. However if the next "great war" is won not by the side with the most destructive weapons but by the side with the best kill switch, subsequent conflicts might be fought with weapons that did not rely on any kind of computer assistance. This is eerily similar to Einstein's (purported) statement that if World War III was fought with nuclear weapons, World War IV would be fought with sticks and stones. Similar, but for entirely different reasons. I'm trying to understand why the characters in Dune fought with swords, pikes and knives.
    • ethbr1 3y ago
      > I'm trying to understand why the characters in Dune fought with swords, pikes and knives. Because the slow blade penetrates the shield. (And personal shields are omnipresent)
      • darkelder 3y ago
        [dead]
    • cblum 3y ago
      > I'm trying to understand why the characters in Dune fought with swords, pikes and knives. At least part of the reason is that the interaction between a lasgun and a shield would cause a powerful explosion that would kill the shooter too. No one wants that and no one will give up their shield, so they had to go back to melee weapons.
      • 3y ago
• varjag 3y ago
  All this circus makes me happy for never moving from sysvinit on embedded.
  • jnxx 3y ago
    It is not just systemd which uses xz. For example, Debian's dpkg links xz-utils.
    • ahartmetz 3y ago
      However, this particular attack only works through libsystemd to compromise sshd and it is related to systemd's kitchen sink "design".
      • JdeBP 3y ago
        It's related to excessive coupling between modules and low coherence. There is a way for programs to implement the systemd readiness notification protocol without using libsystemd, and thus without pulling in liblzma, which is coupled to libsystemd even though the readiness notification protocol does not require any form of compression. libsystemd provides a wide range of things which have only weak relationships to each other. There are in fact two ways, as two people independently wrote their own client code for the systemd readiness notification protocol, which really does not require the whole of libsystemd and its dependencies to achieve. (It might be more than 2 people nowadays.) * https://jdebp.uk/FGA/unix-daemon-readiness-protocol-problems.html#CrippledAdoption https://jdebp.uk/FGA/unix-daemon-readiness-protocol-problems...
      • Matl 3y ago
        It's easy to have your existing biases validated if you already dislike systemd. The reality is that systemd is much more coherently designed than its predecessors from a 'end user interface' point of view, hence why its units are largely portable etc. which was not the case for sysvinit. The reality is that it is not systemd specifically but our modern approach to software design where we tend to rely on too much third party code and delight in designing extremely flexible, yet ultimately extremely complex pieces of software. I mean this is even true as far as the various CPU attack vectors have shown in recent years, that yes speculative execution is a neat and 'clever' optimization and that we rely on it for speed, but that maybe that was just too clever a path to go down and we should've stuck with simpler designs that would maybe led to slower speedups but a more solid foundation to build future CPU generations on.