Update to Go 1.23 and bump golang.org/x/crypto v0.36.0

[Luap99]

What type of PR is this?

/kind api-change
/kind bug
/kind cleanup
/kind deprecation
/kind design
/kind documentation
/kind failing-test
/kind feature
/kind flake
/kind other

What this PR does / why we need it:

How to verify it

Which issue(s) this PR fixes:

Fixes: CVE-2025-22869
Fixes: https://issues.redhat.com/browse/RHEL-82771
Fixes: https://issues.redhat.com/browse/RHEL-81310

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Update minimum go version to 1.23

[packit-as-a-service]

Ephemeral COPR build failed. @containers/packit-build please check.

[lsm5]

LGTM

[lsm5]

@Luap99 Line 97 in .packit.yaml needs to be adjusted as well. Only do x86_64 arches over there. That will make the f40 testing-farm and rpm build job go away.

[lsm5]

LGTM .

[Luap99]

@nalind @TomSweeneyRedHat PTAL

[mtrmac]

LGTM otherwise — or if @lsm5 doesn’t think the comments are needed, please merge as is.

[mtrmac]

If the goal is to revert the targets changes in the file, a comment saying saying that we’d prefer to use fedora-all-… and that we are restricting F40 because of Go 1.22 would be nice (in both places).

[lsm5]

LGTM otherwise — or if @lsm5 doesn’t think the comments are needed, please merge as is.

LGTM. I won't block on this. While commenting is surely nice, I'm guilty of not doing this in packit config myself. And we can switch back to fedora-all in about 2 months. Besides, I wonder how many people besides upstream maintainers and ones doing CI even care.

Looks like the branch needs a rebase though.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lsm5, Luap99

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [lsm5]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Luap99]

Looks like the branch needs a rebase though.

It really doesn't, there is no merge conflict here. If I have to rebase every time something unrelated merges we never get stuff in timely and waste a bunch of time rebasing.

[lsm5]

Looks like the branch needs a rebase though.

It really doesn't, there is no merge conflict here. If I have to rebase every time something unrelated merges we never get stuff in timely and waste a bunch of time rebasing.

Sure, but IIRC, out-of-date branches are blocked from merge on buildah for whatever reason. I noticed that in #5885 at least and I don't remember any conflicts there. But I'll wait for @nalind / @flouthoc to give a slash-lgtm and see if things are different this time.

[nalind]

I'm not aware of a mechanical requirement for rebasing when a PR is out of date, unless there's a merge conflict.

[Luap99]

Require branches to be up to date before merging This ensures pull requests targeting a matching branch have been tested with the latest code. This setting will not take effect unless at least one status check is enabled (see below).

Looks like you have set this on here so github will block the merge, not sure if the openshift merge bot can merge regardless.

[nalind]

The bot evidently bypasses this (though I could've sworn we configured it to pay attention to branch protection rules a while back) — we've had merge commits within the last week.

[Luap99]

The openshift bot is only configured to block on "Total Success" in its config file. However I have seen inconstant results between github merge protection and the bot so honestly I don't even know what the expected behavior around it actually is.