cmd/go: pass information on incompatible versions to consuming modules

[mattfarina]

Consider the following case where you have an app with a dependency on a module (modA) that has a dependency on another module (modB).

App --> modA --> modB

modB is released with a bug. For the examples sake, the bug causes goroutines to not be garbage collected and the number to continue to grow. This bug has been experienced in a real world application.

The developer of modA realizes this bug exists and sets the minimum version to the last stable release that does not contain the bug.

The developer of the App decides to update the dependencies to the latest releases (e.g., go get -u ./...). Alternatively, the apps developer could import a second dependency (modC) that also depends on modB but at the latest release because they did not catch the bug. Some bugs don't show up on tests but rather in long running situations which is why I choose the goroutine example.

There is currently no way for the author of modA to pass along information that modB has a bad releases. We need a way to communicate that information for those periods where that release is in the wild and one to use.

Existing tools like glide and dep let you say not to use a release. This is idea shows up in most other languages dependency management as well (e.g., !=1.2.3).

An idea was suggested, rather quickly and off the cuff, by @rsc to setup a web service to hold the information on buggy versions that should not be used. There are a few constraints that make this idea difficult:

• Who can post details on what versions of what tools are incompatible? There is an opportunity to troll through manipulation of the data
• How is access handled when packages can be hosted by VCS and you can't always count on GitHub
• There is an information leakage problem where data on the dependencies of a proprietary app could be leaked to this services host. For example, a rival to Google is working on an app but leaking the dependencies they use to Google as a host of the service which gives lots of detail. We shouldn't have a case where data is leaked like that

This is a problem because of two things:

• When not vendoring you lose the ability to easily diff the changes to dependencies
• A mass number of developers never really check the changes to their dependencies when they pull in updates
• A bug like this could be easily missed when updating, even for the trained eye, which I posit few will do

How will the Go toolchain handle this situation?

[ucirello]

Existing tools like glide and dep let you say not to use a release. This is idea shows up in most other languages dependency management as well (e.g., !=1.2.3).

Isn't what the exclude clause is?

[mattfarina]

@ucirello great question. The answer is no according to the docs. Specifically, it says:

exclude and replace directives only operate on the current (“main”) module. exclude and replace directives in modules other than the main module are ignored when building the main module. The replace and exclude statements therefore allow the main module complete control over its own build, without also being subject to complete control by dependencies.

[OneOfOne]

@gopherbot, please add labels modules

[ucirello]

@mattfarina OK - I am not the one equipped to debate on this. But it does seem exclude is the right primitive. You are right in the sense that exclude does not cascade down to the dependency tree, but you could still state the exclusion in the main module. In the latest version you can even see when packages are imported indirectly, and thus take action accordingly.

Again, I am not the one equipped to debate on this, so I could be missing something important.

[mattfarina]

@ucirello You bring up some valid questions that are worth discussing and going deeper on. I'm happy to expand for future readers.

To expand on the example... if you had...

App -> modD -> modA -> modB

If modB had the issue and modA had the exclude it would not automatically be honored. Since App imports modD the author of App may very likely not be aware of the details of modA or modB.

And, since it only works for the current main module, if modA or modB were libraries without a main it would not work for their testing situations, either.

[kardianos]

If this issue is just about marking releases as insecure / buggy, then this is a duplicate of #24031 (comment) .

If this issue is about code review and diffing changes, then I have a few thoughts. I'd like make a to address some of the issues you mentioned with code review, but I don't it should be part of cmd/go. Maybe we could discuss something over in Athens tracker or offline first.

If this issues is about the lack of a way for go.mod to transitively exclude module versions, then I think this is working as designed as you noted. One tool you could build could read all the mod files from dependencies and inform the user of any excludes constraints they request locally, and optionally include them locally. As you noted, this isn't what you designed in glide and Russ has acknowledged this situation a number of times and it seems fundamental to the principal of the design.

[flibustenet]

When modB has a bug and make a release to correct it, it will increment at least the patch number. Then go list -m -u all will show that, it's then to maintainer of the App to take care of this and go to look if one of theses dependencies need to be upgraded for it.

[mattfarina]

@kardianos This is similar to #24031 (comment) but not the same.

In this case the latest release has a problem with it. There is no newer release to include information about a previous buggy release. There are numerous reasons this could happen. For example,

1. While a module is useful the author is generally not a great maintainer and is slow to respond to issues
2. The module maintainers went on vacation or are otherwise temporarily unavailable
3. The module maintainers don't see the bug as something they immediately need to issue a release for

The design in #24031 (comment) is one where a module, in this case modB, describes information about its previous releases. The modules modA and modD in the examples here have no way to communicate information themselves.

The design in #24031 (comment) would work if module maintainers were always on the ball and got releases for issues out quickly. In practice people simply don't do that all the time which is where the problem comes in.

Don't we need to be fault tolerant of people? If so, how would that work? How can the ecosystem route around an issue in a release where the maintainer(s) of the module aren't handling it?

I believe any solution to this problem should be part of cmd/go because it's a real world situation and people need the default tooling to handle this well.

[mattfarina]

@flibustenet How do people handle a long time before a bug fix release to modB? How do they work around that situation?

[ucirello]

@mattfarina If I understand you correctly, I think it is not a goal to protect against every possible way bad imports can land in your code, rather the idea is to provide the necessary primitives to handle them (in this case, exclude clauses), and data structures on which the ecosystem supporting modules can evolve around.

Although the modules implementation does not address this concern you put forward directly, it does offer the necessary primitives and the go.mod has the necessary information to dig further your dependency tree through tooling.

Thus, if this case you put forward is important, other use cases are also important (like having a tool that indicates that an update is available for both transitive and intransitive dependencies) - but neither are necessarily dealt by cmd/go.

Personally, I am working on a tool that crystalizes into the main's go.dep all the dependencies - even the intransitive ones, mostly giving me control of what lands or not in my dependency tree.

Edit: Added last paragraph.

[thepudds]

I'm pretty sure @mattfarina would have seen all these given his role in glide, etc., but for other people that might land here, briefly adding some more specific URLs to some conversations about related possible future directions (either previously considered or still being considered):

• declaring deprecated versions as described in the initial vgo blog series
• declaring pair-wise incompatibility between modules in an external system (maybe a renamed godoc.org?) as discussed for example here during the proposal process
• declaring buggy, insecure, or potentially incompatible versions of a module after a release has been published in #24031 (which was mentioned above already)

As far as I am aware, there is a strong desire to do something here, but still an open question as to the exact mechanism(s).

It seems like there is very likely a successful path forward that is possible here, but given its significance, this seems like an important area for the community to discuss, analyze, offer possible solutions, etc. (My 2 cents, anyway...)

[mattfarina]

@thepudds I'd like to add some more detail to your possible future directions...

• declaring deprecated versions as described in the initial vgo blog series

That's already touched on over at #24031 (comment) and in the blog series. That setup requires the author of modB to take an action. The problem here is when the maintainer of modB isn't taking an action.

• declaring pair-wise incompatibility between modules in an external system (maybe a renamed godoc.org?) as discussed for example here during the proposal process

As I noted in the original issue, a problem arises here with information disclosure. If Google operates this site they are in the business of many things. A competitor to Google would be leaking the sets of dependencies they use to Google by using Go. That's not going to be acceptable for many.

• declaring buggy, insecure, or potentially incompatible versions of a module after a release has been published in cmd/go: allow package authors to retract older package versions as insecure, incompatible, or broken #24031 (which was mentioned above already)

Another case where the author of modB takes an action.

The case here is when the author of modB does not take an action or has not taken one, yet. The ecosystem needs to route around the issue they face until action is taken.

[thepudds]

@mattfarina Regarding your last point, I had added a comment #24031 (comment) that at least attempted to outline how the author of modB wouldn’t be required to take an action in this scenario you outlined here?

But I could very easily be off base here…