[jfolkins]

Please understand that if you vendor your dependencies inside your go.mod project, you own them and will need to support and audit them in the future.

The mod command does not vet any computed hashes of the dependencies found in your vendor directory.

[drvd]

Running "go mod vendor" just populates the vendor folder which allows local development with all tooling. It does not force you to check in the vendor folder (you can even .gitignore vendor). Doing "go mod vendor" is not the typical "vendor", it does not make you the owner and you do not need to support and audit these packages (unless you actually vendor them in the sense of check them in).

[jerf]

You own your dependencies and will need to support and audit them in the future.

Note the lack of conditions on that statement, up to and including the fact this statement isn't even about Go, nor is it even about open source! It is simply a fact. You own your dependencies and you need to support and audit them. You are free to support and audit them by not supporting them at all, not auditing them at all, and blindly pulling in whatever random mutations they may go through in the future. You own the consequences of such terrible support. You own the consequences of good support.

[jfolkins]

You are correct and I was unclear. My statement is that you and ONLY you now own them. You've essentially forked the project and lost your community.

[cyphar]

Though of course if you don't use "go mod vendor" then "go build" will require an internet connection, which is a problem for most distributions (package builds generally don't have an internet connection).

[jfolkins]

Why aren't your go build tools pulling from the GOPATH/pkg/mod/cache directory?

This would alleviate the need for your build to have a internet connection no?

[cyphar]

Fresh builds (in an "rpmbuild" for instance) don't use a cache, for obvious reasons.