build(deps): bump github.com/cyphar/filepath-securejoin from 0.3.5 to 0.3.6

[dependabot]

Bumps github.com/cyphar/filepath-securejoin from 0.3.5 to 0.3.6.

Release notes

Sourced from github.com/cyphar/filepath-securejoin's releases.

v0.3.6

This release lowers the minimum Go version to Go 1.18 as well as some library dependencies, in order to make it easier for folks that need to backport patches using the new filepath-securejoin API onto branches that are stuck using old Go compilers. For users using Go >= 1.21, this release contains no functional changes.

• The minimum Go version requirement for filepath-securejoin is now Go 1.18 (we use generics internally).

  For reference, [email protected] somewhat-arbitrarily bumped the Go version requirement to 1.21.

  While we did make some use of Go 1.21 stdlib features (and in principle Go versions <= 1.21 are no longer even supported by upstream anymore), some downstreams have complained that the version bump has meant that they have to do workarounds when backporting fixes that use the new filepath-securejoin API onto old branches. This is not an ideal situation, but since using this library is probably better for most downstreams than a hand-rolled workaround, we now have compatibility shims that allow us to build on older Go versions.

• Lower minimum version requirement for golang.org/x/sys to v0.18.0 (we need the wrappers for fsconfig(2)), which should also make backporting patches to older branches easier.

Signed-off-by: Aleksa Sarai [email protected]

Changelog

Sourced from github.com/cyphar/filepath-securejoin's changelog.

[0.3.6] - 2024-12-17

Compatibility

• The minimum Go version requirement for filepath-securejoin is now Go 1.18 (we use generics internally).

  For reference, [email protected] somewhat-arbitrarily bumped the Go version requirement to 1.21.

  While we did make some use of Go 1.21 stdlib features (and in principle Go versions <= 1.21 are no longer even supported by upstream anymore), some downstreams have complained that the version bump has meant that they have to do workarounds when backporting fixes that use the new filepath-securejoin API onto old branches. This is not an ideal situation, but since using this library is probably better for most downstreams than a hand-rolled workaround, we now have compatibility shims that allow us to build on older Go versions.

• Lower minimum version requirement for golang.org/x/sys to v0.18.0 (we need the wrappers for fsconfig(2)), which should also make backporting patches to older branches easier.

Commits

• 200008e VERSION: release v0.3.6
• 43784dc tests: lower github.com/stretchr/testify requirement to v1.7.1
• 2ec07d2 merge #37 into cyphar/filepath-securejoin:main
• d17d372 gha: use stable/oldstable go versions
• 2d9831f gha: compile-test for all supported Go versions
• 31bfec2 gha: test older Go versions in CI
• e11873c deps: downgrade golang.org/x/sys requirement
• 6ef6896 go: lower Go requirement to Go 1.18
• a06a225 tests: don't call testing.Testing() in mocks
• 07ceaf0 merge #36 into cyphar/filepath-securejoin:main
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[kolyshkin]

The linter warning here is a mystery to me. Here's what it says:

  Running [/home/runner/golangci-lint-1.60.3-linux-amd64/golangci-lint run] in [/home/runner/work/runc/runc] ...
  Received 365481 of 365481 (100.0%), 0.3 MBs/sec
  Error: libcontainer/capabilities/capabilities_linux_test.go:56:7: SA5011: possible nil pointer dereference (staticcheck)
  	if l.Level != expectedLogs.Level {
  	     ^
  Error: libcontainer/capabilities/capabilities_linux_test.go:53:5: SA5011(related information): this check suggests that the pointer can be nil (staticcheck)
 	if l == nil {
  	   ^
  
  Error: issues found

The code in question is here:

runc/libcontainer/capabilities/capabilities_linux_test.go

Lines 52 to 58 in aace922

	l := hook.LastEntry()
	if l == nil {
	t.Fatal("expected a warning, but got none")
	}
	if l.Level != expectedLogs.Level {
	t.Errorf("expected %q, got %q", expectedLogs.Level, l.Level)
	}

So, the warning seems valid but it's not (as calling t.Fatal ensures we don't dereference nil pointer, but maybe the linter doesn't know that).

Now, the mystery is why we haven't seen the warning before -- it's the same code (since 2021, commit 5fb831a) and the same linter version (since August, commit 606257c).

Trying to update golangci-lint to v1.62 in #4561 to make this go away.

[kolyshkin]

The linter warning here is a mystery to me.

Funny, I wanted to re-run the lint CI job to see if this is a one-off or not, and saw that @cyphar already did that (and the linter warning stays the same).

[cyphar]

Yeah, I was also confused by the failure and got to the same point you did. I hoped it was some super wacky race condition in the linter and not something we'd have to go debug. 😅

[lifubang]

Funny, I wanted to re-run the lint CI job to see if this is a one-off or not, and saw that @cyphar already did that (and the linter warning stays the same).

Rerun it today, it's green now. So this is very strange. Though #4561 is not necessary, but I think that's a regular dependency upgrade.

[cyphar]

@dependabot rebase
@dependabot merge

[dependabot]

Dependabot tried to merge this PR, but received the following error from GitHub:

At least 2 approving reviews are required by reviewers with write access.

[cyphar]

Huh, I thought dependabot would be able to handle setting up auto-merge for review requirements.

[dependabot]

Dependabot tried to merge this PR, but received the following error from GitHub:

At least 2 approving reviews are required by reviewers with write access.