go, branch go1.13.1

[release-branch.go1.13-security] go1.13.1

2019-09-25T18:48:17Z

Change-Id: I371ff39537fc617a2462cc947dd717b53ede7bcc Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/558790 Reviewed-by: Dmitri Shuralyov

[release-branch.go1.13-security] doc: add Go 1.13 to release history

2019-09-25T17:33:40Z

Change-Id: I3340561c0b17bf28d8d480e00f5bc8afb2a897ef Reviewed-on: https://go-review.googlesource.com/c/go/+/193042 Run-TryBot: Andrew Bonventre Reviewed-by: Katie Hockman Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/558786 Reviewed-by: Dmitri Shuralyov

[release-branch.go1.13-security] net/textproto: don't normalize headers with spaces before the colon

2019-09-25T17:15:11Z

RFC 7230 is clear about headers with a space before the colon, like X-Answer : 42 being invalid, but we've been accepting and normalizing them for compatibility purposes since CL 5690059 in 2012. On the client side, this is harmless and indeed most browsers behave the same to this day. On the server side, this becomes a security issue when the behavior doesn't match that of a reverse proxy sitting in front of the server. For example, if a WAF accepts them without normalizing them, it might be possible to bypass its filters, because the Go server would interpret the header differently. Worse, if the reverse proxy coalesces requests onto a single HTTP/1.1 connection to a Go server, the understanding of the request boundaries can get out of sync between them, allowing an attacker to tack an arbitrary method and path onto a request by other clients, including authentication headers unknown to the attacker. This was recently presented at multiple security conferences: https://portswigger.net/blog/http-desync-attacks-request-smuggling-reborn net/http servers already reject header keys with invalid characters. Simply stop normalizing extra spaces in net/textproto, let it return them unchanged like it does for other invalid headers, and let net/http enforce RFC 7230, which is HTTP specific. This loses us normalization on the client side, but there's no right answer on the client side anyway, and hiding the issue sounds worse than letting the application decide. Fixes CVE-2019-16276 Change-Id: I6d272de827e0870da85d93df770d6a0e161bbcf1 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/549719 Reviewed-by: Brad Fitzpatrick (cherry picked from commit 1280b868e82bf173ea3e988be3092d160ee66082) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/558935 Reviewed-by: Dmitri Shuralyov

[release-branch.go1.13-security] doc: document Go 1.13.1 and Go 1.12.10

2019-09-25T17:12:25Z

Change-Id: If694ce529393b8ae9c6c55270665efc3a108a3b2 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/558783 Reviewed-by: Dmitri Shuralyov

[release-branch.go1.13] go1.13

2019-09-03T17:05:17Z

Change-Id: Iad80da6df9a6f9a39458e1060bed3557a5ed89a4 Reviewed-on: https://go-review.googlesource.com/c/go/+/193037 Run-TryBot: Andrew Bonventre TryBot-Result: Gobot Gobot Reviewed-by: Bryan C. Mills Reviewed-by: Alexander Rakoczy Reviewed-by: Filippo Valsorda Reviewed-by: Brad Fitzpatrick Reviewed-by: Andrew Bonventre

[release-branch.go1.13] doc/go1.13: remove announcements of arm64 support on NetBSD and OpenBSD

2019-09-03T13:47:38Z

Those configurations currently lack builders, and it is not clear to me what state their tests are in. The Go porting policy¹ requires builders for all active ports, so let's not claim support until that requirement is met. ¹https://golang.org/wiki/PortingPolicy#requirements-for-a-new-port Updates #30824 Updates #31656 Updates #34035 Updates #34036 Change-Id: I6496de9d92fb8546048abf139cf10546a47e314b Reviewed-on: https://go-review.googlesource.com/c/go/+/192997 Reviewed-by: Dmitri Shuralyov (cherry picked from commit 9f5127bfebfc8c3acec4dbb374ff5c0d4c586565) Reviewed-on: https://go-review.googlesource.com/c/go/+/192998 Run-TryBot: Bryan C. Mills

[release-branch.go1.13] os: skip TestPipeThreads on GOOS=darwin

2019-09-03T01:03:47Z

Updates #32326. Updates #33953. Change-Id: I97a1cbe682becfe9592e19294d4d94f5e5b16c21 Reviewed-on: https://go-review.googlesource.com/c/go/+/192342 Run-TryBot: Emmanuel Odeke TryBot-Result: Gobot Gobot Reviewed-by: Ian Lance Taylor (cherry picked from commit bac5b3f0fe7838ecf6e206fa8d2123c7771eb976) Reviewed-on: https://go-review.googlesource.com/c/go/+/192757 Run-TryBot: Andrew Bonventre Reviewed-by: Dmitri Shuralyov

[release-branch.go1.13] net/http: make docs refer to Context.Value as a getter instead of context.WithValue

2019-09-02T21:51:40Z

The doc comments of both ServerContextKey and LocalAddrContextKey both suggest that context.WithValue can be used to access (get) properties of the server or connection. This PR fixes those comments to refer to Context.Value instead. Change-Id: I4ed383ef97ba1951f90c555243007469cfc18d4d GitHub-Last-Rev: 05bc3acf82322e3dc77abc7fa0412efe01a77eac GitHub-Pull-Request: golang/go#33833 Reviewed-on: https://go-review.googlesource.com/c/go/+/191838 Reviewed-by: Brad Fitzpatrick (cherry picked from commit 8b03a3992bc755eadbccc10d97adc21d0b229401) Reviewed-on: https://go-review.googlesource.com/c/go/+/191750 Reviewed-by: Andrew Bonventre Run-TryBot: Andrew Bonventre TryBot-Result: Gobot Gobot

[release-branch.go1.13] doc: document Go 1.13

2019-09-02T21:44:50Z

Change-Id: Icf7e1dab82aa48cc693eb4da8a564dff23312741 Reviewed-on: https://go-review.googlesource.com/c/go/+/192746 Run-TryBot: Andrew Bonventre TryBot-Result: Gobot Gobot Reviewed-by: Dmitri Shuralyov

[release-branch.go1.13] doc/1.13: remove draft note and make various fixes

2019-09-02T21:43:53Z

Updates #33954 Change-Id: Idfe71bf825adcd7cbf70cd139b3e779963394ff6 Reviewed-on: https://go-review.googlesource.com/c/go/+/192105 Run-TryBot: Andrew Bonventre TryBot-Result: Gobot Gobot Reviewed-by: Katie Hockman (cherry picked from commit dec16794cf9136f8887e08391c01f1265b876ddb) Reviewed-on: https://go-review.googlesource.com/c/go/+/192743 Reviewed-by: Dmitri Shuralyov