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

141–150 of 335 posts

Re: Reflections on Distrusting xz

#141

Post by imjonse »

adql wrote: post #126
lispm wrote: post #42

Why not get rid of xz completely? Hoe about using a simpler piece of software, which could be maintained by more people?

> Why not get rid of xz completely? ... you mean compression package used by most big distros to make their packages? Do you really need to ask > Hoe about using a simpler piece of software, which could be maintained by more people? It's not a complex piece of software. Lib itself is ~15k lines of code. It does it's job well and it needs little work. It didn't had any outstanding bugs lingering unfixed for years Comp…

Complexity is one of the root causes of the problem. The script was added via messy autoconf scripts inscrutable to most people. That is decades old tech which has alternatives.

Re: Reflections on Distrusting xz

#142

Post by [deleted] »

moritonal wrote: post #77
berkes wrote: post #36

Earlier quoted context omitted.

I once got a (probably scam) offer for adding a cryptominer to a library that I maintained at that time. And a more serious offer to add trackers to a popular >1M installs app. Both cases I obviously ignored it. But it made me aware of a nasty attack vector: someone who's thanklessly building a wordpress-plugin, pip, npm, or whatever software, thanklessly dealing with issues, PRs, support, maintainence, often for no…

It's why I actually always encourage app devs to charge for their apps, even open source ones. It creates an exchange of value for the author to feel valued and detract from these vectors.

[deleted]

Re: Reflections on Distrusting xz

#143

Post by david_allison »

strogonoff wrote: post #128
berkes wrote: post #36

Earlier quoted context omitted.

I once got a (probably scam) offer for adding a cryptominer to a library that I maintained at that time. And a more serious offer to add trackers to a popular >1M installs app. Both cases I obviously ignored it. But it made me aware of a nasty attack vector: someone who's thanklessly building a wordpress-plugin, pip, npm, or whatever software, thanklessly dealing with issues, PRs, support, maintainence, often for no…

I believe the problem of thankless maintenance is best solved with two things: the thanks (yes, we are all human and want recognition and appreciation from fellow humans)[0], and a stable employment (work for a good large business while open-sourcing what’s possible)[1]. If you do OSS for profit, then it can become a question of where is more money; but if you work a reliable job with insurance, relationships and oth…

3. More maintainers

Days of 100+ notifications aren't easy. Things will slip through

Re: Reflections on Distrusting xz

#144

Post by nottorp »

fsniper wrote: post #9

It's like security 101. If a system has been infiltrated, you can't trust any part of it. So it's better to discard any part that has been reached or possibly affected. Perhaps it's the correct action to distrust xz/lzma or any source code this team has control over and switch to alternatives. If there are no alternatives, to start ones.

> If a system has been infiltrated, you can't trust any part of it. So it's better to discard any part that has been reached or possibly affected.

systemd! let's discard systemd!

Re: Reflections on Distrusting xz

#145

Post by epr »

irdc wrote: post #8

One thing that comes to mind is that “Jia Tan” might be more accurately seen as a “sleeper” of some sort: a foot soldier who infiltrates a juicy open source project and waits for further instructions; backdooring sshd might not have been part of the original plan. Which raises the concerning question of how much more sleeper maintainers there are.

I've never been concerned about spies infiltrating open source projects compared to legitimate maintainers being hacked, even now after this whole xz incident.

I'll put it this way. Let's say a bad guy had a decent budget to spend on paying agents/criminals to break into maintainer's homes on their behalf with a rubber ducky, etc. I'd expect a pretty high success rate compromising their hardware...

Re: Reflections on Distrusting xz

#146

Post by coretx »

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…

Not fallout but increased vigilance is the expected most significant outcome. Some 5+ years ago or so I listened to a Debian guy his talk about reproducible builds and security, he was stressing the audience to be aware of just happened in a very detailed manner. One of the details he mentioned was glowies having moved their focal point to individual developers and their tooling & build systems. At least some people who matter have been working on these threats for many years already, maybe more people will start to listen to them; in such case this entire debacle could have a net positive effect on the long run.

Re: Reflections on Distrusting xz

#147

Post by strogonoff »

david_allison wrote: post #143
strogonoff wrote: post #128

Earlier quoted context omitted.

I believe the problem of thankless maintenance is best solved with two things: the thanks (yes, we are all human and want recognition and appreciation from fellow humans)[0], and a stable employment (work for a good large business while open-sourcing what’s possible)[1]. If you do OSS for profit, then it can become a question of where is more money; but if you work a reliable job with insurance, relationships and oth…

3. More maintainers Days of 100+ notifications aren't easy. Things will slip through

Agreed, but especially in light of recent events it’d be important to know who they are, and that’s not always easy.

Re: Reflections on Distrusting xz

#149

Post by mannykannot »

arp242 wrote: post #69
irdc wrote: post #52

Earlier quoted context omitted.

At this point, considering the apparent ease with which a project that is used pretty much everywhere was taken over, that seems like a reasonable position.

I can walk out on the street and stab someone to death if I wanted to. This is surprisingly easy. Just because something is relatively easy to pull off doesn't mean it happens a lot. It's also not that easy to pull off because you need to have a project with relatively few eyes and a place to hide it. In this case: binary tests. But most projects don't have those. There is no evidence for any of this, including that…

Motive, opportunity, means - and consequences: it is primarily the absence of a motive, and secondarily the likelihood of consequences, that keeps the prevalence of street stabbings way lower that if means and opportunity were the only factors.

The argument against nation-states being involved has some problems: a state can avoid becoming victim to its own work, while its own restraint would not prevent developments elsewhere.

Re: Reflections on Distrusting xz

#150

Post by k3vinw »

Macha wrote: post #4

Yeah, it's left me a little disappointed in Arch in particular that they didn't follow the lead of Debian and Fedora and revert to a much older version, instead just building 5.6.1 from the git repo and basically defended it as "the hacked build script checked for dpkg/rpm anyway".

Wow. So for the xz package it looks like they changed the upstream to this (edit: the original maintainer’s personal repo, Lasse Collins) git repo that still contains Jia Tan’s commits: https://git.tukaani.org/?p=xz.git

tl;dr they re-enabled the sandboxing previously disabled by Jia Tan.

Post reply on HN