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

What we know about the xz Utils backdoor that almost infected the world

arstechnica.com

Post reply on HN
Print view View original

281–290 of 336 posts

Re: What we know about the xz Utils backdoor that almost infected the world

#281

Post by slowmovintarget »

markus_zhang wrote: post #177
thiht wrote: post #172

Earlier quoted context omitted.

How would it have changed anything in this specific case?

This might solve the original author's issues, AND might also attract other people to do the job. The more people, the more eyes. It's definitely not a silver bullet, but I would be surprised that OSS maintainers are fine with the current financial arrangement, or lack of it.

Money itself doesn't necessarily cure mental health issues. I'm mean it usually doesn't hurt, but it's not like you can blend cash up into a smoothy and cure depression. (Yes, that's a South Park reference.)

Re: What we know about the xz Utils backdoor that almost infected the world

#283

Post by bongodongobob »

fransje26 wrote: post #278
bongodongobob wrote: post #179

Earlier quoted context omitted.

I think the message would more likely be "don't use open source and pay for closed source" than "give money to open source and cross your fingers that it does something".

You mean going for safe companies, like Microsoft? That were infiltrated for ages with solarwind, "without any changes to their source code"?

Yes, good example, a company they are likely already doing business with.

Re: What we know about the xz Utils backdoor that almost infected the world

#284

Post by paulmd »

xorcist wrote: post #88
josephg wrote: post #53

Earlier quoted context omitted.

I don’t understand how this is still the best way to test if features are available in C. Can’t the OS / environment provide a “features_available” JSON blob listing all the features on the host system? Is AVX2 available on the cpu? OpenSSL? (And if so, where?) and what about kernel features like io_uring? Doing haphazard feature detection by test compiling random hand written C programs in a giant sometimes autogene…

Satire is so hard on the Internet and maybe I'm just thick headed. Just to clarify things, is that a suggestion to shove a JSON parser into either bash or autoconf?

JSON is too far, says the engineering culture still relying on a pile of shell scripts like it’s 1970.

(that’s unfair, there’s probably tooling to build the shell scripts automatically I bet)

Re: What we know about the xz Utils backdoor that almost infected the world

#287

Post by gumby »

Kuinox wrote: post #80
gumby wrote: post #67

Earlier quoted context omitted.

> 1a. As a consequence of (1) autogenerated artifacts should always be committed. I philosophically and fundamentally hate this suggestion, but have to agree with it. It's going to make porting harder, but is sadly a cost worth paying. > dependencies are maintenance burden and a security risk, this needs to be weighted against the functionality they bring in Tough call. A major library is more likely to be bug fixed…

Why would it make porting harder ?

Often the autogenerated things are dependent on the machine they are running on.

Re: What we know about the xz Utils backdoor that almost infected the world

#288

Post by SAI_Peregrinus »

teddyh wrote: post #169
SAI_Peregrinus wrote: post #153

Earlier quoted context omitted.

There was an upstream OpenSSL bug there: they depended on reading from uninitialized memory to add entropy and thus increase startup speed of their RNG. But reading from uninitialized memory is undefined behavior, it's not guaranteed to add any entropy and should always be treated as a security bug. The Debian maintainers tried to fix the bug, but screwed up the fix. They should have reported the bug upstream, not ju…

IIRC, they did report the bug, and it was rejected.

My memory is fuzzy. In that case, I'd blame the OpenSSL devs if the report wasn't a patch with the (non-working) "fix". Even if it was, they should have accepted the bug & rejected the patch.

Re: What we know about the xz Utils backdoor that almost infected the world

#289

Post by yosito »

queuebert wrote: post #249
yosito wrote: post #4

Are we ever going to figure out who Jia Tan is?

Doesn't that translate to "spy house" in Mandarin? (Depending on tones, of course. I'm assuming 家探.)

I have no idea if you're correct or not, but that doesn't really indicate who was behind it other than suggesting that it might NOT be Chinese state actors because that would be way to obvious of a giveaway when investing multiple years of effort into a stealthy project.

Re: What we know about the xz Utils backdoor that almost infected the world

#290

Post by to11mtm »

mnau wrote: post #270
lenerdenator wrote: post #101

Earlier quoted context omitted.

Really, it starts before things get bad. This thing where - in the famous XKCD example - a single guy is thanklessly maintaining a project for 20 years in Nebraska needs to stop. Software libraries like these are no longer a one-person job. They can't be for the bus factor alone. Major projects like Linux distros or bigger foundations like Apache or Mozilla need to start harping on people hard to contribute to import…

> bigger foundations like Apache or Mozilla What bigger foundations? Apache foundation has yearly revenue $2.1 million. Why do you think they reacted as they reacted to log4j? There are no resources. Open source is running on fumes.

pretty much this.

That's why for whatever anyone thinks of Theo's antics, I appreciated the OpenSSL/LibreSSL Valhalla blogs and overall effort to do something about it.

TBH I'm amazed in it's current state that Apache took in Pekko(FKA JVM Akka...), part of me is guessing it's because some of their other infra is dependent on it...

Foundation based OSS is on fumes. Open core... I am still hopeful for on many levels.

Post reply on HN