Of course, not every project will fail, but in my case it failed and I think that is the issue.

Do you remember the specifics? I am not aware of syntax constructs that were removed in Go, I guess ever.

EDIT: I'm sad folks are downvoting for asking a question...

Older versions of the /x/crypto library no longer compile on newer go versions, there wasn't any indication this would happen and I vendored the library to avoid the API breakage in that library. From my standpoint, that completely ruins using that library as after 3 years either I vendored it and it breaks because of something the go compiler does or I didn't vendor it but the API changed. Either way, my program will break eventually and there is no way to avoid it.

I'm sorry you had this experience. I'm genuinely curious as to what the breakage was so hopefully we can prevent it for some other folks, hence why I asked if you remembered the specifics.

Basically, x/crypto/blake2b received a patch to switch how it detects the presence of AVX and SSE at runtime, the symbols required for that to work with earlier versions where removed. While I understand this is technically covered in the compatibility promise, it's very frustrating when it happens with a library developed by google, especially when, at the time, the general recommendation was to vendor them so as to not suffer from breakage when they update.

I believe this commit has background: https://github.com/golang/crypto/commit/d6449816ce06963d9d13...

To be fair though, that package was depending on a private API to begin with.

Well, that's for the better still.

If you use vulnerable crypto (willing to go with old unpatched vendored code) then you don't really need crypto at all..

@zaarn explained in another comment that the vulnerability did not impact him, he did not exercise that code path.

I understand that, but it's not really relevant.

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".

I exercized a code path that broke, it's not like unrelated code broke, it was code I was actually using in a commit in the upstream library that changed not much for the end user and then was broken by the compiler fairly soon after.

The issue is related to AVX detection in the CPU, which has the reasonable failure path of "don't build it with AVX".