delta/go-git.git/src/crypto, branch dev.boringcrypto.go1.12 github.com: golang/go [dev.boringcrypto.go1.12] all: merge go1.12.16 into dev.boringcrypto.go1.12 2020-02-04T22:53:10+00:00 Filippo Valsorda filippo@golang.org 2020-02-04T22:53:10+00:00 f74e68136cf1ab178c8a773ac7eafc522260f7db Change-Id: I4e773f39dc51294fd43d1478fce54d286f8e2805 
Change-Id: I4e773f39dc51294fd43d1478fce54d286f8e2805
[release-branch.go1.12-security] crypto/x509: mitigate CVE-2020-0601 verification bypass on Windows 2020-01-24T19:25:49+00:00 Filippo Valsorda filippo@golang.org 2020-01-21T19:45:15+00:00 a8b372fb365f4b69f0b06aa9c3e642e6aa022840 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/+/647124 Reviewed-by: Filippo Valsorda <valsorda@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/+/647124
Reviewed-by: Filippo Valsorda <valsorda@google.com>
[dev.boringcrypto.go1.12] all: merge go1.12.11 into dev.boringcrypto.go1.12 2019-10-17T19:48:34+00:00 Filippo Valsorda filippo@golang.org 2019-10-17T19:48:34+00:00 c5a4ae8c8c1b8621b705273aa6928994131e3bce Change-Id: I26e9d9f6ae4724a880ed27c75d279a97d2e2d33b 
Change-Id: I26e9d9f6ae4724a880ed27c75d279a97d2e2d33b
[release-branch.go1.12-security] crypto/dsa: prevent bad public keys from causing panic 2019-10-16T21:24:47+00:00 Katie Hockman katie@golang.org 2019-10-14T20:42:21+00:00 2017d88dbc096381d4f348d2fb08bfb3c2b7ed73 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/+/572809 Reviewed-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 
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/+/572809
Reviewed-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
[dev.boringcrypto.go1.12] all: merge go1.12.9 into dev.boringcrypto.go1.12 2019-08-20T18:58:17+00:00 Filippo Valsorda filippo@golang.org 2019-08-20T18:58:17+00:00 ee88e5b118b55d82f61c0892243d3311469fbe51 Change-Id: Ib50ec8a5ec235570ff1483f393acab48c45af585 
Change-Id: Ib50ec8a5ec235570ff1483f393acab48c45af585
[release-branch.go1.12] crypto/tls: remove TestVerifyHostnameResumed 2019-07-15T23:42:14+00:00 Filippo Valsorda filippo@golang.org 2019-07-15T20:45:17+00:00 8759b531473e1fa93f23508bc90ae878783671a6 Session resumption is not a reliable TLS behavior: the server can decide to reject a session ticket for a number of reasons, or no reason at all. This makes this non-hermetic test extremely brittle. It's currently broken on the builders for both TLS 1.2 and TLS 1.3, and I could reproduce the issue for TLS 1.3 only. As I was debugging it, it started passing entirely on my machine. In practice, it doesn't get us any coverage as resumption is already tested with the recorded exchange tests, and TestVerifyHostname still provides a smoke test checking that we can in fact talk TLS. Updates #32978 Change-Id: I63505e22ff7704f25ad700d46e4ff14850ba5d3c Reviewed-on: https://go-review.googlesource.com/c/go/+/186239 Run-TryBot: Filippo Valsorda <filippo@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> (cherry-picked from 20e4540e9084528a1b36978882596daa7d8d8800) Reviewed-on: https://go-review.googlesource.com/c/go/+/186277 TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> 
Session resumption is not a reliable TLS behavior: the server can decide
to reject a session ticket for a number of reasons, or no reason at all.
This makes this non-hermetic test extremely brittle.

It's currently broken on the builders for both TLS 1.2 and TLS 1.3, and
I could reproduce the issue for TLS 1.3 only. As I was debugging it, it
started passing entirely on my machine.

In practice, it doesn't get us any coverage as resumption is already
tested with the recorded exchange tests, and TestVerifyHostname still
provides a smoke test checking that we can in fact talk TLS.

Updates #32978

Change-Id: I63505e22ff7704f25ad700d46e4ff14850ba5d3c
Reviewed-on: https://go-review.googlesource.com/c/go/+/186239
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry-picked from 20e4540e9084528a1b36978882596daa7d8d8800)
Reviewed-on: https://go-review.googlesource.com/c/go/+/186277
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
[dev.boringcrypto.go1.12] all: merge go1.12.6 into dev.boringcrypto.go1.12 2019-06-13T18:47:03+00:00 Filippo Valsorda filippo@golang.org 2019-06-13T18:47:03+00:00 6b86b09ad4d3f6e53c4dc94afc62117f9d2f8d84 Change-Id: I2598fb7f3a350e0244527c5244e423f9a9e01b86 
Change-Id: I2598fb7f3a350e0244527c5244e423f9a9e01b86
[release-branch.go1.12] crypto/x509: fix value ownership in isSSLPolicy on macOS 2019-06-07T20:51:11+00:00 Filippo Valsorda filippo@golang.org 2019-05-21T18:54:54+00:00 3b05c3c2e68296ebcb9efd9b4b0739161dac964f CFDictionaryGetValueIfPresent does not take ownership of the value, so releasing the properties dictionary before passing the value to CFEqual can crash. Not really clear why this works most of the time. See https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html Fixes #32282 Updates #28092 Updates #30763 Change-Id: I5ee7ca276b753a48abc3aedfb78b8af68b448dd4 Reviewed-on: https://go-review.googlesource.com/c/go/+/178537 Reviewed-by: Adam Langley <agl@golang.org> (cherry picked from commit a3d4655c2435e3777c45f09650539b943bab1c66) Reviewed-on: https://go-review.googlesource.com/c/go/+/179339 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> 
CFDictionaryGetValueIfPresent does not take ownership of the value, so
releasing the properties dictionary before passing the value to CFEqual
can crash. Not really clear why this works most of the time.

See https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html

Fixes #32282
Updates #28092
Updates #30763

Change-Id: I5ee7ca276b753a48abc3aedfb78b8af68b448dd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/178537
Reviewed-by: Adam Langley <agl@golang.org>
(cherry picked from commit a3d4655c2435e3777c45f09650539b943bab1c66)
Reviewed-on: https://go-review.googlesource.com/c/go/+/179339
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
[dev.boringcrypto.go1.12] all: merge go1.12.1 into dev.boringcrypto.go1.12 2019-03-26T19:50:26+00:00 Filippo Valsorda filippo@golang.org 2019-03-26T19:50:26+00:00 88e20e81a61fe07f438f3a07534405ba47414ae0 Change-Id: I4b5300765402816cafd2e37849319237b5f6d688 
Change-Id: I4b5300765402816cafd2e37849319237b5f6d688
[dev.boringcrypto.go1.12] all: merge release-branch.go1.12 into dev.boringcrypto.go1.12 2019-02-28T19:06:48+00:00 Filippo Valsorda filippo@golang.org 2019-02-27T20:06:11+00:00 a0a60eea1ba8e9200d9c68f98b7a42b2a6d397a6 Change-Id: I20ea47cc360126326a810abcfb6141b3d9338f63 
Change-Id: I20ea47cc360126326a810abcfb6141b3d9338f63