moby--moby/vendor/golang.org/x/crypto/go.mod

module golang.org/x/crypto

go 1.11

require (
	golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3
	golang.org/x/sys v0.0.0-20190412213103-97732733099d
)
bump vndr to f5ab8fc5f, and revendor Signed-off-by: Sebastiaan van Stijn <github@gone.nl> 2019-05-14 18:26:24 -04:00			`module golang.org/x/crypto`

vendor: update golang.org/x/crypto 69ecbb4d6d5dab05e49161c6e77ea40a030884e1 full diff: https://github.com/golang/crypto/compare/88737f569e3a9c7ab309cdc09a07fe7fc87233c3...69ecbb4d6d5dab05e49161c6e77ea40a030884e1 Includes https://github.com/golang/crypto/commit/69ecbb4d6d5dab05e49161c6e77ea40a030884e1 (forward-port of https://github.com/golang/crypto/commit/8b5121be2f68d8fc40bb06467003bdde1040a094), which fixes CVE-2020-7919: - Panic in crypto/x509 certificate parsing and golang.org/x/crypto/cryptobyte On 32-bit architectures, a malformed input to crypto/x509 or the ASN.1 parsing functions of golang.org/x/crypto/cryptobyte can lead to a panic. The malformed certificate can be delivered via a crypto/tls connection to a client, or to a server that accepts client certificates. net/http clients can be made to crash by an HTTPS server, while net/http servers that accept client certificates will recover the panic and are unaffected. Thanks to Project Wycheproof for providing the test cases that led to the discovery of this issue. The issue is CVE-2020-7919 and Go issue golang.org/issue/36837. Signed-off-by: Sebastiaan van Stijn <github@gone.nl> 2020-01-29 12:36:06 -05:00			`go 1.11`

			`require (`
			`golang.org/x/net v0.0.0-20190404232315-eb5bcb51f2a3`
			`golang.org/x/sys v0.0.0-20190412213103-97732733099d`
			`)`