This should affect people only if they're not using specific versions and not using package-lock.json. It's exactly what those features are meant to do, updating should be a deliberate action. It's really bad that it's affected production sites so the devs will hopefully make use of package lock.
Then you get 5 year out of date packages, which eventually have a security vulnerability, and now you have the task of upgrading and working through 5 years of (potentially) breaking changes and deprecations.
It's generally easier in the long run to keep your dependencies up to date. If a package has a new breaking change each week, that's a sign you probably shouldn't be using it for production code.
Perhaps you're misunderstanding what this article about.
The author is making a pr that updates the package.json, which also means the lockfile is updated.
If you don't accept any PR that touches the package.json file, then that means you're not accepting a PR that introduces any new dependency, tries to update a dependency for security reasons, or uses a feature available in a newer version of the dependency.
All of those reasons seem like valid reasons to accept a lockfile change -- that the author of the PR changed the package.json file for any of those reasons.
> Worried about the dependency changing? Lock the version.
And get p0wned a year later when some security researcher finds a vulnerability in code that you don't even use, but pulled in as part of that dependency.
It partially helps but in the article I mention the package it had a change, a minor (non-breaking) one, that caused A to affect B without us having a direct explanation as to why.
Locking helps on packaging, it reduces the problem of packages being updated without your control but it doesn't help interdependency or the other things I mentioned (not even talking about security here)
This is not a good idea for certain packages. For example, if you are using something that is under seriously active development, such as Rails and Ruby, and in another case, SBCL Lisp, and even often Emacs.
Up-to-date security is one seriously important reason.
How about you 1) leave old versions in place on the package index, 2) declare that you will not be providing further updates to the package through the index because of this issue, 3) go publish your stuff on your website or an alternate package index?
Author here. I'd love to have you read the two links I refer to at the top of my post. They articulate why it's a bad thing.
Incidentally, version locking every dependency is identical to just inlining every dependency in the repo. And I actually like this approach a lot. See my example of "exemplary library use" at http://arclanguage.org/item?id=20221. OP was an attempt to reconcile my priorities with the mainstream.
> As the writer of an application I like the power of short-cutting that path if needed for an important update of a transitive dependency by simply telling my package manager to update the lockfile, vs having to wait for the update to trickle through the chain of dependencies.
MVS has this shortcut without requiring a lockfile. Just update the minimum version for that dependency in your own project.
No. Update dependencies as needed for security patches (which typically avoid breaking changes), other than that never update unless there is an explicit business need.
Lock files are only one part of the solution. Even with a lock file dependencies need to be fetched from somewhere and if a particular version of a package was deleted by its author then you're back to case one.
"People don't run Cargo update willy nilly."
We don't know the same people then. Most devs like to keep their stuff up to date. Auditing the dependencies tree before updating a lock file is like reading a ToS. Most people don't even if they should.The problem of securing the chain of production is not solved with a simple lock file.
> Lock files also remove the "silent security fix" that was touted as the benefit of other systems.
That is the great thing about lock files. You don't have to check them in. If you want reproducible builds, you do check them in. If you don't, you don't. The user, not the package manager, gets to make this choice on a case-by-case basis.
> The difference is in default behavior of the system: vgo by default picks predictable, consistent version of dependencies. That version doesn't change if dependencies release new versions.
And that right there is the problem. You don't get the latest version unless you explicitly ask for it. This makes the user do what a package manager is perfectly capable of doing. It thrusts the problem onto the user instead of applying a well-known solution that was causing problems for nobody.
If you are writing an application, don't you want your transitive dependencies to get security fixes without having to trawl through the tree?
Some people prefer to commit them (along with composer lock files for php). I always advise against it for this exact reason and because I want to make sure packages are correctly installed on the target system. Occasionally, deeply flawed versions are removed and it helps with catching it as well since you are forced to reinstall packages on a pull or build.
Edit: a minor version update should not be backwards incompatible and break things. If it does, the package is poorly maintained imo.
Your argument supports the idea of getting rid of the lock file and instead committing the hash in the original dependencies file - so that it's never an automatic process to update the hashes/versions.
OP here. Totally right, the final goal being that a new version of the package gets automatically rebuilt whenever a buildpack gets updated with a security fix.
The correct approach would be to allow changes like this to be pushed to _new_ versions but to lock pre-existing versions in place. The alternative is this weird world where the platforms themselves have spooky editorial control over every package and could step in at any time and lock out the maintainers (sounds a lot like SourceForge).
> Especially when the old project in question is not yours
Then it falls out of the stated scope of "updating my small website once every 5 years or so"
reply