[3.5] Backport bump to go 1.19.6 and golang.org/x/net to v0.7.0

[jmhbnz]

Golang 1.17 is out of support; and all active K8s branches (1.23 ~ 1.26) have already bumped to 1.19.

Additionally the x/net package has a CVE we need to address: https://pkg.go.dev/vuln/GO-2023-1571

Part of #15332

[ahrtr]

Note this PR can resolve the following CVEs (score 7.5 high) beside the https://pkg.go.dev/vuln/GO-2023-1571:

• https://nvd.nist.gov/vuln/detail/CVE-2022-27664
• https://nvd.nist.gov/vuln/detail/CVE-2022-41715
• https://nvd.nist.gov/vuln/detail/CVE-2022-2880
• https://nvd.nist.gov/vuln/detail/CVE-2022-2879
• https://nvd.nist.gov/vuln/detail/CVE-2022-41716
• https://nvd.nist.gov/vuln/detail/CVE-2022-41720

@jmhbnz could you resolve the workflow (linux-amd64-fmt) failure?

[ahrtr]

cc @mitake @ptabor @serathius @spzala

[jmhbnz]

@jmhbnz could you resolve the workflow (linux-amd64-fmt) failure?

Looks like a bit more than a standard go fmt error, the receiver_name test from ./tests.sh failed with:

 'receiver_name' started at Mon Feb 20 08:36:39 UTC 2023
Mismatched receiver for Copy(w...
func (d *dispatcherPool) Copy(w io.Writer, f fetchFunc) error {
func (d *dispatcherImmediate) Copy(w io.Writer, f fetchFunc) error {
FAIL: 'receiver_name' failed at Mon Feb 20 08:36:41 UTC 2023

I'm not sure why but when I run the same GOARCH=amd64 PASSES='fmt bom dep' ./test.sh that the actions workflow is running it does get to the receiver_name section then seems to hang.

While the actions output doesn't print a filename I think the code it's worried about is in tools/local-tester/bridge/dispatch.go.

@ahrtr are you able to give me any guidance or background on resolving a receiver mismatch?

[ahrtr]

It seems we need to update the go_srcs_in_module per the main branch.

Please try it out.

[jmhbnz]

It seems we need to update the go_srcs_in_module per the main branch.

Pushed a new commit that brings the changes to that function back to 3.5. It did open a can of worms with goword so I worked my way through fixing all those, hopefully that was the right approach 🙏🏻

[ahrtr]

LGTM

Thanks @jmhbnz

We can ignore the workflow failure for Release, because it always runs test against upstream release-3.5 instead of the dev branch.

cc @mitake @ptabor @serathius @spzala PTAL. I think this PR is required for etcd 3.5.8, because it resolves some high CVEs.

[ahrtr]

@jmhbnz Could you please update both 3.5 and 3.4 changelog?

[ahrtr]

This PR also resolved CVE-2022-41723.

We recently resolved a couple of high CVEs, I suggest to release 3.5.8 and 3.4.25 soon. All other bug fixes can be included in next patches. cc @mitake @ptabor @serathius @spzala

I think we need also clearly document that we should release patches asap to address any CVE with a score >= 7.5, unless there is any critical issue which must be included in next patch, otherwise no reason to wait. WDYT