KeePass users continue to live the stress free live. I've managed to avoid several security breaches in last 5 years alone by using KeePass locally on my own infra.
I don't understand how this solves the issue in this case. Bitwarden vaults were not compromised, there was a problem in a tool you used to access the secrets. What makes it impossible for KeePass access tools to have these issues?
> I don't understand how this solves the issue in this case.
I'd say since it is a local only tool, you don't really need to update it constantly provided you are a sane person that don't use a browser extension. It makes it easier to audit and yourself less at risk of having your tool compromised.
It doesn't have to be keypass though, it can be any local password management tool like pass[1] or its guis or simply a local encrypted file.
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…
But how do you know which one is good? If foo package sends out an announcement that v1.4.3 was hacked, upgrade now to v1.4.4 and you're on v1.4.3, waiting a week seems like a bad idea. But if the hackers are the one sending the announcement, then you'd really want to wait the week!
I love how the first comment is a complain having nothing to do with the actual subjec
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.
Probably terminal emulator is like iTerm2 and double click to select and copy to clipboard is feature.
Syncthing can synchronize Keepass files between devices quite well.
What happens if you add a new item on two devices simultaneously?
Why would you do that?
By the way, syncthing can manage conflicts by keeping one copy of the file with a specific name and date. You can also decide is one host is the source of truth.
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…
I like the idea of a cool down. But my next question is would this have been caught if no one updated? I know in practice not everyone would be on a cool down. But presumably this comprise was only found out because a lot of people did update.
Can someone explain why people struggle with CORS? The full strength of the SOP applies by default. CORS is an in security feature that relaxes the SOP. Unless you need to relax the SOP, you shouldn't be enabling CORS, meaning you shouldn't be sending an Access-Control-Allow-Origin header at all. If your front-end at www.example.com makes calls to api.example.com, then it's simple enough to just add www.example.com t…
IME, CORS is pretty straightforward in prod but can be a huge pain in dev environments, so you end up with lots of little hacks to get your dev environments working (and then one of those hacks leaks back into prod and now you have CORS problems in prod).
This. This is a result of not having proper environments and engineering practices in place and so the team or engineer is free to just wing it and add hacks around security best practices because the Security Team (tm) is elsewhere and they never understand the ask. They know PKI and certificates, access card identity, maybe Cisco for their "cyber security" but that's usually where it ends. Yet somehow, they are in charge of CORS and TLS and Sast/Dast scans and everything else that should be baked into the pipelines and process. Resulting in an engineer saying f'it and adding an `if localhost` hack or something. CORS is one example but there are many others in pretty much every area of security. OAuth, CORS, LDAP, Secrets, Hashing, TOTP, you name it. Each has a plethora of packages and libraries that can "do" the thing but it always becomes a hairball mess to the dev because they never understood it to begin with.
"326 seems large, but not abnormal" was the state of JS in the past as well. Chance of someone auditing all of them is virtually zero, and in practice no one audits anything, so you are still effectively blindly trusting that none of those 326 got compromised.
It is baffling to me that a language that is as focused on safety/security as Rust decided to take the JavaScript approach to their ecosystem. I find it rather contradictory.
That's because you're mixing things. "Rust the language" isn't the one starting new projects and add new dependencies that have hundreds of dependencies of their own, this is the doing of developers. The developers who built Rust with a focus on safety and security is not the same developers mentioned before.
Sounds serious to me It's highly unlikely that the people behind an attack like this would come out (non-anonimously) and take credit. And it's unlikely they'll be caught. So does it matter to most peoplee if it's Russians, Americans, Iranians, North Koreans, or some other country? If you're a 3-letter agency, you'd want to know and potentially arrest them, but as a random guy on the internet, or even a maintainer, I…
So if it came out that the NSA was attempting to put backdoors in consumer password managers, it wouldn't change the context of the side channel attack? How about if it was a company (like Google)? It seemed like an unserious question because I can't understand how someone would think something like that wouldn't change the situation.
> So if it came out that the NSA was attempting to put backdoors in consumer password managers, it wouldn't change the context of the side channel attack?
Not really, we already know that NSA attempts shit like this all the time, if that came out, it'd be the same as the Snowden leaks meaning, a bunch of nerds going "Huh, who could have predicted this?". I don't see the point in it being Russia, China or the US, I'd like it as much if the US did it as Russia, so that's why I asked why it matters.
The issue was a compromised build pipeline that shipped a poisoned package. But PSA: If something is critical to the business and you’re using npm, pin your dependencies. I’ve had this debate with other devs throughout the years and they usually point to the lockfile as assurance, but version ranges with a ^ mean that when the lockfile gets updated, you can pull in newer versions you didn’t explicitly choose. If what…
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.