mirror of
https://github.com/golang/go
synced 2024-11-08 02:26:11 -07:00
f81aa23cf0
Colons are port separators, so it's risky to allow them in hostnames. Per the CL 231377 rule, if we at least consider them invalid we will not apply wildcard processing to them, making behavior a little more predictable. We were considering hostnames with colons valid (against spec) because that meant we'd not ignore them in Common Name. (There was at least one deployment that was putting colons in Common Name and expecting it to verify.) Now that Common Name is ignored by default, those clients will break again, so it's a good time to drop the exception. Hopefully they moved to SANs, where invalid hostnames are checked 1:1 (ignoring wildcards) but still work. (If they didn't, this change means they can't use GODEBUG=x509ignoreCN=0 to opt back in, but again you don't get to use a legacy deprecated field AND invalid hostnames.) Updates #24151 Change-Id: Id44b4fecb2d620480acdfc65fea1473f7abbca7f Reviewed-on: https://go-review.googlesource.com/c/go/+/231381 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Katie Hockman <katie@golang.org> |
||
|---|---|---|
| .. | ||
| aes | ||
| cipher | ||
| des | ||
| dsa | ||
| ecdsa | ||
| ed25519 | ||
| elliptic | ||
| hmac | ||
| internal | ||
| md5 | ||
| rand | ||
| rc4 | ||
| rsa | ||
| sha1 | ||
| sha256 | ||
| sha512 | ||
| subtle | ||
| tls | ||
| x509 | ||
| crypto.go | ||
| issue21104_test.go | ||