[syvolt]

Thank you for working on it. It is a nice feature and still better than alternatives.

I'm not a library author and I try to be careful about what dependencies I introduce to my projects (including indirect dependencies). On one project, switching to `go tool` makes my go.mod go from 93 lines to 247 (excluding the tools themselves) - this makes it infeasible to manually review.

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?

[wakawaka28]

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

[syvolt]

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?

[verdverm]

In addition, a good dependency security scanning tool can analyze reachability to answer this question for you

[arccy]

it probably doesn't, and good vulnerability scanners like govulncheck from the go team won't complain about them, because they're unreachable from your source code.

now, do you care about some development tool you're running locally has a security issue? if yes, you needed to update anyway, if not, nothing changes.