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

Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

socket.dev

Post reply on HN
Print view View original

321–330 of 458 posts

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#321

Post by bdangubic »

neya wrote: post #320
eranation wrote: post #144

Anyone know of a better way to protect yourself than setting a min release age on npm/pnpm/yarn/bun/uv (and anything else that supports it)? Setting min-release-age=7 in .npmrc (needs npm 11.10+) would have protected the 334 unlucky people who downloaded the malicious @bitwarden/cli 2026.4.0, published ~19+ hours ago (see https://www.npmjs.com/package/@bitwarden/cli?activeTab=versi... and select "show deprecated vers…

Stop using Javascript. Or Typescript or whatever excuses they have for the fundamentally flawed language that should have been retired eons ago instead of trying to get it fixed. Javascript, its ecosystem has always been a pack of cards. Time and again it has been proven again. I think this is like the 3rd big attack in the last 30 days alone.

it is being attacked precisely because it is ubiquitous. no one is going to attack haskell, erlang or whatever no one uses.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#322

Post by saghm »

LegionMammal978 wrote: post #312
saghm wrote: post #292

Earlier quoted context omitted.

> At least they're pinned though. Frustratingly, they're not by default though; you need to explicitly use `--locked` (or `--frozen`, which is an alias for `--locked --offline`) to avoid implicit updates. I've seen multiple teams not realize this and get confused about CI failures from it. The implicit update surface is somewhat limited by the fact that versions in Cargo.toml implicitly assume the `^` operator on ver…

> The implicit update surface is somewhat limited by the fact that versions in Cargo.toml implicitly assume the `^` operator on versions that don't specify a different operator, so "1.2.3" means "1.2.x, where x >= 3". For reasons that have never been clear to me, people also seem to really like not putting the patch version in though and just putting stuff like "1.2", meaning that anything other than a major version…

I don't know how I got this wrong because I literally went and looked at that page to try to remind myself, but I somehow misread it, because you're definitely right. This probably isn't the first time I've gotten this wrong either.

From thinking it through more closely, it does actually seem like it might be a little safer to avoid specifying the patch version; it seems like putting 1.2.3 would fail to resolve any valid version in the case that 1.2.2 is the last non-yanked version and 1.2.3 is yanked. I feel like "1.2.3" meaning "~1.2.3" would have been a better default, since it at least provides some useful tradeoff compared to "1.2", but with the way it actually works, it seems like putting a full version with no operator is basically worse than either of the other options, which is disappointing.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#323

Post by saghm »

subarctic wrote: post #300
saghm wrote: post #292

Earlier quoted context omitted.

> At least they're pinned though. Frustratingly, they're not by default though; you need to explicitly use `--locked` (or `--frozen`, which is an alias for `--locked --offline`) to avoid implicit updates. I've seen multiple teams not realize this and get confused about CI failures from it. The implicit update surface is somewhat limited by the fact that versions in Cargo.toml implicitly assume the `^` operator on ver…

Is there a plan to change this? I don't see why --locked shouldn't be the default

I haven't heard anything about this, but I really wish it was there by default. I don't think the way it works right now fits anyone's expectations of what the lockfile is supposed to do; the whole point of storing the resolved versions in a file is to, well, lock them, and implicitly updating them every time you build doesn't do that.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#324

Post by jpleger »

bfivyvysj wrote: post #304
fragmede wrote: post #260

Earlier quoted context omitted.

But it goes the other way too. If there's a security vulnerability that was fixed in a later version, you want the system to automatically pick that up and apply it for you in an ideal scenario.

Why would you patch a security vuln in a later version? Should be patched in all versions.. that's what semver is for.

Ah yes the incredibly common practice of... checks notes backporting security packages in node packages.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#325

Post by kijin »

bfivyvysj wrote: post #304
fragmede wrote: post #260

Earlier quoted context omitted.

But it goes the other way too. If there's a security vulnerability that was fixed in a later version, you want the system to automatically pick that up and apply it for you in an ideal scenario.

Why would you patch a security vuln in a later version? Should be patched in all versions.. that's what semver is for.

Semver doesn't help if you just declare all older versions EOL.

What you're looking for are Debian stable packages. :p

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#326

Post by hsbauauvhabzb »

saghm wrote: post #319
hsbauauvhabzb wrote: post #308

Earlier quoted context omitted.

So uninstall Reddit? That app is spyware at best and malware at worst.

I'm guessing you meant to respond to the sibling comment rather than mine

Yes, weirdly enough at the time there was no reply button, I thought HN comments had a maximum nested depth, but now it has a reply button and so does yours. Weird.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#327

Post by d0liver »

neya wrote: post #320
eranation wrote: post #144

Anyone know of a better way to protect yourself than setting a min release age on npm/pnpm/yarn/bun/uv (and anything else that supports it)? Setting min-release-age=7 in .npmrc (needs npm 11.10+) would have protected the 334 unlucky people who downloaded the malicious @bitwarden/cli 2026.4.0, published ~19+ hours ago (see https://www.npmjs.com/package/@bitwarden/cli?activeTab=versi... and select "show deprecated vers…

Stop using Javascript. Or Typescript or whatever excuses they have for the fundamentally flawed language that should have been retired eons ago instead of trying to get it fixed. Javascript, its ecosystem has always been a pack of cards. Time and again it has been proven again. I think this is like the 3rd big attack in the last 30 days alone.

This isn't a JS specific issue.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#328

Post by saghm »

poly2it wrote: post #314
saghm wrote: post #292

Earlier quoted context omitted.

> At least they're pinned though. Frustratingly, they're not by default though; you need to explicitly use `--locked` (or `--frozen`, which is an alias for `--locked --offline`) to avoid implicit updates. I've seen multiple teams not realize this and get confused about CI failures from it. The implicit update surface is somewhat limited by the fact that versions in Cargo.toml implicitly assume the `^` operator on ver…

It should be fine to do this according to semver as long as the major version is above zero.

Sure, but according to semver it's also totally fine to change a function that returns a Result to start returning Err in cases that used to be Ok. Semver might be ae to project from your Rust code not compiling after you update, but it doesn't guarantee it will do the same thing the next time you run it. While changes like that could still happen in a patch release, I'd argue that you're losing nothing by forgoing new API features if all you're doing is recompiling the existing code you have without making any changes, so only getting patches and manually updating for anything else is a better default. (That said, one of the sibling comments pointed out I was actually wrong about the implicit behavior of Cargo dependencies, so what I recommended doesn't protect from anything, but not for the reasons it sounds like you were thinking).

Some people might argue that changing a function to return an error where it didn't previously would be a breaking change; I'd argue that those people are wrong about what semver means. From what I can tell, people having their own mental model of semver that conflicts with the actual specification is pretty common. Most of the time when I've had coworkers claim that semver says something that actively conflicts with what it says, after I point out the part of the spec that says something else, they end up still advocating for what they originally had said. This is fine, because there's nothing inherently wrong with a version schema other than semver, but I try to push back when the term itself gets used incorrectly because it makes discussions much more difficult than they need to be.

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#329

Post by saghm »

wycats wrote: post #310
subarctic wrote: post #300

Earlier quoted context omitted.

Is there a plan to change this? I don't see why --locked shouldn't be the default

As one of the original authors of Cargo, I agree. lockfiles are for apps and CLIs are apps. QED.

Since you're here, and you happened to indirectly allude to something that seems to have become increasingly common in the Rust world nowadays, I can't help but be curious about your thoughts on libraries checking their lockfiles into version control. It's not totally clear to me exactly when or why it became widespread, but it used to be relatively rare for me to see in open source libraries in the first few post-1.0 years of Rust, whereas at this point I think it's more common for me to see than not.

Do you think it's an actively bad practice, completely benign, or something in between where it makes sense in some cases but probably should still be avoided in others? Offhand, the only variable I can think of that might influence a different choice is that maybe closed-source packages been reused within a company (especially if trying to interface with other package management systems, which I saw firsthand when working at AWS but I'm guessing is something other large companies would also run into), but I'm curious if there are other names nuances I haven't thought of

Re: Bitwarden CLI compromised in ongoing Checkmarx supply chain campaign

#330

Post by mayama »

MetaWhirledPeas wrote: post #245
PunchyHamster wrote: post #223

Earlier quoted context omitted.

Don't write anything backend or cli tool in NPM would be good start

Other package managers are magically immune?

You could write most of the cli tools using stdlib in python and go, without need for including hundreds of libraries even for trivial things.
Post reply on HN