Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

git.tukaani.org

Post reply on HN
Print view View original

271–280 of 322 posts

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

#271

Post by eacapeisfutuile »

surajrmal wrote: post #261
deckard1 wrote: post #154

Earlier quoted context omitted.

you can have ten comments about the name of a variable, but no one bats an eye at a new npm package introduced. Also, devs that wrote code that Google depends on can't pass the leetcode gate check to get a job there. Our industry is a laughingstock.

I'm not sure about your experience, but companies which have strong code review practices also have strong controls on the third party code. In terms of review granularity, it makes more sense to be critical of maintenance/readability for code you actually own and maintain. Third party code has a lower bar and should, although I also believe it needs to be reviewed

Yeah I think this is the common case. I think we usually trust that dependency A took a look at their dependency B and C before releasing a new version of A. And even if properly reviewing our bump of A, how often do we check out changes in B and C

Edit: yes for FAANG-ish companies this is usually a bit different, for this reason. And licenses..

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

#272

Post by josefx »

acdha wrote: post #231
josefx wrote: post #195

Earlier quoted context omitted.

You could just run tests for the feature detection on a known system or a dozen(VMs are cheap). The big problem is that most code is not tested at all or test errors are flat out ignored.

Nothing “just” about it. VMs weren’t cheap when the C world started using autoconf - that was a feature mostly known on IBM mainframes – and in any case that couldn’t do what you need. The goal is not to figure out what’s there on systems _you_ control, it’s to figure out what is actually available on the systems other users are building on. Think about just this library, for example, your dozen VMs wouldn’t even be…

The goal is to figure out if the optional features work at all. For that a system you control is required.

That the sabotage worked at all relied on the fact that nobody was testing those features.

How secure is a sandbox that may not even exist? Apparently its good enough for most.

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

#273

Post by estebank »

rmast wrote: post #252
humanrebar wrote: post #225

Earlier quoted context omitted.

I'd prefer if the ecosystem standardized on some dependency management primitives so critical projects aren't expected to invent buggy and insecure hacks ("does this strong parse?") in order to accurately add dependencies.

It would be interesting to see what the most common compile feature checks are for, and see what alternative ways could be used to make the same information available to a build system — it seems like any solution that requires libraries being updated to “export” information on the features they provide would have difficulties getting adoption (and not be backwards compatible with older versions of desired dependenci…

From my experience looking at rust builds, Pareto applies here: most checks are trivial and used by a lot, and a handful are super complex and niche.

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

#274

Post by estebank »

rmast wrote: post #256
masklinn wrote: post #175

Earlier quoted context omitted.

> if they fail for something like a syntax error, flag it as a broken check. A syntax error might be exactly what they’re looking for e.g. they’re feature testing a new bit of syntax or a compiler extension. > so perhaps filtering based on the type of error would be best done as part of the build system functionality for doing the feature checking. Which would require every compiler to have detailed, consistent, and…

At least for newer C++ standards it seems like there is decent support for feature test macros, which could reduce the need for a feature check involving compiling a snippet of test code to decide if a feature is available: https://en.cppreference.com/w/cpp/feature_test Handling the output from several of the most recent GCC and Clang versions would probably cover the majority of cases, and add in MSVC for Windows. I…

That would only work for projects that care only about current compilers, where C in general has more desire to support niche compilers.

A mitigation here would be to make result of autoconf only provide instructions for humans to change their build config, instead of doing it for them silently. The latter is an anti-pattern.

FWIW, the approach you propose is how the UI tests for rustc work, with checks for specific annotations on specific lines, but those have the benefit of being tied to a single implementation/version and modified in tandem with the app. Unless all compilers could be made to provide reasonable machine readable output for errors, doing that for this use case isn't workable.

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

#275

Post by asveikau »

asveikau wrote: post #253
londons_explore wrote: post #168

Earlier quoted context omitted.

The fact GitHub suspended his account too suggests that they might have info saying he is involved.

I think it was somewhat irresponsible to block everything. It hampers instigation of the repo's history. It's good that Lasse had another mirror.

Woops, too late to edit this comment and say *investigation

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

#276

Post by Terr_ »

pajko wrote: post #210
SV_BubbleTime wrote: post #131

Earlier quoted context omitted.

Is there a GCC option to error on non-standard English characters?

Probably the code review tools should be hardened as well, to indicate if extended identifiers had been introduced to a line where there wasn't any. That would help catching the replacement of a 'c' character with a Russian one. Btw, the -fno-extended-identifiers compiler parameter gives an error if UTF-8 identifiers are used in the code: :3:11: error: stray '\317' in program float = 0.5f;

> Probably the code review tools should be hardened as well, to indicate if extended identifiers had been introduced to a line where there wasn't any.

Maybe in the future more languages/ tools will have the concept of per-project character sets, as opposed to trying to wrangle all possible Unicode ambiguity problems.

I suppose then the problem is how to permit exceptions when integrating with some library written in another (human) language.

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

#278

Post by Jevon23 »

peteradio wrote: post #235
throwaway2037 wrote: post #207

Earlier quoted context omitted.

The last sentence is an overreach to me, but I have experienced much of the same bike-shedding during code reviews. 95% of them are useless. Read that twice; I am not joking, sadly. I am not against code reviews, but in my experience(!), the reviewers are not incentivized to do a thorough job. Seriously, if you deliver a new feature vs do a deep, difficult code reviews, which one benefits you more? To repeat: I don't…

One 1 hour doing code review is not really stolen from doing feature work really is it? For the vast majority its stolen from playing video games or some other non-work.

That heavily depends on the individual developer and the organization in question.

In general, the most highly skilled developers who are most capable of doing a thorough code review are also the ones who are most likely to be genuinely over capacity as is.

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

#279

Post by dullcrisp »

lazide wrote: post #241
mysidia wrote: post #198

Earlier quoted context omitted.

It's standard autoconf stuff, BUT... the right thing to do for a security option should be to throw an error at the configure stage If the Option is requested but can't be supported, And not to silently turn it off. That is because a human should have to Look at the build and manually make the decision to switch off a security feature from the build.

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

If you break the build they’ll notice

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

#280

Post by kaashif »

patrakov wrote: post #242
kaashif wrote: post #239

Earlier quoted context omitted.

With the . the author can claim it was unintentional. It's impossible (or at least very hard) to claim the Cyrillic c is unintentional. To me, that makes the . more evil.

Well, on Russian keyboards, they are on the same key.

Good point - it might be plausible if the author actually were Russian, but they aren't.
Post reply on HN