Patching Go sources - which files end up in the build?

[cpu...@gmail.com]

For various reasons we need to patch cryptobytes for our build (https://github.com/evcc-io/eebus/issues/1#issuecomment-1146843187). 

We've tried to do this in a consistent way for local, Docker and Github CI build by vendoring our modules (go mod vendor) and patching the vendored copy. Test confirms the vendored copy is successfully patched (https://github.com/evcc-io/evcc/blob/master/main.go#L37).

However, and that part is harder to explain, our application- when receiving TLS connections- still seems to act as if the patch is not in place. Since cryptobytes is also part of GOROOT I'm wondering is there is any chance of the original file ending up in our build, too?

What is the role of GOROOT for the final binary and which files (vendored vs. mod cache vs. GOROOT) really end up the build in the end?

Much appreciated,

Andreas (andig)

[Ian Lance Taylor]

When files are vendored into the standard library, such as the
golang.org/x/crypto/cryptobyte package, all references to that package
from the standard library will refer to the vendored copy. If you
want to change references from the standard library, you will need to
modify the standard library sources. This of course means that you
must be using a custom Go distribution. There is currently no way to
tell the standard library to use a different version of a vendored
package. A mechanism for supporting that is
https://go.dev/issue/30241.

Ian