Also golang.org/x/crypto is not a core library so doesn't actually fall under the compatibility guarantee but they seem to try their best not to break it.
You can use a comment of the format '//go:linkname [localname] [method]' to link some function as another one. Notably, this includes unexported private methods in the go runtime and stdlib.
I've seen code in the wild that uses this to grab go's map hash algorithm, get monotonic time, and other things.
The go authors have used this hack themselves in the stdlib often enough because the runtime doesn't expose some knob, and rather than thinking that perhaps other developers may want that knob too, they instead use such hacks, but they also don't support said hacks (because how could you, obviously keeping all private functions stable forever is silly and impossible)
However, we try to hold x/crypto itself to the same compatibility standard as the standard library, so I think simply updating x/crypto at the same time should have made it a smooth update.
So I guess YMMV...
EDIT: I'm sad folks are downvoting for asking a question...
To be fair though, that package was depending on a private API to begin with.
If you use vulnerable crypto (willing to go with old unpatched vendored code) then you don't really need crypto at all..
The code path that failed to build was still related to the included crypto (even if it was due to compiler change).
If that was their only way to fix the crypto issue, then it's totally fine, because that way they fixed it for people who did need and exercize the crypto code path -- and those take priority over people who "bundled some crypto code but didn't exercize that code path and their build still broke".
The issue is related to AVX detection in the CPU, which has the reasonable failure path of "don't build it with AVX".
> Use of package unsafe. Packages that import unsafe may depend on internal properties of the Go implementation. We reserve the right to make changes to the implementation that may break such programs.
I suspect the crypto code you vendored used unsafe somewhere within it (whether to use `//go:linkname` or for other reasons), which would except it from the go1 compatibility promise.
See:
It doesn't seem reasonable to me. When I developed my project, vendoring /x/ projects was recommended exactly due to the breakage, so now it breaks my projects because of recommendations of the golang team.
I think the Go devs should improve in that section a bit.