"Just" is doing a lot of work; most ecosystems are not set up or equipped to do this kind of server-side queuing in 2026. That's not to say that we shouldn't do this, but nobody has committed the value (in monetary and engineering terms) to realizing it. Perhaps someone should.

By contrast, a client-side cooldown doesn't require very much ecosystem or index coordination.

I agree, even without project glasswing (that Microsoft is part of) even with cheaper models, and Microsoft's compute (Azure, OpenAI collaboration), it makes no sense that private companies needs to scan new package releases and find malware before npm does. I'm sure they have some reason for it (people rely on packages to be immediately available on npm, and the real use case of patching a zero day CVE quickly), but until this is fixed fundamentally, I'd say the default should be a cooldown (either serverside or not) and you'll need to opt in to get the current behavior. This might takes years of deprecation though, I'm sure it was turned on now, a lot of things would break. (e.g. every CVE public disclosure will also have to wait that additional cooldown... and if Anthropic are not lying, we are bound for a tsunami of patched CVEs soon...)

That's just direct dependencies. Including all the dependency tree is 785k LOC according to lib.rs. Most rust libraries include tons of others.

https://lib.rs/crates/rbw

Password managers are all about trust, the main link is about a compromise, so it's not surprising that the first comment is also about trust too, even if it's not directly about this particular compromise.

I found the default bwcli clunky and unacceptable, and it's why I don't use it, even though I still have a BitWarden subscription.

Not to mention utter nonsense. There’s no possible way that BW CLI somehow injected command history into a remote server. That was 100% something the GP did, a bug in their terminal, or a config they have with ssh/tmux, not Bitwarden.

It's crazy because it's not default bw behavior, or even any bw behavior... I don't use the cli, but I don't see any built-in capacity to copy bw output to the clipboard. (In the UNIX way, you'd normally pipe it to a clipboard utility if you wanted it copied, and then the security consequences are on you.)

They probably caused it themselves, somehow, and then blamed bitwarden. Note in the original comment they aren't even entirely sure what the command was, and they weren't familiar with it or they wouldn't have been surprised by its output... so how can they be sure what else they did between that command and the weechat thing?

If the terminal or tmux fed terminal history into weechat, that's also not bw's problem.

I don't know, I use a vanilla weechat setup

Exactly. That is the problem.

There is a time and place for where it makes sense and a password manager CLI written in TypeScript importing hundreds of third-party packages is a direct red flag. It is a frequent occurrence.

We have seen it happen with Axios which is one of the biggest supply chain attacks on the Javascript / Typescript ecosystem and it makes no sense to build sensitive tools with that.

The problem is that the UX with a browser extension is so much better.

In theory the browser integration shouldn’t leak anything beyond the credentials being used, even if compromised.

When you use autofill, the native application will prompt to disclose credentials to the extension. At that point, only those credentials go over the wire. Others remain inaccessible to the extension.

That is why we have discussions like these: https://x.com/i/status/2039099810943304073

Exactly this. For anyone who wants to do it for various package managers:

  ~/.npmrc: 
  min-release-age=7 (npm 11.10+)

  ~/Library/Preferences/pnpm/rc: 
  minimum-release-age=10080 (minutes)

  ~/.bunfig.toml 
  [install]: 
  minimumReleaseAge = 604800 (seconds)

(plug: released a small CLI to auto-configure these — https://depsguard.com — I tried to find something that will help non developers quickly apply recommended settings, and couldn't find one)

I am not sure that works - imagine that the next shellshock had been found. Would you want to wait 7 days to update?

We need to either screen everybody or cut of countries like North Korea and Iran from the Internet.

If the software gets poisoned then your YubiKey will not save you.

ah, the old bash.org.

Does it matter? Lots of groups do such checks at startup at this point, because every news outlet who reports on it suddenly believe the group to be Russian if you do, so it's a no brainer to add today to misdirect even a little.

> but it does serve to make it very obvious it was a state actor

Lol no, lots of groups do this, non-state ones too.

Keepass is just a single file, you can share it between devices however you want (google drive, onedrive, dropbox, nextcloud, syncthing, rsync, ftp, etc); as long as you can read and write to it, it just works. There are keepass clients for just about everything (keepassxc for desktops, keepass2android or keepassdx for android, keepassium for iphone).

Not op but I mean you can use a public cloud with Cryptomator on top if you don’t trust your password DB on a non E2E cloud. Or you can just use your own cloud (but then no access outside or can risk and open up infra), and then any of the well known clients on your phone. Can optionally sandbox them if possible and then just be mindful of sync conflicts with the DB file but I assume you, like most people, will 99.9% of the time be reading the DB not writing to it.

Syncthing can synchronize Keepass files between devices quite well.

For me it is nextcloud + wireguard

I use self-hosted Bitwarden (Vaultwarden) for this. It runs on my local network, and I have it installed on my phone etc. When I’m on my local network, everything works fine. When I’m not on my local network, the phone still has the credentials from the last time it was synced (i.e., last time it was used while the phone was on the home network). It’s a pretty painless way to keep things in sync without ever allowing Bitwarden to be accessible outside my home network.

In short, when I make a major password or credential change I do it from my laptop, consider that file on disk to be the "master" copy, and then manually sync the file on a periodic basis to my phone. I treat the file on the phone as read-only. Works fine so far.

To date there have been zero instances when I needed to significantly change a password/service/login/credential solely from my phone and I was unable to access my laptop.

Additionally the file gets synchronized to a workstation that sits in my home office accessible by personal VPN, where it can be accessed in a shell session with the keepass CLI: https://tracker.debian.org/pkg/kpcli

You can use an extremely wide variety of your own choice of secure methods for how to get the file from the primary workstation (desktop/laptop) to your phone.

I mean there are ways i.e. if you run something like tailscale and can always access your private network etc. but it is a hassle.

Plus, now you're responsible for everything. Backups, auditing etc.

what "infra"? keepass works locally, and just opens a database file. it works the same as any other password manager.

The average user is reusing their password everywhere, and rotation means changing the numeral 6 at the end of the password to 7.

This article is borderline malicious in how it skirts the facts.

This wasn't a case where KeePass was compromised in any way, as far as I can tell. This appears to be a basic case of a threat actor distributing a trojanized version via malicious ads. If users made sure they are getting the correct version, they were never in danger. That's not to say that a supply chain attack couldn't affect KeePass, but this article doesn't say that it has.

That looks like you'd have to download and run a hacked installer that was never avaliable from an official location. That is a much lower risk than a supply-chain attack where anyone building birwarden-cli from the official repo would be infected via the compromised dependency.

Long term keepass users aren't going to be affected. If you mention software to others make sure you send them a link to a known safe download location instead of having them search for one (as new users searching like that are more at risk of stumbling on a malicious copy of the official site hosting a hacked version).

This AI generated article is not about vulnerabilities in KeePass, rather about malicious KeePass clones.

I think most people use keepassxc, not original keepass.

Happy 1password user for more than a decade.

It's only a matter of time until _they_ are also popped :(.

That's an AI slop article. I'm not sure how someone creating their own installer and buying a few domains to distribute it is a mark against KeePass itself.

> The beacon established command and control over HTTPS

You save the single password in your head. All other passwords go inside Keepass.

What do you use?

Seamless syncing is the primary reason I stick with BW

Maybe language based package managers aren't great. Also, npm has design decisions that make it especially prone to supply chain attacks iirc

This is the break right now, we will smile back on these times

Where does it answer this question in the article?

kinda crazy to see this comment required in this particular context, yet here we are

The article waffles on forever and gives some generic advice.

Meanwhile, Bitwarden themselves state that end users were almost never affected: https://community.bitwarden.com/t/bitwarden-statement-on-che...

You had to install the CLI through NPM at a very short time frame for it to be affected. If you did get infected, you have to assume all secrets on your computer were accessed and that any executable file you had write access to may be backdoored.

No it doesn't?

Don't GitHub Actions actually use npm?

The above comment is just a bunch of generalizations not meant to address seriously that's why.