News for hackers. Stuff that matters.
Re:Xz: Can you spot the single character that disabled Linux... by karmakaze on Saturday March 30, 2024 @10:49AM (#39875417)
I can't believe that system security is dependent on such a loose chain of correctness. Any number of things could have stopped this.

  +   # A compile check is done here because some systems have
  +   # linux/landlock.h, but do not have the syscalls defined
  +   # in order to actually use Linux Landlock.
Fix those headers on those systems to explicitly opt-out. What's the point of headers if they don't declare their capabilities?

Also why isn't there a single test after a binary blob (even when compiled from open source) is made to ensure security is in-tact?

I wouldn't even ship a website checkout without end-to-end tests for core capabilities. There must be a priority misalignment of adding features > stability.

Edit: I hope the 'fix' isn't to remove the '.'--I just saw the other post on HN that shows removing the '.'

Re:Xz: Can you spot the single character that disabled Linux... by kardos on Saturday March 30, 2024 @12:35PM (#39876339)
Well, do we know if that commented code you quoted is accurate?
Re:Xz: Can you spot the single character that disabled Linux... by karmakaze on Saturday March 30, 2024 @03:07PM (#39877657)
It's the content of TFA, so flag it if you believe it isn't.
Re:Xz: Can you spot the single character that disabled Linux... by kardos on Saturday March 30, 2024 @04:33PM (#39878362)
Yes that is what I mean -- the commit in TFA is from the bad actor -- so the quoted comment is suspect..
Re:Xz: Can you spot the single character that disabled Linux... by pas on Saturday March 30, 2024 @08:33PM (#39880145)
... there's a huge bias in things that get tested (and how they get tested). easy to test things get tested. there's a lot more developer, committer, maintainer for web stuff. there's a cultural issue, it's hard to improve on old ossified processes/projects, etc.
Re:Xz: Can you spot the single character that disabled Linux... by Hnrobert42 on Saturday March 30, 2024 @08:33PM (#39880147)
As a user of open source who doesn’t know enough to make those suggestions, I would be grateful if you would develop and contribute them.
Re:Xz: Can you spot the single character that disabled Linux... by missblit on Saturday March 30, 2024 @09:17PM (#39880436)
You are quoting Jia Tan [1]. The malicious actor wrote that comment when deliberately breaking the check in the first place.

Fixing headers or extra tests would not have prevented this, as there is no indication the headers were broken in the first place, and extra tests could have been compromised (or ignored for release tarball) some other way.

[1] https://git.tukaani.org/?p=xz.git;a=commit;h=328c52da8a2bbb8...

Re:Xz: Can you spot the single character that disabled Linux... by manwe150 on Sunday March 31, 2024 @12:11AM (#39881360)
Should the better fix then to have been to revert the bad commit with the malicious commit message, rather than just deleting the dot (as was done)?
Re:Xz: Can you spot the single character that disabled Linux... by humanrebar on Sunday March 31, 2024 @08:29AM (#39883655)
The better fix would be to move to proper dependency management and depend on a version range of a dependency instead of hoping you can do a better job of modelling the same with strings hardcoded into a CMakeLists.txt.
Re:Xz: Can you spot the single character that disabled Linux... by Randalthorro on Saturday March 30, 2024 @10:37PM (#39880845)
He introduced a whole new testing framework then slowly put a backdoor in it over 2 years
Re:Xz: Can you spot the single character that disabled Linux... by deathanatos on Saturday March 30, 2024 @11:54PM (#39881259)
I'm pretty certain the comment isn't accurate, and is just more subterfuge.
Re:Xz: Can you spot the single character that disabled Linux... by RaisingSpear on Sunday March 31, 2024 @06:49AM (#39883102)
Tangentially related, but I've had a case where GCC 9.4.0 shipped a broken arm_acle.h header [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100985] - code which includes the header would always fail to compile.

Since users could be trying to compile it on GCC 9.4.0, and as the functionality dependent on the header isn't critical to the application, if the build detects the header is broken, it just disables the functionality and emits a warning.

Back to xz: If security isn't your top priority, it seems reasonable to just ignore the failure of an optional feature and just move along. Of course, in hindsight, it's easy to point fingers, but without that, it doesn't sound completely unreasonable to me.