delta/go-git.git/src/net, branch dev.boringcrypto.go1.12 github.com: golang/go [release-branch.go1.12] net/http: avoid writing to Transport.ProxyConnectHeader 2020-01-07T22:39:30+00:00 Bryan C. Mills bcmills@google.com 2020-01-07T17:03:28+00:00 c5af2aa0037b39db801154451a3f70982751d988 Previously, we accidentally wrote the Proxy-Authorization header for the initial CONNECT request to the shared ProxyConnectHeader map when it was non-nil. Updates #36431 Fixes #36433 Change-Id: I5cb414f391dddf8c23d85427eb6973f14c949025 Reviewed-on: https://go-review.googlesource.com/c/go/+/213638 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> (cherry picked from commit 249c85d3aab2ad2d0bcbf36efe606fdd66f25c72) Reviewed-on: https://go-review.googlesource.com/c/go/+/213677 
Previously, we accidentally wrote the Proxy-Authorization header for
the initial CONNECT request to the shared ProxyConnectHeader map when
it was non-nil.

Updates #36431
Fixes #36433

Change-Id: I5cb414f391dddf8c23d85427eb6973f14c949025
Reviewed-on: https://go-review.googlesource.com/c/go/+/213638
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 249c85d3aab2ad2d0bcbf36efe606fdd66f25c72)
Reviewed-on: https://go-review.googlesource.com/c/go/+/213677
[release-branch.go1.12] net: avoid an infinite loop in LookupAddr 2019-10-03T02:07:10+00:00 Brad Fitzpatrick bradfitz@golang.org 2019-10-02T20:59:27+00:00 273d946ec451a0722d21ac12494be7e367bbaac6 If a request for a PTR record returned a response with a non-PTR answer, goLookupPTR would loop forever. Skipping non-PTR answers guarantees progress through the DNS response. Fixes #34661 Updates #34660 Change-Id: Ib5e5263243bc34b9e2f85aa2b913c9cd50dbcaa5 Reviewed-on: https://go-review.googlesource.com/c/go/+/198497 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> 
If a request for a PTR record returned a response with a non-PTR
answer, goLookupPTR would loop forever.  Skipping non-PTR answers
guarantees progress through the DNS response.

Fixes #34661
Updates #34660

Change-Id: Ib5e5263243bc34b9e2f85aa2b913c9cd50dbcaa5
Reviewed-on: https://go-review.googlesource.com/c/go/+/198497
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
[release-branch.go1.12-security] net/textproto: don't normalize headers with spaces before the colon 2019-09-25T17:15:22+00:00 Filippo Valsorda filippo@golang.org 2019-09-12T16:37:36+00:00 6e6f4aaf70c8b1cc81e65a26332aa9409de03ad8 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 <bradfitz@google.com> (cherry picked from commit 1280b868e82bf173ea3e988be3092d160ee66082) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/558776 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> 
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 <bradfitz@google.com>
(cherry picked from commit 1280b868e82bf173ea3e988be3092d160ee66082)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/558776
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
[release-branch.go1.12-security] net/url: make Hostname and Port predictable for invalid Host values 2019-08-12T23:49:46+00:00 Filippo Valsorda filippo@golang.org 2019-08-06T23:32:16+00:00 3226f2d492963d361af9dfc6714ef141ba606713 When Host is not valid per RFC 3986, the behavior of Hostname and Port was wildly unpredictable, to the point that Host could have a suffix that didn't appear in neither Hostname nor Port. This is a security issue when applications are applying checks to Host and expecting them to be meaningful for the contents of Hostname. To reduce disruption, this change only aims to guarantee the following two security-relevant invariants. * Host is either Hostname or [Hostname] with Port empty, or Hostname:Port or [Hostname]:Port. * Port is only decimals. The second invariant is the one that's most likely to cause disruption, but I believe it's important, as it's conceivable an application might do a suffix check on Host and expect it to be meaningful for the contents of Hostname (if the suffix is not a valid port). There are three ways to ensure it. 1) Reject invalid ports in Parse. Note that non-numeric ports are already rejected if and only if the host starts with "[". 2) Consider non-numeric ports as part of Hostname, not Port. 3) Allow non-numeric ports, and hope they only flow down to net/http, which will reject them (#14353). This change adopts both 1 and 2. We could do only the latter, but then these invalid hosts would flow past port checks, like in http_test.TestTransportRejectsAlphaPort. Non-numeric ports weren't fully supported anyway, because they were rejected after IPv6 literals, so this restores consistency. We could do only the former, but at this point 2) is free and might help with manually constructed Host values (or if we get something wrong in Parse). Note that net.SplitHostPort and net.Dial explicitly accept service names in place of port numbers, but this is an URL package, and RFC 3986, Section 3.2.3, clearly specifies ports as a number in decimal. net/http uses a mix of net.SplitHostPort and url.Parse that would deserve looking into, but in general it seems that it will still accept service names in Addr fields as they are passed to net.Listen, while rejecting them in URLs, which feels correct. This leaves a number of invalid URLs to reject, which however are not security relevant once the two invariants above hold, so can be done in Go 1.14: IPv6 literals without brackets (#31024), invalid IPv6 literals, hostnames with invalid characters, and more. Tested with 200M executions of go-fuzz and the following Fuzz function. u, err := url.Parse(string(data)) if err != nil { return 0 } h := u.Hostname() p := u.Port() switch u.Host { case h + ":" + p: return 1 case "[" + h + "]:" + p: return 1 case h: fallthrough case "[" + h + "]": if p != "" { panic("unexpected Port()") } return 1 } panic("Host is not a variant of [Hostname]:Port") Fixes CVE-2019-14809 Updates #29098 Change-Id: I7ef40823dab28f29511329fa2d5a7fb10c3ec895 Reviewed-on: https://go-review.googlesource.com/c/go/+/189258 Reviewed-by: Ian Lance Taylor <iant@golang.org> (cherry picked from commit 61bb56ad63992a3199acc55b2537c8355ef887b6) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526408 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> 
When Host is not valid per RFC 3986, the behavior of Hostname and Port
was wildly unpredictable, to the point that Host could have a suffix
that didn't appear in neither Hostname nor Port.

This is a security issue when applications are applying checks to Host
and expecting them to be meaningful for the contents of Hostname.

To reduce disruption, this change only aims to guarantee the following
two security-relevant invariants.

* Host is either Hostname or [Hostname] with Port empty, or
  Hostname:Port or [Hostname]:Port.

* Port is only decimals.

The second invariant is the one that's most likely to cause disruption,
but I believe it's important, as it's conceivable an application might
do a suffix check on Host and expect it to be meaningful for the
contents of Hostname (if the suffix is not a valid port).

There are three ways to ensure it.

1) Reject invalid ports in Parse. Note that non-numeric ports are
   already rejected if and only if the host starts with "[".

2) Consider non-numeric ports as part of Hostname, not Port.

3) Allow non-numeric ports, and hope they only flow down to net/http,
   which will reject them (#14353).

This change adopts both 1 and 2. We could do only the latter, but then
these invalid hosts would flow past port checks, like in
http_test.TestTransportRejectsAlphaPort. Non-numeric ports weren't fully
supported anyway, because they were rejected after IPv6 literals, so
this restores consistency. We could do only the former, but at this
point 2) is free and might help with manually constructed Host values
(or if we get something wrong in Parse).

Note that net.SplitHostPort and net.Dial explicitly accept service names
in place of port numbers, but this is an URL package, and RFC 3986,
Section 3.2.3, clearly specifies ports as a number in decimal.

net/http uses a mix of net.SplitHostPort and url.Parse that would
deserve looking into, but in general it seems that it will still accept
service names in Addr fields as they are passed to net.Listen, while
rejecting them in URLs, which feels correct.

This leaves a number of invalid URLs to reject, which however are not
security relevant once the two invariants above hold, so can be done in
Go 1.14: IPv6 literals without brackets (#31024), invalid IPv6 literals,
hostnames with invalid characters, and more.

Tested with 200M executions of go-fuzz and the following Fuzz function.

	u, err := url.Parse(string(data))
	if err != nil {
		return 0
	}
	h := u.Hostname()
	p := u.Port()

	switch u.Host {
	case h + ":" + p:
		return 1
	case "[" + h + "]:" + p:
		return 1
	case h:
		fallthrough
	case "[" + h + "]":
		if p != "" {
			panic("unexpected Port()")
		}
		return 1
	}
	panic("Host is not a variant of [Hostname]:Port")

Fixes CVE-2019-14809
Updates #29098

Change-Id: I7ef40823dab28f29511329fa2d5a7fb10c3ec895
Reviewed-on: https://go-review.googlesource.com/c/go/+/189258
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 61bb56ad63992a3199acc55b2537c8355ef887b6)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526408
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
[release-branch.go1.12-security] net/http: update bundled http2 to import security fix 2019-08-12T21:44:22+00:00 Filippo Valsorda filippo@golang.org 2019-08-12T20:45:15+00:00 7139b45d1410ded14e1e131151fd8dfc435ede6c Apply the following unpublished golang.org/x/net commit. commit cdfb69ac37fc6fa907650654115ebebb3aae2087 Author: Filippo Valsorda <filippo@golang.org> Date: Sun Aug 11 02:12:18 2019 -0400 [release-branch.go1.12] http2: limit number of control frames in server send queue An attacker could cause servers to queue an unlimited number of PING ACKs or RST_STREAM frames by soliciting them and not reading them, until the program runs out of memory. Limit control frames in the queue to a few thousands (matching the limit imposed by other vendors) by counting as they enter and exit the scheduler, so the protection will work with any WriteScheduler. Once the limit is exceeded, close the connection, as we have no way to communicate with the peer. Change-Id: I842968fc6ed3eac654b497ade8cea86f7267886b Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/525552 Reviewed-by: Brad Fitzpatrick <bradfitz@google.com> (cherry picked from commit 589ad6cc5321fb68a90370348a241a5da0a2cc80) Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526069 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Fixes CVE-2019-9512 and CVE-2019-9514 Updates #33606 Change-Id: I282b3e0fa22422d9ea0d07f4a3935685ce4a7433 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526071 Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> 
Apply the following unpublished golang.org/x/net commit.

    commit cdfb69ac37fc6fa907650654115ebebb3aae2087
    Author: Filippo Valsorda <filippo@golang.org>
    Date:   Sun Aug 11 02:12:18 2019 -0400

    [release-branch.go1.12] http2: limit number of control frames in server send queue

    An attacker could cause servers to queue an unlimited number of PING
    ACKs or RST_STREAM frames by soliciting them and not reading them, until
    the program runs out of memory.

    Limit control frames in the queue to a few thousands (matching the limit
    imposed by other vendors) by counting as they enter and exit the scheduler,
    so the protection will work with any WriteScheduler.

    Once the limit is exceeded, close the connection, as we have no way to
    communicate with the peer.

    Change-Id: I842968fc6ed3eac654b497ade8cea86f7267886b
    Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/525552
    Reviewed-by: Brad Fitzpatrick <bradfitz@google.com>
    (cherry picked from commit 589ad6cc5321fb68a90370348a241a5da0a2cc80)
    Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526069
    Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

Fixes CVE-2019-9512 and CVE-2019-9514
Updates #33606

Change-Id: I282b3e0fa22422d9ea0d07f4a3935685ce4a7433
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526071
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
[release-branch.go1.12] net/http: prevent Transport from spamming stderr on server 408 reply 2019-06-07T22:00:46+00:00 Brad Fitzpatrick bradfitz@golang.org 2019-05-29T21:49:20+00:00 918368e46c53e716f6c4137c174f19d9a907f887 HTTP 408 responses now exist and are seen in the wild (e.g. from Google's GFE), so make Go's HTTP client not spam about them when seen. They're normal (now). Fixes #32367 Updates #32310 Change-Id: I558eb4654960c74cf20db1902ccaae13d03310f6 Reviewed-on: https://go-review.googlesource.com/c/go/+/179457 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> (cherry picked from commit ba66d89d7882892f762e7980562287d2c79ad87e) Reviewed-on: https://go-review.googlesource.com/c/go/+/181239 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> 
HTTP 408 responses now exist and are seen in the wild (e.g. from
Google's GFE), so make Go's HTTP client not spam about them when seen.
They're normal (now).

Fixes #32367
Updates #32310

Change-Id: I558eb4654960c74cf20db1902ccaae13d03310f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/179457
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
(cherry picked from commit ba66d89d7882892f762e7980562287d2c79ad87e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/181239
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
[release-branch.go1.12] net: use network and host as singleflight key during lookupIP 2019-04-02T17:40:15+00:00 Cezar Sa Espinola cezarsa@gmail.com 2019-03-07T15:52:16+00:00 578e281583f098c67ad5803ed2db1dad436b54d9 In CL 120215 the cgo resolver was changed to have different logic based on the network being queried. However, the singleflight cache key wasn't updated to also include the network. This way it was possible for concurrent queries to return the result for the wrong network. This CL changes the key to include both network and host, fixing the problem. Fixes #31062 Change-Id: I8b41b0ce1d9a02d18876c43e347654312eba22fc Reviewed-on: https://go-review.googlesource.com/c/go/+/166037 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> (cherry picked from commit e341bae08d75611adea6566c1d01c1e3a0de57f9) Reviewed-on: https://go-review.googlesource.com/c/go/+/170320 Run-TryBot: Andrew Bonventre <andybons@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> 
In CL 120215 the cgo resolver was changed to have different logic based
on the network being queried. However, the singleflight cache key wasn't
updated to also include the network. This way it was possible for
concurrent queries to return the result for the wrong network.

This CL changes the key to include both network and host, fixing the
problem.

Fixes #31062

Change-Id: I8b41b0ce1d9a02d18876c43e347654312eba22fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/166037
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit e341bae08d75611adea6566c1d01c1e3a0de57f9)
Reviewed-on: https://go-review.googlesource.com/c/go/+/170320
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
[release-branch.go1.12] net/http/httputil: make ReverseProxy flush headers on FlushInterval 2019-04-02T03:09:03+00:00 Jordan Liggitt liggitt@google.com 2019-03-29T03:37:54+00:00 ec06e9ba4578d26fdb9c521d4042e3f9f7f42435 A regression was introduced in CL 137335 (5440bfc) that caused FlushInterval to not be honored until the first Write() call was encountered. This change starts the flush timer as part of setting up the maxLatencyWriter. Fixes #31144 Change-Id: I75325bd926652922219bd1457b2b00ac6d0d41b0 Reviewed-on: https://go-review.googlesource.com/c/go/+/170066 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> (cherry picked from commit 2cc347382f4df3fb40d8d81ec9331f0748b1c394) Reviewed-on: https://go-review.googlesource.com/c/go/+/170137 
A regression was introduced in CL 137335 (5440bfc) that caused FlushInterval
to not be honored until the first Write() call was encountered. This change
starts the flush timer as part of setting up the maxLatencyWriter.

Fixes #31144

Change-Id: I75325bd926652922219bd1457b2b00ac6d0d41b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/170066
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 2cc347382f4df3fb40d8d81ec9331f0748b1c394)
Reviewed-on: https://go-review.googlesource.com/c/go/+/170137
[release-branch.go1.12] net: fix test after 8.8.8.8 changed its reverse DNS name 2019-03-27T18:20:10+00:00 Brad Fitzpatrick bradfitz@golang.org 2019-03-27T17:41:12+00:00 827c5d5355b0753f144c27fd5d1d5e62ffc2fb7e Google's 8.8.8.8 DNS server used to reports its reverse DNS name as ending in ".google.com". Now it's "dns.google.". Change-Id: I7dd15f03239e5c3f202e471618ab867690cb4f9d Reviewed-on: https://go-review.googlesource.com/c/go/+/169679 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> (cherry picked from commit 3089d189569ed272eaf2bc6c4330e848a46e9999) Reviewed-on: https://go-review.googlesource.com/c/go/+/169717 
Google's 8.8.8.8 DNS server used to reports its reverse DNS name
as ending in ".google.com". Now it's "dns.google.".

Change-Id: I7dd15f03239e5c3f202e471618ab867690cb4f9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/169679
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
(cherry picked from commit 3089d189569ed272eaf2bc6c4330e848a46e9999)
Reviewed-on: https://go-review.googlesource.com/c/go/+/169717
[release-branch.go1.12] net/http/httptrace: fix typo 2019-02-14T00:24:49+00:00 berkant ipek 41230766+0xbkt@users.noreply.github.com 2019-02-12T14:45:12+00:00 e3a53db2b838655f5f1d887156cfbc4ed0a0b714 Change-Id: I15279e4aa9306bde925929907a7b5e7ef5d8b642 GitHub-Last-Rev: 6bc2d66aecd424b322ec0c23b280e74cb22e08c3 GitHub-Pull-Request: golang/go#30193 Reviewed-on: https://go-review.googlesource.com/c/162018 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> (cherry picked from commit 1edd2a34c1bcf2133b659878e8b59e401eb8cc24) Reviewed-on: https://go-review.googlesource.com/c/162359 Reviewed-by: Ian Lance Taylor <iant@golang.org> 
Change-Id: I15279e4aa9306bde925929907a7b5e7ef5d8b642
GitHub-Last-Rev: 6bc2d66aecd424b322ec0c23b280e74cb22e08c3
GitHub-Pull-Request: golang/go#30193
Reviewed-on: https://go-review.googlesource.com/c/162018
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 1edd2a34c1bcf2133b659878e8b59e401eb8cc24)
Reviewed-on: https://go-review.googlesource.com/c/162359
Reviewed-by: Ian Lance Taylor <iant@golang.org>