There are a lot of other implementations of this idea that don't necessarily rely on trust-on-first-use. The securedrop team explicitly includes malicious JS served by the primary-domain in the threat-model and made WEBCAT[0] as an outcome of that research. Their article on webcrypto is much better than this one.
The solution obviously is to go out-of-band:
> When a user visits a website that has enrolled in WEBCAT, before the site can load the content is checked against a signed manifest to ensure that it has not been tampered with (more on enrollment later). If everything checks out, the page loads normally. If, however, any content does not match what’s expected, the page load is aborted and a warning is displayed, protecting the user from potentially malicious content before it can execute.
I wrote superbright to be able to force it: https://github.com/captn3m0/superbright (fork of BrightIntosh). The display does get hit after 10-15 minutes of this though.
> The problem of everchanging malware isn't fixable by global policies and global rulesets.
But it is an important tool that's missing in our toolbox. You could do most of the above, and still get pwned by a typo in an `npx` command. Capability based access management is not likely to land in any large package manager in the next few years, and we need solutions that work today.
I wrote this in response to the recent AUR attacks. The problem isn’t really too many dependencies - it is that most users cannot be auditing everything they install and we need mechanisms that help users where they are.
I audit my AUR pkg builds, and I would have likely caught any malware. But so would a Dependency Cooldown or a third-party threat feed. Package Managers should make it easy to build this tooling via hooks.
Aliases and pre-hooks are nowhere near the guarantees you want, that’s what I am arguing - not everything is invoked from a blessed shell. Safely-bump-does.sh is also impossibly hard to write because you are replicating _all of the work NPM does in transitive dependency resolution_. Unless you are re-generating the lock file from scratch - it isn’t safe. Just updating package.json isn’t sufficient for eg.
Author here - people are definitely looking at other places. This just happens to be where the attacks are, and gets disproportionate attention as a result.
Do you have examples of campaigns that weren’t flagged? Everything except xz had a 1 day window and Dependency Cooldowns are super effective against most campaigns for that reason.
I think the packaging ecosystem is varied enough that this should be left for the package managers to decide. Yarn allows dependency resolution and WebFetch overrides in its hooks for eg.
(Author here). I don’t really care _how and what you decide to do with it_, the post is about package managers giving users the ability to decide.
Dependency Cooldowns can be implemented with global hooks, git-commit-signing checks can be implemented, LLM-scans can be implemented, someone can run the code in a jail and use the eBPF logs to publish a threat feed.
Modern language packaging is also _source available_, and we have a huge leg up over traditional virus scans - we have the source code almost always. You can do amazing static analysis.
(Author here). It isn’t a matter of pre-install hooks. I don’t want known malware on my system irrespective of whether it runs at install-time or not. Pre-install hooks are going away in NPM, but we will have code injected in index.js next.
Modern package managers are not amenable to letting another script override its resolutions, and that is what needs fixing.
You can route an encrypted video stream through a server, same as messages. Zoom supports this as well now. You can’t do fancy stuff like transcoding at the server to support an older client, but WhatsApp dropped support for non-e2e really-old clients eons ago (Symbian and the like).
This was published in April, and we are far from consensus on what is “varnish”. Lots of distributions are now packaging vinyl and calling it varnish, some are pointing to the varnish repo instead (Fedora, Homebrew).
> I don't think there exist a password manager that is explicitly designed for a compromised/hostile device.
The crypto people tried this with hardware only password managers but they were too annoying. I have a halfway solution of using pass with Yubikey/GPG where each password decryption requires a touch. It does protect against the entire vault being decrypted at once and exfiltrated.
[ my public key: https://keybase.io/captn3m0; my proof: https://keybase.io/captn3m0/sigs/MrazMfyap5PnbYUKQhtqeLGfctJcwxsDB6Oo0t6ABxM ]
my email: [email protected]
meet.hn/city/in-Bengaluru
Socials: - github.com/captn3m0 - x.com/captn3m0 - t.me/captn3m0
Interests: Books, Cybersecurity, DevOps, Fintech, Open Source, Privacy, Web Development
---
hnchat:Z44vjhzI6AG5YXzEY5pD