5 ms·

I just compiled a fairly complex (CGo etc...) project a few weeks ago which I hadn't compiled since 2014, and it just worked. So I guess YMMV...

by steeve 6y ago

zaarn 6y ago
Of course, not every project will fail, but in my case it failed and I think that is the issue.
- steeve 6y ago
  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...
  - zaarn 6y ago
    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.
    - coldtea 6y ago
      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..
      - hibbelig 6y ago
        @zaarn explained in another comment that the vulnerability did not impact him, he did not exercise that code path.
        coldtea 6y ago
        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".
        zaarn 6y ago
        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".
    - steeve 6y ago
      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.
      - zaarn 6y ago
        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.
        steeve 6y ago
        I believe this commit has background: https://github.com/golang/crypto/commit/d6449816ce06963d9d136eee5a56fca5b0616e7e#diff-08466c4c14798cc53ca7d9080070e62f https://github.com/golang/crypto/commit/d6449816ce06963d9d13... To be fair though, that package was depending on a private API to begin with.

I just compiled a fairly complex (CGo etc...) project a few weeks ago which I hadn't compiled since 2014, and it just worked. So I guess YMMV...

by steeve 6y ago

I just compiled a fairly complex (CGo etc...) project a few weeks ago which I hadn't compiled since 2014, and it just worked. So I guess YMMV...

zaarn 6y ago

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

steeve 6y ago
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...
- zaarn 6y ago
  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.
  - coldtea 6y ago
    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..
    - hibbelig 6y ago
      @zaarn explained in another comment that the vulnerability did not impact him, he did not exercise that code path.
      - coldtea 6y ago
        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".
        zaarn 6y ago
        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".
  - steeve 6y ago
    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.
    - zaarn 6y ago
      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.
      - steeve 6y ago
        I believe this commit has background: https://github.com/golang/crypto/commit/d6449816ce06963d9d136eee5a56fca5b0616e7e#diff-08466c4c14798cc53ca7d9080070e62f https://github.com/golang/crypto/commit/d6449816ce06963d9d13... To be fair though, that package was depending on a private API to begin with.