Change-Id: I9d398ed495011487544b1e5d0a469ae73c6f5927
Reviewed-on: https://go-review.googlesource.com/c/go/+/219218
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>

Change-Id: I95f81f269e742ac058cb3e6404cc43beb2428926
Reviewed-on: https://go-review.googlesource.com/c/go/+/219200
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>

Change-Id: Ic8ed07ad2c77042a67d7e1d4e9c0d5953610cf07

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

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

    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/+/645211Reviewed-by: Katie Hockman <katiehockman@google.com>
Reviewed-by: Adam Langley <agl@google.com>

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/+/647483Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>

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 <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ryan Sleevi <sleevi@google.com>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/647124Reviewed-by: Filippo Valsorda <valsorda@google.com>

Updates #36557
Fixes #36574

Change-Id: Ia8125f382d5e14e5612da811268a58971cc9ac08
Reviewed-on: https://go-review.googlesource.com/c/go/+/214917
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Austin Clements <austin@google.com>
(cherry picked from commit d2de9bd5)
Reviewed-on: https://go-review.googlesource.com/c/go/+/215017

Commit e0cf3de987e6 of the vcs-test.golang.org/git/querytest repo
includes a go.mod file specifying path vcs-test.golang.org/git/querytest.git,
as does the latest commit. Since the repository also lacks v3 tags,
a query for "latest" with a v3 path should fail.

Due to a bug, that query does not fail as expected with Go 1.12.
However, we do not need to continue to test for buggy behavior that
was fixed in a subsequent release.

Updates #36489

Change-Id: I766390c962fc75ba98fad02831310d90abf3055f
Reviewed-on: https://go-review.googlesource.com/c/go/+/214281
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

Change-Id: I6e47da51c3687ae9590554d003d803270f50911e
Reviewed-on: https://go-review.googlesource.com/c/go/+/214082
Run-TryBot: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>

Change-Id: I3b2c26d4818ca28a71a7fd6927a0c39c9253f06f
Reviewed-on: https://go-review.googlesource.com/c/go/+/214079Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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/+/212626Reviewed-by: Austin Clements <austin@google.com>
(cherry picked from commit ffbc0276)
Reviewed-on: https://go-review.googlesource.com/c/go/+/213684
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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 249c85d3)
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

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/+/208317Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/213198

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 <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/213197

The test for gopkg.in/yaml.v2@v2 assumes that there are
no future upstream releases. That assumption empirically
does not hold. Backporting fixes to this test is annoying,
and other gopkg.in cases are already reasonably covered,
so remove the problematic test.

Updates #28856

Change-Id: I6455baa1816ac69e02d1ad5d03b82a93e1481a17
Reviewed-on: https://go-review.googlesource.com/c/go/+/205437
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit f0390ffc)
Reviewed-on: https://go-review.googlesource.com/c/go/+/205439Reviewed-by: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Not all closed issues in a given minor milestone are included in that
release, only the ones that have been labeled as CherryPickApproved are.

Update the links to the GitHub issue tracker to include a filter on the
CherryPickApproved label, so that the default view shows only the
backports that were included in a given release. This should more useful
to most people than seeing all backports (considered and approved).

Do this only for Go 1.9.1 and newer releases, as that is when we started
using the CherryPickCandidate and CherryPickApproved labels.

Updates #35988
Fixes #36002

Change-Id: I51e07c1bc3ab9c4a5744e8f668c5470adf78bffe
Reviewed-on: https://go-review.googlesource.com/c/go/+/210118
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I3f3fcee395bd3f9bdb6ad4028506ac90fb84c388
Reviewed-on: https://go-review.googlesource.com/c/go/+/209897
Run-TryBot: Carlos Amedee <carlos@golang.org>
Run-TryBot: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I3641a086f167a1337aaaacd2d758b6a42b84a7fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/209845
Run-TryBot: Carlos Amedee <carlos@golang.org>
Run-TryBot: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 98e7270a)
Reviewed-on: https://go-review.googlesource.com/c/go/+/209846

Change-Id: I7589ef4bdac776c8f141e9cc60f59f8643649310
Reviewed-on: https://go-review.googlesource.com/c/go/+/209840Reviewed-by: Alexander Rakoczy <alex@golang.org>
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit f805b05b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/209842
Run-TryBot: Carlos Amedee <carlos@golang.org>

If a compilation has multiple text sections, code in
textOff must compare the offset argument against the range
for each text section to determine which one it is in.
The comparison looks like this:

if uintptr(off) >= sectaddr && uintptr(off) <= sectaddr+sectlen

If the off value being compared is equal to sectaddr+sectlen then it
is not within the range of the text section but after it. The
comparison should be just '<'.

Fixes #35210

Change-Id: I114633fd734563d38f4e842dd884c6c239f73c95
Reviewed-on: https://go-review.googlesource.com/c/go/+/203817
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
(cherry picked from commit 0ae93896)
Reviewed-on: https://go-review.googlesource.com/c/go/+/203818
Run-TryBot: Carlos Amedee <carlos@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

Binary files included in testdata directories can cause Apple’s
notarization service to reject us since they don’t abide by their
strict requirements.

To emulate go mod vendor, remove all _test.go and testdata files
from the vendor directory and update the instructions.

Updates #34986
Fixes #35747

Change-Id: I5cde905fc78838d2e3b1519dab4aeee13d8d5356
Reviewed-on: https://go-review.googlesource.com/c/go/+/208227
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>

Starting with macOS 10.15 (Catalina), Apple now requires all software
distributed outside of the App Store to be notarized. Any binaries we
distribute must abide by a strict set of requirements like code-signing
and having a minimum target SDK of 10.9 (amongst others).

Apple’s notarization service will recursively inspect archives looking to
find notarization candidate binaries. If it finds a binary that does not
meet the requirements or is unable to decompress an archive, it will
reject the entire distribution. From cursory testing, it seems that the
service uses content sniffing to determine file types, so changing
the file extension will not work.

There are some binaries and archives included in our distribution that
are being detected by Apple’s service as potential candidates for
notarization or decompression. As these are files used by tests and some
are intentionally invalid, we don’t intend to ever make them compliant.

As a workaround for this, we base64-encode any binaries or archives that
Apple’s notarization service issues a warning for, as these warnings will
become errors in January 2020.

Updates #34986
Updates #35747

Change-Id: I106fbb6227b61eb221755568f047ee11103c1680
Reviewed-on: https://go-review.googlesource.com/c/go/+/208118
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 8bbfc51d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/208220Reviewed-by: Alexander Rakoczy <alex@golang.org>

Change-Id: Ic4db4625c4b7031aa08cb235f526267058a50430
Reviewed-on: https://go-review.googlesource.com/c/go/+/204641
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>

Change-Id: Ic65a74e56320adbd76aeef1cf3b19d7906ffe8fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/204639
Run-TryBot: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Change-Id: I3494e831beac93e322788f7bd76948b52f769f37
Reviewed-on: https://go-review.googlesource.com/c/go/+/201822
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>

Change-Id: I832ba5f32d513b586bb0b02371231786b25631e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/201817Reviewed-by: Andrew Bonventre <andybons@golang.org>
(cherry picked from commit 58e8f789)
Reviewed-on: https://go-review.googlesource.com/c/go/+/201821

Change-Id: Ied19fb5f182670c9dc3bd15327d461b203187cf6

Change-Id: I8421754104cb795270dbcb6f554ed3a78a719483
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/575988Reviewed-by: Filippo Valsorda <valsorda@google.com>

Change-Id: I73f27924046a0a2493330ddc732d1a2fd3f730a5
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/575981Reviewed-by: Filippo Valsorda <valsorda@google.com>
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/575985

dsa.Verify might currently use a nil s inverse in a
multiplication if the public key contains a non-prime Q,
causing a panic. Change this to check that the mod
inverse exists before using it.

Fixes CVE-2019-17596

Change-Id: I94d5f3cc38f1b5d52d38dcb1d253c71b7fd1cae7
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/572809Reviewed-by: Filippo Valsorda <valsorda@google.com>
(cherry picked from commit 9119dfb0511326d4485b248b83d4fde19c95d0f7)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/575232

[release-branch.go1.12] cmd/vendor/golang.org/x/arch/arm64/arm64asm: recognise new ssbb/pssbb mnemonics from objdump

This patches in CL 136455 from the 'arch' repo.

Commands run:
~/go/src/cmd$ GOPATH=$(../../bin/go env GOROOT) govendor fetch golang.org/x/arch/arm64/arm64asm@b19384d3c130858bb31a343ea8fce26be71b5998

Updates #27754
Fixes #31305

Change-Id: I8fcc3bc3c718cf0d93afbd1d383df48316b522d4
Reviewed-on: https://go-review.googlesource.com/136455
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/200057
Run-TryBot: Bryan C. Mills <bcmills@google.com>

On Ubuntu 18.04 I am seeing GDB fail to restore the stack pointer
during this test because stack unwinding can't find the PC. This CL
is essentially a partial revert of CL 23940 and fixes the issue on
s390x.

Fixes #33757

Change-Id: Ib4c41162dc85dc882eb6e248330f4082c3fa94c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/169857
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
(cherry picked from commit d91f7e66)
Reviewed-on: https://go-review.googlesource.com/c/go/+/200039
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Munday <mike.munday@ibm.com>

Update the expected data to fix the longtest builder.

Updates #28856

Change-Id: I7fb6ee72e8469d974561b4b4057f40142f5b3654
Reviewed-on: https://go-review.googlesource.com/c/go/+/198557
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
(cherry picked from commit 64785bf9)
Reviewed-on: https://go-review.googlesource.com/c/go/+/198700
Run-TryBot: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit 17a492fdd5560a1b6e640a47a9ca83d2853341df)
Reviewed-on: https://go-review.googlesource.com/c/go/+/200038

Updates #30571
Fixes #34789

Change-Id: Id4c74e83ee58a080d1c2894ae5ebdbf4aeb1ce42
Reviewed-on: https://go-review.googlesource.com/c/go/+/167084
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit bd680d94)
Reviewed-on: https://go-review.googlesource.com/c/go/+/200037

TestGoGetInsecure verifies that 'go get -insecure' can fetch a
particular package. However, the GOPROXY protocol does not provide a
means for proxies to indicate packages as insecure; thus, proxies
cannot safely serve those packages.

This also squashes the typo fix from CL 167086.

Updates #30571
Fixes #33758

Change-Id: I447776dff98bd8ee6eb5055b897b9c7d293e3423
Reviewed-on: https://go-review.googlesource.com/c/go/+/165745
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/199820
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.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>

Change-Id: I6c822dfc305d629022c7da21ab399367bf021cf7

Change-Id: I64d76a35ad113110cb83117c6ce5d4d923d93c93
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/558789Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>