Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.

 help



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

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


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


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


It does not much matter if it imports 300 or 30 of them, those vulns will land somewhere in those 30 with equal frequency statistically. If you are advocating developing without dependencies at all, then please start (with any language) and show us all how much you actually ship.

JS is a target of these dumb accusations because it's literally the best cross-platform way to ship apps. Stop inventing issues where there are none.


> It does not much matter if it imports 300 or 30 of them, those vulns will land somewhere in those 30 with equal frequency statistically.

The point is the risk is far higher with more dependencies as I said from the very start. But it happens much more frequently in the NPM ecosystem than in others.

> If you are advocating developing without dependencies at all, then please start (with any language) and show us all how much you actually ship.

The languages in the former (especially Go) encourages you to use the standard library when possible. Javascript / TypeScript does not and encourages you to import more libraries than you need.

> JS is a target of these dumb accusations because it's literally the best cross-platform way to ship apps. Stop inventing issues where there are none.

Nope. It is a target because of the necessity for developers to import random packages to solve a problem due to its weak standard library and the convenience that comes with installing them.

You certainly have a Javascript bias towards this issue yourself and there is clearly a problem and you ignoring it just makes it worse.

If it wasn't an issue, we would not be talking about yet another supply chain attack in the NPM ecosystem.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: