Go += Package Versioning • Hacker News Board

Re: Go += Package Versioning

#211

Post by slrz » Fri, Feb 23, 2018, 9:58 AM UTC

Manishearth wrote: post #54

rsc wrote: post #32

Earlier quoted context omitted.

Hi. As I said in that page, I do know that cargo is working as designed, and that "0.4.1" is the same as "^0.4.1". My point is maybe a little more subtle, that cargo takes the newest allowed under the constraints, so given "^0.4.1", it has a choice between 0.4.1, 0.4.2, 0.4.3, 0.4.4, and 0.4.5, and it takes the last. When you're adding a new direct dependency, taking the latest is almost certainly right. But when you…

I think your wording there is incorrect and very misleading, even if you do understand it. You say > Cargo selects the latest version of a new dependency and its own new dependencies but that's not true; it selects the "latest semver-compatible minor version", which is a pretty different thing. The way you've phrased it makes it seem like cargo just flat out selects the newest version period (which can cause breaking…

> but that's not true; it selects the "latest semver-compatible minor version", which is a pretty different thing.

No, it's exactly the same thing. Russ already established that an incompatible module is not just a later version but, in fact, a totally different thing.

Re: Go += Package Versioning

#212

Post by tatersolid » Fri, Feb 23, 2018, 2:11 PM UTC

sseth wrote: post #209

tatersolid wrote: post #208

Earlier quoted context omitted.

This proposed “minimum version” behavior will effectively prevent “automated” security updates, which is what most reasonable people expect from their package manager. Consider all tens of thousands of CVE bugs found in widely used image, video, XML, etc. libraries. Even “updated” software is often compromised via outdated libraries. With a “min version” approach, none of those will get patched without explicit actio…

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 ver…

> 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.

Re: Go += Package Versioning

#213

Post by rogpeppe1 » Fri, Feb 23, 2018, 6:08 PM UTC

avar wrote: post #56

rsc wrote: post #34

Earlier quoted context omitted.

We do reject version pinning. There is no way to pin a particular version. The only constraint you can express is ">= this specific version". If nothing else pushes it forward, though, you'll keep getting that specific version. But it's not pinning, it's just stating a minimum, and the system uses the single oldest version that satisfies all the stated minimums (the max of the mins).

If you have no way to do pinning, how do you e.g. reproduce a bug or issue with a specific set of older dependencies?

You can specify that a given dependency be replaced by another one. That only applies at the top level though, not when the go.mod file with the replace clause is used by another module.