Is it time for a Lock file?

[HeyItsGilbert]

Always installing Latest can be problematic. The reality is that there are more and more cyber threats where assuming that latest is the best approach is going to eventually shoot us in the foot. Currently PSDepend doesn't have a lock file. This sort of falls onto the package manager to implement, but the problem is not every package manager supports it. So the question is: Do we write an intermediate layer to create a lock system for things like PowerShell modules?

I am creating this as a discussion because I want to try to get feedback from the community before we just start to implement. I suspect this is not difficult to implement (famous last words), but I'm sure there are plenty of foot guns that I'm not considering.

What is a lock file?

Lock files are files that store a resolved version of the intended package. For example, if you want version >2.1 and version 2.5 is available, the lock file would update to point to the specific version (e.g. 2.5.0). In future calls, you can restore to a specific version and/or update to the new latest. They also document any dependencies and their resolved version. So even a sub-dependency that has a similar minimum version would get resolved and saved.

See node's package-lock.json for a real life example: https://docs.npmjs.com/cli/v12/configuring-npm/package-lock-json

Why have lock files?

1. Allow "time-travel" to be able to recreate an exact build
2. Dependencies update deterministically
3. Reduce supply chain attacks

With transitive dependencies, you can run into the issue that a previously working build begins to fail because a downstream dependency changed. This can be difficult to diagnose when dependency versions are dynamic.

Supply chain attacks are on the rise even with package managers that make it easier to control dependancies. This has been very prevalent in the npm world: https://unit42.paloaltonetworks.com/npm-supply-chain-attack/

[bchap1n]

I don't understand the benefit vs setting the version in requirements.json?

[HeyItsGilbert]

Let's say you want the latest version of something, but you need to know what the last "latest" working version was (that you actually used in the project), this would help. You could totally pin the version in the requirements file, but when's the last time you updated it? You also probably don't have visibility into any of the transitive dependencies.

[adilio]

+1 on this, and my vote is for locking over pinning.

@bchap1n a pin says what you asked for. A lock says what you actually got, including the transitive stuff you never asked for. That’s where I keep seeing the supply chain issues happen. The pattern in the npm incidents is almost always a sub-dependency nobody had eyes on. PowerShell isn't immune. RequiredModules in a manifest can be as loose as the author felt like making it that day.

The other half is that pins rot. Nobody bumps requirements.json for eight months, then someone updates everything at once and spends a day figuring out which of eleven modules broke the build.