This may be naive, but it seems to me that a failed compile should generate an error worth worrying about.
Xz: Can you spot the single character that disabled Linux landlock?
281–290 of 322 posts
Re: Xz: Can you spot the single character that disabled Linux landlock?
#282Earlier 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
Re: Xz: Can you spot the single character that disabled Linux landlock?
#283Re: Xz: Can you spot the single character that disabled Linux landlock?
#284Earlier 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.
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?
#285Earlier 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?
Re: Xz: Can you spot the single character that disabled Linux landlock?
#286Earlier 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
Re: Xz: Can you spot the single character that disabled Linux landlock?
#287Earlier 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.
Re: Xz: Can you spot the single character that disabled Linux landlock?
#288Earlier 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…
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?
#289Earlier 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'.
How?
Re: Xz: Can you spot the single character that disabled Linux landlock?
#290Earlier 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
Tabs still have syntactical meaning and are still invisible
Python will never be a success, I predict, because of this
Trust me