Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pnpm has a new setting to stave off supply chain attacks

pnpm.io

Post reply on HN
Print view View original

61–70 of 152 posts

Re: Pnpm has a new setting to stave off supply chain attacks

#61

Post by DougBTX »

mcintyre1994 wrote: post #29
anematode wrote: post #3

Earlier quoted context omitted.

A lot of people will still use npm, so they'll be the canaries in the coal mine :) More seriously, automated scanners seem to do a good job already of finding malicious packages. It's a wonder that npm themselves haven't already deployed an automated countermeasure.

In the case of the chalk/debug etc hack, the first detection seemed to come from a CI build failure it caused: https://jdstaerk.substack.com/p/we-just-found-malicious-code... > It started with a cryptic build failure in our CI/CD pipeline, which my colleague noticed > This seemingly minor error was the first sign of a sophisticated supply chain attack. We traced the failure to a small dependency, error-ex. Our packag…

> Our package-lock.json specified the stable version 1.3.2 or newer

Is that possible? I thought the lock files restricted to a specific version with an integrity check hash. Is it possible that it would install a newer version which doesn't match the hash in the lock file? Do they just mean package.json here?

Re: Pnpm has a new setting to stave off supply chain attacks

#62

Post by mcintyre1994 »

cap11235 wrote: post #52
mcintyre1994 wrote: post #33

Earlier quoted context omitted.

Nice, but I think the config file is a much better implementation for protecting against supply chain attacks, particularly those targeting developers rather than runtime. You don’t want to rely on every developer passing a flag every time they install. This does suffer from the risk of using `npm install` instead of `pnpm install` though. It would also be nice to have this as a flag so you can use it on projects tha…

You can put the uv setting in pyproject.toml or uv.toml.

Nice, supporting both definitely seems ideal.

Re: Pnpm has a new setting to stave off supply chain attacks

#63

Post by ramses0 »

mcintyre1994 wrote: post #33
the_mitsuhiko wrote: post #31

I think uv should get some credit for being an early supporter of this. They originally added it as a hidden way to create stable fixtures for their own tests, but it has become a pretty popular flag to use. This for instance will only install packages that are older than 14 days: uv sync --exclude-newer $(date -u -v-14d '+%Y-%m-%dT%H:%M:%SZ') It's great to see this kind of stuff being adopted in more places.

Nice, but I think the config file is a much better implementation for protecting against supply chain attacks, particularly those targeting developers rather than runtime. You don’t want to rely on every developer passing a flag every time they install. This does suffer from the risk of using `npm install` instead of `pnpm install` though. It would also be nice to have this as a flag so you can use it on projects tha…

Just Minimum Version Selection in conjunction with "Minimum non-Vulnerable Version" (and this "--minAge") would do a lot, and effectively suss out a lot of poorly/casually maintained packages (eg: "finished" ones).

https://research.swtch.com/vgo-mvs#upgrade_timing

MVS makes tons of sense that you shouldn't randomly uptake "new" packages that haven't been "certified" by package maintainers in their own dependencies.

In the case of a vulnerable sub-dependency, you're effectively having to "do the work" to certify that PackageX is compatible with PackageY, and "--minAge" gives industry (and maintainers) time to scan before insta-pwning anyone who is unlucky that day.

Re: Pnpm has a new setting to stave off supply chain attacks

#64

Post by streptomycin »

DougBTX wrote: post #61
mcintyre1994 wrote: post #29

Earlier quoted context omitted.

In the case of the chalk/debug etc hack, the first detection seemed to come from a CI build failure it caused: https://jdstaerk.substack.com/p/we-just-found-malicious-code... > It started with a cryptic build failure in our CI/CD pipeline, which my colleague noticed > This seemingly minor error was the first sign of a sophisticated supply chain attack. We traced the failure to a small dependency, error-ex. Our packag…

> Our package-lock.json specified the stable version 1.3.2 or newer Is that possible? I thought the lock files restricted to a specific version with an integrity check hash. Is it possible that it would install a newer version which doesn't match the hash in the lock file? Do they just mean package.json here?

If they were for some reason doing `npm install` rather than `npm ci`, then `npm install` does update packages in the lock file. Personally I always found that confusing, and yarn/pnpm don't behave that way. I think most people do `npm ci` in CI, unless they are using CI to specifically test if `npm install` still works, which I guess maybe would be a good idea if you use npm since it doesn't like obeying the lock file.

Re: Pnpm has a new setting to stave off supply chain attacks

#68

Post by slowroll22 »

dtech wrote: post #48
OskarS wrote: post #6

I have a question: when I’ve seen people discussing this setting, people talk about using like ”3 days” or ”7 days” as the timeout, which seems insanely short to me for production use. As a C++ developer, I would be hesitant to use any dependency in the first six months of release in production, unless there’s some critical CVE or something (then again, we make client side applications with essentially no networking,…

Waiting 6 months to upgrade a dependency seems crazy, that's definitely not a thing in other languages or maybe companies. (It might be due to priorization, but not due to some rule of thumb) In the JVM ecosystem it's quite common to have Dependabot or Renovate automatically create PRs for dependency upgrades withing a few hours of it being released. If it's manual it highly irregular and depends on the company.

For a previous place I worked - on some of our products 6 months was the minimum - and explicitly a year for a few of the dependencies.

The main deciding factors were the process and frequency it was released / upgraded by us or our customers.

The on-prem installs had the longest delay because once it was out there it was harder for us to address issues. Some customers also had a change freeze in place once things have been approved which was a pain to deal with if we needed to patch something for them.

Products that had a shorter release or update cycle (e.g. the mobile app) had a shorter delay (but still a delay) because any issue could be addressed faster.

The services that were hosted by us had the shortest delay on the order of days to weeks.

There were obviously exceptions in both directions but we tried to avoid them.

Prioritisation wasnt really an issue - a lot of dependencies were increased on internal builds so we had more time to test and verify before committing to it once it reached our stability rules.

Other factors that influenced us: - Blast radius - a buggy dependency in our desktop/server applications had more chance to cause damage than our hosted web application so it rolled a little slower for dependencies.

- Language (more like ergonomics of the language) - updating our C++ deps was a lot more cumbersome than JS deps)

Re: Pnpm has a new setting to stave off supply chain attacks

#69

Post by Mattwmaster58 »

DougBTX wrote: post #61
mcintyre1994 wrote: post #29

Earlier quoted context omitted.

In the case of the chalk/debug etc hack, the first detection seemed to come from a CI build failure it caused: https://jdstaerk.substack.com/p/we-just-found-malicious-code... > It started with a cryptic build failure in our CI/CD pipeline, which my colleague noticed > This seemingly minor error was the first sign of a sophisticated supply chain attack. We traced the failure to a small dependency, error-ex. Our packag…

> Our package-lock.json specified the stable version 1.3.2 or newer Is that possible? I thought the lock files restricted to a specific version with an integrity check hash. Is it possible that it would install a newer version which doesn't match the hash in the lock file? Do they just mean package.json here?

> Is that possible?

This comes up every time npm install is discussed. Yes, npm install will "ignore" your lockfile and install the latest dependancies it can that satisfy the constraints of your package.json. Yes, you should use npm clean-install. One shortcoming is the implementation insists on deleteing the entire node_modules folder, so package installs can actually take quite a bit of time, even when all the packages are being served from the npm disk cache: https://github.com/npm/cli/issues/564

Post reply on HN