Revert "lock to go 1.20.7"

[sparrc]

This reverts commit 7ea28b0.

Issue #, if available:

#746

Description of changes:

This commit was originally added to pin the golang build version to 1.20.7 because of an issue in golang related to CGO: golang/go#62130 (comment)

This issue was fixed for most systems, although the issue is still open because it appears to have opened up a separate issue with MUSL-based systems (such as alpine): golang/go#68285

Since the fluent-bit container is on a glibc-based system (Amazon Linux), we should be safe to revert back to building with the latest version of golang.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[swapneils]

Looks good! Thanks for also checking the scope of the Golang-side changes.

We can publish this in the upcoming 2.32.3.

[aaithal]

thanks! i do have one question though. I see that we're using AL2 as the base image (Switching to AL2023 is topic for another day). Why would we not want to install the golang version that's packaged in AL2 repos vs doing our own "stable" determinations? What's the harm in doing something like RUN yum install -y golang? The advantage is that we don't have to figure out a CVE/patching story for golang ourselves. We have AL maintainers for that.

[sparrc]

thanks! i do have one question though. I see that we're using AL2 as the base image (Switching to AL2023 is topic for another day). Why would we not want to install the golang version that's packaged in AL2 repos vs doing our own "stable" determinations? What's the harm in doing something like RUN yum install -y golang? The advantage is that we don't have to figure out a CVE/patching story for golang ourselves. We have AL maintainers for that.

I think there are two main advantages to building with the latest golang version for now:

1. We get onto the latest version of golang with all CVE fixes as soon as possible and avoid having to wait on Amazon Linux releasing the latest CVE patches to their yum repos.
2. We are made aware as soon as possible when the latest golang version might have some change, bug, or incompatibility with our build process.

So far we have been able to rely on the latest golang version being stable and not causing us any major issues so I don't think we currently have any strong reason to hold back on picking up the latest as soon as it's available.

[aaithal]

thanks! i do have one question though. I see that we're using AL2 as the base image (Switching to AL2023 is topic for another day). Why would we not want to install the golang version that's packaged in AL2 repos vs doing our own "stable" determinations? What's the harm in doing something like RUN yum install -y golang? The advantage is that we don't have to figure out a CVE/patching story for golang ourselves. We have AL maintainers for that.

I think there are two main advantages to building with the latest golang version for now:

1. We get onto the latest version of golang with all CVE fixes as soon as possible and avoid having to wait on Amazon Linux releasing the latest CVE patches to their yum repos.
2. We are made aware as soon as possible when the latest golang version might have some change, bug, or incompatibility with our build process.

So far we have been able to rely on the latest golang version being stable and not causing us any major issues so I don't think we currently have any strong reason to hold back on picking up the latest as soon as it's available.

I don't want to hold off this PR for now. But, I do think we need to revisit this. Supply chain integrity is an important aspect of security and by not relying on AL vended golang binaries, we are vulnerable to mitm attacks or attackers compromising 3rd party repos that we're depending on for our golang binaries.

If we're out of compliance because AL hasn't caught up with CVEs, we have bigger issues at that point anyway because the container image as a whole would not be considered compliant.

But as I said earlier, I don't want to hold off this PR for now. But, we need to revisit how we consume all of our dependencies more holistically.