Skip to content

Conversation

@thaJeztah
Copy link
Member

@thaJeztah thaJeztah commented Aug 31, 2022

see individual commits for details

@k8s-ci-robot
Copy link

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@thaJeztah

This comment was marked as outdated.

@thaJeztah thaJeztah force-pushed the gofmt_119 branch 3 times, most recently from 505c13d to 0393b32 Compare October 8, 2022 12:04
Comment on lines +238 to +243
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 {
Copy link
Member Author

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")

@thaJeztah thaJeztah changed the title [WIP] clean-up nolint-tags, remove unused ones, update golangci-lint clean-up "nolint" comments, remove unused ones, update golangci-lint Oct 8, 2022
}

interactive, err := svc.IsAnInteractiveSession() // nolint:staticcheck
interactive, err := svc.IsAnInteractiveSession() //nolint:staticcheck
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one was added in edc671d (#4626). I'll open a separate PR to replace it

tlsConfig.Certificates = []tls.Certificate{cert}
}
tlsConfig.BuildNameToCertificate() // nolint:staticcheck
tlsConfig.BuildNameToCertificate() //nolint:staticcheck
Copy link
Member Author

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).

tlsConfig.Certificates = []tls.Certificate{cert}
}
tlsConfig.BuildNameToCertificate() // nolint:staticcheck
tlsConfig.BuildNameToCertificate() //nolint:staticcheck
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@thaJeztah thaJeztah marked this pull request as ready for review October 8, 2022 15:43
@thaJeztah
Copy link
Member Author

This one should be ready for review 👍

@samuelkarp @estesp @mikebrow PTAL 🤗

Copy link
Member

@mikebrow mikebrow left a 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]>
Copy link
Member

@estesp estesp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@thaJeztah
Copy link
Member Author

@mikebrow PTAL; this one good to go?

Copy link
Member

@mikebrow mikebrow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants