Comment by karmakaze
3 years ago
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 '.'
He introduced a whole new testing framework then slowly put a backdoor in it over 2 years
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...
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)?
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.
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.
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.
Well, do we know if that commented code you quoted is accurate?
It's the content of TFA, so flag it if you believe it isn't.
Yes that is what I mean -- the commit in TFA is from the bad actor -- so the quoted comment is suspect..
I'm pretty certain the comment isn't accurate, and is just more subterfuge.
... 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.