Consider shipping release tarball with vendored dependencies

[illiliti]

For example, dnscrypt-proxy does this by simply maintaining vendor directory. You can also setup CI to vendor dependencies into release tarball without needing to keep vendor directory within repository. Here is the command that can be used for this: go mod vendor

With vendored dependencies, i can build age from source without internet connection by using this command: go build -mod=vendor

[FiloSottile]

I’m not opposed to it, but help me understand the use case, is it about downloading a release in a connected environment and then building it in an offline one? Can’t a binary be moved to the offline env instead so there isn’t a need for the toolchain either? Or can’t you run “go mod vendor” in the environment where you downloaded the release?

[illiliti]

Internet connection requirement defeats the purpose of checksums. It's pointless to maintain them if tarball isn't self-contained.

[FiloSottile]

The release contains the go.sum file, which contains the checksums of everything that gets fetched from the Internet, so the tarball checksum transitively authenticates everything that goes into the build. This is an explicit security property of the Go build system. “go build” will fail on an incomplete or mismatching go.sum.

[illiliti]

It doesn't matter if language has it's own checksums becase system/distro package manager doesn't know about them. Proper package manager should never trust and offload checksum verification to the programs in build script because that's completely unacceptable and no-go in secure and constrained environments.