Live data from Hacker News

Xz: Can you spot the single character that disabled Linux landlock?

git.tukaani.org

281–290 of 322 posts

Re: Xz: Can you spot the single character that disabled Linux landlock?

#281

This may be naive, but it seems to me that a failed compile should generate an error worth worrying about.

It's in an autoconf style compile test. The compile or not of the snippet is being tested, unfortunately. This just decides the configuration, doesn't stop the build.

Re: Xz: Can you spot the single character that disabled Linux landlock?

#282

Earlier quoted context omitted.

I mean, some CI system should be checking that "if_code_compiles()" blocks compile somewhere. It should be an error until the CI system has that header and can test both variants. People are really quick to add optionality like this without understanding the maintenance cost. (Every boolean feature flag increases the number of variants you need to test by 2!) Either make a decision, or check that both sides work. Don…

multiplies it by 2, not increases

yup, meant to say "a factor of 2".

Re: Xz: Can you spot the single character that disabled Linux landlock?

#283
post #241

Earlier quoted context omitted.

Autocomf output is so incredibly noisy though, still long odds someone would notice anytime soon.

If you break the build they’ll notice

Good thing they disabled the check that would have broken the build/tests in this case eh?

Re: Xz: Can you spot the single character that disabled Linux landlock?

#284

Earlier quoted context omitted.

Yep. It was a few years ago while that was stilled allowed (as I'd noted ;) ) but regardless. Significant whitespace is just annoying.. There's a lot of things that render as whitespace, and source code one might be reviewing could be printed wrapped or copied and pasted in odd ways. Other languages are more robust to this.

> There's a lot of things that render as whitespace Like what? As you note, mixing tabs and spaces is now an error. I've never understood the objection to semantic whitespace. Complaining about having to indent code correctly strikes me as being akin to complaining about having to pee in the toilet instead of the bathtub.

there is a huge difference between having a coding standard (handled easily by a linter on commit in most languages) and making a particular whitespace indentation a critical language feature.

Bonus, if there's a good reason to change the linter format, you can do so. Rust handles this rather well I think.

Re: Xz: Can you spot the single character that disabled Linux landlock?

#285
post #232

Earlier quoted context omitted.

Now we are running in circles. As you see in the git commit, the compile check was added because the existance of linux/landlock.h alone was not enough to check that the feature can be used. This header defines the data types for the Linux kernel interface, but not how the syscall landlock_create_ruleset(2) will be issued. That is provided by libc either as a separate wrapper function (does not exist in glibc) or the…

The only source of the claim that the existence of.linux/landlock.h is insufficient is (AFAICT) the malicious git commit. Why trust the comment, written by the attacker, to explain away a malicious change?

I already explained above why the existence of linux/landlock.h is not sufficient. Why do you still question it? If you know a bit about system programming and how configure checks work, the change in itself is totally reasonable.

Re: Xz: Can you spot the single character that disabled Linux landlock?

#286
post #7

Earlier quoted context omitted.

So that function checked if the following C code compiled, and only in that situation enabled the landlock? Except that lone period, hard to recognize because of its small size and proximity to the left edge of the diff, caused the C code to become always invalid, hence keeping the landlock always disabled? That's both vilely impressive and impressively vile. I didn't even spot it on my first read-through.

It's also iffy tbh. that the compilation check functionality: - doesn't force users to differentiate between syntax errors and other errors (e.g. symbols not found). Partially you can't even make it work properly if you want due to C macros. - it seems sensible, tbh. if "does compile" checks for compatibility seems sensible then there is so much wrong with the ecosystem in so many ways

Agreed. I just opened https://gitlab.kitware.com/cmake/cmake/-/issues/25846 although I have no idea how hard it is to address this sort of issue robustly.

Re: Xz: Can you spot the single character that disabled Linux landlock?

#287
post #163
post #91

Earlier quoted context omitted.

Which non-printing characters are you talking about? Whitespace characters are very much printable. Yes, I agree that Python should just forbid tabs. As a second best, you can tell your linter (and/or formatter) to forbid tabs (and any weird unicode whitespace). That's basically the equivalent of compiling your C with -Wall.

This was an issue in Python 2, where for some dumb reason it allowed mixing tabs and spaces and equated tab to 8 spaces (I think). Python 3 doesn't have that issue.

Of course, if one was coding an exploit, one could still use python2. It is still commonly available due to a long tail of legacy scripts and in some cases (like a script I use routinely but didn't write) the difficulty of porting it to python3 (I've asked over a dozen pythonistas over the years, they kept running into same problems)

Re: Xz: Can you spot the single character that disabled Linux landlock?

#288
post #67

Earlier quoted context omitted.

I don’t know. In my code I’d always compile and check at runtime?

Some of the checks are there to tell whether or not the compiler even supports your code. You may not be able to compile your code at all, and the job of the build system is sometimes to just emit useful errors to help the person building the code to understand that they need a compiler which supports [language feature X]. Again, this is intended to be portable software. It is designed to work on lots of OS’s, with l…

> If you have a security feature for example, which uses the pledge() syscall on OpenBSD, but you can only use that feature on OpenBSD systems, you have two choices:

Just in case, I want to note that pledge(2) and unveil(2) are also supported by SerenityOS, so checking only for an OpenBSD target is insufficent.

https://awesomekling.github.io/pledge-and-unveil-in-Serenity...

Pledge and unveil in SerenityOS, combined with the planned move to memory safety, will be a powerful combination.

Re: Xz: Can you spot the single character that disabled Linux landlock?

#289
post #186

Earlier quoted context omitted.

The point still stands that this is an inherit possibility in the language it self.

Well, in C the visual indentation and the meaning of the code (given by {}) can diverge. That's even worse, and happens in practice. Many style guidelines for C have evolved specifically to address that problem with 'the language itself'.

> Well, in C the visual indentation and the meaning of the code (given by {}) can diverge.

How?

Re: Xz: Can you spot the single character that disabled Linux landlock?

#290

Earlier quoted context omitted.

Yeah, if anything, python worsens the situation. I had a friend DOS our server because he accidentally inserted a tab, causing the illusion that one statement was inside a block but was actually outside it. He swore off python at that point. I personally avoid the language, but I understand due to issues like that these days mixing tabs and spaces is an error (or is it just a warning?) by default. Regardless, still p…

Yes mixing tabs and spaces is a big no no and rightfully throws an error now

Not an improvement

Tabs still have syntactical meaning and are still invisible

Python will never be a success, I predict, because of this

Trust me

Post reply on HN