- release notes: https://github.com/opencontainers/runc/releases/tag/v1.3.0
- full diff: https://github.com/opencontainers/runc/compare/v1.2.6..v1.3.0
-----
This is the first release of the 1.3.z release branch of runc. It
contains a few minor fixes for issues found in 1.3.0-rc.2.
This is the first release of runc that will follow our new release and
support policy (see RELEASES.md for more details). This means that, as
of this release:
* As of this release, the runc 1.2.z release branch will now only
receive security and "significant" bugfixes.
* Users are encouraged to plan migrating to runc 1.3.0 as soon as
possible.
* Due to its particular situation, runc 1.1.z is officially no longer
supported and will no longer receive any updates (not even for
critical security issues). Users are urged (in the strongest possible
terms) to upgrade to a supported version of runc.
* Barring any future changes to our release policy, users should expect
a runc 1.4.0 release in late October 2025.
Fixed
* Removed pre-emptive "full access to cgroups" warning when calling
`runc pause` or `runc unpause` as an unprivileged user without
`--systemd-cgroups`. Now the warning is only emitted if an actual permission
error was encountered.
* Several fixes to our CI, mainly related to AlmaLinux and CRIU.
Changed
* In runc 1.2, we changed our mount behaviour to correctly handle clearing
flags. However, the error messages we returned did not provide as much
information to users about what clearing flags were conflicting with locked
mount flags. We now provide more diagnostic information if there is an error
when in the fallback path to handle locked mount flags.
* Upgrade our CI to use golangci-lint v2.0.
* `runc version` information is now filled in using `//go:embed` rather than
being set through `Makefile`. This allows `go install` or other non-`make`
builds to contain the correct version information. Note that
`make EXTRA_VERSION=...` still works.
* Remove `exclude` directives from our `go.mod` for broken `cilium/ebpf`
versions. `v0.17.3` resolved the issue we had, and `exclude` directives are
incompatible with `go install`.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Allow overriding the go-swagger version to install.
With this patch:
docker build -q --call=outline --target=swagger .
TARGET: swagger
BUILD ARG VALUE DESCRIPTION
GO_VERSION 1.24.5
BASE_DEBIAN_DISTRO bookworm
GOLANG_IMAGE golang:1.24.5-bookworm
XX_VERSION 1.6.1
GO_SWAGGER_VERSION v0.32.3 specifies the version of the go-swagger binary to install.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- https://github.com/golang/go/issues?q=milestone%3AGo1.24.5+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.24.4...go1.24.5
This minor releases include 1 security fixes following the security policy:
- cmd/go: unexpected command execution in untrusted VCS repositories
Various uses of the Go toolchain in untrusted VCS repositories can result in
unexpected code execution. When using the Go toolchain in directories fetched
using various VCS tools (such as directly cloning Git or Mercurial repositories)
can cause the toolchain to execute unexpected commands, if said directory
contains multiple VCS configuration metadata (such as a '.hg' directory in a Git
repository). This is due to how the Go toolchain attempts to resolve which VCS
is being used in order to embed build information in binaries and determine
module versions.
The toolchain will now abort attempting to resolve which VCS is being used if it
detects multiple VCS configuration metadata in a module directory or nested VCS
configuration metadata (such as a '.git' directoy in a parent directory and a
'.hg' directory in a child directory). This will not prevent the toolchain from
building modules, but will result in binaries omitting VCS related build
information.
If this behavior is expected by the user, the old behavior can be re-enabled by
setting GODEBUG=allowmultiplevcs=1. This should only be done in trusted
repositories.
Thanks to RyotaK (https://ryotak.net) of GMO Flatt Security Inc for reporting
this issue.
This is CVE-2025-4674 and https://go.dev/issue/74380.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.24.5
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
- https://github.com/golang/go/issues?q=milestone%3AGo1.24.4+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.24.3...go1.24.4
This release includes 3 security fixes following the security policy:
- net/http: sensitive headers not cleared on cross-origin redirect
Proxy-Authorization and Proxy-Authenticate headers persisted on cross-origin redirects potentially leaking sensitive information.
Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for reporting this issue.
This is CVE-2025-4673 and Go issue https://go.dev/issue/73816.
- os: inconsistent handling of O_CREATE|O_EXCL on Unix and Windows
os.OpenFile(path, os.O_CREATE|O_EXCL) behaved differently on Unix and Windows systems when the target path was a dangling symlink. On Unix systems, OpenFile with O_CREATE and O_EXCL flags never follows symlinks. On Windows, when the target path was a symlink to a nonexistent location, OpenFile would create a file in that location.
OpenFile now always returns an error when the O_CREATE and O_EXCL flags are both set and the target path is a symlink.
Thanks to Junyoung Park and Dong-uk Kim of KAIST Hacking Lab for discovering this issue.
This is CVE-2025-0913 and Go issue https://go.dev/issue/73702.
- crypto/x509: usage of ExtKeyUsageAny disables policy validation
Calling Verify with a VerifyOptions.KeyUsages that contains ExtKeyUsageAny unintentionally disabledpolicy validation. This only affected certificate chains which contain policy graphs, which are rather uncommon.
Thanks to Krzysztof Skrzętnicki (@Tener) of Teleport for reporting this issue.
This is CVE-2025-22874 and Go issue https://go.dev/issue/73612.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
I'm horrible at vim, and use nano as my go-to editor for quick changes.
Let's install nano in the dev-container as alternative to vim for those
like me, who are not so vim-savvy ^O^C^C:wq:
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
`moby/vpnkit` now officially pushes a binary image to `moby/vpnkit-bin`
repository on Docker Hub.
Use it to fetch the vpnkit binary.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The syntax was pinned for 1.7 in f696e0d2a7
possibly because it was not yet promoted as "latest stable" at the
time.
I don't think we need to pin to an old version, and just go with
the latest, so that we can use the latest features provided.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This updates the Docker CLI version used for integration-cli tests from
v17.06.2-ce to v18.06.3-ce.
v18.06 is the first one that supports enabling BuildKit.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
full diff: https://github.com/golang/go/compare/go1.23.7...go1.23.8
release notes: https://go.dev/doc/devel/release#go1.24.2
go1.23.8 (released 2025-04-01) includes security fixes to the net/http package,
as well as bug fixes to the runtime and the go command. See the Go 1.23.8
milestone on our issue tracker for details;
https://github.com/golang/go/issues?q=milestone%3AGo1.23.8+label%3ACherryPickApproved
From the mailing list:
Hello gophers,
We have just released Go versions 1.24.2 and 1.23.8, minor point releases.
These minor releases include 1 security fixes following the security policy:
- net/http: request smuggling through invalid chunked data
The net/http package accepted data in the chunked transfer encoding
containing an invalid chunk-size line terminated by a bare LF.
When used in conjunction with a server or proxy which incorrectly
interprets a bare LF in a chunk extension as part of the extension,
this could permit request smuggling.
The net/http package now rejects chunk-size lines containing a bare LF.
Thanks to Jeppe Bonde Weikop for reporting this issue.
This is CVE-2025-22871 and Go issue https://go.dev/issue/71988.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Since commit cfc049c the dev container has been using iptables-nft,
but the Dockerfile configured firewalld to use its iptables backend
(if firewalld is enabled, which it accidentally hasn't been in CI).
The integration tests run ok for a while, then some things start
failing with the less than obvious message:
Error: COMMAND_FAILED: UNKNOWN_ERROR: nonexistent or underflow of priority count
So, let firewalld use its default nftables backend.
Signed-off-by: Rob Murray <rob.murray@docker.com>
