Hacker News Reader

Re 1., we know because we are developers but managers and other less technical folks involved in software development want to know whether it's safe to use things, even if SSH is not involved.

Re 2., I honestly agree, but I think it's fair to refer to "the XZ backdoor" as the one we know about vs. the potential ones that we don't know about yet.

I also kind of think "we are not vulnerable" might inspire unwarranted confidence. The real answer also needs "(but honestly, we totally would've been if it targeted us)" but this creates a lot of fear that isn't going to help much. (Hopefully though, the existing fear and paranoia created by this attempt will help us push assurances a bit further. I feel the OpenSSL exploits definitely helped push some things forward, too, even if the world is clearly not perfect after all of that.)

I prefer not to refer to 'the' XZ backdoor, because people are under pressure to declare this over. This imprecise way of talking allows management to say ssh is secure, so the backdoor is fixed, so stop spending time and money looking deeper into this. Meanwhile, other potential xz backdoors might fly under the radar.

Well, for all intents and purposes, it is over for the security issue that is disclosed. Even if people continue investigating further potential issues and rolling back potentially innocuous changes out of an abundance of caution, there's genuinely nothing else for consumers of liblzma5 or xz to do directly, unless they want to participate in that investigation.

But, for users of xz, like package managers, I think the right thing to do is sandbox all of the compression (and other data handling routines) using OS-level sandboxing technology like seccomp and pledge if they don't already. It's already a common strategy for handling potentially unsafe data, and while packages are typically signed and could potentially compromise the system anyway if not trustworthy, it's still worth it because a compromise via RCE in the LZ algorithm could possibly be VASTLY more difficult to detect than the package itself being malicious, in the same way that compromising SSH via a library it doesn't even nominally depend on is. (e.g. a package could potentially detect if it is being unpacked manually or via a package manager to try to hide that it is malicious!)

If you're using ruby gems you're a developer and should know the diff between an os package and language lib. And this is Hacker news.

A "didn't happen to us" is noise because it could have happened for a different actor/target.

Engineering managers and their managers are not all technical enough to know if RubyGems is vulnerable, but nonetheless are often technical enough to know that RubyGems is used by them. I'm not posing a hypothetical here, I've already seen management asking similar questions.

The flip side is companies that are not active participants in the open source community (but know they use open source), are pinging all their engineering managers and asking "are we exposed to this!? how do you know!?".

So while it's useless noise to you, it's likely triggered by being on the receiving end of communications like "Hey, my boss is asking if $PROJECT is vulnerable because of a terrible article he read in $MAINSTREAM_MEDIA_PROPERTY?" times however many bosses are harassing their reports.

"I don't want to craft an email reply to every single person, just put up the no-op blog post and be done with it."

> Given these two points, I really believe we should not be posting "hey we are not vulnerable" blog posts here because at best they are useless noise (nobody aside of debian or redhat and their downstreams is vulnerable) and at worst false assurances.

Nobody has said this. The post says specifically that nothing on RubyGems is known to use the known backdoor; nobody has made (or could reasonably make) claims about unknown future backdoors. It’s incumbent on you to understand that this kind of announcement doesn’t imply the absence of potential future ones.

Not commenting on the applicability to the RubyGems post, but just in general point number 2 is something I've been thinking of as well. If I were going to undertake a long-term effort like this to compromise, I would not have put all my eggs in one basket. We might only have discovered 1 of 3 and should not be celebrating yet (though a congratulatory toast is very appropriate)

Completely disagree. Every project that has xz/liblzma added as a dependency should be looking at the source, compiling from said source and making sure their binaries that they shipped with their software match this. For example, homebrew should do this. If the attacker configured the backdoor for the server to enable a universal master key, who's to say they didn't engineer a backdoor for the Homebrew version to export private keys from the current user's .ssh folder?

That's my second point. Just checking for version <= 5.6.0 is not safe either and is exactly what the original article has done.

But if all you use as the basis of the vulnerability analysis is the version constraint and what we currently know about the backdoor, then, unless you are a distro building a liblzma distro package, you will not be vulnerable no matter the version (which was my point 1)

> it's too early to claim that a project is not vulnerable to backdoors

I don’t think that’s a fair or accurate paraphrase of the blogpost.

They said they weren’t exposed to the backdoor (headline), or this issue (body of article). Both are deliberately singular, and from context clearly referencing the known back door.

I don’t see anything in the post claiming they aren’t vulnerable to back doors in general.

That's my first point though. If you only take into account what is currently known about the backdoor, unless you are a linux distro building a liblzma debian or RPM package, you are not vulnerable to the backdoor.

So I believe, given the current state of knowledge, that all the projects that are not about building liblzma packages are not vulnerable and thus their postings about them not being vulnerable is noise.

Much like PyPI, there are a large number of gems on RubyGems that either vendor library builds or provide source redistributions for local builds. That’s why these kinds of indices need to perform these scans; it’s not sufficient to assume that the host distribution or OS is the only source of runtime libraries.

Sure, I wasn't disagreeing with your first point. I was disagreeing with your second point.