471–480 of 494 posts
Earlier quoted context omitted.
Nuget/.NET ecosystem just handles it so much better. Netvips assumes libvips is available and they provide packages for common platforms. No need to waste electricity rebuilding stuff, or install native build chains, build and test deps. Similar for Skia or Sqlite or whatever.
but how can you verify that the prebuilt binaries aren’t compromised?
One thing I've never understood is why NPM allows packages to run code immediately after they are installed. What's the use case for that? A package should just be some code you can call on at runtime
Earlier quoted context omitted.
Even if everyone used it, the security scanners would still have time to do their static analysis of new packages. Basically, all the clients implementing a delay would create a de facto quarantine status for new packages so they can be examined before everyone starts installing them. (Why npm doesn't just implement that themselves, I do not know.)
Then shouldn’t the analyzers just be part of NPMs acceptance requirements?
I guess it could work better if it was enabled for only actual attack vectors projects.
Qubes offers the strongest protection against these threats. It's surprising it isn't more commonly adopted.
The alternative proposal with "trusted" publishing is to grant all of GitHub's automated infrastructure the ultimate authority to publish things on your behalf automatically in a way that it is shown as being more "trusted" than the developer uploading it themselves! I'm honestly surprised that it took this long for supply-chain attackers to start targeting this obvious security hole -- I doubt any user of GitHub would argue that GitHub Actions are a parogon of security, and yet the strongly recommended deployment workflow for several language communities involved bolting it into the core of your release mechanisms! I think the OCID stuff is interesting and provides some nice properties but it doesn't prove that the GHA workload is actually trusted in the sense that "trusted publishing" means.
The arguments for adding speed bumps to auto-applying updates apply just as much to adding speed bumps to doing releases (arguably even more so -- even rapidly evolving libraries don't have hundreds of releases a week). Automating everything to the nth degree just expands the blast radius when stuff like this happens.
I do all runc releases manually and sign them with a PGP key stored in a hardware token that requires a pin for every signature attempt. Yes, it's a bit more cumbersome but it certainly would be harder to supply-chain hundreds of projects of every maintainer would need to manually publish them. For some other projects that need to publish to crates.io or PyPI I was honestly a little dismayed at how prominently they push for "trusted" publishing and how little support there is for making the "dumb" publishing flow more secure (they even visually display such releases as less trusted, and the only way to get more green checkmarks is to let GitHub take the wheel).
Earlier quoted context omitted.
I don't understand why you're confident that those Github issues won't just end up coming later if literally everyone adds this cooldown
The security companies looking for and reporting the issues aren't going to use the cooldown too.
Earlier quoted context omitted.
As an embedded dev who’s used to locking to toolchains and deps for years at a time, web dev is a culture shock in so many ways.
I once worked in a project that vendored most of its third-party dependencies, it was a culture shock at first, but damn, after a while it was so nice being able to work just by building from local source, with normal tooling like `make`, instead of pulling a shitton of deps from the outside world. Made me realize how much "webdev culture" did a disservice to software engineering as a whole.
Generally you can also configure rules in your internal package cache about what to do if a package is missing from the cache/hasn't been pulled yet. They also commonly integrate automaticaly CVE tracking and pull statistics so they give a nice "heads up" what everyone is using even if it's a local PoC
As an added bonus, they can also lower bandwidth bills like in expensive cloud environments when you can co-locate the proxy close to CI/build machines.
Earlier quoted context omitted.
A friend of mine has a github repo with references to how to set things up in sane and slightly more secure manner: https://github.com/jordanconway/package-manager-hardening
From that repo: > Exact version pinning — specifying precise versions (1.0.0, ==1.0.0, =1.0.0, = 5.31.0) rather than ranges (^, ~>, >=) in package manifests. Ranges allow any version satisfying the constraint to be resolved at install time; exact pins mean only one version is ever valid. My understanding is that pinning the dependency within the manifest isn't the mechanism that prevents the version from changing acr…
You end up with ancient dependencies because you add friction to periodic refreshes instead of running `package-manage refresh-lockfile` (whatever the relevant command is for your package manager)
Just some suggestions: 1. Dependency cooldowns of 1-2 days seem to be extremely effective without negatively impacting your ability to patch for CVEs. 2. Anywhere you have `npm install` or `npm test` or anything where code executes , that should happen in an environment that has no privileges. In your github actions you can do this semi-straightforwardly by using two separate jobs - one to build the artifacts and tes…
> anything where code executes ALL the agentic orchestrators like codex, claude-code, etc. seem to do this by default.