On Sun, Oct 2, 2022 at 8:45 AM cpu...@gmail.com <cpui...@gmail.com> wrote: > > 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?
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 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcU4nyLe-N3OJt6ZCZLw1r3qGUjx84e0Q6O3_ERwFBP%2B%3Dg%40mail.gmail.com.
