Move api/types.IDResponse to a "common" package (to prevent cyclic import
issues), and introduce a container.CommitResponse type as alias. This allows
consumers to use ContainerCommit without having to import the "types" package,
and allows us to differentiate the response for container commit separate from
other endpoints currently using IDResponse.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This minor release include 1 security fix following the security policy:
- crypto/elliptic: timing sidechannel for P-256 on ppc64le
Due to the usage of a variable time instruction in the assembly implementation
of an internal function, a small number of bits of secret scalars are leaked on
the ppc64le architecture. Due to the way this function is used, we do not
believe this leakage is enough to allow recovery of the private key when P-256
is used in any well known protocols.
This is CVE-2025-22866 and Go issue https://go.dev/issue/71383.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.23.6
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
go1.23.5 (released 2025-01-16) includes security fixes to the crypto/x509 and
net/http packages, as well as bug fixes to the compiler, the runtime, and the
net package. See the Go 1.23.5 milestone on our issue tracker for details;
- https://github.com/golang/go/issues?q=milestone%3AGo1.23.5+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.23.4...go1.23.5
Hello gophers,
We have just released Go versions 1.23.5 and 1.22.11, minor point releases.
These minor releases include 2 security fixes following the security policy:
- crypto/x509: usage of IPv6 zone IDs can bypass URI name constraints
A certificate with a URI which has a IPv6 address with a zone ID may
incorrectly satisfy a URI name constraint that applies to the certificate
chain.
Certificates containing URIs are not permitted in the web PKI, so this
only affects users of private PKIs which make use of URIs.
Thanks to Juho Forsén of Mattermost for reporting this issue.
This is CVE-2024-45341 and Go issue https://go.dev/issue/71156.
- net/http: sensitive headers incorrectly sent after cross-domain redirect
The HTTP client drops sensitive headers after following a cross-domain redirect.
For example, a request to a.com/ containing an Authorization header which is
redirected to b.com/ will not send that header to b.com.
In the event that the client received a subsequent same-domain redirect, however,
the sensitive headers would be restored. For example, a chain of redirects from
a.com/, to b.com/1, and finally to b.com/2 would incorrectly send the Authorization
header to b.com/2.
Thanks to Kyle Seely for reporting this issue.
This is CVE-2024-45336 and Go issue https://go.dev/issue/70530.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Networking tests have been creeping towards the limit for a
while, but they're reliably failing in a upcoming PR that adds
a relatively slow test.
Signed-off-by: Rob Murray <rob.murray@docker.com>
This is the fourth patch release of the 1.2.z release branch of runc. It
includes a fix for a regression introduced in 1.2.0 related to the
default device list.
- Re-add tun/tap devices to built-in allowed devices lists.
In runc 1.2.0 we removed these devices from the default allow-list
(which were added seemingly by accident early in Docker's history) as
a precaution in order to try to reduce the attack surface of device
inodes available to most containers. At the time we thought
that the vast majority of users using tun/tap would already be
specifying what devices they need (such as by using --device with
Docker/Podman) as opposed to doing the mknod manually, and thus
there would've been no user-visible change.
Unfortunately, it seems that this regressed a noticeable number of
users (and not all higher-level tools provide easy ways to specify
devices to allow) and so this change needed to be reverted. Users
that do not need these devices are recommended to explicitly disable
them by adding deny rules in their container configuration.
full diff: https://github.com/opencontainers/runc/compare/v1.2.3...v1.2.4
release notes: https://github.com/opencontainers/runc/releases/tag/v1.2.4
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Go has a nice tool to inspect the currently set (or default) `GOPATH`
with `go env GOPATH`.
We should do that rather than absolutely requiring people to manually
set `GOPATH` or use the `AUTO_GOPATH`.
This doesn't actually remove `AUTO_GOPATH`, people can still use it.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
This is the third patch release of the 1.2.z release branch of runc. It
primarily fixes some minor regressions introduced in 1.2.0.
- Fixed a regression in use of securejoin.MkdirAll, where multiple
runc processes racing to create the same mountpoint in a shared rootfs
would result in spurious EEXIST errors. In particular, this regression
caused issues with BuildKit.
- Fixed a regression in eBPF support for pre-5.6 kernels after upgrading
Cilium's eBPF library version to 0.16 in runc.
full diff: https://github.com/opencontainers/runc/compare/v1.2.2...v1.2.3
release notes: https://github.com/opencontainers/runc/releases/tag/v1.2.3
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- 1.2.2 release notes: https://github.com/opencontainers/runc/releases/tag/v1.2.2
- 1.2.1 release notes: https://github.com/opencontainers/runc/releases/tag/v1.2.1
- 1.2.0 release notes: https://github.com/opencontainers/runc/releases/tag/v1.2.0
Breaking changes and deprecations are included below;
Breaking changes:
Several aspects of how mount options work has been adjusted in a way that
could theoretically break users that have very strange mount option strings.
This was necessary to fix glaring issues in how mount options were being
treated. The key changes are:
- Mount options on bind-mounts that clear a mount flag are now always
applied. Previously, if a user requested a bind-mount with only clearing
options (such as rw,exec,dev) the options would be ignored and the
original bind-mount options would be set. Unfortunately this also means
that container configurations which specified only clearing mount options
will now actually get what they asked for, which could break existing
containers (though it seems unlikely that a user who requested a specific
mount option would consider it "broken" to get the mount options they
asked foruser who requested a specific mount option would consider it
"broken" to get the mount options they asked for). This also allows us to
silently add locked mount flags the user did not explicitly request to be
cleared in rootless mode, allowing for easier use of bind-mounts for
rootless containers.
- Container configurations using bind-mounts with superblock mount flags
(i.e. filesystem-specific mount flags, referred to as "data" in
mount(2), as opposed to VFS generic mount flags like MS_NODEV) will
now return an error. This is because superblock mount flags will also
affect the host mount (as the superblock is shared when bind-mounting),
which is obviously not acceptable. Previously, these flags were silently
ignored so this change simply tells users that runc cannot fulfil their
request rather than just ignoring it.
Deprecated
- runc option --criu is now ignored (with a warning), and the option will
be removed entirely in a future release. Users who need a non-standard
criu binary should rely on the standard way of looking up binaries in
$PATH.
- runc kill option -a is now deprecated. Previously, it had to be specified
to kill a container (with SIGKILL) which does not have its own private PID
namespace (so that runc would send SIGKILL to all processes). Now, this is
done automatically.
- github.com/opencontainers/runc/libcontainer/user is now deprecated, please
use github.com/moby/sys/user instead. It will be removed in a future
release.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
While it's still turned off by default, it's easier to just flip the
`false` to `true` inside the devcontainer.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Commit 4e567e16 added firewalld to the test matrix for various CI jobs
(namely unit, integration and integration-cli).
Commit 2807c0c2 reverted that commit as it was putting too much load on
GHA cache, and thus it was returning 429 more frequently, so builds had
a greater chance of spending time building everything from scratch. This
was slowing down our CI even more than what it was before.
This new commit re-adds firewalld to the test matrix of unit,
integration and integration-cli jobs. Unlike 4e567e16, not all
combinations of OS, storage and 'mode' will be tested. Instead,
firewalld jobs will run only on ubuntu-22.04, and with the containerd
snapshotter.
Also, the revert commit mistakenly reverted a fix that was originally
intended for commit 8883db20, but was actually 'fixed up' in the wrong
commit. Let's re-revert that too.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
Temporarily remove firewallds jobs. These are actually not running
firewalld due to a typo in GHA definitions. Moreover, these new jobs
are putting too much load on the CI, causing GHA cache backend to return
429 for many jobs. This slows down build jobs (as they can't use
existing cache), and at least one buildkit test is now failing.
This reverts commit 4e567e1622.
Signed-off-by: Albin Kerouanton <albinker@gmail.com>
BoltDB
- Fix the freelist.allocs isn't rollbacked when a tx is rollbacked.
CMD
- Add -gobench-output option for bench command to adapt to benchstat.
Other
- Bump go version to 1.22.x.
- This patch also added dmflakey package, which can be reused by other projects. See #812.
full diff: https://github.com/etcd-io/bbolt/compare/v1.3.10...v1.3.11
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- https://github.com/golang/go/issues?q=milestone%3AGo1.22.7+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.22.6...go1.22.7
These minor releases include 3 security fixes following the security policy:
- go/parser: stack exhaustion in all Parse* functions
Calling any of the Parse functions on Go source code which contains deeply nested literals can cause a panic due to stack exhaustion.
This is CVE-2024-34155 and Go issue https://go.dev/issue/69138.
- encoding/gob: stack exhaustion in Decoder.Decode
Calling Decoder.Decode on a message which contains deeply nested structures can cause a panic due to stack exhaustion.
This is a follow-up to CVE-2022-30635.
Thanks to Md Sakib Anwar of The Ohio State University (anwar.40@osu.edu) for reporting this issue.
This is CVE-2024-34156 and Go issue https://go.dev/issue/69139.
- go/build/constraint: stack exhaustion in Parse
Calling Parse on a "// +build" build tag line with deeply nested expressions can cause a panic due to stack exhaustion.
This is CVE-2024-34158 and Go issue https://go.dev/issue/69141.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.23.1
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Update the runc binary that's used in CI and for the static packages.
diff: https://github.com/opencontainers/runc/compare/v1.1.13...v1.1.14
Release Notes:
- Fix CVE-2024-45310, a low-severity attack that allowed maliciously configured containers to create empty files and directories on the host.
- Add support for Go 1.23.
- Revert "allow overriding VERSION value in Makefile" and add EXTRA_VERSION.
- rootfs: consolidate mountpoint creation logic.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
pie-mode is supported for windows/arm64 since https://go.dev/cl/452415,
which is part of go1.20. Also update link to Go source for pie-mode support
to match the location for current versions of Go because the package was
moved in https://go.dev/cl/438475.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
cross-compiling for arm/v5 was failing;
#56 84.12 /usr/bin/arm-linux-gnueabi-clang -marm -o $WORK/b001/exe/a.out -Wl,--export-dynamic-symbol=_cgo_panic -Wl,--export-dynamic-symbol=_cgo_topofstack -Wl,--export-dynamic-symbol=crosscall2 -Qunused-arguments -Wl,--compress-debug-sections=zlib /tmp/go-link-759578347/go.o /tmp/go-link-759578347/000000.o /tmp/go-link-759578347/000001.o /tmp/go-link-759578347/000002.o /tmp/go-link-759578347/000003.o /tmp/go-link-759578347/000004.o /tmp/go-link-759578347/000005.o /tmp/go-link-759578347/000006.o /tmp/go-link-759578347/000007.o /tmp/go-link-759578347/000008.o /tmp/go-link-759578347/000009.o /tmp/go-link-759578347/000010.o /tmp/go-link-759578347/000011.o /tmp/go-link-759578347/000012.o /tmp/go-link-759578347/000013.o /tmp/go-link-759578347/000014.o /tmp/go-link-759578347/000015.o /tmp/go-link-759578347/000016.o /tmp/go-link-759578347/000017.o /tmp/go-link-759578347/000018.o -O2 -g -O2 -g -O2 -g -lpthread -O2 -g -no-pie -static
#56 84.12 ld.lld: error: undefined symbol: __atomic_load_4
#56 84.12 >>> referenced by gcc_libinit.c
#56 84.12 >>> /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
#56 84.12 >>> referenced by gcc_libinit.c
#56 84.12 >>> /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
#56 84.12 >>> referenced by gcc_libinit.c
#56 84.12 >>> /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
#56 84.12 >>> referenced 2 more times
#56 84.12
#56 84.12 ld.lld: error: undefined symbol: __atomic_store_4
#56 84.12 >>> referenced by gcc_libinit.c
#56 84.12 >>> /tmp/go-link-759578347/000009.o:(_cgo_wait_runtime_init_done)
#56 84.12 >>> referenced by gcc_libinit.c
#56 84.12 >>> /tmp/go-link-759578347/000009.o:(x_cgo_notify_runtime_init_done)
#56 84.12 >>> referenced by gcc_libinit.c
#56 84.12 >>> /tmp/go-link-759578347/000009.o:(x_cgo_set_context_function)
#56 84.12 clang: error: linker command failed with exit code 1 (use -v to see invocation)
From discussion on GitHub;
https://github.com/moby/moby/pull/46982#issuecomment-2206992611
The arm/v5 build failure looks to be due to libatomic not being included
in the link. For reasons probably buried in mailing list archives,
[gcc](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358) and clang don't
bother to implicitly auto-link libatomic. This is not a big deal on many
modern platforms with atomic intrinsics as the compiler generates inline
instruction sequences, avoiding any libcalls into libatomic. ARMv5 is not
one of those platforms: all atomic operations require a libcall.
In theory, adding `CGO_LDFLAGS=-latomic` should fix arm/v5 builds.
While it could be argued that cgo should automatically link against
libatomic in the same way that it automatically links against libpthread,
the Go maintainers would have a valid counter-argument that it should be
the C toolchain's responsibility to link against libatomic automatically,
just like it does with libgcc or compiler-rt.
Co-authored-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Cory Snider <csnider@mirantis.com>
cross-compiling for arm/v5 fails on go1.22; a fix is included for this
in go1.23 (https://github.com/golang/go/issues/65290), but for go1.22
we can set the correct option manually.
1.189 + go build -mod=vendor -modfile=vendor.mod -o /tmp/bundles/binary-daemon/dockerd -tags 'netgo osusergo static_build journald' -ldflags '-w -X "github.com/docker/docker/dockerversion.Version=dev" -X "github.com/docker/docker/dockerversion.GitCommit=HEAD" -X "github.com/docker/docker/dockerversion.BuildTime=2024-08-29T16:59:57.000000000+00:00" -X "github.com/docker/docker/dockerversion.PlatformName=" -X "github.com/docker/docker/dockerversion.ProductName=" -X "github.com/docker/docker/dockerversion.DefaultProductLicense=" -extldflags -static ' -gcflags= github.com/docker/docker/cmd/dockerd
67.78 # runtime/cgo
67.78 gcc_libinit.c:44:8: error: large atomic operation may incur significant performance penalty; the access size (4 bytes) exceeds the max lock-free size (0 bytes) [-Werror,-Watomic-alignment]
67.78 gcc_libinit.c:47:6: error: large atomic operation may incur significant performance penalty; the access size (4 bytes) exceeds the max lock-free size (0 bytes) [-Werror,-Watomic-alignment]
67.78 gcc_libinit.c:49:10: error: large atomic operation may incur significant performance penalty; the access size (4 bytes) exceeds the max lock-free size (0 bytes) [-Werror,-Watomic-alignment]
67.78 gcc_libinit.c:69:9: error: large atomic operation may incur significant performance penalty; the access size (4 bytes) exceeds the max lock-free size (0 bytes) [-Werror,-Watomic-alignment]
67.78 gcc_libinit.c:71:3: error: large atomic operation may incur significant performance penalty; the access size (4 bytes) exceeds the max lock-free size (0 bytes) [-Werror,-Watomic-alignment]
78.20 + rm -f /go/src/github.com/docker/docker/go.mod
Co-authored-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Cory Snider <csnider@mirantis.com>
