require a compatible Go version to have built the garble binary

[mvdan]

Right now, on the master branch, we only test Go 1.16 builds with a garble built on Go 1.16.

Would Go 1.16 builds work on a garble built with Go 1.15?

What about Go 1.16 builds on a garble built with Go tip/master (1.17)?

You might think "it should be fine", but it's not always the case. I've encountered some rare failures because I did go install on 1.17 and then built some packages with garble on 1.16, and those failures go away if I consistently use 1.16. I think the underlying cause is a change of behavior in go/types, affecting our decision to obfuscate certain package paths.

I think we should require the major version to be the same. That is, if the user built garble on 1.15, they can't use it for builds on 1.16, and vice versa.

I think it should be fine to use a different minor version, such as building garble on Go 1.16 and then using it for an obfuscated build on Go 1.16.1. Major versions change lots of features and internals, but minor versions usually only fix security and other critical bugs, which are far less likely to affect garble.

Option B: rejecting this idea

Another option is to say "no" and explicitly support and test version mismatches. For example, if garble v0.2.0 supports Go 1.16.x and Go 1.17.x, we must test 2x2 combinations on CI:

• install garble on 1.16.x, test on 1.16.x
• install garble on 1.16.x, test on 1.17.x
• install garble on 1.17.x, test on 1.16.x
• install garble on 1.17.x, test on 1.17.x

However, note that this can multiply our CI cost, and we'd also have to worry about other cases such as "install garble on 1.15.x" even if we don't support that Go version at all - just because it happens to successfully build.

Personal preference

I feel fairly strongly about only supporting the same major Go version. It's the only scenario we've been testing, and I think doing the opposite would be added work and complexity just for the benefit of user convenience. It is more convenient to not have to rebuild when switching Go versions, or to download a single prebuilt binary that will work for multiple Go versions, but I reckon the most common use case is using a version of garble with a single major version of Go.

Plus, I think this is how most Go tools work nowadays. I doubt that a gopls built on Go 1.15.x and used for developing code on Go 1.16.x is an edge case that is supported or well tested. This is a tool for developing Go code, so it is expected that the end user has Go installed already; they should use it to build garble too.

Supporting major version mismatches is also a bad idea for other reasons. For instance, a garble built on Go 1.16.x can't support builds on Go 1.17.x if said build uses a language feature introduced in Go 1.17.x, as garble would use packages like go/parser and go/types from Go 1.16.x, which would not know about the new feature yet.

That last nasty edge case could be solved by only allowing a newer garble build to use older versions of Go for builds, but that still leaves us with the other possible failures like the one I encountered with go/types.

Implementation

Option A is to make the build fail if the major version of Go does not match the currently supported version. We could accomplish this with build tags, like // +build go1.16 and // +build !go1.17. GopherJS does this with build-tagged constants, I think. The main downside is that build errors are pretty confusing.

Option B is to use https://golang.org/pkg/runtime/#Version when garble runs and match it against the supported Go version, just like we do for go version. This won't fail until the first time the user calls garble build, but we can provide a helpful error message and the implementation will be simpler.

I lean towards option B.

[mvdan]

I think the underlying cause is a change of behavior in go/types, affecting our decision to obfuscate certain package paths.

That particular code went away with 748c6a0; see the removed implementedOutsideGo.

I'm inclined to sit on this for now, because maybe I'm being overly dramatic. If we don't do hacks that assume internal and undocumented details, like implementedOutsideGo, it should generally be fine to use a slightly older or newer version of Go to build garble.

For instance, a garble built on Go 1.16.x can't support builds on Go 1.17.x if said build uses a language feature introduced in Go 1.17.x, as garble would use packages like go/parser and go/types from Go 1.16.x, which would not know about the new feature yet.

I suspect that this edge case is what will be most common around users, so we might want to add a check for it in the future. It wouldn't need to be as strict as "the major version must be an exact match", but rather "the major version used to build garble must not be older than the version of Go currently being used".