This brings in several new and useful lints. It also brings in one CABF
BR lint which we have to ignore in our default profile which includes
the Subject Key Identifier extension:
"w_ext_subject_key_identifier_not_recommended_subscriber". In our modern
profile which omits several fields, we have to ignore the opposite
RFC5280 lint "w_ext_subject_key_identifier_missing_sub_cert".
Release notes: https://github.com/zmap/zlint/releases/tag/v3.6.4
Changelog: https://github.com/zmap/zlint/compare/v3.6.0...v3.6.4
Note that the majority of the ~400 file changes are merely copyright
date changes.
The corresponding production config changes tracked in IN-10466 are
complete.
Upgrade to zlint v3.6.0
Two new lints are triggered in various places:
aia_contains_internal_names is ignored in integration test
configurations, and unit tests are updated to have more realistic URLs.
The w_subject_common_name_included lint needs to be ignored where we'd
ignored n_subject_common_name_included before.
Related to https://github.com/letsencrypt/boulder/issues/7261
Thing brings in a number of new lints, including those which check for
correct encoding of the KeyUsage bitstring, which has led to incidents
for a number of CAs recently.
The `go` directive inside go.mod determines certain behaviors of
the go command. Since we're using go 1.17 everywhere, we should
update our module's go directive to reflect that, and update its contents
to match the new behavior.
Particularly, updating to 1.17 here means that all indirect dependencies
are listed directly inside go.mod (in a separate block, to keep things clean),
and the go.sum and go.mod files are deleted from vendored dependencies
so that the go tool can correctly find the root of the module even when run
from a vendored dependency's subdirectory.
Update zlint from v3.2.0 to just past v3.3.0, pulling in both an update
to the zlint interface and a number of new and improved checks. In
particular, pull in `lint_dnsname_contains_prohibited_reserved_label`,
which checks that DNSNames do not begin with any two characters followed
by two dashes, unless those two leading characters are "xn".
Also, update our few custom lints to match the new zlint v3.3.0
interface.
Fixes#5720
Update the pinned version of zlint from v2.2.1 to v3.1.0.
Also update the relevant path from v2 to v3 in both go.mod
and in individual imports. Update the vendored files to match.
No changes from v2.2.1 to v3.1.0 appear to affect the lints
we directly care about (e.g. those that we explicitly ignore).
Fixes#5206
This brings in the following changes to zlint:
https://github.com/zmap/zlint/compare/v2.1.0...9ab0643
Importantly, this prevents the cert lifetime lint from triggering on
CA certs, and removes the OCSP url requirement lint entirely.
* deps: update publicsuffix-go to 342bab7
This updates `github.com/weppos/publicsuffix-go` to 342bab7, the tip of
master at the time of writing.
Unit tests are confirmed to pass:
```
~/go/src/github.com/weppos/publicsuffix-go$ git log --pretty=format:'%h' -n 1
342bab7
~/go/src/github.com/weppos/publicsuffix-go$ go test ./...
? github.com/weppos/publicsuffix-go/cmd/load [no test files]
ok github.com/weppos/publicsuffix-go/net/publicsuffix 0.023s
ok github.com/weppos/publicsuffix-go/publicsuffix 0.015s
? github.com/weppos/publicsuffix-go/publicsuffix/generator [no test files]
```
* deps: update zmap/zlint to 71201e7
This updates `github.com/zmap/zlint` to 71201e7, the tip of master at
the time of writing.
Unit tests are confirmed to pass:
```
~/go/src/github.com/zmap/zlint$ git log --pretty=format:'%h' -n 1
71201e7
~/go/src/github.com/zmap/zlint$ go test ./...
ok github.com/zmap/zlint 0.205s
? github.com/zmap/zlint/cmd/zlint [no test files]
? github.com/zmap/zlint/cmd/zlint-gtld-update [no test files]
ok github.com/zmap/zlint/lints 0.214s
ok github.com/zmap/zlint/util 0.014s
```
Updates `github.com/weppos/publicsuffix-go` to 3dd5f42, and
`github.com/zmap/zlint` to eea5fe8. Both hashes are the tip of master at
the time of writing.
Unit tests are confirmed to pass:
```
~/go/src/github.com/weppos/publicsuffix-go$ git log --pretty=format:'%h' -n 1
3dd5f42
~/go/src/github.com/weppos/publicsuffix-go$ go test ./...
? github.com/weppos/publicsuffix-go/cmd/load [no test files]
ok github.com/weppos/publicsuffix-go/net/publicsuffix 0.008s
ok github.com/weppos/publicsuffix-go/publicsuffix 0.005s
? github.com/weppos/publicsuffix-go/publicsuffix/generator [no test files]
~/go/src/github.com/zmap/zlint$ git log --pretty=format:'%h' -n 1
eea5fe8
~/go/src/github.com/zmap/zlint$ go test ./...
ok github.com/zmap/zlint 0.240s
? github.com/zmap/zlint/cmd/zlint [no test files]
? github.com/zmap/zlint/cmd/zlint-gtld-update [no test files]
ok github.com/zmap/zlint/lints 0.156s
ok github.com/zmap/zlint/util 0.020s
```
A unit test is included to verify that a TLS-ALPN-01 challenge to
a TLS 1.3 only server doesn't succeed when the `GODEBUG` value to
disable TLS 1.3 in `docker-compose.yml` is set. Without this env var
the test fails on the Go 1.13 build because of the new default:
```
=== RUN TestTLSALPN01TLS13
--- FAIL: TestTLSALPN01TLS13 (0.04s)
tlsalpn_test.go:531: expected problem validating TLS-ALPN-01 challenge against a TLS 1.3 only server, got nil
FAIL
FAIL github.com/letsencrypt/boulder/va 0.065s
```
With the env var set the test passes, getting the expected connection
problem reporting a tls error:
```
=== RUN TestTLSALPN01TLS13
2019/09/13 18:59:00 http: TLS handshake error from 127.0.0.1:51240: tls: client offered only unsupported versions: [303 302 301]
--- PASS: TestTLSALPN01TLS13 (0.03s)
PASS
ok github.com/letsencrypt/boulder/va 1.054s
```
Since we plan to eventually enable TLS 1.3 support and the `GODEBUG`
mechanism tested in the above test is platform-wide vs package
specific I decided it wasn't worth the time investment to write a
similar HTTP-01 unit test that verifies the TLS 1.3 behaviour on a
HTTP-01 HTTP->HTTPS redirect.
Resolves https://github.com/letsencrypt/boulder/issues/4415
* deps: update github.com/zmap/zlint to latest.
This captures a new lint (`e_subject_printable_string_badalpha`) that
addresses a historic Let's Encrypt incident related to the allowed
PrintableString character set. It also pulls in minor housekeeping
related to consistently prefixing lint names with their respective lint
result level.
* review: fix expected lint name in TestIgnoredLint.
The upstream `zlint` project added a missing `w_` prefix on the
`ct_sct_policy_count_unsatisifed` lint that needed to be reflected in
expected test output.
* deps: update github.com/zmap/zlint to latest.
Update the `github.com/zmap/zlint` dependency to b126a9b. This captures
a small fix to the `ct_sct_policy_count_unsatisfied` lint that ensures
it isn't run for precertificates.
* config: remove ct_sct_policy_count_unsatisfied from ignored_lints.
With the latest `zlint` the `ct_sct_policy_count_unsatisfied` lint won't
flag precertificates as having an info-level lint result for missing
SCTs. With that fix in place we no longer have to ignore this lint in
the config-next CA configs that enable preissuance linting.
Notably this brings in:
* A mild perf. boost from an updated transitive zcrypto dep and a reworked util func.
* A new KeyUsage lint for ECDSA keys.
* Updated gTLD data.
* A required `LintStatus` deserialization fix that will unblock a CFSSL update.
The `TestIgnoredLint` unit test is updated to no longer expect a warning from the
` w_serial_number_low_entropy` lint. This lint was removed in the upstream project.
Because the package versions in go.mod match what we use in Godeps.json,
there are no substantive code diffs. However, there are some tiny
differences resulting from how go mod vendors things differently than
godep:
go mod does not preserve executable permissions on shell scripts
Some packages have import lines like:
package ocsp // import "golang.org/x/crypto/ocsp"
godep used to remove the comment from these lines, but go mod vendor does not.
This introduces several indirect dependencies that we didn't have
before. This is because godep used to operate at a package level, but
go mod operates at a module (~= repository) level. So if we used a
given repository, but didn't use all of its packages, we wouldn't
previously care about the transitive dependencies of the packages we
weren't using. However, in the go mod world, once we care about the
repository, we care about all of that repository's transitive
dependencies. AFAICT this doesn't affect vendoring.
Fixes#4116
The vendored copy of `github.com/zmap/zlint` is updated to
f38bd22 - the tip of master at the time of writing.
This pulls in a new deprecated gTLD: `.active`.
Unit tests are confirmed to pass:
```
~/go/src/github.com/zmap/zlint$ git log --pretty=format:'%h' -n 1
f38bd22
~/go/src/github.com/zmap/zlint$ go test ./...
ok github.com/zmap/zlint 0.220s
? github.com/zmap/zlint/cmd/zlint [no test files]
? github.com/zmap/zlint/cmd/zlint-gtld-update [no test files]
ok github.com/zmap/zlint/lints 0.270s
ok github.com/zmap/zlint/util 0.015s
```
The vendored copy of `github.com/zmap/zlint` is updated to b2aa746 - the
tip of master at the time of writing.
This pulls in two deprecated gTLDs (`.zippo`, `.epost`).
```
~/go/src/github.com/zmap/zlint$ git log --pretty=format:'%h' -n 1
b2aa746
~/go/src/github.com/zmap/zlint$ go test ./...
ok github.com/zmap/zlint 0.212s
? github.com/zmap/zlint/cmd/zlint [no test files]
? github.com/zmap/zlint/cmd/zlint-gtld-update [no test files]
ok github.com/zmap/zlint/lints 0.210s
ok github.com/zmap/zlint/util 0.006s
```
The vendored copy of `github.com/zmap/zlint` is updated to fbc0b69 - the
tip of master at the time of writing.
This pulls in a deprecated gTLD (`.blanco`).
Unit tests are confirmed to pass:
```
~/go/src/github.com/zmap/zlint$ git log --pretty=format:'%h' -n 1
fbc0b69
~/go/src/github.com/zmap/zlint$ go test ./...
ok github.com/zmap/zlint 0.215s
? github.com/zmap/zlint/cmd/zlint [no test files]
? github.com/zmap/zlint/cmd/zlint-gtld-update [no test files]
ok github.com/zmap/zlint/lints 0.270s
ok github.com/zmap/zlint/util 0.007s
```
The vendored copy of `github.com/zmap/zlint` is updated to bb32118 - the
tip of master at the time of writing.
This pulls in an updated `gtld_map.go` and a few new lints.
Unit tests are confirmed to pass:
```
$ go test ./...
ok github.com/zmap/zlint (cached)
? github.com/zmap/zlint/cmd/zlint [no test files]
? github.com/zmap/zlint/cmd/zlint-gtld-update [no test files]
ok github.com/zmap/zlint/lints (cached)
ok github.com/zmap/zlint/util (cached)
```
Unit tests are confirmed to pass:
```
$> git rev-parse HEAD
34b7be2e59081f4bbe6970785e021e6bf0741f2a
$> go test ./...
ok github.com/zmap/zlint 0.224s
? github.com/zmap/zlint/cmd/zlint [no test files]
? github.com/zmap/zlint/cmd/zlint-gtld-update [no test files]
ok github.com/zmap/zlint/lints 0.121s
ok github.com/zmap/zlint/util 0.008s
```
This updates our zlint dependency to 8093f211c4 - the tip of master at the time of writing. Notably this brings in a gTLD map that has effective periods so cert-checker can catch issuance for removed gTLDs after their removal date.
Unit tests are confirmed to pass:
```
$> git rev-parse HEAD
8093f211c43679b1ade744d238a02ba1f0c07371
$> go test ./...
ok github.com/zmap/zlint 0.284s
? github.com/zmap/zlint/cmd/zlint [no test files]
? github.com/zmap/zlint/cmd/zlint-gtld-update [no test files]
ok github.com/zmap/zlint/lints 0.165s
ok github.com/zmap/zlint/util 0.005s
```
Notably this brings an [updated gTLD list](https://github.com/zmap/zlint/pull/233).
Tests are confirmed to pass:
```
go test ./...
ok github.com/zmap/zlint 0.157s
? github.com/zmap/zlint/cmd/zlint [no test files]
ok github.com/zmap/zlint/lints 0.130s
ok github.com/zmap/zlint/util 0.005s
```
Switch linting library to zmap/zlint.
```
github.com/zmap/zlint$ go test ./...
ok github.com/zmap/zlint 0.190s
? github.com/zmap/zlint/cmd/zlint [no test files]
ok github.com/zmap/zlint/lints 0.216s
ok github.com/zmap/zlint/util (cached)
```