go, branch go1.12.16

[release-branch.go1.12-security] go1.12.16

2020-01-27T22:27:19Z

Change-Id: Iea658e285670a897a45eca3756004f050763c64d Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/649301 Reviewed-by: Katie Hockman

[release-branch.go1.12-security] doc: document Go 1.12.16

2020-01-27T21:15:08Z

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

[release-branch.go1.12-security] internal/x/crypto/cryptobyte: import security fix for 32-bit archs

2020-01-27T20:31:21Z

cryptobyte: fix panic due to malformed ASN.1 inputs on 32-bit archs When int is 32 bits wide (on 32-bit architectures like 386 and arm), an overflow could occur, causing a panic, due to malformed ASN.1 being passed to any of the ASN1 methods of String. Tested on linux/386 and darwin/amd64. This fixes CVE-2020-7919 and was found thanks to the Project Wycheproof test vectors. Change-Id: I8c9696a8bfad1b40ec877cd740dba3467d66ab54 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/645211 Reviewed-by: Katie Hockman Reviewed-by: Adam Langley x/crypto/cryptobyte is used in crypto/x509 for parsing certificates. Malformed certificates might cause a panic during parsing on 32-bit architectures (like arm and 386). Change-Id: I3c619af508bacff84023be4d5a7c4992c2f20a56 Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/647483 Reviewed-by: Dmitri Shuralyov

[release-branch.go1.12-security] crypto/x509: mitigate CVE-2020-0601 verification bypass on Windows

2020-01-24T19:25:49Z

An attacker can trick the Windows system verifier to use a poisoned set of elliptic curve parameters for a trusted root, allowing it to generate spoofed signatures. When this happens, the returned chain will present the unmodified original root, so the actual signatures won't verify (as they are invalid for the correct parameters). Simply double check them as a safety measure and mitigation. Windows users should still install the system security patch ASAP. This is the same mitigation adopted by Chromium: https://chromium-review.googlesource.com/c/chromium/src/+/1994434 Change-Id: I2c734f6fb2cb51d906c7fd77034318ffeeb3e146 Reviewed-on: https://go-review.googlesource.com/c/go/+/215905 Run-TryBot: Filippo Valsorda TryBot-Result: Gobot Gobot Reviewed-by: Ryan Sleevi Reviewed-by: Katie Hockman Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/647124 Reviewed-by: Filippo Valsorda

[release-branch.go1.12] go1.12.15

2020-01-09T19:00:28Z

Change-Id: I6e47da51c3687ae9590554d003d803270f50911e Reviewed-on: https://go-review.googlesource.com/c/go/+/214082 Run-TryBot: Carlos Amedee TryBot-Result: Gobot Gobot Reviewed-by: Alexander Rakoczy

[release-branch.go1.12] doc: document Go 1.12.15

2020-01-09T16:23:25Z

Change-Id: I3b2c26d4818ca28a71a7fd6927a0c39c9253f06f Reviewed-on: https://go-review.googlesource.com/c/go/+/214079 Reviewed-by: Dmitri Shuralyov Reviewed-by: Alexander Rakoczy Run-TryBot: Dmitri Shuralyov Run-TryBot: Alexander Rakoczy TryBot-Result: Gobot Gobot

[release-branch.go1.12] runtime: ensure memmove write pointer atomically on ARM64

2020-01-08T22:22:22Z

If a pointer write is not atomic, if the GC is running concurrently, it may observe a partially updated pointer, which may point to unallocated or already dead memory. Most pointer writes, like the store instructions generated by the compiler, are already atomic. But we still need to be careful in places like memmove. In memmove, we don't know which bits are pointers (or too expensive to query), so we ensure that all aligned pointer-sized units are written atomically. Fixes #36367. Updates #36101. Change-Id: I1b3ca24c6b1ac8a8aaf9ee470115e9a89ec1b00b Reviewed-on: https://go-review.googlesource.com/c/go/+/212626 Reviewed-by: Austin Clements (cherry picked from commit ffbc02761abb47106ce88e09290a31513b5f6c8a) Reviewed-on: https://go-review.googlesource.com/c/go/+/213684 Run-TryBot: Cherry Zhang TryBot-Result: Gobot Gobot

[release-branch.go1.12] net/http: avoid writing to Transport.ProxyConnectHeader

2020-01-07T22:39:30Z

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 Reviewed-by: Brad Fitzpatrick TryBot-Result: Gobot Gobot (cherry picked from commit 249c85d3aab2ad2d0bcbf36efe606fdd66f25c72) Reviewed-on: https://go-review.googlesource.com/c/go/+/213677

[release-branch.go1.12] runtime: do not use PowerRegisterSuspendResumeNotification on systems with "program time" timer

2020-01-03T23:40:29Z

Systems where PowerRegisterSuspendResumeNotification returns ERROR_ FILE_NOT_FOUND are also systems where nanotime() is on "program time" rather than "real time". The chain for this is: powrprof.dll!PowerRegisterSuspendResumeNotification -> umpdc.dll!PdcPortOpen -> ntdll.dll!ZwAlpcConnectPort("\\PdcPort") -> syscall -> ntoskrnl.exe!AlpcpConnectPort Opening \\.\PdcPort fails with STATUS_OBJECT_NAME_NOT_FOUND when pdc.sys hasn't been initialized. Pdc.sys also provides the various hooks for sleep resumption events, which means if it's not loaded, then our "real time" timer is actually on "program time". Finally STATUS_OBJECT_NAME_ NOT_FOUND is passed through RtlNtStatusToDosError, which returns ERROR_ FILE_NOT_FOUND. Therefore, in the case where the function returns ERROR_ FILE_NOT_FOUND, we don't mind, since the timer we're using will correspond fine with the lack of sleep resumption notifications. This applies, for example, to Docker users. Updates #35447 Updates #35482 Fixes #36377 Change-Id: I9e1ce5bbc54b9da55ff7a3918b5da28112647eee Reviewed-on: https://go-review.googlesource.com/c/go/+/208317 Reviewed-by: Jason A. Donenfeld Reviewed-by: Austin Clements Run-TryBot: Jason A. Donenfeld TryBot-Result: Gobot Gobot Reviewed-on: https://go-review.googlesource.com/c/go/+/213198

[release-branch.go1.12] runtime: monitor for suspend/resume to kick timeouts

2020-01-03T23:37:47Z

Starting in Windows 8, the wait functions don't take into account suspend time, even though the monotonic counters do. This results in timer buckets stalling on resume. Therefore, this commit makes it so that on resume, we return from the wait functions and recalculate the amount of time left to wait. This is a cherry pick of CL 191957 and its cleanup, CL 198417. Updates #31528 Fixes #36376 Change-Id: I0db02cc72188cb620954e87a0180e0a3c83f4a56 Reviewed-on: https://go-review.googlesource.com/c/go/+/193607 Run-TryBot: Jason A. Donenfeld TryBot-Result: Gobot Gobot Reviewed-by: Austin Clements Reviewed-on: https://go-review.googlesource.com/c/go/+/213197