Whats the most full proof way of defending ourselves from such attacks? My opinion is that the applications should never deal with credentials at all. Sidecars can be run which can inject credentials in real time. These sidecars can be under tight surveillance against such attacks. After all, application code is the most volatile in an organization.
Shai-Hulud Returns: Over 300 NPM Packages Infected
701–710 of 797 posts
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#702Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#703Earlier quoted context omitted.
An example: Java Maven artifacts typically name the exact version of their dependencies. They rarely write "1.2.3 or any newer version in the 1.2.x series ", as is the de-facto standard in NPM dependencies. Therefore, it's up to each dependency-user to validate newer versions of dependencies before publishing a new version of their own package. Lots of manual attention needed, so a slower pace of releases. This is a…
> An example: Java Maven artifacts typically name the exact version of their dependencies. They rarely write "1.2.3 or any newer version in the 1.2.x series" You can definitely do this. To be honest, you just end up with the same thing via dependabot/renovate.
You can specify a dependency version range in Maven artifacts. But the Maven community culture and default tooling behaviour is to specify exact versions.
You can specify an exact dependency version in npm packages. But the npm community culture and default tooling behaviour is to specify version ranges.
Even if a maintainer uses a bot to bump dependency versions, most typically they will test if their package works before publishing an updated version, and also because this release work is manual (even if the bot helps out), it takes some time after the dependency is released for upstream consumers of it to endorse and use it. Therefore, nobody consuming foo 1.0.4 will use dependency bar 2.3.5 until foo 1.0.5 is released... whereas an npm foo 1.0.4 with bar dependency "^2.3.0" will give its users bar 2.3.6 from the very moment bar 2.3.6 is released, even without a foo 1.0.5 release.
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#704Earlier quoted context omitted.
You forgot to mention it is also tied to provable namespaces. People keep saying that NPM is just the biggest target... Hate to break it to you but from targeting enterprises, java maven artifacts would be a MASSIVE target. It is just harder to compromise because NPM is such shit.
Maven Central verifies the domain used for the package namespace, too. You need to create a DNS TXT entry with a key. This adds a bit more overhead to typo squatting, and a paper trail, since a domain registrar can have identity/billing information subpoenaed. Versus changing a config file and running a publish command...
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#705Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#706https://about.gitlab.com/blog/gitlab-discovers-widespread-np...
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#707Earlier quoted context omitted.
It's not "node" or "Javascript" the problem, it's this convenient packaging model. This is gonna ruffle some feathers, but it's only a matter of time until it'll happen on the Rust ecosystem which loves to depend on a billion subpackages, and it won't be fault of the language itself. The more I think about it, the more I believe that C, C++ or Odin's decision not to have a convenient package manager that fosters a ca…
There are ecosystems that have package managers but also well developed first party packages. In .NET you can cover a lot of use cases simply using Microsoft libraries and even a lot of OSS not directly a part of Microsoft org maintained by Microsoft employees.
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#708Earlier quoted context omitted.
I think they were using "writing Rust" in the most strict sense: the part of the development cycle that involves typing the majority of the code, before you really start debugging in earnest and really make things work. But their point is that "developing Rust" (as in, the entire process) ends up being a similar total effort to C, only with more up front "writing" and less work on the debugging phase.
Thank you for the clarification, that's exactly what I was trying to say :). Perhaps another way to phrase this: in Rust, you spend more time telling the compiler how your code is expected to work (making the borrow checker happy, adding sync traits on objects you "know" are thread safe because of how you use them or assurances the underlying hardware provides, etc etc etc). In return, the compiler does a lot of work…
Because from here, it seems like they’re having a great time, which is extremely at-odds with your comment.
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#709([0-9a-z]{18})
Re: Shai-Hulud Returns: Over 300 NPM Packages Infected
#710ProTip: use PNPM, not NPM. PNPM 10.x shutdown a lot of these attack vectors. 1. Does not default to running post-install scripts (must manually approve each) 2. Let's you set a min age for new releases before `pnpm install` will pull them in - e.g. 4 days - so publishers have time to cleanup. NPM is too insecure for production CLI usage. And of course make a very limited scope publisher key, bind it to specific packa…
For Python ecosystem people: > Does not default to running post-install scripts (must manually approve each) To get equivalent protection, use `--only-binary=:all:` when running `pip install` (or `uv pip install`). This prevents installing source distributions entirely , using exclusively pre-built wheels. (Note that this may limit version ability or even make your installation impossible.) Python source packages are…
I do this by having my shell init do this:
export UV_EXCLUDE_NEWER=$(date -Iu -d "14 days ago")
That’s easy to override if you need to but otherwise seamless.