[Romario77]

I think another thing that affects security is that in javascript culture people often tie to the latest version instead of concrete version.

This makes it so an update to a popular library can compromise a huge number of packages that depend on it.

In Java for example almost all packages specify a concrete version, even if someone compromises the latest the blast radius is usually pretty small.

[Pxtl]

MS Nuget is also lock-by-default. Latest-by-default should be considered harmful unless the package manager is directly vouching for the veracity and reputability of the packages.

[Uvix]

NuGet is lock-by-default for the parent package, but with the move from packages.config to <PackageReference> it's no longer lock-by-default for dependencies.

[Pxtl]

It never made sense the other way. If I reference a package, logically I'm also referencing its dependencies at the version that the package uses. Forcing the user to also reference dependencies of dependencies of dependencies means the package reference lists aren't DRY.

[Uvix]

But just the dependency list isn't sufficient to pick a specific version, thanks to dependency ranges. If Package A depends on Package B >= 1.0, and Package B has v1.0 and v1.1 available, it will use v1.0. But if Package B suddenly unlists v1.0, then future restores will change to v1.1.

[Pxtl]

Ah, I see the worry. A supply-chain attacker can use de-listing to force an upgrade to the malicious version if clients have dependency ranges that reach into the future.

I didn't know about that one.

In general, any dependency system that allows "you can silently upgrade to versions of the package that did not exist at the time the packagereference list was created" seems to be a vulnerability.

It's frustrating since this vuln seems trivially simple to fix, at a glance... although it would require an API change in PackageReference. Mandatory lockfiles by default, or getting rid of the floating versions misfeature. BindingRedirects let you override declared dependency versions anyways, they're not a blood pact.

[Uvix]

It seems trivially simple until you have two dependencies with conflicting exact version requirements... So I don't think you can get rid of floating versions entirely. They did add NPM-style lockfiles for PackageReference, but currently not mandatory.

The version numbers for BindingRedirects are orthogonal to the package versions. You can have multiple package versions use the same AssemblyVersion so that applications don't need to create BindingRedirects. (e.g. Newtonsoft.Json - 13.0.0, and 13.0.1 in NuGet are both 13.0.0.0 for binding redirect purposes) And .NET Core/5+ don't need BindingRedirects at all!

[m4rtink]

Won't pinning a version lead to dependency hell, not to mention potentially using vulnerable versions if you don't a new version after it has some CVE fixes ?