-
Notifications
You must be signed in to change notification settings - Fork 3.8k
clean-up "nolint" comments, remove unused ones, update golangci-lint #7349
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Skipping CI for Draft Pull Request. |
This comment was marked as outdated.
This comment was marked as outdated.
505c13d to
0393b32
Compare
| srv := &http.Server{ | ||
| Addr: c.Metrics, | ||
| Handler: metrics.Handler(), | ||
| ReadHeaderTimeout: 5 * time.Minute, // "G112: Potential Slowloris Attack (gosec)"; not a real concern for our use, so setting a long timeout. | ||
| } | ||
| if err := srv.ListenAndServe(); err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Taking similar approach as I dd in moby/moby#44174 (we discussed this warning there, and considered that it was not an actual problem for how it's used, but setting a timeout doesn't hurt either, and somewhat better than "just add some //nolint comments")
| } | ||
|
|
||
| interactive, err := svc.IsAnInteractiveSession() // nolint:staticcheck | ||
| interactive, err := svc.IsAnInteractiveSession() //nolint:staticcheck |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pkg/cri/server/image_pull.go
Outdated
| tlsConfig.Certificates = []tls.Certificate{cert} | ||
| } | ||
| tlsConfig.BuildNameToCertificate() // nolint:staticcheck | ||
| tlsConfig.BuildNameToCertificate() //nolint:staticcheck |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This //nolint was added in containerd/cri@f5c7ac9 (containerd/cri#1517)
to suppress warnings about the NameToCertificate function being deprecated:
// Deprecated: NameToCertificate only allows associating a single certificate
// with a given name. Leave that field nil to let the library select the first
// compatible chain from Certificates.
Looking at that, I see it was deprecated in Go 1.14 through golang/go@eb93c68 (https://go-review.googlesource.com/c/go/+/205059), which describes:
crypto/tls: select only compatible chains from Certificates
Now that we have a full implementation of the logic to check certificate
compatibility, we can let applications just list multiple chains in
Certificates (for example, an RSA and an ECDSA one) and choose the most
appropriate automatically.
NameToCertificate only maps each name to one chain, so simply deprecate
it, and while at it simplify its implementation by not stripping
trailing dots from the SNI (which is specified not to have any, see RFC
6066, Section 3) and by not supporting multi-level wildcards, which are
not a thing in the WebPKI (and in crypto/x509).
I think we should at least have a comment describing why we're ignoring this, but preferably review whether we should still use it. I'm kinda horrible on TLS stuff, so perhaps someone else would be able to assist on this (I'm happy to open a pull request to make the actual changes).
pkg/cri/sbserver/image_pull.go
Outdated
| tlsConfig.Certificates = []tls.Certificate{cert} | ||
| } | ||
| tlsConfig.BuildNameToCertificate() // nolint:staticcheck | ||
| tlsConfig.BuildNameToCertificate() //nolint:staticcheck |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same as https://github.com/containerd/containerd/pull/7349/files#r990644833 (this code was forked from pkg/cri/server
|
This one should be ready for review 👍 @samuelkarp @estesp @mikebrow PTAL 🤗 |
mikebrow
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a nit on FIXME->TODO
GOGC=75 golangci-lint run
services/server/server.go:320:27: G114: Use of net/http serve function that has no support for setting timeouts (gosec)
return trapClosedConnErr(http.Serve(l, m))
^
services/server/server.go:340:27: G114: Use of net/http serve function that has no support for setting timeouts (gosec)
return trapClosedConnErr(http.Serve(l, m))
^
cmd/containerd-stress/main.go:238:13: G114: Use of net/http serve function that has no support for setting timeouts (gosec)
if err := http.ListenAndServe(c.Metrics, metrics.Handler()); err != nil {
^
Signed-off-by: Sebastiaan van Stijn <[email protected]>
THis makes it easier to find which linters are enabled when going through the list. Signed-off-by: Sebastiaan van Stijn <[email protected]>
…fy nolint This `//nolint` was added in containerd/cri@f5c7ac9 to suppress warnings about the `NameToCertificate` function being deprecated: // Deprecated: NameToCertificate only allows associating a single certificate // with a given name. Leave that field nil to let the library select the first // compatible chain from Certificates. Looking at that, it was deprecated in Go 1.14 through golang/go@eb93c68 (https://go-review.googlesource.com/c/go/+/205059), which describes: crypto/tls: select only compatible chains from Certificates Now that we have a full implementation of the logic to check certificate compatibility, we can let applications just list multiple chains in Certificates (for example, an RSA and an ECDSA one) and choose the most appropriate automatically. NameToCertificate only maps each name to one chain, so simply deprecate it, and while at it simplify its implementation by not stripping trailing dots from the SNI (which is specified not to have any, see RFC 6066, Section 3) and by not supporting multi-level wildcards, which are not a thing in the WebPKI (and in crypto/x509). We should at least have a comment describing why we are ignoring this, but preferably review whether we should still use it. Signed-off-by: Sebastiaan van Stijn <[email protected]>
- fix "nolint" comments to be in the correct format (`//nolint:<linters>[,<linter>` no leading space, required colon (`:`) and linters. - remove "nolint" comments for errcheck, which is disabled in our config. - remove "nolint" comments that were no longer needed (nolintlint). - where known, add a comment describing why a "nolint" was applied. Signed-off-by: Sebastiaan van Stijn <[email protected]>
Remove nolint-comments that weren't hit by linters, and remove the "structcheck"
and "varcheck" linters, as they have been deprecated:
WARN [runner] The linter 'structcheck' is deprecated (since v1.49.0) due to: The owner seems to have abandoned the linter. Replaced by unused.
WARN [runner] The linter 'varcheck' is deprecated (since v1.49.0) due to: The owner seems to have abandoned the linter. Replaced by unused.
WARN [linters context] structcheck is disabled because of generics. You can track the evolution of the generics support by following the golangci/golangci-lint#2649.
Signed-off-by: Sebastiaan van Stijn <[email protected]>
Also remove "nolint" comments for deadcode, which is deprecated, and removed from the defaults. Signed-off-by: Sebastiaan van Stijn <[email protected]>
estesp
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
|
@mikebrow PTAL; this one good to go? |
mikebrow
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
see individual commits for details