commit 8febd417255233249076f0101fcd9d2cf48d9bd2 [browse]
Author: Sergey Matveev
Date: 2023-07-11 20:51:16 +03:00

Autogenerated TLS-related strings

go install golang.org/x/tools/cmd/stringer@latest
cd src/crypto/tls ; go generate

commit 7311c4331604bc9dda6fa96fca482e6213c2a58d [browse]
Author: Sergey Matveev
Date: 2023-02-02 00:19:57 +03:00

GOST X.509 and TLS 1.3 support via GoGOST

commit 2c358ffe9762ba08c8db0196942395f97775e31b [browse]
Author: Gopher Robot
Date: 2023-07-11 15:32:23 Z

[release-branch.go1.20] go1.20.6

Change-Id: I9dc89e8bca8cd6262f85be1266c53f53ab8c55a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/508838
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Joedian Reid <joedian@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Gopher Robot <gobot@golang.org>
Auto-Submit: Gopher Robot <gobot@golang.org>

commit 312920c00aac9897b2a0693e752390b5b0711a5a [browse]
Author: Damien Neil
Date: 2023-06-28 13:20:08 -07:00

[release-branch.go1.20] net/http: validate Host header before sending

Verify that the Host header we send is valid.
Avoids surprising behavior such as a Host of "go.dev\r\nX-Evil:oops"
adding an X-Evil header to HTTP/1 requests.

Add a test, skip the test for HTTP/2. HTTP/2 is not vulnerable to
header injection in the way HTTP/1 is, but x/net/http2 doesn't validate
the header and will go into a retry loop when the server rejects it.
CL 506995 adds the necessary validation to x/net/http2.

For #60374
Fixes #61076
For CVE-2023-29406

Change-Id: I05cb6866a9bead043101954dfded199258c6dd04
Reviewed-on: https://go-review.googlesource.com/c/go/+/506996
Reviewed-by: Tatiana Bradley <tatianabradley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
(cherry picked from commit 499458f7ca04087958987a33c2703c3ef03e27e2)
Reviewed-on: https://go-review.googlesource.com/c/go/+/507357
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Tatiana Bradley <tatianabradley@google.com>
Reviewed-by: Roland Shoemaker <roland@golang.org>

commit 4db13d762ba3f3487677087a3c5a6221b4c3bd8f [browse]
Author: Jelle van den Hooff
Date: 2023-06-21 18:28:05 -07:00

[release-branch.go1.20] runtime: set raceignore to zero when starting a new goroutine

When reusing a g struct the runtime did not reset
g.raceignore. Initialize raceignore to zero when initially
setting racectx.

A goroutine can end with a non-zero raceignore if it exits
after calling runtime.RaceDisable without a matching
runtime.RaceEnable. If that goroutine's g is later reused
the race detector is in a weird state: the underlying
g.racectx is active, yet g.raceignore is non-zero, and
raceacquire/racerelease which check g.raceignore become
no-ops. This causes the race detector to report races when
there are none.

For #60934
Fixes #60949

Change-Id: Ib8e412f11badbaf69a480f03740da70891f4093f
Reviewed-on: https://go-review.googlesource.com/c/go/+/505055
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit 48dbb6227acf3ebc8ac21924567aa2b6d5064915)
Reviewed-on: https://go-review.googlesource.com/c/go/+/505676
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>