4 ms·

And absolutely pin, pin, pin, ALL your dependencies. If I see a package version dependency that looks like this: ^1.0.0 or even this: "*", then stop reading, p

by rvz 6mo ago

And absolutely pin, pin, pin, ALL your dependencies. If I see a package version dependency that looks like this: ^1.0.0 or even this: "*", then stop reading, pin it to a secure version immediately.

AgentME 6mo ago
Npm's package-lock.json already handles pinning everything to exact versions, including subdependencies. Pinning exact versions in package.json doesn't affect your subdependencies.
- beart 6mo ago
  You aren't wrong. However, this article does offer some additional advice on this matter, and some potential reasons why it might still be desirable to pin your deps in package.json. https://docs.renovatebot.com/dependency-pinning/#pinning-dependencies-and-lock-files https://docs.renovatebot.com/dependency-pinning/#pinning-dep... Some exerts: > If a lock file gets out of sync with its package.json, it can no longer be guaranteed to lock anything, and the package.json will be the source of truth for installs. > provides much less visibility than package.json, because it's not designed to be human readable and is quite dense. > If the package.json has a range, and a new in-range version is released that would break the build, then essentially your package.json is in a state of "broken", even if the lock file is still holding things together.
jonchurch_ 6mo ago
its so wild to have seen this advice reverse course over the past year. it used to be that projects that pinned deps were called out as being less secure due to not being able to receive updates without a publish. different times, different threat model I suppose
- n_e 6mo ago
  > it used to be that projects that pinned deps were called out as being less secure due to not being able to receive updates without a publish. This is still the right advice for libraries. For security it doesn’t matter a whole lot anymore as package managers can force the transitive dependencies version, but it allows for much better transitive dependency de duplication. For non-libraries it doesn’t matter as the exact versions get pinned in the package-lock.
captn3m0 6mo ago
I've been collecting things you can't pin: - Python inline dependencies in PEP-0723, which you can pin with a==1.0, but can't be hash-pinned afaik. - The bin package manager lets you pin binaries, but they aren't hash-pinned either. - The pants build tool suggests vendoring a get-pants.sh script[0] but it downloads the latest. Even if you pass it a version, it doesn't do any checks on the version number and just installs it to ~/.local/bin [0]: https://github.com/pantsbuild/setup/blob/gh-pages/get-pants.sh https://github.com/pantsbuild/setup/blob/gh-pages/get-pants....
losvedir 6mo ago
Are you talking about in package.json? What's your threat model? That's what the lock file is for, which also pins transitive dependencies, which is just as crucial. Now what's actually insecure is if you don't commit the lockfile. and if you don't do `npm ci`. I think `npx` might pull down new versions, too? I wish npm worked more like Elixir where updating the lock file was an explicit command, and everything else used the lock file directly.
eqvinox 6mo ago
Or help distributions do the manual process of packaging - which involves at least rudimentary security checks - so they can ship newer versions faster. And then use distro packages. (I'm not accepting distro fragmentation as counterargument. With containerization the distro is something you can choose. Choose one, help there, and use it everywhere.)

by rvz 6mo ago

And absolutely pin, pin, pin, ALL your dependencies. If I see a package version dependency that looks like this: ^1.0.0 or even this: "*", then stop reading, pin it to a secure version immediately.

AgentME 6mo ago

Npm's package-lock.json already handles pinning everything to exact versions, including subdependencies. Pinning exact versions in package.json doesn't affect your subdependencies.

beart 6mo ago
You aren't wrong. However, this article does offer some additional advice on this matter, and some potential reasons why it might still be desirable to pin your deps in package.json. https://docs.renovatebot.com/dependency-pinning/#pinning-dependencies-and-lock-files https://docs.renovatebot.com/dependency-pinning/#pinning-dep... Some exerts: > If a lock file gets out of sync with its package.json, it can no longer be guaranteed to lock anything, and the package.json will be the source of truth for installs. > provides much less visibility than package.json, because it's not designed to be human readable and is quite dense. > If the package.json has a range, and a new in-range version is released that would break the build, then essentially your package.json is in a state of "broken", even if the lock file is still holding things together.

jonchurch_ 6mo ago

its so wild to have seen this advice reverse course over the past year. it used to be that projects that pinned deps were called out as being less secure due to not being able to receive updates without a publish. different times, different threat model I suppose

n_e 6mo ago
> it used to be that projects that pinned deps were called out as being less secure due to not being able to receive updates without a publish. This is still the right advice for libraries. For security it doesn’t matter a whole lot anymore as package managers can force the transitive dependencies version, but it allows for much better transitive dependency de duplication. For non-libraries it doesn’t matter as the exact versions get pinned in the package-lock.

captn3m0 6mo ago

I've been collecting things you can't pin: - Python inline dependencies in PEP-0723, which you can pin with a==1.0, but can't be hash-pinned afaik. - The bin package manager lets you pin binaries, but they aren't hash-pinned either. - The pants build tool suggests vendoring a get-pants.sh script[0] but it downloads the latest. Even if you pass it a version, it doesn't do any checks on the version number and just installs it to ~/.local/bin [0]: https://github.com/pantsbuild/setup/blob/gh-pages/get-pants.sh https://github.com/pantsbuild/setup/blob/gh-pages/get-pants....

losvedir 6mo ago

Are you talking about in package.json? What's your threat model? That's what the lock file is for, which also pins transitive dependencies, which is just as crucial. Now what's actually insecure is if you don't commit the lockfile. and if you don't do `npm ci`. I think `npx` might pull down new versions, too? I wish npm worked more like Elixir where updating the lock file was an explicit command, and everything else used the lock file directly.

eqvinox 6mo ago

Or help distributions do the manual process of packaging - which involves at least rudimentary security checks - so they can ship newer versions faster. And then use distro packages. (I'm not accepting distro fragmentation as counterargument. With containerization the distro is something you can choose. Choose one, help there, and use it everywhere.)