>If I'm only using a single feature of a multi-purpose tool for example, does it matter to me that some unrelated dependency of theirs has a security issue?
How is anyone supposed to know whether there's an issue or not? To simplify things, if you use the tool and the dependency belongs to the tool, then the issue can affect you. Anything more advanced than that requires analyzing the code.
What if I'm already using techniques, such as sandboxing, to prevent the tools from doing anything unexpected? Why bring this entire mess of indirect dependencies into my project if I'm just using a tool to occasionally analyze my binary's output size? Or a tool to lint my protobuf files?
If it's a build dependency, then you have to have it. If you don't like the size of the tool then take it up with the authors. I'm not a Go programmer by the way, this is all just obvious to me.
The functionality we're discussing can be used for tools that are not build dependencies. They may be important for your project and worth having contributors be on the same version but not part of the build.
It will still add the dependencies of those tools as indirect dependencies to your go.mod file, that is what's being discussed.
If you use the tool to develop your project then it is basically a build dependency. That is a sweeping generalization, but it's essentially correct in most cases.
That is a bit much to ask for IMO. In any case, the project may not be aware of how any given developer will use the tool. So who is to say that if you change the order of two parameters to the tool, the tool might not take a different path and proceed to hack your computer? You really don't want any of this problem. What you should ask for is for the tools' dependencies to be listed separately, and for each tool to follow the Unix philosophy of "do one thing well."
There is a lot of merit to this statement, as applied to `go tool` usage and to security scanning. Just went through a big security vendor analysis and POCs. In the middle I saw Filippo Valsorda post [1] about false positives from the one stop shops, while govulncheck (language specific) did not have them. At the same time, there was one vendor who did not false positive with the reachability checks on vulns. While not always as good, one-stop-shops also add value by removing a lot of similar / duplicated work. Tradeoffs and such...
The similar/duplicated stuff can be rolled into libraries. Just don't make the libraries too big lol. I suspect there's less duplicated stuff than you think. Most of it would be stuff related to parsing files and command parameters, I guess.
Reachability analysis on a tool that could be called by something outside of the project? We're talking about tools here after all - anything that can run `go tool` in that directory can call it. The go.mod tool entry could just be being used for versioning.
How is anyone supposed to know whether there's an issue or not? To simplify things, if you use the tool and the dependency belongs to the tool, then the issue can affect you. Anything more advanced than that requires analyzing the code.