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

81–90 of 152 posts

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

#81

Post by esafak »

slowroll22 wrote: post #68
dtech wrote: post #48

Earlier quoted context omitted.

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 ha…

As long as you can quickly upgrade a package when there's a security patch you're good. You make it sound like that's not the case, though.

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

#82

Post by esafak »

chr15m wrote: post #50

The correct value for this setting is infinity seconds. Upgrades should be considered and deliberate, not automatic.

No, it isn't. Upgrades should be routine, like exercising. With your approach it becomes increasingly difficult and eventually impossible to upgrade anything since it requires moving a mountain. An update a ̶d̶a̶y̶ week makes the tech debt go away.

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

#83

Post by JoshuaEN »

chr15m wrote: post #50

The correct value for this setting is infinity seconds. Upgrades should be considered and deliberate, not automatic.

I don't think this is realistic in the default npm ecosystem where projects can have 1000s of dependencies (with the majority being transitive with fuzzy versions).

Though pnpm does have a setting to help with this too: https://pnpm.io/settings#resolutionmode time-based, which effectively pins subdependencies based on the published time of the direct dependency.

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

#86

Post by slowroll22 »

esafak wrote: post #81
slowroll22 wrote: post #68

Earlier quoted context omitted.

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 ha…

As long as you can quickly upgrade a package when there's a security patch you're good. You make it sound like that's not the case, though.

It was definitely possible, as mentioned there were some exceptions (such as cases where we did need to roll out a version with dependencies bumped or with our own critical fixes).

The harder part, as is often the case, wasn't technical - but more convincing customers to take the new version and getting time with their IT teams to manage. It got easier over time but the bureaucracy at some of the clients was slow to change so I suspect they still face some issues.

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

#87

Post by cluckindan »

mort96 wrote: post #43
fzeindl wrote: post #7

Earlier quoted context omitted.

ISO8601 durations should be used, like PT3M.

Oh wow, never looked at ISO8601 durations before and I had no idea they were this ugly. Please, no, don't make me deal with ISO8601. I'd rather write a number of seconds or a format like 'X weeks' or 'Y hours Z minutes'x ISO8601 looks exclusively like a data interchange format

When in doubt, use only seconds. PT86400S

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

#89

Post by cluckindan »

Rockslide wrote: post #71
streptomycin wrote: post #64

Earlier quoted context omitted.

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 fi…

How does this get repeated over and over, when it's simply not true? At least not anymore. npm install will only update the lockfile if you make changes to your package.json. Otherwise, it will install the versions from the lockfile.

Are you 100% on that?

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

#90

Post by mirashii »

Rockslide wrote: post #71
streptomycin wrote: post #64

Earlier quoted context omitted.

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 fi…

How does this get repeated over and over, when it's simply not true? At least not anymore. npm install will only update the lockfile if you make changes to your package.json. Otherwise, it will install the versions from the lockfile.

> How does this get repeated over and over, when it's simply not true?

Well, for one, the behavior is somewhat insane.

`npm install` with no additional arguments does update the lockfile if your package.json and your lockfile are out of sync with one another for any reason, and so to get a guarantee that it doesn't change your lockfile, you must do additional configuration or guarantee by some external mechanism that you don't ever have an out of date package.json and lock. For this reason alone, the advice of "just don't use npm install, use npm ci instead" is still extremely valid, you'd really like this to fail fast if you get out of sync.

`npm install additional-package` also updates your lock file. Other package managers distinguish these two operations, with the one to add a new dependency being called "add" instead of "install".

The docs add to the confusion. https://docs.npmjs.com/cli/v11/commands/npm-install#save suggests that writing to package-lock.json is the default and you need to change configuration to disable it. The notion that it won't change your lock file if you're already in sync between package.json and package-lock.json is not actually spelled out clearly anywhere on the page.

> At least not anymore.

You've partially answered your own question here.

Post reply on HN