3 ms·

Note that even currently, lockfiles have the effect of locking you to an old version of the software. You could choose to automatically update all dependencies

by sseth 9y ago

Note that even currently, lockfiles have the effect of locking you to an old version of the software. You could choose to automatically update all dependencies to latest in CI, but then by that token you can run vgo get -u, to get the latest versions here as well. One of the issues which the vgo developers point out is that the "latest" behaviour has the perverse effect that a module A may declare a dependency of version 1.1 of a module B, and may have never been even tested on that version because the package manager always picked the latest. In some sense, the vgo approach is saying that across hierarchy of module owners, each one should keep upgrading their manifest to the latest versions of their direct dependencies, and ensure that things keep working, rather than relying on the topmost module to pull in the latest of the entire tree of dependencies. This seems to be good for the entire ecosystem.

tatersolid 9y ago
> each one should keep upgrading their manifest to the latest versions of their direct dependencies, and ensure that things keep working But that’s the problem. You’re relying on N people, including the package maintainers and end developers to all take timely action in order to get a security fix to the end user. That simply won’t happen. What should happen is a single package maintainer fixes a vulnerability, and that fix automatically flows through the system to all places where that package is used. And insecure versions should be made unavailable or throw a critical “I won’t build” error. Perhaps some way of marking versions as security critical might help, but the proposed approach will leave tons of vulnerable libraries in the wild. All the current package managers for other languages have this issue to some degree. Golang should do better with knowledge of those mistakes.

by sseth 9y ago

tatersolid 9y ago

> each one should keep upgrading their manifest to the latest versions of their direct dependencies, and ensure that things keep working But that’s the problem. You’re relying on N people, including the package maintainers and end developers to all take timely action in order to get a security fix to the end user. That simply won’t happen. What should happen is a single package maintainer fixes a vulnerability, and that fix automatically flows through the system to all places where that package is used. And insecure versions should be made unavailable or throw a critical “I won’t build” error. Perhaps some way of marking versions as security critical might help, but the proposed approach will leave tons of vulnerable libraries in the wild. All the current package managers for other languages have this issue to some degree. Golang should do better with knowledge of those mistakes.