go, branch go1.19.6

[release-branch.go1.19] go1.19.6

2023-02-14T18:09:51Z

Change-Id: Iaafff862e746e7c81a6df9ca9b7b6179efe1172e Reviewed-on: https://go-review.googlesource.com/c/go/+/468237 Reviewed-by: Michael Pratt Run-TryBot: Gopher Robot Reviewed-by: Than McIntosh Auto-Submit: Gopher Robot TryBot-Result: Gopher Robot

[release-branch.go1.19] net/http: update bundled golang.org/x/net/http2

2023-02-14T17:25:54Z

Disable cmd/internal/moddeps test, since this update includes PRIVATE track fixes. Fixes CVE-2022-41723 Fixes #58355 Updates #57855 Change-Id: Ie870562a6f6e44e4e8f57db6a0dde1a41a2b090c Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1728939 Reviewed-by: Damien Neil Reviewed-by: Julie Qiu Reviewed-by: Tatiana Bradley Run-TryBot: Roland Shoemaker Reviewed-on: https://go-review.googlesource.com/c/go/+/468118 TryBot-Result: Gopher Robot Run-TryBot: Michael Pratt Auto-Submit: Michael Pratt Reviewed-by: Than McIntosh

[release-branch.go1.19] crypto/tls: replace all usages of BytesOrPanic

2023-02-14T17:25:52Z

Message marshalling makes use of BytesOrPanic a lot, under the assumption that it will never panic. This assumption was incorrect, and specifically crafted handshakes could trigger panics. Rather than just surgically replacing the usages of BytesOrPanic in paths that could panic, replace all usages of it with proper error returns in case there are other ways of triggering panics which we didn't find. In one specific case, the tree routed by expandLabel, we replace the usage of BytesOrPanic, but retain a panic. This function already explicitly panicked elsewhere, and returning an error from it becomes rather painful because it requires changing a large number of APIs. The marshalling is unlikely to ever panic, as the inputs are all either fixed length, or already limited to the sizes required. If it were to panic, it'd likely only be during development. A close inspection shows no paths for a user to cause a panic currently. This patches ends up being rather large, since it requires routing errors back through functions which previously had no error returns. Where possible I've tried to use helpers that reduce the verbosity of frequently repeated stanzas, and to make the diffs as minimal as possible. Thanks to Marten Seemann for reporting this issue. Updates #58001 Fixes #58358 Fixes CVE-2022-41724 Change-Id: Ieb55867ef0a3e1e867b33f09421932510cb58851 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1679436 Reviewed-by: Julie Qiu TryBot-Result: Security TryBots Run-TryBot: Roland Shoemaker Reviewed-by: Damien Neil (cherry picked from commit 0f3a44ad7b41cc89efdfad25278953e17d9c1e04) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1728204 Reviewed-by: Tatiana Bradley Reviewed-on: https://go-review.googlesource.com/c/go/+/468117 Auto-Submit: Michael Pratt Run-TryBot: Michael Pratt TryBot-Result: Gopher Robot Reviewed-by: Than McIntosh

[release-branch.go1.19] mime/multipart: limit memory/inode consumption of ReadForm

2023-02-14T17:25:50Z

Reader.ReadForm is documented as storing "up to maxMemory bytes + 10MB" in memory. Parsed forms can consume substantially more memory than this limit, since ReadForm does not account for map entry overhead and MIME headers. In addition, while the amount of disk memory consumed by ReadForm can be constrained by limiting the size of the parsed input, ReadForm will create one temporary file per form part stored on disk, potentially consuming a large number of inodes. Update ReadForm's memory accounting to include part names, MIME headers, and map entry overhead. Update ReadForm to store all on-disk file parts in a single temporary file. Files returned by FileHeader.Open are documented as having a concrete type of *os.File when a file is stored on disk. The change to use a single temporary file for all parts means that this is no longer the case when a form contains more than a single file part stored on disk. The previous behavior of storing each file part in a separate disk file may be reenabled with GODEBUG=multipartfiles=distinct. Update Reader.NextPart and Reader.NextRawPart to set a 10MiB cap on the size of MIME headers. Thanks to Jakob Ackermann (@das7pad) for reporting this issue. Updates #58006 Fixes #58362 Fixes CVE-2022-41725 Change-Id: Ibd780a6c4c83ac8bcfd3cbe344f042e9940f2eab Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1714276 Reviewed-by: Julie Qiu TryBot-Result: Security TryBots Reviewed-by: Roland Shoemaker Run-TryBot: Damien Neil (cherry picked from commit ed4664330edcd91b24914c9371c377c132dbce8c) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1728949 Reviewed-by: Tatiana Bradley Run-TryBot: Roland Shoemaker Reviewed-by: Damien Neil Reviewed-on: https://go-review.googlesource.com/c/go/+/468116 TryBot-Result: Gopher Robot Reviewed-by: Than McIntosh Run-TryBot: Michael Pratt Auto-Submit: Michael Pratt

[release-branch.go1.19] path/filepath: do not Clean("a/../c:/b") into c:\b on Windows

2023-02-14T17:25:26Z

Do not permit Clean to convert a relative path into one starting with a drive reference. This change causes Clean to insert a . path element at the start of a path when the original path does not start with a volume name, and the first path element would contain a colon. This may introduce a spurious but harmless . path element under some circumstances. For example, Clean("a/../b:/../c") becomes `.\c`. This reverts CL 401595, since the change here supersedes the one in that CL. Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this issue. Updates #57274 Fixes #57275 Fixes CVE-2022-41722 Change-Id: I837446285a03aa74c79d7642720e01f354c2ca17 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1675249 Reviewed-by: Roland Shoemaker Run-TryBot: Damien Neil Reviewed-by: Julie Qiu TryBot-Result: Security TryBots (cherry picked from commit 780dfa043ff5192c37de0d6fd1053a66b2b9f378) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1728206 Reviewed-by: Damien Neil Run-TryBot: Roland Shoemaker Reviewed-by: Tatiana Bradley Reviewed-on: https://go-review.googlesource.com/c/go/+/468115 Reviewed-by: Than McIntosh Run-TryBot: Michael Pratt Auto-Submit: Michael Pratt TryBot-Bypass: Michael Pratt

[release-branch.go1.19] cmd/link: keep go.buildinfo even with --gc-sections

2023-02-10T17:30:36Z

If you use an external linker with --gc-sections, nothing refers to .go.buildinfo, so the section is deleted, which in turns makes 'go version' fail on the binary. It is important for vulnerability scanning and the like to be able to run 'go version' on any binary. Fix this by inserting a reference to .go.buildinfo from the rodata section, which will not be GC'ed. Fixes #58222. Fixes #58223. Change-Id: I1e13e9464acaf2f5cc5e0b70476fa52b43651123 Reviewed-on: https://go-review.googlesource.com/c/go/+/464435 Run-TryBot: Russ Cox Reviewed-by: Cherry Mui Reviewed-by: Than McIntosh Auto-Submit: Russ Cox TryBot-Result: Gopher Robot Reviewed-on: https://go-review.googlesource.com/c/go/+/464795

[release-branch.go1.19] cmd/go: remove tests that assume lack of new versions of external modules

2023-02-10T17:29:31Z

In general it seems ok to assume that an open-source module that did exist will continue to do so — after all, users of open-source modules already do that all the time. However, we should not assume that those modules do not publish new versions — that's really up to their maintainers to decide. Two existing tests did make that assumption for the module gopkg.in/natefinch/lumberjack.v2. Let's remove those two tests. If we need to replace them at some point, we can replace them with hermetic test-only modules (#54503) or perhaps modules owned by the Go project. Updates #58445. Fixes #58449. Change-Id: Ica8fe587d86fc41f3d8445a4cd2b8820455ae45f Reviewed-on: https://go-review.googlesource.com/c/go/+/466862 Reviewed-by: David Chase Run-TryBot: Bryan Mills TryBot-Result: Gopher Robot

[release-branch.go1.19] cmd/go: skip test cases that depend on gopkg.in

2023-02-09T20:12:58Z

Updates #54503. Change-Id: Ie13d028b09260d2d316c343b3ea812bb9cce4e6d Reviewed-on: https://go-review.googlesource.com/c/go/+/424594 Auto-Submit: Bryan Mills TryBot-Result: Gopher Robot Run-TryBot: Bryan Mills Reviewed-by: Russ Cox (cherry picked from commit c7f870ebc41029e07e7ffd8ff2d96b91fd83cd40) Reviewed-on: https://go-review.googlesource.com/c/go/+/466857 Reviewed-by: Heschi Kreinick Run-TryBot: David Chase Reviewed-by: Than McIntosh

[release-branch.go1.19] time: update windows zoneinfo_abbrs

2023-02-09T18:52:56Z

zoneinfo_abbrs hasn't been updated since go 1.14, it's time to regenerate it. Fixes #58118. Change-Id: Ic156ae607c46f1f5a9408b1fc0b56de6c14a4ed4 Reviewed-on: https://go-review.googlesource.com/c/go/+/463838 Reviewed-by: Alex Brainman Run-TryBot: Quim Muntal TryBot-Result: Gopher Robot Reviewed-by: Bryan Mills Reviewed-by: Dmitri Shuralyov (cherry picked from commit 007d8f4db1f890f0d34018bb418bdc90ad4a8c35) Reviewed-on: https://go-review.googlesource.com/c/go/+/466555 TryBot-Bypass: David Chase Run-TryBot: David Chase Reviewed-by: Quim Muntal Reviewed-by: Than McIntosh

[release-branch.go1.19] net/http: accept HEAD requests with a body

2023-01-30T17:13:30Z

RFC 7231 permits HEAD requests to contain a body, although it does state there are no defined semantics for payloads of HEAD requests and that some servers may reject HEAD requests with a payload. Accept HEAD requests with a body. Fix a bug where a HEAD request with a chunked body would interpret the body as the headers for the next request on the connection. For #53960. For #56154. Change-Id: I83f7112fdedabd6d6291cd956151d718ee6942cd Reviewed-on: https://go-review.googlesource.com/c/go/+/418614 Run-TryBot: Damien Neil Reviewed-by: Brad Fitzpatrick Reviewed-by: Cherry Mui TryBot-Result: Gopher Robot Reviewed-on: https://go-review.googlesource.com/c/go/+/457438 Reviewed-by: Than McIntosh