Post

Isn't this just like using a lock file but it's more tedious to update dependencies when vulnerabilities are found?

0 reposts11 likes

I don't really keep any keys accessible on my machine so I'm happy to trust registries that haven't been compromised in decades. It's a risk but if you can't trust registries we wouldn't use package managers and they haven't fucked up yet.

That argument sounds a lot like "i have nothing to hide so I don't need privacy" Maybe the registries themselves are secure but if someone uploads a bad version the registry will happily serve it to you until it's blocked. If it's a transitive dep not even a lock file will save you

Every form of lockfile I've used pins transitive dependencies just the same as it pins direct dependencies. If it doesn't, it's not really doing its job as a lockfile because repeated installs won't get the same software. Certainly they don't solve all problems, though.

There have been a lot of supply chain attacks recently and automatic dependency management makes it much easier to be affected. Vendoring dependencies is the "correct" way to deal with it but also tedious.

This is an argument against automated dependency management not one against lockfiles. If someone isn't looking at the diffs of the dependency code you're running you're vulnerable regardless of how you import the code.

Lockfiles are part of the automatic dependency management and even when using a lockfile you are not safe against every supply chain attack socket.dev/blog/hidden-... With vendoring you have no pre and postinstall scripts, no chains of transitive deps and more friction means less deps in use overall

socket.devThe Hidden Blast Radius of the Axios Compromise - SocketThe Axios compromise shows how time-dependent dependency resolution makes exposure harder to detect and contain.