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

181–190 of 335 posts

Re: Reflections on Distrusting xz

#181

Post by Matumio »

loftsy wrote: post #86

I took a look at the diff linked in the article with code that "we are all running". The top of the diff certainly looks interesting. They remove the bounds check in dict_put() and add a safe version dict_put_safe(). This kind of change is difficult to make without mistakes because it silently changes the assumptions made when code calling dict_put() was originally written. ALL call sites would need to be audited to…

Agree, nice catch. Also, there are many other opportunities in this patch to hide memory safety bugs.

This is the kind of optimization I might have done in C 10 years ago. But coming back from Rust, I wouldn't consider it any more. Rust, despite its focus on performance, will simply not allow it (without major acrobatics). And you can usually find a way to make the compiler optimize it out of the critical path.

Re: Reflections on Distrusting xz

#182

Post by mrspuratic »

galangalalgol wrote: post #90
pdimitar wrote: post #12

Earlier quoted context omitted.

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…

Agreed, as a developer: minimize your dependencies while providing your core function. Don't grant dependencies permissions they don't need. Be granular about it. Austral lets you select what filesystem, network, etc. access each library gets. Also, in big organizations, risk assessment is more about making sure there is someone to point the finger at, than actual security. Treating libfubar as golden because it ship…

"reduce the attack surface" is Security 101. Noting again that sshd doesn't natively use xz/liblzma (just libz) or systemd, so I don't think I need to point out where the billowing attack surface is ;)

Apache (by way of mod_systemd) is similarly afflicted, as is rsyslogd, I guess most contemporary daemons that need systemd to play fair are (try: "fuser -v /lib64/liblzma.so.?" and maybe "ldd /lib64/libsystemd.so.?" too).

Like a Luddite I still use Slackware and prefer to avoid creeping dependencies, ever since libkrb5 starting getting its tentacles into things more than a decade ago.

Re: Reflections on Distrusting xz

#183

Post by transportgo »

chjj wrote: post #179
cletus wrote: post #170

The US spends $30-60 billion a year on agriculture and subisides [1]. This is controversial for all the obvious reasons. Without subsidies we'd waste less food but overproduction of food is an intentional objective of these programs. Why? Because if there's a major drought or crops are lost to ice or snow or flooding, Americans won't starve. It's why we have things like the US government having a reserve of over a bi…

I'm not sure why people keep misidentifying the problem as "lack of funding". Lasse Collin was doing fine as a maintainer up until Jia Tan showed up. He was psy-op'd into believing there was a crowd of angry people eagerly awaiting a new release when there wasn't. No real person was unhappy with the way he'd been maintaining xz.

But if he was paid he might not have given up control

Re: Reflections on Distrusting xz

#184

Post by diggan »

chjj wrote: post #179
cletus wrote: post #170

The US spends $30-60 billion a year on agriculture and subisides [1]. This is controversial for all the obvious reasons. Without subsidies we'd waste less food but overproduction of food is an intentional objective of these programs. Why? Because if there's a major drought or crops are lost to ice or snow or flooding, Americans won't starve. It's why we have things like the US government having a reserve of over a bi…

I'm not sure why people keep misidentifying the problem as "lack of funding". Lasse Collin was doing fine as a maintainer up until Jia Tan showed up. He was psy-op'd into believing there was a crowd of angry people eagerly awaiting a new release when there wasn't. No real person was unhappy with the way he'd been maintaining xz.

I'm not saying money would absolutely fix the issue, but I could also see it helping. If Collin was approached by a government that said "Hey, the thing you're maintaining is important, if you want, we'll fund 2 additional full-time maintainers that can contribute based on your guidance", maybe Collin would be in a better position to ensure the Jia Tan contributions were genuine and proper.

Re: Reflections on Distrusting xz

#185

Post by kzrdude »

liendolucas wrote: post #176
loftsy wrote: post #86

I took a look at the diff linked in the article with code that "we are all running". The top of the diff certainly looks interesting. They remove the bounds check in dict_put() and add a safe version dict_put_safe(). This kind of change is difficult to make without mistakes because it silently changes the assumptions made when code calling dict_put() was originally written. ALL call sites would need to be audited to…

I think at this point is clear that everybody has to assume that XZ is completely rotten and can no longer be trusted. Is it XZ easy to replace with some other compression tool? Or has it been so widely adopted that is going to take huge effort moving out of it?

Huge effort, because it is the default .deb compressor in Debian for example

Re: Reflections on Distrusting xz

#186

Post by udev4096 »

transportgo wrote: post #183
chjj wrote: post #179

Earlier quoted context omitted.

I'm not sure why people keep misidentifying the problem as "lack of funding". Lasse Collin was doing fine as a maintainer up until Jia Tan showed up. He was psy-op'd into believing there was a crowd of angry people eagerly awaiting a new release when there wasn't. No real person was unhappy with the way he'd been maintaining xz.

But if he was paid he might not have given up control

He never mentioned about any financial problems, it was more about his mental health

Re: Reflections on Distrusting xz

#187

Post by alt227 »

codezero wrote: post #117

Consider “Jia Tan” started working on xz because they already found a critical vulnerability and wanted to maintain it, or more tin foil, they burned xz to get upstreams to use another compression that is also already backdoored. When dealing with state actors there’s really no limit to how complex the situation can be.

This is something I also wondered but havent seen discussed anywhere. This could all be a smokescreen to get distros to switch to the next best compression library which already contains malicious code. Hopefully maintainers of any upstream compression libraries are all looking hard at their code bases right now.

Re: Reflections on Distrusting xz

#188

Post by rthnbgrredf »

kzrdude wrote: post #185
liendolucas wrote: post #176

Earlier quoted context omitted.

I think at this point is clear that everybody has to assume that XZ is completely rotten and can no longer be trusted. Is it XZ easy to replace with some other compression tool? Or has it been so widely adopted that is going to take huge effort moving out of it?

Huge effort, because it is the default .deb compressor in Debian for example

Arch Linux has replaced it with zstd in 2020 already. It's doable for the next major release of Debian.

Re: Reflections on Distrusting xz

#189

Post by simoncion »

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…

> ... you mean compression package used by most big distros to make their packages? Do you really need to ask

Because of the existence of gzip, zlib, bzip2, and many others, it's trivial to drop xz.

So yeah, why not get rid of xz completely?

Re: Reflections on Distrusting xz

#190

Post by Cthulhu_ »

chjj wrote: post #179
cletus wrote: post #170

The US spends $30-60 billion a year on agriculture and subisides [1]. This is controversial for all the obvious reasons. Without subsidies we'd waste less food but overproduction of food is an intentional objective of these programs. Why? Because if there's a major drought or crops are lost to ice or snow or flooding, Americans won't starve. It's why we have things like the US government having a reserve of over a bi…

I'm not sure why people keep misidentifying the problem as "lack of funding". Lasse Collin was doing fine as a maintainer up until Jia Tan showed up. He was psy-op'd into believing there was a crowd of angry people eagerly awaiting a new release when there wasn't. No real person was unhappy with the way he'd been maintaining xz.

Funding aside, single individuals being responsible for software is not a good thing, see bus factor.
Post reply on HN