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

Reflections on Distrusting xz

joeyh.name

Post reply on HN
Print view View original

11–20 of 335 posts

Re: Reflections on Distrusting xz

#11

Post by skywhopper »

berkes wrote: post #2

Full on tinfoil hat here. But warranted and practical. I'm wondering what fallout we'll see from this backdoor in the coming weeks, months or years. Was the backdoor used on obscure build servers or obscure pieces of build infrastructure somewhere? Lying dormant for a moment in future to start injecting code into built packages maybe? Are distro's going to go full-on tinfoil-hat and lock down their distribution, halt…

IIRC Debian has wiped and is rebuilding all their build hosts, so yes.

But while I understand what you mean, I would not call improving the security of a piece of software “halting progress”. Security improvements are progress, too. Plus, revisiting processes and assumptions can also give opportunities to improve efficiency elsewhere. Maintenance can be an opportunity if you approach it properly.

Re: Reflections on Distrusting xz

#12

Post by pdimitar »

berkes wrote: post #2

Full on tinfoil hat here. But warranted and practical. I'm wondering what fallout we'll see from this backdoor in the coming weeks, months or years. Was the backdoor used on obscure build servers or obscure pieces of build infrastructure somewhere? Lying dormant for a moment in future to start injecting code into built packages maybe? Are distro's going to go full-on tinfoil-hat and lock down their distribution, halt…

It's impossible to insure against in any practical terms.

The way forward is to invest heavily in a much more security-oriented kernel(s) and make sure that each program has the bare minimum to achieve what it offers as a value-add.

The human aspect of vetting seems like an impossibly difficult game of whack-a-mole. Though realistically I doubt that the bad actors have infinite agents everywhere, this also has to be said. So maybe a "sweep" could eliminate 90% of them, though I'd be skeptical.

Re: Reflections on Distrusting xz

#13

Post by gammalost »

berkes wrote: post #2

Full on tinfoil hat here. But warranted and practical. I'm wondering what fallout we'll see from this backdoor in the coming weeks, months or years. Was the backdoor used on obscure build servers or obscure pieces of build infrastructure somewhere? Lying dormant for a moment in future to start injecting code into built packages maybe? Are distro's going to go full-on tinfoil-hat and lock down their distribution, halt…

You can't really remove dependencies in open source. It is so intertwined at this point that doing it would be too expensive for most companies.

I think the solution is to containerize, containerize and then containerize some more times and make it all with zero trust in mind.

Re: Reflections on Distrusting xz

#15

Post by rwmj »

I think Joey's right that we should all go back to the "pre-Jia-Tan" xz, and I've raised this with Red Hat too. It's actually not a big deal as xz and liblzma is relatively stable and the version from 2 years ago is fine, although I understand that Debian's dpkg uses some new API(s) from liblzma which makes this a problem albeit a minor one.

(Unfortunately the Debian bug report that Joey filed got derailed with a lot of useless comments early on.)

Re: Reflections on Distrusting xz

#16

Post by ducktective »

I'm here wondering why big tech companies that have Too Much to Lose didn't already massively fund a project that freaking sshd depended on it (through systemd).

Like how does it hurt Google to assign 100 people to review and investigate commits of some project as basic and fundamental as a compression tool

Re: Reflections on Distrusting xz

#17

Post by rfoo »

Nit-picking but, eh, png does not use lzma at all.

> PNG compression method 0 (the only compression method presently defined for PNG) specifies deflate/inflate compression with a sliding window of at most 32768 bytes. Deflate compression is an LZ77 derivative used in zip, gzip, pkzip, and related programs.

Re: Reflections on Distrusting xz

#18

Post by funcDropShadow »

gammalost wrote: post #13
berkes wrote: post #2

Full on tinfoil hat here. But warranted and practical. I'm wondering what fallout we'll see from this backdoor in the coming weeks, months or years. Was the backdoor used on obscure build servers or obscure pieces of build infrastructure somewhere? Lying dormant for a moment in future to start injecting code into built packages maybe? Are distro's going to go full-on tinfoil-hat and lock down their distribution, halt…

You can't really remove dependencies in open source. It is so intertwined at this point that doing it would be too expensive for most companies. I think the solution is to containerize, containerize and then containerize some more times and make it all with zero trust in mind.

Docker containers are not really a security measure.

Re: Reflections on Distrusting xz

#19

Post by junon »

ducktective wrote: post #16

I'm here wondering why big tech companies that have Too Much to Lose didn't already massively fund a project that freaking sshd depended on it (through systemd). Like how does it hurt Google to assign 100 people to review and investigate commits of some project as basic and fundamental as a compression tool

sshd didn't depend on it, to be fair. Not officially at least.

Re: Reflections on Distrusting xz

#20

Post by rwmj »

afc wrote: post #6
throwaway63467 wrote: post #3

Seems like a sensible thing to do, assuming this is a state-level threat actor there’s really no easy way to prove that their contributions are free of back doors. Seems not worthwhile risking the security of a large part of the Internet over a few thousand lines of code.

But why would the entire behind this submit all their attacks through the same single identity? Removing all this code could just be removing 1% of their harmful code. How do you deal with the rest? How do you discover the other identities?

You start with what you know about, and you investigate other projects carefully at the same time. There's no easy answer here, you do what you can.
Post reply on HN