4 ms·
I had the same issue. The issue was a security one https://nvd.nist.gov/vuln/detail/CVE-2019-11840 https://nvd.nist.gov/vuln/detail/CVE-2019-11840 which require
by jeffsmith82 6y ago
I had the same issue. The issue was a security one https://nvd.nist.gov/vuln/detail/CVE-2019-11840 https://nvd.nist.gov/vuln/detail/CVE-2019-11840 which required a breaking change to fix so their options where leave everyone vulnerable but could compile or break anyone that uses this code and fix it. I think they made the right choice.
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.
- zaarn 6y agoNeither of those things applied though; I had x/crypto vendored, so it didn't change it's code either and the CVE is unrelated to the actual code that broke (I used blake2b) and again; it was vendored, so my code wouldn't break but be vulnerable.
- Scaevolus 6y agoHow did vendored code that didn't change break your build?
- zaarn 6y agoI updated the compiler.
- TheDong 6y agoThe easiest way to accomplish that is definitely with //go:linkname 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)