I use a separate dev user account (on macOS) for package installations, VSCode extensions, coding agents and various other developer activities.

I know it's far from watertight (and it's useless if you're working with bitwarden itself), but I hope it blocks the low hanging fruit sort of attacks.

> 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)?

Most of these attacks don't make it into the upstream source, so solutions[1] that build from source get you ~98% of the way there. If you can't get a from-source build vs. pulling directly from the registries, can reduce risk somewhat with a cooldown period.

For the long tail of stuff that makes it into GitHub, you need to do some combination of heuristics on the commits/maintainers and AI-driven analysis of the code change itself. Typically run that and then flag for human review.

[1] Here's the only one I know that builds everything from source: https://www.chainguard.dev/libraries

(Disclaimer: I work there.)

> 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)?

With pnpm, you can also use trustPolicy: no-downgrade, which prevents installing packages whose trust level has decreased since older releases (e.g. if a release was published with the npm cli after a previous release was published with the github OIDC flow).

Another one is to not run post-install scripts (which is the default with pnpm and configurable with npm).

These would catch most of the compromised packages, as most of them are published outside of the normal release workflow with stolen credentials, and are run from post-install scripts

Cooldowns are passing the buck. These are all caught with security scanning tools, and AI is probably going to be better at this than people going forward, so just turn on the cooldowns server-side. Package updates go into a "quarantine" queue until they are scanned. Only after scanning do they go live.

The problem with cooldowns is that the more people use them, the less effective they become.

Haha what if there's an urgent security fix in an updated package?

> A password manager does not need a CLI tool.

A password manager absolutely does need a CLI tool??

I seems like we need better standard libraries, but standard libraries turn into tarpits. I sort of like the way python's stdlib works.

I guess anyone/anything using a non-graphical interface should just not use a password manager for some reason?

Not to mention that a graphical application is just as vulnerable to supply chain attacks.

> A password manager does not need a CLI tool.

That's a wild statement. The CLI is just another UI.

The problem in this case is JS and the NPM ecosystem. Go would be an improvement, but complexity is the enemy of security. Something like (pass)age is my preference for storing sensitive data.

Yeah Im going to have to agree with this

This + vaultwarden is an awesome self-hostable rust version of bitwarden. We might as well close the loop!

Oh nice it works as an ssh-agent too. Definitely checking this one out.

Use the desktop or web vault directly, don't use the browser plugin.

How to prevent it?

tl;dr

- https://cooldowns.dev

- https://depsguard.com

(disclaimer: I maintain the 2nd one, if I knew of the first, I wouldn't have released it, just didn't find something at that time, they do pretty much the same thing, mine in a bit of an overkill by using rust...)

"Discretion is the better part of valor", "Never point it at your own feet", "Russian roulette is best enjoyed as a spectator", and many other sayings seem applicable.

Smells like blackmail from another nation..

That isn't a smoking gun. I think it was the Vault7 leaks which showed that the NSA and CIA deliberately leave trails like this to obfuscate which nation state did it. I'm sure other state actors do this as well, and it's not a particularly "crazy" technique.

It’s the new Npm

Why not stick to simple/heavily vetted password managers (like keepassx)? is there some advanced feature you use?

> A password manager does not need a CLI tool.

Why not? Even macos keychain supports cli.

"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...)

care to elaborate?

Well.. https://github.com/doy/rbw/blob/main/Cargo.toml#L16

You're still pulling a lot of dependencies. At least they're pinned though.

I love how the first comment is a complain having nothing to do with the actual subjec

I thought that CLI would be efficent when I looked for using it and then I figured it is JavaScript

Wow. Thats crazy. Is there an extension for bwcli in weechat? BTW I didnt even know BW had a cli until now. I use keepass locally.

Integration points increase the risk of compromise. For that reason, I never use the desktop browser extensions for my password manager. When password managers were starting to become popular there was one that had security issues with the browser integration so I decided to just avoid those entirely. On iOS, I'm more comfortable with the integration so I use it, but I'm wary of it.

We need cooldowns everywhere, by default. Development package managers, OS package managers, browser extensions. Even auto-updates in standalone apps should implement it. Give companies like Socket time to detect malicious updates. They're good at it, but it's pointless if everyone keeps downloading packages just minutes after they're published.

> What can I do to prevent it?

My two most precious digital possessions - my email and my Bitwarden account - are protected by a Yubikey that's always on my person (and another in another geographical location). I highly recommend such a setup, and it's not that much effort (I just keep my Yubikey with my house keys)

I got a bit scared reading the title, but I'm doing all I can to be reasonably secure without devolving into paranoia.

You should use hunter2 as your password on all services.

That password cannot be cracked because it will always display as ** for anyone else.

My password is *****. See? It shows as asterisks so it's totally safe to share. Try it!

... Scnr •́ ‿ , •̀

The worst thing is that you can't even tell if that's "real" or just a false flag.

ah yes, because everyone sets locale on their npm publish github CI job.

obvious misdirection, but it does serve to make it very obvious it was a state actor.

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 need my passwords to be accessible from my infrastructure and my phone. How do you achieve this with KeePass? I assumed it was not possible, but in fairness, I haven't really gone down that rabbit hole to investigate.

Which is great for Hacker News users that can maintain their own infra. But if we're talking "stress free", that's not an answer for the average user...

Ok, single file, blah, blah. Realistically how do you sync that and how do you resolve conflicts? What happens if two devices add a password while offline, then go online?

> KeePass users continue to live the stress free live.

https://cyberpress.org/hackers-exploit-keepass-password-mana...

the only thing I can't find to do with keepass is how back up it in the cloud, like if you encrypt your back up, then where do you save that password, then where do you save the password for the cloud provider?.

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

Don't GitHub Actions actually use npm?

Seamless syncing is the primary reason I stick with BW

There are so many ways to self-host package repos that "immediate availability" to the wider npm-using public is a non-issue.

Exceptions to quarantine rules just invites attackers to mark malicious updates as security patches.

If every kind of breakage, including security bugs, results in a 2-3 hour wait to ship the fix, maybe that would teach folks to be more careful with their release process. Public software releases really should not be a thing to automate away; there needs to be a human pushing the button, ideally attested with a hardware security key.

Install tools using a package manager that performs builds as an unprivileged user account other than your own, sandboxes builds in a way that restricts network and filesystem access, and doesn't run let packages run arbitrary pre/post-install hooks by default.

Avoid software that tries to manage its own native (external, outside the language ecosystem) dependencies or otherwise needs pre/post-install hooks to build.

If you do packaging work, try to build packages from source code fetched directly from source control rather than relying on release tarballs or other published release artifacts. These attacks are often more effective at hiding in release tarballs, NPM releases, Docker images, etc., than they are at hiding in Git history.

Learn how your tools actually build. Build your own containers.

Learn how your tools actually run. Write your own CI templates.

My team at work doesn't have super extreme or perfect security practices, but we try to be reasonably responsible. Just doing the things I outlined above has spared me from multiple supply chain attacks against tools that I use in the past few weeks.

Platform, DevEx, and AppSec teams are all positioned well to help with stuff like this so that it doesn't all fall on individual developers. They can:

  - write and distribute CI templates
  - run caches, proxies, and artifact repositories which might create room to
    - pull through packages on a delay
    - run automated scans on updates and flag packages for risks?
    - maybe block other package sources to help prevent devs from shooting themselves in the foot with misconfiguration
  - set up shared infrastructure for CI runners that
    - use such caches/repos/proxies by default
    - sandbox the network for build$
    - help replace or containerize or sandbox builds that currently only run on bare metal on some aging Jenkins box on bare metal
  - provide docs
    - on build sandboxing tools/standards/guidelines
    - on build guidelines surrounding build tools and their behaviours (e.g., npm ci vs npm install, package version locking and pinning standards)
  - promote packaging tools for development environments and artifact builds, e.g.,
    - promote deterministic tools like Nix
    - run build servers that push to internal artifact caches to address trust assumptions in community software distributions
    - figure out when/whether/how to delegate to vendors who do these things

I think there's a lot of things to do here. The hardest parts are probably organizational and social; coordination is hard and network effects are strong. But I also think that there are some basics that help a lot. And developers who serve other developers, whether they are formally security professionals or not, are generally well-positioned to make it easier to do the right thing than the sloppy thing over time.

Maybe using a slower, stable package manager that still gets security/bug fixes, like nix.

Yeah, I should work on avoiding that word.

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

Renovate can do it as well

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

I hope you're not using KeePassX, it's been unmaintained for years. KeePassXC is only available for Linux, which means I'd need to use a third-party app for Mac and iOS, so I'd be trusting three vendors instead of one.

Aside from passwords, I store passkeys, secure notes, and MFA tokens.

Yep! depsguard sets trustPolicy: "no-downgrade" where applicable.

The approach you outline is totally compatible with an additional one or two day time gate for the artifact mirrors that back prod builds. Deploy in locked-down non-prod environments with strong monitoring after the scans pass, wait a few days for prod, and publicly report whatever you find, and you're now "doing your part" in real-time while still accounting for the fallibility of your automated tools.

There's risk there of a monoculture categorically missing some threats if everyone is using the same scanners. But I still think that approach is basically pro-social even if it involves a "cooldown".

The hypothesis you're referring to is something like "if everyone uses a 7-day cooldown, then the malware just doesn't get discovered for 7 days?", right?

An alternative hypothesis: what if 7-day cooldowns incentivize security scanners, researchers, and downstream packagers to race to uncover problems within an 7-day window after each release?

Without some actual evidence, I'm not sure which of these is correct, but I'm pretty sure it's not productive to state either one of these as an accepted fact.

Well, luckily, those who find the malicious activity are usually companies who do this proactively (for the good of the community, and understandably also for marketing). There are several who seem to be trying to be the first to announce, and usually succeed. IMHO it should be Microsoft (as owners of GitHub, owners of npm) who should take the helm and spend the tokens to scan each new package for malicious code. It gets easier and easier to detect as models improve (also gets easier and easier to create, and try to avoid detection on the other hand)

That was my first instinct as well but I'm not sure how true it really is.

Many companies exist now whose main product is supply chain vetting and scanning (this article is from one such company). They are usually the ones writing up and sharing articles like this - so the community would more than likely hear about it even if nobody was actually using the package yet.

Build from source is a great idea, I assume you provide SLSA/sigstore like provenance as well?

Yep, that's the main argument against cooldowns, but there are ways to override them. I'll update the docs soon.

I use MacOS and iOS for home home devices and Windows for work, and use Strongbox on the Apple side with KeePassXC on the Windows side and sync them using DropBox.

For me it is nextcloud + wireguard

Someone is about hop on and tell you how they simply run a Dropbox/GDrive to host their keepass vault and how that’s good enough for me (which should be Keepass’s tagline) and mobile they use a copy or some other manually derived and dependency ridden setup. They will support ad hoc over designed because their choice of ad hoc cloud is better than a service you use.

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.

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.

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 actually was a Bitwarden user at first, but over time in reality the frequency that I change email/password is not that much. It's not like I change those things every hour or every day like with my work files/documents and need constant syncing to the drive. And the chance that I add/change passwords at 2 devices at a close time is even less.

So gradually I don't feel I need syncing that much any more and switched to Keepass. I made my mind that I'll only change the database from my computer and rclone push that to any cloud I like (I'm using Koofr for that since it's friendly to rclone) then in any other devices I'll just rclone pull them after that when needed. If I change something in other devices (like phones), I'll just note locally there and change the database later.

But ofc if someone needs to change their data/password frequently then Bitwarden is clearly the better choice.

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.

Happy 1password user for more than a decade.

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

I think most people use keepassxc, not original keepass.

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.

Same as Bitwarden? You just need to remember Keepass password, just like remember Bitwarden password.

I have family I need to support, so I use 1password. It also helped that work gives me a 1P family plan free.

The practical differences to me:

    * 1P is aimed at non-tech users more than Bitwarden.
    * 1P lets you easily store things other than just passwords (serial #'s, license info, SSN's, etc) You can in Bitwarden, but it's a little annoying.
    * 1P lets you store SSH keys(by effectively being an ssh-agent): https://developer.1password.com/docs/ssh/

All that said, I still happily recommend BW, especially for people that are cost-conscious, the free BW plan is Good Enough for most everyone.

Security wise, they are equivalent enough to not matter.

It's an understandable question, the article reads like an AI generated mess.

I think the rest of your analysis is correct! I'm only pushing back on perceptions that we can get there trivially; I think people often (for understandable reasons) discount the social and technical problems that actually dominate modernization efforts in open source packaging.

Yep, depsguard has support for renovate and dependabot cooldown settings too.

Github has had some recent uptime issues

https://mrshu.github.io/github-statuses/

This is one reason why we have lock files / version pinning

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.

Yes it does, under technical analysis. I don’t want to paste it here when it’s laid out in the article…

So the comparison here is that you would rather trust a password manager with a CLI that imports hundreds of third-party dependencies over a first party password manager with a CLI that comes with the OS?

I don't think macOS Keychain uses NPM and it isn't in TypeScript or Javascript and, yes it does not need a CLI either.

The NPM and Java/Typescript ecosystem is part of the problem that encourages developers to import hundreds of third-party libraries, due to its weak standard library which it takes at least ONE transitive dependency to be compromised and it is game over.

That’s my concern too. Rust has the same dependency concerns, which is how hackers get into code. VaultWarden has the same Rust dependency concern. Ironically we’re entering an age where C/C++ seems to have everything figured out from a dependency injection standpoint

Other package managers are magically immune?

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.

The flaw of the cooldown solution speaks for itself.

The chainguard folks built sigstore :)

For a given tool, I'd expect the Rust version to have even more deps than the JS version because code reuse is more important in a lower-level language. I get the argument that JS users are on average less competent than Rust users, but we're talking about authors who build serious tools/libs in the first place.

Node deps are pinned: https://docs.npmjs.com/cli/v8/configuring-npm/package-lock-j...

The problem is that you also want to update deps.

Where's the evidence that 1024kb's issue had anything to do with bw? How is that vaguely recalled anecdote a trust issue with bw? It was probably caused by accidentally copying something to the clipboard or some other buffer which was then transferred via ssh and imported into weechat, possibly with the help of custom terminal, ssh, tmux, or weechat settings making it too easy for data to be slung around like that.

I can't think of a plausible explanation for how bw is at fault for its terminal output ending up, across a ssh session and tmux invocation, in the chat history of weechat. Even if bw auto-copied its output to the clipboard (which as far as I could tell by glancing at the cli options, it doesn't and can't), and the clipboard is auto-copied to remote hosts, clipboard contents shouldn't appear in an irc client's history without explicit hacking to do that.

The claim is just noise, particularly because it doesn't seem to have ever been investigated.

It seems prudent, if someone wants to use a cli, to use rbw rather than bw, or even just pass or keypassxc-cli (and self-managed cloud backup or syncing). However, that's based on bw being a javascript mess, not based on the unlikely event of bw injecting its output through ssh into irc clients.

Importantly IMO is the extra phishing protection that the UX is really nice if and only if the url matches what's expected. If you end up on a fake url somehow, it's a nice speed bump that it doesn't let you auto-fill to make you think, hold on, something is wrong here.

If you're used to the clunkier workflow of copy-pasting from a separate app, then it's much easier to absent-mindedly repeat it for a not-quite-right url.

Also, you want to avoid exposing your passwords through the clipboard as much as possible.

These vulnerabilities are all caught by scanners and the packages are taken down 2-3 hours after going live. Nothing needs to take 7 days, that's just a recommendation. But maybe all packages should be scanned, which apparently only takes a couple of hours, before going live to users?

X is the worst place to hold community discussions.

I think they mean to secure your most valuable accounts with a hardware token rather than in a normal password manager, so they aren't at risk if your password manager has an issue.

It's a hard decision, I would say a cooldown by default in the last few months would have prevented more attacks than not upgrading to the latest version due to an immediate RCE, zero-click, EPSS 100%, CVSS 10.0, KEV mentioned Zero Day CVE. But now that the Mythos 90 days disclosure window gets closer, I don't know what tsunami of urgent patches is in our way... it's not an easy problem to solve.

I lean toward cooldown by default, and bypass it when an actual reachable exploitable ZeroDay CVE is released.

I think this is the real news. There seems to be an ongoing attack against Checkmarx.

That thing is expensive as he'll and used by lots of huge corps. I know at least one very large one in Mexico ... where the IT team is pretty useless.

So, I dont doubt the possibility that in the short future we will hear about more hacks.

Nobody inspects packages after install, your theory has been debunked multiple times, caring about npm install running scripts is moot when you’ll inevitably run the actual binary after install.

And besides, you could always pull the package and inspect before running install, which unless you really know the installer and understand/know guarantees deeply (e.g., whether it’s possible for an install to deploy files outside of node_modules) it’s insane to even vaguely trust it to pull and unpack potentially malicious code.

Use a package repository that fast-tracks security updates, like Debian Stable.

Most other password managers have a cloud component so if your local storage breaks or gets lost you don't lose all your passwords.

It seems to be describing what the Checkmarx vulnerability allows to be done on a GitHub Actions runner?

`bw list` shows plaintext credentials in the CLI https://bitwarden.com/help/cli/#list

I know this because I had the same surprised reaction

> importing hundreds of third-party packages

But how else are you going to check if a number is even or odd? Remember, the ONLY design goal is not repeating yourself (or in fact anything anyone has ever thought of implementing).

Top comment has a great explicit refutation:

> This plan works by letting software supply chain companies find security issues in new releases. Many security companies have automated scanners for popular and less popular libraries, with manual triggers for those libraries which are not in the top N.

that's our future... with AI. Engineers that don't know the difference between client-side convenience and server-side injection, how to configure `php.ini`, or that no synchronized password manager is safe. While the OAuth scope is `*`, and CORS is what you drink on the weekend.

I also find it far easier to resist accidentally entering credentials in a phishing site... I'm pretty good about checking, but it's something I tend to point out to family and friends to triple check if it doesn't auto suggest the right site.

The 1Password mobile and desktop apps have such a nice UX that I’m happy copy pasting from and into it instead of having any of the browser extensions enabled.

I have 1Password configured to require password to unlock once per 24 hours. Rest of the time I have it running in the background or unlock it with TouchID (on the MacBook Pro) or FaceID (on the iPhone).

It also helps that I don’t really sign into a ton of services all the time. Mostly I log into HN, and GitHub, and a couple of others. A lot of my usage of 1Password is also centered around other kinds of passwords, like passwords that I use to protect some SSH keys, and passwords for the disk encryption of external hard drives, etc.

https://cooldowns.dev/#javascript-ecosystem ;-)

How is the quality of browser extensions compared to Bitwarden?

My point is that it could still be Russia, as they know that we know it is used as a false flag.

I rely on this too, but counting down the days android no longer lets syncthing touch another app's files :(

What happens if you add a new item on two devices simultaneously?

"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.

We should be encouraging those users to switch to a password manager.

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

It's better, but calling it so much better [that it's unreasonable to forgo the browser extension] is a bit silly to me.

1. Go to website login page

2. trigger the global shortcut that will invoke your password manager

3. Your password manager will appear with the correct entry usually preselected, if not type 3 letters of the site's name.

4. Press enter to perform the auto type sequence.

There, an entire class of exploits entirely avoided. No more injecting third party JS in all pages. No more keeping an listening socket in your password manager, ready to give away all your secrets.

The tradeoff? You now have to manually press ctrl+shift+space or whatever instead when you need to log in.

KeePassXC is cross-platform, unsure about iOS.

Exactly. Same principle of passkeys, Yubikeys and FIDO2. Much harder to phish because the domains have to match.

I’m impressed with their feature to add the URL for next time, after manually filling on an unmatched URI. Hairs raised on neck clicking confirm though.

I don't have any points of comparison since I've never used Bitwarden, but it works well enough for my purposes. It'll match the url, offer to autofill (sometimes those multiflow sites like Microsoft will trip it up, but you can always just right click -> enter username/password for a site and that'll work), and it does TOTP filling too.

Love it, I'll link to it!

I never enjoyed the Android syncthing experience, so I just plug my phone in once a month and manually copy the vault over. I don't ever edit on my phone, so I don't need two-way syncing.

It renames one of them to $hostname_conflicted, or something like that. Keepass has a built in tool for reconciling two databases, you can use that in this scenario.

It would be strange if Android locked that down further than even iOS - Keepassium on iOS can open files from any sync app IIRC

I do when I can, but there's a learning curve, and the rest of the world is trying to move those users in a very different direction (passkeys and other bullshit).

Password habits for many people are now decades-old, and very difficult to break.

Now all they need to figure out is how to actually make the C/C++ code that isn't from dependencies secure and they'll be all set

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.

yes obviously.

isn't it obvious?

it should be obvious.

why isn't obvious?

Even with ^ you won't get an updated version until somebody runs an install and updates the lockfile.

We have things like dependebot for this.

https://docs.github.com/en/code-security/tutorials/secure-yo...

At this point, the risk of a compromised package outweighs the risk of an upstream vuln that actually matters. Npm audit is full of junk like client side redos vulns, you could probably ignore 90%+ of the reports and still be secure against the majority of of-concern attack classes.

Yep yep, hence the ask, expected for containers, wondering if also for build from source.

Can someone explain why people struggle with CORS?

The full strength of the SOP applies by default. CORS is an insecurity 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 to CORS.

> The 1Password mobile and desktop apps have such a nice UX that I’m happy copy pasting from and into it instead of having any of the browser extensions enabled.

Also a great way of missing out on one of the best protections of password managers; completely eliminating phishing even without requiring thinking. And yes, still requires you to avoid manually copy-pasting without thinking when it doesn't work, but so much better than the current approach you're taking, which basically offers 0 protection against phishing.

My point is; what changes if we knew for a fact it was Russia or that it was someone else?

They are not, but npm is uniquely bad in that regard. Refusal to implement security features that would have made attacks like this harder really doesn't help https://github.com/node-forward/discussions/issues/29

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

Still it's something like a second factor (or even, literally, overriding might require 2FA).

We've had all those well before AI.

> no synchronized password manager is safe

Care to elaborate? I'd agree that the security/availability tradeoff is different, but "not safe" is as nonsensical a blanket statement as "all/only offline/paper-based/... password managers are safe".

for most people, nothing.

for threat intel people, a lot.

The tradeoff is that you need to know how to setup a global shortcut or even know it's even possible. I wish people would stop minimizing the knowledge they have as something everyone just knows.

Sorry, you're right, I missed the tabs on top. No iOS support though.

How do you set up this shortcut? I'd prefer to get rid of extensions, if for no better reason than sometimes it switches to my work profile and I have to re-login

> You initially complained about CLIs, not the dependency mess of the JS ecosystem.

I complained about both. What does this say from the start?

>> Once again, it is in the NPM ecosystem.

> You still have not said why this is an issue of having a CLI.

Why do you need one? Automation reasons? OpenClaw? This is an attractive way for an attacker to get ALL your passwords in your vault. The breach itself if run in GitHub Actions would just make it a coveted target to compromise it which makes having one worse not better and for easier exfiltration.

So it makes even more sense for a password manager to not need a CLI at all. This is even before me mentioning the NPM and the Javascript ecosystem.

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.

My approach is that for critical sites like banking, I use the site URL stored in the password manager too, I don't navigate via any link clicking. I personally am fine with thinking when my entire net worth is potentially at stake.

>My point is; what changes if we knew for a fact it was Russia or that it was someone else?

Is this a serious question?

In Safari on iOS I have all the main pages I use as favourites, so that they show on the home screen of Safari.

Likewise I have links in the bookmarks bar on desktop.

I use these links to navigate to the main sites I use. And log in from there.

I don’t really need to think that way either.

But I agree that eliminating the possibility all-together is a nice benefit of using the browser integration, that I am missing out on by not using it.

>Why do you need one? Automation reasons? OpenClaw? This is an attractive way for an attacker to get ALL your passwords in your vault.

I need one because I am not always using a graphical interface. What exactly in a GUI do you think makes it harder/less attractive for an attacker?

If the GUI code is compromised in the same way as the CLI, it'll have the same level of access to your vault as soon as you enter your master password, exactly the same as in the CLI.

Which works great until tags.tiqcdn.com, insuit.net or widget-mediator.zopim.com (example 3rd party domains loaded when you enter the landing page from some local banks) get compromised. I guess it's less likely to happen with the bigger banks, my main bank doesn't seem to load any scripts from 3rd party as an counter-example. Still, rouge browser extensions still scare me, although I only have like three installed.

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).

It's not only about how you get there, but that the autofill shows/doesn't show, which is the true indicator (beyond the URL) if you're in the right place or not.

Rouge browser extensions for example could redirect you away from the bank website (if the bank website has poor security) when you go there, so even if you use the URL from the password manager, if you don't use the autofill feature, you can still get phished. And if the autofill doesn't show, and you mindlessly copy-paste, you'd still get phished. It's really the autofill that protects you here, not the URL in the password manager.

A patch updates is a newer version, and they are just as likely to be compromised by supply chain attacks as minor or major updates.

The lack of a comprehensive standard library for JavaScript also results in projects pulling many more third party dependencies than you would with most other modern environments. It’s just a bigger attack surface. And if you can compromise a module used for basic functionality that you’d get out of the box elsewhere, the blast radius will be enormous.

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

Who is 'you' here? All of the npm package maintainers?

Yes, if they all just backport security patches we'll be fine. No, people are not going to just.

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

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

If you have rogue browser extensions installed, the browser extension can surely read the values that got filled into the login page without having to redirect to another site.

I doubt Microsoft's kernel/system Rust code is pulling in a lot of crates. The Linux kernel sure isn't, and Android's Bluetooth stack doesn't seem to either.

Using crates is a choice. You can write fully independent C++ or you can pull in Boost + Qt + whatever libraries you need. Even for C programs, I find my package manager downloading tons of dependencies for some programs, including things like full XML parsers to support a feature I never plan to use.

Javascript was one of the first languages to highlight this problem with things like left-pad, but the xz backdoor showed that it's also perfectly possible to do the same attack on highly-audited programs written in a system language that doesn't even have a package manager.

Same here.

Not necessarily, a user could have accepted a permission request for some (legit) redirect extension that never asked for content permission, then when the rogue actor takes over, they want to compromise users and not change the already accepted permissions.

Concretely, I think for redirect browser extension users I'd use "webRequest" permission, while for in page access you'd need a content-script for specific pages, so in practice they differ in what the extension gets access to.

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.

Not to mention a culture of basically one-line packages ad infinitum. I downloaded a JS tool the other day to generate test reports and it had around 300 dependencies.

Needless to say I’m running all my JS tools in a Docker container these days.

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.

What exactly would you have done differently?

Cargo made its debut in 2014, a year before the infamous left-pad incident, and three years before the first large-scale malicious typosquatting attacks hit PyPI and NPM. The risks were not as well-understood then as they are today. And even today it is very far from being a solved problem.

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 really don't think it matters.

Not exactly.

Security patches aren't like bugs or features where you can just roll a new version. Often patches need to be backported to older versions allowing software and libraries to be "upgraded" in place with no other change introduced.

Say you had software that controlled the careful mix of chemicals introduced into a municipal water supply. You just don't move from version 1.4 to 3.2, you fix 1.4 in place.

So why hasn’t someone created a batteries include JS library? I don’t program in JS on the backend so I don’t know how feasible something like that is.

Yet Go is half a decade older and seems to have handled the situation much better.

Rust and Cargo are, if not inseparable, at least tightly connected. Rust and Rust's stdlib are inseparable.

Cargo is modeled after NPM. It works more or less identically, and makes adding thousands of transient dependencies effortless, just like NPM.

Rust's stdlib is pretty anemic. It's significantly smaller than node's.

These are decisions made by the bodies governing Rust. It has predictable results.

That's true. But it does seem like a logic result of having no real standard library. That lone fact has kept me away from Rust for real projects, because I don't want to pull in a bunch of defacto-standard-but-not-officially dependencies for simple tasks. That's probably a large contributor to the current state of dependency bloat.

No, you create version 1.4.19, which fixes a bug in 1.4.18.

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.

https://github.com/stdlib-js/stdlib was is one of several attempts at that, but yes the issue is that different people have very different views of what should be standard.

Everyone’s ideas of what batteries should be included differ

ohh noo, the devs gave users a choice instead of forcing their hand..

Yeah, it does require you to be meticulous about what you depend on. Personally I stick with libraries that don't use 100s of other crates, and tried and reviewed various libraries over the year, so you have your "toolkit" of libraries you know are well built and you know how they work internally.

Ultimately in any language you get the sort of experience you build for yourself with the environment you setup, it is possible in most languages to be more conservative and minimal even if the ecosystem at large is not, but it does require more care and time.

I think there's actually a decent compromise one could make here (not that Rust did, mind), and it's what I'm planning for my own language, in big part to avoid the Rust/NPM/etc situation.

TL;DR, the official libraries are going to be split into three parts:

---

1) `core.*` (or maybe `lang.*` or `$MYLANGUAGE.*` or w/e, you get the point) this is the only part that's "blessed" to be known by the compiler, and in a sense, part of the compiler, not a library. It's stuff like core type definitions, interfaces, that sort of stuff. I may or may not put various intrinsics here too (e.g. bit count or ilog2), but I don't know yet.

Reserved by the compiler; it will not allow you to add custom stuff to it.

There is technically also a "pseudo-package" of `debug.*` ("pseudo" in the sense that you must always use it in the full prefixed form, you can't import it), which is just going to be my version of `__LINE__` and similar. Obviously blessed by compiler by necessity, but think stuff like `debug.file` (`__FILE__`), `debug.line` (`__LINE__`), `debug.compiler.{vendor,version}` (`__GNUC__`, `_MSC_VER`, and friends). `debug` is a keyword, which makes it de-facto non-overridable by users (and also easy for both IDEs and compiler to reason about). Of course I'll provide ways of overriding these, as to not leak file paths to end users in release builds, etc.

(side-note: since I want reproducible builds to be the default, I'm internally debating even having a `debug.build.datetime` or similar ... one idea would be to allow it but require explicitly specifying a datetime [as build option] in such cases, lest it either errors out, or defaults to e.g. 1970-01-01 or 2000-01-01 or whatever for reproducibility)

---

2) `std.*`, which is minimal, 100% portable (to the point where it'd probably even work in embedded [in the microcontroller sense, not "embedded Linux" sense] systems and such --- though those targets are, at least for now, not a primary goal), and basically provides some core tooling.

Unlike #1, this is not special to the compiler ... the `std.*` package is de jure reserved, but that's not actually enforced at a technical level. It's bundled with the language, and included/compiled by default.

As a rule (of thumb, admittedly), code in it needs to be inherently portable, with maybe a few exceptions here or there (e.g. for some very basic I/O, which you kind of need for debugging). Code is also required to have no external (read: native/upstream) dependencies whatsoever (other than maybe libc, libdl, libm, and similar things that are really more part of the OS than any particular library).

All of `std.*` also needs to be trivially sandboxable --- a program using only `core.*` & `std.*` should not be able to, in any way, affect anything outside of whatever the host/parent system told it that it can.

---

3) `etc.*`, which actually work a lot like Rust/Cargo crates or npm packages in the sense that they're not installed by default ..... except that they're officially blessed. They likely will be part of a default source distribution, but not linked to by default (in other words: included with your source download, but you can't use them unless you explicitly specify).

This is much wider in scope, and I'm expecting it to have things like sockets, file I/O (hopefully async, though it's still a bit of a nightmare to make it portable), downloads, etc. External dependencies are allowed here --- to that end, a downloads API could link to libcurl, async I/O could link to libuv, etc.

---

Essentially, `core.*` is the "minimal runtime", `std.*` is roughly a C-esque (in terms of feature count, or at least dependencies) stdlib, and `etc.*` are the Python-esque batteries.

Or to put it differently: `core.*` is the minimum to make the language run/compile, `std.*` is the minimum to make it do something useful, and `etc.*` is the stuff to make common things faster to make. (roughly speaking, since you can always technically reimplement `std.*` and such)

I figured keeping them separate allows me to provide for a "batteries included, but you have to put them in yourself" approach, plus clearly signaling which parts are dependency-free & ultra-sandbox-friendly (which is important for embedding in the Lua/JavaScript sense), plus it allows me to version them independently in cases of security issues (which I expect there to be more of, given the nature of sockets, HTTP downloads, maybe XML handling, etc).

'no real standard library' doesn't seem entirely fair. Rust has a huge standard library. What it does have is the policy to only include "mature" things with little expected API evolution in the standard libary, which leaves gaping holes where a json parser, a http client or a logging library should be. Those are all those defacto-standard-but-not-officially dependencies

Does the nsa really need that ? 99% of our services are hosted on American servers, which the nsa already has full access.

Why would you steal the key when you're already in the house ?

And for the high profile, like some Iranian scientist who has the code to something important, they wouldn't use things like bitwarden.

I really see no use case when the nsa would need access to your bitwarden vault.

> 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.

I, for one, root for AAA

That doesn't seem like it should be an issue in practice? Rather than a single standard library endorsed by the language stewards if the community at large converges on a small handful of "standard" solutions that seems like it would satisfy the security aspect of things.

Design decisions have predictable consequences. Large masses of people, who make up an ecosystem like the that of a programming language community, respond predictably to their environment. Each individual programmer has a choice, sure, but you can't just "individual responsibility" your way out of the predictable consequences of incentive structures.

Perhaps that’s just a sign Rust isn’t suitable for those type of projects.