Includes multiline support in the chat, improved pull messages, show untagged and removed information on `rm`, allow implicit registry on `tag` and `--backend` tag for `run` and `list`. https://github.com/docker/model-cli/releases/tag/v0.1.34.
Signed-off-by: Dorin Geman <dorin.geman@docker.com>
This adds support for the USER_AGENT environment variable set by Compose (in conjunction with Compose v2.38.2).
Signed-off-by: Dorin Geman <dorin.geman@docker.com>
- https://github.com/golang/go/issues?q=milestone%3AGo1.24.5+label%3ACherryPickApproved
- full diff: golang/go@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>
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The Docker CLI no longer requires libtool-ltdl as a build dependency.
Previously it was an indirect dependency introduced by pkcs11, but it's
no longer needed after:
cb3e55bf58
This patch removes these dependencies from both the Debian control file
and RPM spec files.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This brings support for the new top-level models: key in Compose (in
conjunction with Compose v2.38.1).
Signed-off-by: Jacob Howard <jacob.howard@docker.com>
This disables DWARF generation, which dramatically decreases the size of the binary.
Notably, this does *not* include `-s` which disables the symbol table, as doing so would *also* make it so that `govulncheck` cannot be run on the resulting binary with meaningful results.
Before is ~90M and after is ~72M.
If we add `-s` as well, that ~72M drops to ~63M, but we also lose `govulncheck` so again, IMO, that's not worth doing.
Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
Ubuntu 20.04 reached end of support on April 30. There's still commercial
ESM (Extended Security Maintenance) support, but we don't account for that
in our packages; https://ubuntu.com/blog/ubuntu-20-04-eol-for-devicesional
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit 3ded61e6d7 moved the man-pages for
dockerd to the docker-ce package, but used the wrong path for installing
them, which resulted in the man-pages being installed in a "man" subdirectory
with.
Before this patch:
make fedora-42
rpm -ql ./rpm/rpmbuild/fedora-42/RPMS/aarch64/docker-ce-*.rpm | grep dockerd.8
/usr/share/man/man/man8/dockerd.8.gz
After this patch:
make fedora-42
rpm -ql ./rpm/rpmbuild/fedora-42/RPMS/aarch64/docker-ce-*.rpm | grep dockerd.8
/usr/share/man/man8/dockerd.8.gz
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Switches away from the groupadd postinstall commands to managing
the docker group with sysusers.
This is a declarative way to create and manage users, better suited
for the atomic distros such as Silverblue.
Signed-off-by: Robert Sturla <robertsturla@outlook.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Before this patch, lintian would complain about missing pre-depends:
lintian ./*.deb
...
W: docker-ce: skip-systemd-native-flag-missing-pre-depends (does not satisfy init-system-helpers:any) [postinst:51]
W: docker-ce: skip-systemd-native-flag-missing-pre-depends (does not satisfy init-system-helpers:any) [prerm:10]
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Before this patch, some linting warnings were shown related to the descriptions
lintian ./*.deb
...
W: docker-ce: extended-description-line-too-long line 5
W: docker-ce-cli: extended-description-line-too-long line 5
W: docker-ce-rootless-extras: description-starts-with-leading-spaces line 1
E: docker-buildx-plugin: extended-description-is-empty
W: docker-compose-plugin: extended-description-contains-empty-paragraph
W: docker-model-plugin: extended-description-contains-empty-paragraph
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Docker Model Runner's support for Docker CE is going to require
availability of the docker model command, so this commit adds the new
package by following the mechanisms used by buildx and compose.
Signed-off-by: Jacob Howard <jacob.howard@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>
We had a few "runaway jobs" in other repos, where the job got stuck, and kept
running for 6 hours (in one case even 24 hours, probably due some github
outage). Some of those jobs could not be terminated.
While running these actions on public repositories doesn't cost us, it's
still not desirable to have jobs running for that long (as they can still
hold up the queue).
This patch adds a blanket "1 hour" time-limit. We should look at tweaking
the limit to actually expected duration, but having a default at least is
a start.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- https://github.com/golang/go/issues?q=milestone%3AGo1.23.7+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.23.6...go1.23.7
These minor releases include 1 security fixes following the security policy:
net/http, x/net/proxy, x/net/http/httpproxy: proxy bypass using IPv6 zone IDs
Matching of hosts against proxy patterns could improperly treat an IPv6
zone ID as a hostname component. For example, when the NO_PROXY
environment variable was set to "*.example.com", a request to
"[::1%25.example.com]:80` would incorrectly match and not be proxied.
Thanks to Juho Forsén of Mattermost for reporting this issue.
This is CVE-2025-22870 and Go issue https://go.dev/issue/71984.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.23.7
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Enables docker-ce builds for Fedora 42. This will be GA in a couple months, and like usual,
has a lifespan of two years.
The workarounds required for Go on ARM are still required on this version, so have
been left in. The comments are still relevant.
Signed-off-by: Robert Sturla <robertsturla@outlook.com>
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>
When splitting the docker CLI from the moby/moby repository, the dockerd
documentation and man-pages were moved to the CLI repository. This was a
bit of a bad choice, as now the documentation and code lived in separate
repositories, but when the CLI and dockerd packages were split, the man
page for dockerd ended up in the CLI package.
Starting with [moby@d6e9b5f], the dockerd man-page has been reintegrated
into the moby repository, which means that we can build the man-page
from that repository, and remove it from the CLI repository.
This patch updates the packing to do so:
Before this patch;
dpkg-deb -c docker-ce_0.0.0~20250124134141.b8879a4-1~ubuntu.24.04~noble_arm64.deb | grep -E '^-'
-rw-r--r-- root/root 642 2025-01-24 14:29 ./etc/default/docker
-rwxr-xr-x root/root 2946 2025-01-24 14:29 ./etc/init.d/docker
-rwxr-xr-x root/root 2741336 2025-01-24 19:54 ./usr/bin/docker-proxy
-rw-r--r-- root/root 1727 2025-01-24 14:29 ./usr/lib/systemd/system/docker.service
-rw-r--r-- root/root 295 2025-01-24 14:29 ./usr/lib/systemd/system/docker.socket
-rwxr-xr-x root/root 604336 2025-01-24 19:54 ./usr/libexec/docker/docker-init
-rw-r--r-- root/root 2248 2025-01-24 14:29 ./usr/share/doc/docker-ce/README.md
-rw-r--r-- root/root 168 2025-01-24 19:54 ./usr/share/doc/docker-ce/changelog.Debian.gz
rpm -qpl ./docker-ce-0.0.0~20250124134141.b8879a4-0.fc41.aarch64.rpm
/etc/docker
/usr/bin/docker-proxy
/usr/bin/dockerd
/usr/lib/systemd/system/docker.service
/usr/lib/systemd/system/docker.socket
/usr/libexec/docker/docker-init
With this patch:
dpkg-deb -c docker-ce_0.0.0~20250124134141.b8879a4-1~ubuntu.24.04~noble_arm64.deb | grep -E '^-'
-rw-r--r-- root/root 642 2025-01-24 14:29 ./etc/default/docker
-rwxr-xr-x root/root 2946 2025-01-24 14:29 ./etc/init.d/docker
-rwxr-xr-x root/root 2741336 2025-01-24 20:55 ./usr/bin/docker-proxy
-rwxr-xr-x root/root 79458592 2025-01-24 20:55 ./usr/bin/dockerd
-rw-r--r-- root/root 1727 2025-01-24 14:29 ./usr/lib/systemd/system/docker.service
-rw-r--r-- root/root 295 2025-01-24 14:29 ./usr/lib/systemd/system/docker.socket
-rwxr-xr-x root/root 604336 2025-01-24 20:55 ./usr/libexec/docker/docker-init
-rw-r--r-- root/root 2248 2025-01-24 14:29 ./usr/share/doc/docker-ce/README.md
-rw-r--r-- root/root 166 2025-01-24 20:55 ./usr/share/doc/docker-ce/changelog.Debian.gz
-rw-r--r-- root/root 6561 2025-01-24 20:55 ./usr/share/man/man8/dockerd.8.gz
rpm -qpl ./docker-ce-0.0.0~20250124134141.b8879a4-0.fc41.aarch64.rpm
/etc/docker
/usr/bin/docker-proxy
/usr/bin/dockerd
/usr/lib/systemd/system/docker.service
/usr/lib/systemd/system/docker.socket
/usr/libexec/docker/docker-init
/usr/share/man/man8/dockerd.8.gz
Given that the dockerd man-page was previously packaged as part of docker-ce-cli,
we need to add a "Replaces:" condition to the package, to prevent dpkg from
detecting it as a conflict when an older version of the docker-ce-cli package
was installed that contains the manpage;
Unpacking docker-ce (5:0.0.0~20250124134141.b8879a4-1~raspbian.12~bookworm) ...
dpkg: error processing archive ./deb/debbuild/raspbian-bookworm/docker-ce_0.0.0~20250124134141.b8879a4-1~raspbian.12~bookworm_armhf.deb (--install):
trying to overwrite '/usr/share/man/man8/dockerd.8.gz', which is also in package docker-ce-cli 5:0.0.0~20250124134141.b8879a4-1~raspbian.12~bookworm
From the [Debian manual][1]
> 7.6.1. Overwriting files in other packages
>
> It is usually an error for a package to contain files which are on the
> system in another package. However, if the overwriting package declares
> that it Replaces the one containing the file being overwritten, then dpkg
> will replace the file from the old package with that from the new. The
> file will no longer be listed as “owned” by the old package and will be
> taken over by the new package.
[1]: https://www.debian.org/doc/debian-policy/ch-relationships.html
[moby@d6e9b5f]: d6e9b5fe30
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The CLI currently builds man-pages for sections 1, 5, and 8, but this
list may change; for example, the dockerd man-page is currently built
from the CLI repository but intended to be removed.
This patch changes the code to check all (1..9) secions, and install the
man-pages found in them.
This patch also updates the %doc and %files section; from the Fedora packaging
guide (see [1]);
> The %files section holds a list of all the files that RPM should install
> from the package. **This list should be exhaustive**, so that the RPM system
> knows exactly what your package installs. There are some options, though,
> to name all the files within a directory to help with packages containing
> hundreds of files.
> (...)
> In addition to naming each file on a line, you can use glob-style wildcards.
But also worth noting that it's NOT needed to mark manpages as %doc, see [2];
> Note also that files installed in %{_mandir} are automatically marked by RPM
> as documentation. Thus it is not necessary to use %doc.
So this patch:
- uses wildcards to enumerate all manpages in all sections
- removes the %doc for manpages, as this is automatic.
[1]: https://jfearn.fedorapeople.org/en-US/RPM/4/html/RPM_Guide/ch09s05.html
[2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_manpages
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
For make commands, we can just pass the directory through "-C", and for
"install" we can pass the full path of the source.
There's some remaining uses for targets that build through a script
or using "go build", which may still require changing.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The dh_bash-completion debhelper provides an easy way to install the
shell-completion scripts for Bash. Unfortunately there is no stable
equivalent yet for the other shells (zsh, fish, powershell), which
resulted in two out of three shells requiring manual install.
Given that the installation path for Bash is [well-documented][1],
we can align Bash with the other shells to make this less confusing.
This patch makes that change, and adds a code-comment to outline
the reasoning (and possible future options) for future readers.
[1]: 79fd051907/README.md
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Makes it slightly clearer where installing the CLI itself
ends, and where installing completion scripts start.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This unlikely makes a big difference, as some files may have timestamps
based on checkout date or being generated, but it doesn't hurt doing
either.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This unlikely makes a big difference, as some files may have timestamps
based on checkout date or being generated, but it doesn't hurt doing
either.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The "-D" option creates parent directories if missing; we
can use it in most places, except for one where we're using
wildcards, as installing multiple files requires the target
directory to exist.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The "make dynbinary" target calls ./scripts/build/binary with the
right options set, and does not use docker to build (so can be
run as part of our deb/rpm build scripts.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Remove the obsoletes for `docker-ce-selinux`, `docker-engine-selinux`, and
`docker-engine`.
These were obsoleted in 2017 through 94943b4752
> Mark docker-*-selinux pkgs as obsolete
>
> These are replaced by `container-selinux` on fedora-25 and centos-7.
> Marking these packages as obsolete makes the installation process a bit
> smoother, otherwise the user will have to manually uninstall the older
> packages to install the new one.
>
> Also makes fedora24 use container-selinux which is now supports labeling
> the `dockerd` binary correctly.
Both CentOS 6/7 and Fedora 25 are EOL now, and these packages have not been
published for a long time. Time to remove them, also to reduce some noise
during builds;
RPM build warnings:
line 51: It's not recommended to have unversioned Obsoletes: Obsoletes: docker-ce-selinux
line 52: It's not recommended to have unversioned Obsoletes: Obsoletes: docker-engine-selinux
line 53: It's not recommended to have unversioned Obsoletes: Obsoletes: docker-engine
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
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>
Update the license fields to use the (now recommented) SPDX identifier;
> https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ lists
> Apache-2.0 as the SPDX identifier and ASL 2.0 as a "Legacy Abbreviation"
> for Apache License 2.0.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This reverts commit 78242140d7.
That change was added to fix a missing archive_write_add_filter_zstd when
compiling tini, but it's no longer needed;
> Add libarchive build-dep to fix missing archive_write_add_filter_zstd
>
> Trying to fix
>
> + echo 'Install tini version de40ad007797e0dcd8b7126f27bb87401d224240'
> + git clone https://github.com/krallin/tini.git /go/tini
> Install tini version de40ad007797e0dcd8b7126f27bb87401d224240
> Cloning into '/go/tini'...
> + cd /go/tini
> + git checkout -q de40ad007797e0dcd8b7126f27bb87401d224240
> + cmake .
> cmake: symbol lookup error: cmake: undefined symbol: archive_write_add_filter_zstd
> error: Bad exit status from /var/tmp/rpm-tmp.Dl5CDf (%build)
>
> According to https://bugs.centos.org/view.php?id=18212, upgrading to libarchive-3.3.3-1.el8.x86_64
> should resolve the problem.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The AuFS storage driver was deprecated and removed, so we can remove it
as a suggested dependency.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The version constraint was added in e4b1c10a6b,
later updated in a246b19b07 to prevent old
versions to be used, as they had some issues.
Current version on RHEL8 (which is the oldest rpm distro we build for) is
2:2.229, so we can remove this explicit constraint.
Installing:
container-selinux noarch 2:2.229.0-2.module+el8.10.0+22417+2fb00970 ubi-8-appstream-rpms 71 k
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This dependency was added in [docker@42d8fe6], at which time we were building
a docker-selinux policy with additional policies, but we're now depending
on the distro's `container-selinux` package and it was removed in the moby
repository in [docker@bfe5cab], so we can remove it here as well.
[docker@42d8fe6]: 42d8fe6105
[docker@bfe5cab]: bfe5cab13b
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
We used to have `libseccomp-dev` as a build-time dependency, but this
part is handled by the OCI runtime (runc). Similarly, the `libseccomp2`
runtime dependency is used by `runc`, not by `dockerd` directly.
The docker-ce package depends on `containerd.io`, which defines `libseccomp2`
as a dependency, so we can remove it from the docker-ce package;
apt-cache depends containerd.io
containerd.io
Depends: libc6
Depends: libseccomp2
Conflicts: containerd
Conflicts: runc
Replaces: containerd
containerd.io
Replaces: runc
containerd.io
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Depending on the host configuration, the `br_netfilter` module may not
be loaded by default. In this situation, docker will try to load the module
through `modprobe`.
Older versions of docker would silently ignore failing to do so, log a message,
and continue;
time="2024-11-29T20:04:58.538404376Z" level=warning msg="Running modprobe bridge br_netfilter failed with message: , error: exec: \"modprobe\": executable file not found in $PATH"
However, starting with [db25b0dcd0461802289e962aa0df3abd323d1994][1] and
[264c15bfc427d1321c5b302e48e16d113b06ef92][2], we now produce an error:
=== FAIL: libnetwork/drivers/bridge TestCreateFullOptions (0.04s)
time="2024-11-29T19:03:44Z" level=error msg="Running modprobe br_netfilter failed with message: " error="exec: \"modprobe\": executable file not found in $PATH"
bridge_linux_test.go:280: Failed to create bridge: loadBridgeNetFilterModule failed: cannot restrict inter-container communication: modprobe br_netfilter failed: exec: "modprobe": executable file not found in $PATH
This patch updates the packages to add `kmod` (which provides `modprobe`)
as a recommended dependency. We should probably look for alternatives in
our code to not require `modprobe`.
[1]: db25b0dcd0
[2]: 264c15bfc4
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Use image "stream10-development" for now, after the release we should
remove the "-development" suffix.
Signed-off-by: Romain Geissler <romain.geissler@amadeus.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 784a53cec5 added `rpmlint` to the
Dockerfiles and added a step in the Dockerfile to validate the SPEC files.
The validation step was removed in c245ce12c1,
but didn't remove the step to install the package.
The `rpmlint` package is also being removed from CentOS Stream 10 ("CS10");
- https://issues.redhat.com/browse/CS-2451
- https://issues.redhat.com/browse/CS-2453
Remove the package as it's not used currently.
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.22.7
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This is the equivalent of https://github.com/docker/containerd-packaging/pull/390
for containerd packages, but unlike for containerd packages, we currently do
not run into this issue when building docker-ce packages. We're installing
this as a precaution, but perhaps it's not needed.
go1.21 and up have a patch that enforces the use of ld.gold to work around
a bug in GNU binutils. See;
- https://github.com/golang/go/issues/22040.
- cd77738198
Fedora 41 and up has a fixed version of binutils, and no longer requires that
patch, but may fail without ld.gold installed;
/usr/bin/gcc -Wl,-z,now -Wl,-z,nocopyreloc -fuse-ld=gold -o $WORK/b001/exe/a.out -rdynamic /tmp/go-link-1738353519/go.o /tmp/go-link-1738353519/000000.o /tmp/go-link-1738353519/000001.o /tmp/go-link-1738353519/000002.o /tmp/go-link-1738353519/000003.o /tmp/go-link-1738353519/000004.o /tmp/go-link-1738353519/000005.o /tmp/go-link-1738353519/000006.o /tmp/go-link-1738353519/000007.o /tmp/go-link-1738353519/000008.o /tmp/go-link-1738353519/000009.o /tmp/go-link-1738353519/000010.o /tmp/go-link-1738353519/000011.o /tmp/go-link-1738353519/000012.o /tmp/go-link-1738353519/000013.o /tmp/go-link-1738353519/000014.o /tmp/go-link-1738353519/000015.o /tmp/go-link-1738353519/000016.o /tmp/go-link-1738353519/000017.o /tmp/go-link-1738353519/000018.o /tmp/go-link-1738353519/000019.o /tmp/go-link-1738353519/000020.o /tmp/go-link-1738353519/000021.o /tmp/go-link-1738353519/000022.o /tmp/go-link-1738353519/000023.o /tmp/go-link-1738353519/000024.o -O2 -g -lresolv -O2 -g -lpthread -O2 -g -ldl -O2 -g
collect2: fatal error: cannot find 'ld'
Fedora's build of Go carries a patch for that, but it's not (yet) in upstream;
- a867bd88a6/f/0006-Default-to-ld.bfd-on-ARM64.patch
- a867bd88a6?branch=rawhide
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `GO_IMAGE` build-arg doesn't have a default;
- InvalidDefaultArgInFrom: Default value for ARG ${GO_IMAGE} results in empty or invalid base image name (line 8)
This is not a real issue when building using the Makefiles (which is how
these Dockerfiles are expected to be used) but we can probably set a
default.
This patch sets the default to `golang:latest` to pick the latest version,
which should be fine for this (until we get a linter recommending not
to use `:latest`).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit d61915e6c4 addressed these warnings
for the deb-based Dockerfiles, but didn't update the rpm ones;
- LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy "ENV key value" format (line 13)
- LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy "ENV key value" format (line 15)
- LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy "ENV key value" format (line 16)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit a4090a0e19 added GOTOOLCHAIN=local,
but for some reason missed the centos Dockerfiles.
The env-var is set to make sure we don't get unexpected updates of the go
toolchain when building. We need to set this env-var, because we're not using
the official golang image as base-image, but instead copy the binaries into
a distro-image.
This patch adds the missing GOTOOLCHAIN env-vars.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The addrepo command has a bug that causes it to fail if the `.repo` file
contains empty lines, causing it to fail;
dnf config-manager addrepo --from-repofile="https://download.docker.com/linux/fedora/docker-ce.repo"
Error in added repository configuration file. Cannot set repository option "#1=
": Option "#1" not found
Use a temporary file and strip empty lines as a workaround until the bug
is fixed.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Fedora 41 and up use the new dnf5 as default, which is a rewrite of
the dnf commands with different options;
+ dnf config-manager --add-repo https://download.docker.com/linux/fedora/docker-ce.repo
Unknown argument "--add-repo" for command "config-manager". Add "--help" for more information about the arguments.
make: *** [Makefile:95: verify] Error 2
script returned exit code 2
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- use command -v for detecting dnf instead of the --version
- quote repo-IDs to prevent globbing by the shell
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Taking a similar approach as is used for containerd-packaging.
Note that the resulting subscription file will still be persisted
in the image, but this image is only used as an ephemeral image,
and on our builder-nodes.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Replace legacy `ENV key value` syntax with `ENV key=value`.
This fixes the build linter warning LegacyKeyValueFormat.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The `docker-proxy.exe` binary was added to the static Windows packages through
commit 09541b553c (which introduced a bug, later
fixed through fc5379fee8).
It looks like that commit added the `docker-proxy.exe` binary with the
assumption that it's used on Windows (given that its also built in upstream),
but recent discussions revealed that's not the case.
This patch removes binary from the static packages for Windows, because it's
not used.
A quick look at Docker Desktop's build scripts show that it's not included
in those packages, and installation instructions for static binaries on
Windows do not mention this binary, so no further changes should be needed.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The containerd-shim binary that's shipped with containerd 1.6 did not provide
a `-v` flag to show the version, so f1f6f220e6
used `--help` as alternative.
Now that we package containerd 1.7, we can use the `-v` flag instead;
containerd-shim -v
containerd-shim
Version: 1.7.19
Revision: 2bf793ef6dc9a18e00cb12efb64355c2c9d5eb41
Go version: go1.21.12
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Now that CentOS/RHEL 7 and 8 reached EOL and removed from our packaging
(in 88a6cdca6c, 67c89e9aa0),
we can remove the patch.
> RLIMIT_NOFILE defaults to an unusable value on EL 7 systems, but more
> modern systems have sane defaults. As such, patch the systemd unit only
> on EL 7 systems to ensure correct behaviour.
This reverts commit 4e7a147bbc.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- https://github.com/golang/go/issues?q=milestone%3AGo1.21.12+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.21.11...go1.21.12
These minor releases include 1 security fixes following the security policy:
net/http: denial of service due to improper 100-continue handling
The net/http HTTP/1.1 client mishandled the case where a server responds to a request with an "Expect: 100-continue" header with a non-informational (200 or higher) status. This mishandling could leave a client connection in an invalid state, where the next request sent on the connection will fail.
An attacker sending a request to a net/http/httputil.ReverseProxy proxy can exploit this mishandling to cause a denial of service by sending "Expect: 100-continue" requests which elicit a non-informational response from the backend. Each such request leaves the proxy with an invalid connection, and causes one subsequent request using that connection to fail.
Thanks to Geoff Franks for reporting this issue.
This is CVE-2024-24791 and Go issue https://go.dev/issue/67555.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.21.12
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Remove this version of Debian, which reaches end of the line. End of standard
support already reached EOL on 2022-09-10, and stopped advertising this version
of Debian in our documentation, but builds were still running.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.21.11 (released 2024-06-04) includes security fixes to the archive/zip
and net/netip packages, as well as bug fixes to the compiler, the go command,
the runtime, and the os package. See the Go 1.21.11 milestone on our issue
tracker for details;
- https://github.com/golang/go/issues?q=milestone%3AGo1.21.11+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.21.10...go1.21.11
From the security announcement;
We have just released Go versions 1.22.4 and 1.21.11, minor point releases.
These minor releases include 2 security fixes following the security policy:
- archive/zip: mishandling of corrupt central directory record
The archive/zip package's handling of certain types of invalid zip files
differed from the behavior of most zip implementations. This misalignment
could be exploited to create an zip file with contents that vary depending
on the implementation reading the file. The archive/zip package now rejects
files containing these errors.
Thanks to Yufan You for reporting this issue.
This is CVE-2024-24789 and Go issue https://go.dev/issue/66869.
- net/netip: unexpected behavior from Is methods for IPv4-mapped IPv6 addresses
The various Is methods (IsPrivate, IsLoopback, etc) did not work as expected
for IPv4-mapped IPv6 addresses, returning false for addresses which would
return true in their traditional IPv4 forms.
Thanks to Enze Wang of Alioth and Jianjun Chen of Zhongguancun Lab
for reporting this issue.
This is CVE-2024-24790 and Go issue https://go.dev/issue/67680.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This was added in [docker@a15b67b1affb2eac5365614e55703f43b6f73e9b] (2015),
at which time this package was already deprecated / replaced:
> Add old docker-engine-cs name to package conflicts
[docker@a15b67b1affb2eac5365614e55703f43b6f73e9b]: a15b67b1af
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- https://github.com/golang/go/issues?q=milestone%3AGo1.21.10+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.21.9...go1.21.10
These minor releases include 2 security fixes following the security policy:
- cmd/go: arbitrary code execution during build on darwin
On Darwin, building a Go module which contains CGO can trigger arbitrary code execution when using the Apple version of ld, due to usage of the -lto_library flag in a "#cgo LDFLAGS" directive.
Thanks to Juho Forsén of Mattermost for reporting this issue.
This is CVE-2024-24787 and Go issue https://go.dev/issue/67119.
- net: malformed DNS message can cause infinite loop
A malformed DNS message in response to a query can cause the Lookup functions to get stuck in an infinite loop.
Thanks to long-name-let-people-remember-you on GitHub for reporting this issue, and to Mateusz Poliwczak for bringing the issue to our attention.
This is CVE-2024-24788 and Go issue https://go.dev/issue/66754.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.22.3
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
commit 07b5d9031f disabled seccomp for the
deb-builds because `chmod` failed tar was failing with an EPERM (Ubuntu
24.04 armhf on 20.04 host).
It looks like the same problem happens when running Fedora 40 on a Debian
bookworm host on ppc64le.
That issue was confirmed to be related to `fchmodat2(2)`, which is a new
syscall that's not supported on the host, and therefore gets the seccomp's
default EPERM;
fchmodat2(AT_FDCWD, "docker", 0775, AT_SYMLINK_NOFOLLOW) = -1 EPERM (Operation not permitted)
tar: docker: Cannot change mode to rwxrwxr-x: Operation not permitted
tar: Exiting with failure status due to previous errors
Ultimately we need to update the libseccomp profile to use ENOSYS (see
moby ticket 42871) to allow it to degrade gracefully;
fchmodat2(AT_FDCWD, "docker", 0775, AT_SYMLINK_NOFOLLOW) = -1 ENOSYS (Function not implemented)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.21.9 (released 2024-04-03) includes a security fix to the net/http
package, as well as bug fixes to the linker, and the go/types and
net/http packages. See the [Go 1.21.9 milestone](https://github.com/golang/go/issues?q=milestone%3AGo1.21.9+label%3ACherryPickApproved)
for more details.
These minor releases include 1 security fixes following the security policy:
- http2: close connections when receiving too many headers
Maintaining HPACK state requires that we parse and process all HEADERS
and CONTINUATION frames on a connection. When a request's headers exceed
MaxHeaderBytes, we don't allocate memory to store the excess headers but
we do parse them. This permits an attacker to cause an HTTP/2 endpoint
to read arbitrary amounts of header data, all associated with a request
which is going to be rejected. These headers can include Huffman-encoded
data which is significantly more expensive for the receiver to decode
than for an attacker to send.
Set a limit on the amount of excess header frames we will process before
closing a connection.
Thanks to Bartek Nowotarski (https://nowotarski.info/) for reporting this issue.
This is CVE-2023-45288 and Go issue https://go.dev/issue/65051.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.21.9
- https://github.com/golang/go/issues?q=milestone%3AGo1.21.9+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.21.8...go1.21.9
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
Debian armhf is armv7 and hard-float, and Raspbian is a rebuild of
Debian with armv6 and hard-float. This is done to make use of the
BCM2835 FPU, as while the Debian armel (armv5 and soft-float) port
works, it does not make full use of the CPU's hardware.
By making this change, our 'armhf' binaries will work on both armv6 and
armv7 systems.
Signed-off-by: Bjorn Neergaard <bjorn.neergaard@docker.com>
Both the DOCKER_COMPOSE_REF and DOCKER_BUILDX_REF versions are frequently
updated, which made it more likely to run into merge conflicts when
pull requests are merged to update either.
Add a comment in between to reduce the probability for such PRs to
conflict.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The End of Standard Support is set to June, not April, in 2027.
https://wiki.ubuntu.com/Releases
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
go1.21.5 (released 2023-12-05) includes security fixes to the go command,
and the net/http and path/filepath packages, as well as bug fixes to the
compiler, the go command, the runtime, and the crypto/rand, net, os, and
syscall packages. See the Go 1.21.5 milestone on our issue tracker for
details:
- https://github.com/golang/go/issues?q=milestone%3AGo1.21.5+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.21.5...go1.21.5
from the security mailing:
[security] Go 1.21.5 and Go 1.20.12 are released
Hello gophers,
We have just released Go versions 1.21.5 and 1.20.12, minor point releases.
These minor releases include 3 security fixes following the security policy:
- net/http: limit chunked data overhead
A malicious HTTP sender can use chunk extensions to cause a receiver
reading from a request or response body to read many more bytes from
the network than are in the body.
A malicious HTTP client can further exploit this to cause a server to
automatically read a large amount of data (up to about 1GiB) when a
handler fails to read the entire body of a request.
Chunk extensions are a little-used HTTP feature which permit including
additional metadata in a request or response body sent using the chunked
encoding. The net/http chunked encoding reader discards this metadata.
A sender can exploit this by inserting a large metadata segment with
each byte transferred. The chunk reader now produces an error if the
ratio of real body to encoded bytes grows too small.
Thanks to Bartek Nowotarski for reporting this issue.
This is CVE-2023-39326 and Go issue https://go.dev/issue/64433.
- cmd/go: go get may unexpectedly fallback to insecure git
Using go get to fetch a module with the ".git" suffix may unexpectedly
fallback to the insecure "git://" protocol if the module is unavailable
via the secure "https://" and "git+ssh://" protocols, even if GOINSECURE
is not set for said module. This only affects users who are not using
the module proxy and are fetching modules directly (i.e. GOPROXY=off).
Thanks to David Leadbeater for reporting this issue.
This is CVE-2023-45285 and Go issue https://go.dev/issue/63845.
- path/filepath: retain trailing \ when cleaning paths like \\?\c:\
Go 1.20.11 and Go 1.21.4 inadvertently changed the definition of the
volume name in Windows paths starting with \\?\, resulting in
filepath.Clean(\\?\c:\) returning \\?\c: rather than \\?\c:\ (among
other effects). The previous behavior has been restored.
This is an update to CVE-2023-45283 and Go issue https://go.dev/issue/64028.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Revert "Revert "update to go1.21.4" due to regressions / breaking changes."
This reverts commit 65de054a1e.
This re-applies commit 8cb2b0efee
----
update to go1.21.4
go1.21.4 (released 2023-11-07) includes security fixes to the path/filepath
package, as well as bug fixes to the linker, the runtime, the compiler, and
the go/types, net/http, and runtime/cgo packages. See the Go 1.21.4 milestone
on our issue tracker for details:
- https://github.com/golang/go/issues?q=milestone%3AGo1.21.4+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.21.3...go1.21.4
from the security mailing:
[security] Go 1.21.4 and Go 1.20.11 are released
Hello gophers,
We have just released Go versions 1.21.4 and 1.20.11, minor point releases.
These minor releases include 2 security fixes following the security policy:
- path/filepath: recognize `\??\` as a Root Local Device path prefix.
On Windows, a path beginning with `\??\` is a Root Local Device path equivalent
to a path beginning with `\\?\`. Paths with a `\??\` prefix may be used to
access arbitrary locations on the system. For example, the path `\??\c:\x`
is equivalent to the more common path c:\x.
The filepath package did not recognize paths with a `\??\` prefix as special.
Clean could convert a rooted path such as `\a\..\??\b` into
the root local device path `\??\b`. It will now convert this
path into `.\??\b`.
`IsAbs` did not report paths beginning with `\??\` as absolute.
It now does so.
VolumeName now reports the `\??\` prefix as a volume name.
`Join(`\`, `??`, `b`)` could convert a seemingly innocent
sequence of path elements into the root local device path
`\??\b`. It will now convert this to `\.\??\b`.
This is CVE-2023-45283 and https://go.dev/issue/63713.
- path/filepath: recognize device names with trailing spaces and superscripts
The `IsLocal` function did not correctly detect reserved names in some cases:
- reserved names followed by spaces, such as "COM1 ".
- "COM" or "LPT" followed by a superscript 1, 2, or 3.
`IsLocal` now correctly reports these names as non-local.
This is CVE-2023-45284 and https://go.dev/issue/63713.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
RLIMIT_NOFILE defaults to an unusable value on EL 7 systems, but more
modern systems have sane defaults. As such, patch the systemd unit only
on EL 7 systems to ensure correct behaviour.
Signed-off-by: Bjorn Neergaard <bjorn.neergaard@docker.com>
Unfortunately, the go1.21.4 security update exposed some regressions / breaking
changes in moby (docker engine) and containerd. These issues are looked into,
but in the meantime we should revert this patch.
This temporarily reintroduces CVE-2023-45284 and CVE-2023-45283.
This reverts commit 8cb2b0efee.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.21.4 (released 2023-11-07) includes security fixes to the path/filepath
package, as well as bug fixes to the linker, the runtime, the compiler, and
the go/types, net/http, and runtime/cgo packages. See the Go 1.21.4 milestone
on our issue tracker for details:
- https://github.com/golang/go/issues?q=milestone%3AGo1.21.4+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.21.3...go1.21.4
from the security mailing:
[security] Go 1.21.4 and Go 1.20.11 are released
Hello gophers,
We have just released Go versions 1.21.4 and 1.20.11, minor point releases.
These minor releases include 2 security fixes following the security policy:
- path/filepath: recognize `\??\` as a Root Local Device path prefix.
On Windows, a path beginning with `\??\` is a Root Local Device path equivalent
to a path beginning with `\\?\`. Paths with a `\??\` prefix may be used to
access arbitrary locations on the system. For example, the path `\??\c:\x`
is equivalent to the more common path c:\x.
The filepath package did not recognize paths with a `\??\` prefix as special.
Clean could convert a rooted path such as `\a\..\??\b` into
the root local device path `\??\b`. It will now convert this
path into `.\??\b`.
`IsAbs` did not report paths beginning with `\??\` as absolute.
It now does so.
VolumeName now reports the `\??\` prefix as a volume name.
`Join(`\`, `??`, `b`)` could convert a seemingly innocent
sequence of path elements into the root local device path
`\??\b`. It will now convert this to `\.\??\b`.
This is CVE-2023-45283 and https://go.dev/issue/63713.
- path/filepath: recognize device names with trailing spaces and superscripts
The `IsLocal` function did not correctly detect reserved names in some cases:
- reserved names followed by spaces, such as "COM1 ".
- "COM" or "LPT" followed by a superscript 1, 2, or 3.
`IsLocal` now correctly reports these names as non-local.
This is CVE-2023-45284 and https://go.dev/issue/63713.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.21.3 (released 2023-10-10) includes a security fix to the net/http package.
See the Go 1.21.3 milestone on our issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.21.3+label%3ACherryPickApproved
full diff: https://github.com/golang/go/compare/go1.21.2...go1.21.3
From the security mailing:
[security] Go 1.21.3 and Go 1.20.10 are released
Hello gophers,
We have just released Go versions 1.21.3 and 1.20.10, minor point releases.
These minor releases include 1 security fixes following the security policy:
- net/http: rapid stream resets can cause excessive work
A malicious HTTP/2 client which rapidly creates requests and
immediately resets them can cause excessive server resource consumption.
While the total number of requests is bounded to the
http2.Server.MaxConcurrentStreams setting, resetting an in-progress
request allows the attacker to create a new request while the existing
one is still executing.
HTTP/2 servers now bound the number of simultaneously executing
handler goroutines to the stream concurrency limit. New requests
arriving when at the limit (which can only happen after the client
has reset an existing, in-flight request) will be queued until a
handler exits. If the request queue grows too large, the server
will terminate the connection.
This issue is also fixed in golang.org/x/net/http2 v0.17.0,
for users manually configuring HTTP/2.
The default stream concurrency limit is 250 streams (requests)
per HTTP/2 connection. This value may be adjusted using the
golang.org/x/net/http2 package; see the Server.MaxConcurrentStreams
setting and the ConfigureServer function.
This is CVE-2023-39325 and Go issue https://go.dev/issue/63417.
This is also tracked by CVE-2023-44487.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The deb pacakges have this dependency as "recommends", but older versions
of yum (RHEL7 / CentOS 7) do not support this. and only support "requires".
This patch uses a similar approach as bb4bd31ab6
did for the CLI, and changes the dependency to be "recommends" where possible,
falling back to "requires" for older rpm versions.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.20.8 (released 2023-09-06) includes two security fixes to the html/template
package, as well as bug fixes to the compiler, the go command, the runtime,
and the crypto/tls, go/types, net/http, and path/filepath packages. See the
Go 1.20.8 milestone on our issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.20.8+label%3ACherryPickApproved
full diff: https://github.com/golang/go/compare/go1.20.7...go1.20.8
From the security mailing:
[security] Go 1.21.1 and Go 1.20.8 are released
Hello gophers,
We have just released Go versions 1.21.1 and 1.20.8, minor point releases.
These minor releases include 4 security fixes following the security policy:
- cmd/go: go.mod toolchain directive allows arbitrary execution
The go.mod toolchain directive, introduced in Go 1.21, could be leveraged to
execute scripts and binaries relative to the root of the module when the "go"
command was executed within the module. This applies to modules downloaded using
the "go" command from the module proxy, as well as modules downloaded directly
using VCS software.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2023-39320 and Go issue https://go.dev/issue/62198.
- html/template: improper handling of HTML-like comments within script contexts
The html/template package did not properly handle HMTL-like "<!--" and "-->"
comment tokens, nor hashbang "#!" comment tokens, in <script> contexts. This may
cause the template parser to improperly interpret the contents of <script>
contexts, causing actions to be improperly escaped. This could be leveraged to
perform an XSS attack.
Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for reporting this
issue.
This is CVE-2023-39318 and Go issue https://go.dev/issue/62196.
- html/template: improper handling of special tags within script contexts
The html/template package did not apply the proper rules for handling occurrences
of "<script", "<!--", and "</script" within JS literals in <script> contexts.
This may cause the template parser to improperly consider script contexts to be
terminated early, causing actions to be improperly escaped. This could be
leveraged to perform an XSS attack.
Thanks to Takeshi Kaneko (GMO Cybersecurity by Ierae, Inc.) for reporting this
issue.
This is CVE-2023-39319 and Go issue https://go.dev/issue/62197.
- crypto/tls: panic when processing post-handshake message on QUIC connections
Processing an incomplete post-handshake message for a QUIC connection caused a panic.
Thanks to Marten Seemann for reporting this issue.
This is CVE-2023-39321 and CVE-2023-39322 and Go issue https://go.dev/issue/62266.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Includes a fix for CVE-2023-29409
go1.20.7 (released 2023-08-01) includes a security fix to the crypto/tls
package, as well as bug fixes to the assembler and the compiler. See the
Go 1.20.7 milestone on our issue tracker for details:
- https://github.com/golang/go/issues?q=milestone%3AGo1.20.7+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.20.6...go1.20.7
From the mailing list announcement:
[security] Go 1.20.7 and Go 1.19.12 are released
Hello gophers,
We have just released Go versions 1.20.7 and 1.19.12, minor point releases.
These minor releases include 1 security fixes following the security policy:
- crypto/tls: restrict RSA keys in certificates to <= 8192 bits
Extremely large RSA keys in certificate chains can cause a client/server
to expend significant CPU time verifying signatures. Limit this by
restricting the size of RSA keys transmitted during handshakes to <=
8192 bits.
Based on a survey of publicly trusted RSA keys, there are currently only
three certificates in circulation with keys larger than this, and all
three appear to be test certificates that are not actively deployed. It
is possible there are larger keys in use in private PKIs, but we target
the web PKI, so causing breakage here in the interests of increasing the
default safety of users of crypto/tls seems reasonable.
Thanks to Mateusz Poliwczak for reporting this issue.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.20.7
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This reverts commit cafc21c4f6.
This also removes the now-obsolete upstart script and updates the
"debhelper compat level" to 12 (which necessitates adding "override_dh_dwz"
-- safe to remove once we can update to debhelper-compat 13+).
(See also https://lists.debian.org/debian-devel-announce/2020/02/msg00000.html)
Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Bjorn Neergaard <bjorn.neergaard@docker.com>
go1.20.6 (released 2023-07-11) includes a security fix to the net/http package,
as well as bug fixes to the compiler, cgo, the cover tool, the go command,
the runtime, and the crypto/ecdsa, go/build, go/printer, net/mail, and text/template
packages. See the Go 1.20.6 milestone on our issue tracker for details.
https://github.com/golang/go/issues?q=milestone%3AGo1.20.6+label%3ACherryPickApproved
Full diff: https://github.com/golang/go/compare/go1.20.5...go1.20.6
These minor releases include 1 security fixes following the security policy:
net/http: insufficient sanitization of Host header
The HTTP/1 client did not fully validate the contents of the Host header.
A maliciously crafted Host header could inject additional headers or entire
requests. The HTTP/1 client now refuses to send requests containing an
invalid Request.Host or Request.URL.Host value.
Thanks to Bartek Nowotarski for reporting this issue.
Includes security fixes for [CVE-2023-29406 ][1] and Go issue https://go.dev/issue/60374
[1]: https://github.com/advisories/GHSA-f8f7-69v5-w4vx
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Use COPY --link for steps that don't depend on the base image
or prior steps, to allow for better sharing of build-cache.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
While we only use the golang binaries from these images (which should be
the same for both), Debian buster reached EOL. Update the Golang image
to the current stable version of Debian (Debian 12 "bookworm")
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.20.5 (released 2023-06-06) includes four security fixes to the cmd/go and
runtime packages, as well as bug fixes to the compiler, the go command, the
runtime, and the crypto/rsa, net, and os packages. See the Go 1.20.5 milestone
on our issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.20.5+label%3ACherryPickApproved
full diff: https://github.com/golang/go/compare/go1.20.4...go1.20.5
These minor releases include 3 security fixes following the security policy:
- cmd/go: cgo code injection
The go command may generate unexpected code at build time when using cgo. This
may result in unexpected behavior when running a go program which uses cgo.
This may occur when running an untrusted module which contains directories with
newline characters in their names. Modules which are retrieved using the go command,
i.e. via "go get", are not affected (modules retrieved using GOPATH-mode, i.e.
GO111MODULE=off, may be affected).
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2023-29402 and Go issue https://go.dev/issue/60167.
- runtime: unexpected behavior of setuid/setgid binaries
The Go runtime didn't act any differently when a binary had the setuid/setgid
bit set. On Unix platforms, if a setuid/setgid binary was executed with standard
I/O file descriptors closed, opening any files could result in unexpected
content being read/written with elevated prilieges. Similarly if a setuid/setgid
program was terminated, either via panic or signal, it could leak the contents
of its registers.
Thanks to Vincent Dehors from Synacktiv for reporting this issue.
This is CVE-2023-29403 and Go issue https://go.dev/issue/60272.
- cmd/go: improper sanitization of LDFLAGS
The go command may execute arbitrary code at build time when using cgo. This may
occur when running "go get" on a malicious module, or when running any other
command which builds untrusted code. This is can by triggered by linker flags,
specified via a "#cgo LDFLAGS" directive.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2023-29404 and CVE-2023-29405 and Go issues https://go.dev/issue/60305 and https://go.dev/issue/60306.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.20.4 (released 2023-05-02) includes three security fixes to the html/template
package, as well as bug fixes to the compiler, the runtime, and the crypto/subtle,
crypto/tls, net/http, and syscall packages. See the Go 1.20.4 milestone on our
issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.20.4+label%3ACherryPickApproved
release notes: https://go.dev/doc/devel/release#go1.20.4
full diff: https://github.com/golang/go/compare/go1.20.3...go1.20.4
from the announcement:
> These minor releases include 3 security fixes following the security policy:
>
> - html/template: improper sanitization of CSS values
>
> Angle brackets (`<>`) were not considered dangerous characters when inserted
> into CSS contexts. Templates containing multiple actions separated by a '/'
> character could result in unexpectedly closing the CSS context and allowing
> for injection of unexpected HMTL, if executed with untrusted input.
>
> Thanks to Juho Nurminen of Mattermost for reporting this issue.
>
> This is CVE-2023-24539 and Go issue https://go.dev/issue/59720.
>
> - html/template: improper handling of JavaScript whitespace
>
> Not all valid JavaScript whitespace characters were considered to be
> whitespace. Templates containing whitespace characters outside of the character
> set "\t\n\f\r\u0020\u2028\u2029" in JavaScript contexts that also contain
> actions may not be properly sanitized during execution.
>
> Thanks to Juho Nurminen of Mattermost for reporting this issue.
>
> This is CVE-2023-24540 and Go issue https://go.dev/issue/59721.
>
> - html/template: improper handling of empty HTML attributes
>
> Templates containing actions in unquoted HTML attributes (e.g. "attr={{.}}")
> executed with empty input could result in output that would have unexpected
> results when parsed due to HTML normalization rules. This may allow injection
> of arbitrary attributes into tags.
>
> Thanks to Juho Nurminen of Mattermost for reporting this issue.
>
> This is CVE-2023-29400 and Go issue https://go.dev/issue/59722.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.20.3 (released 2023-04-04) includes security fixes to the go/parser,
html/template, mime/multipart, net/http, and net/textproto packages, as well
as bug fixes to the compiler, the linker, the runtime, and the time package.
See the Go 1.20.3 milestone on our issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.20.3+label%3ACherryPickApproved
full diff: https://github.com/golang/go/compare/go1.20.2...go1.20.3
Further details from the announcement on the mailing list:
We have just released Go versions 1.20.3 and 1.19.8, minor point releases.
These minor releases include 4 security fixes following the security policy:
- go/parser: infinite loop in parsing
Calling any of the Parse functions on Go source code which contains `//line`
directives with very large line numbers can cause an infinite loop due to
integer overflow.
Thanks to Philippe Antoine (Catena cyber) for reporting this issue.
This is CVE-2023-24537 and Go issue https://go.dev/issue/59180.
- html/template: backticks not treated as string delimiters
Templates did not properly consider backticks (`) as Javascript string
delimiters, and as such did not escape them as expected. Backticks are
used, since ES6, for JS template literals. If a template contained a Go
template action within a Javascript template literal, the contents of the
action could be used to terminate the literal, injecting arbitrary Javascript
code into the Go template.
As ES6 template literals are rather complex, and themselves can do string
interpolation, we've decided to simply disallow Go template actions from being
used inside of them (e.g. "var a = {{.}}"), since there is no obviously safe
way to allow this behavior. This takes the same approach as
github.com/google/safehtml. Template.Parse will now return an Error when it
encounters templates like this, with a currently unexported ErrorCode with a
value of 12. This ErrorCode will be exported in the next major release.
Users who rely on this behavior can re-enable it using the GODEBUG flag
jstmpllitinterp=1, with the caveat that backticks will now be escaped. This
should be used with caution.
Thanks to Sohom Datta, Manipal Institute of Technology, for reporting this issue.
This is CVE-2023-24538 and Go issue https://go.dev/issue/59234.
- net/http, net/textproto: denial of service from excessive memory allocation
HTTP and MIME header parsing could allocate large amounts of memory, even when
parsing small inputs.
Certain unusual patterns of input data could cause the common function used to
parse HTTP and MIME headers to allocate substantially more memory than
required to hold the parsed headers. An attacker can exploit this behavior to
cause an HTTP server to allocate large amounts of memory from a small request,
potentially leading to memory exhaustion and a denial of service.
Header parsing now correctly allocates only the memory required to hold parsed
headers.
Thanks to Jakob Ackermann (@das7pad) for discovering this issue.
This is CVE-2023-24534 and Go issue https://go.dev/issue/58975.
- net/http, net/textproto, mime/multipart: denial of service from excessive resource consumption
Multipart form parsing can consume large amounts of CPU and memory when
processing form inputs containing very large numbers of parts. This stems from
several causes:
mime/multipart.Reader.ReadForm limits the total memory a parsed multipart form
can consume. ReadForm could undercount the amount of memory consumed, leading
it to accept larger inputs than intended. Limiting total memory does not
account for increased pressure on the garbage collector from large numbers of
small allocations in forms with many parts. ReadForm could allocate a large
number of short-lived buffers, further increasing pressure on the garbage
collector. The combination of these factors can permit an attacker to cause an
program that parses multipart forms to consume large amounts of CPU and
memory, potentially resulting in a denial of service. This affects programs
that use mime/multipart.Reader.ReadForm, as well as form parsing in the
net/http package with the Request methods FormFile, FormValue,
ParseMultipartForm, and PostFormValue.
ReadForm now does a better job of estimating the memory consumption of parsed
forms, and performs many fewer short-lived allocations.
In addition, mime/multipart.Reader now imposes the following limits on the
size of parsed forms:
Forms parsed with ReadForm may contain no more than 1000 parts. This limit may
be adjusted with the environment variable GODEBUG=multipartmaxparts=. Form
parts parsed with NextPart and NextRawPart may contain no more than 10,000
header fields. In addition, forms parsed with ReadForm may contain no more
than 10,000 header fields across all parts. This limit may be adjusted with
the environment variable GODEBUG=multipartmaxheaders=.
Thanks to Jakob Ackermann for discovering this issue.
This is CVE-2023-24536 and Go issue https://go.dev/issue/59153.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
docker scan was deprecated in favor of docker scout, so we can stop
building it as part of the 24.0 release.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Includes a security fix for crypto/elliptic (CVE-2023-24532).
> go1.19.7 (released 2023-03-07) includes a security fix to the crypto/elliptic
> package, as well as bug fixes to the linker, the runtime, and the crypto/x509
> and syscall packages. See the Go 1.19.7 milestone on our issue tracker for
> details.
https://go.dev/doc/devel/release#go1.19.minor
From the announcement:
> We have just released Go versions 1.20.2 and 1.19.7, minor point releases.
>
> These minor releases include 1 security fixes following the security policy:
>
> - crypto/elliptic: incorrect P-256 ScalarMult and ScalarBaseMult results
>
> The ScalarMult and ScalarBaseMult methods of the P256 Curve may return an
> incorrect result if called with some specific unreduced scalars (a scalar larger
> than the order of the curve).
>
> This does not impact usages of crypto/ecdsa or crypto/ecdh.
>
> This is CVE-2023-24532 and Go issue https://go.dev/issue/58647.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.19.6 (released 2023-02-14) includes security fixes to the crypto/tls,
mime/multipart, net/http, and path/filepath packages, as well as bug fixes to
the go command, the linker, the runtime, and the crypto/x509, net/http, and
time packages. See the Go 1.19.6 milestone on our issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.19.6+label%3ACherryPickApproved
From the announcement on the security mailing:
We have just released Go versions 1.20.1 and 1.19.6, minor point releases.
These minor releases include 4 security fixes following the security policy:
- path/filepath: path traversal in filepath.Clean on Windows
On Windows, the filepath.Clean function could transform an invalid path such
as a/../c:/b into the valid path c:\b. This transformation of a relative (if
invalid) path into an absolute path could enable a directory traversal attack.
The filepath.Clean function will now transform this path into the relative
(but still invalid) path .\c:\b.
This is CVE-2022-41722 and Go issue https://go.dev/issue/57274.
- net/http, mime/multipart: denial of service from excessive resource
consumption
Multipart form parsing with mime/multipart.Reader.ReadForm can consume largely
unlimited amounts of memory and disk files. This also affects form parsing in
the net/http package with the Request methods FormFile, FormValue,
ParseMultipartForm, and PostFormValue.
ReadForm takes a maxMemory parameter, and is documented as storing "up to
maxMemory bytes +10MB (reserved for non-file parts) in memory". File parts
which cannot be stored in memory are stored on disk in temporary files. The
unconfigurable 10MB reserved for non-file parts is excessively large and can
potentially open a denial of service vector on its own. However, ReadForm did
not properly account for all memory consumed by a parsed form, such as map
ntry overhead, part names, and MIME headers, permitting a maliciously crafted
form to consume well over 10MB. In addition, ReadForm contained no limit on
the number of disk files created, permitting a relatively small request body
to create a large number of disk temporary files.
ReadForm now properly accounts for various forms of memory overhead, and
should now stay within its documented limit of 10MB + maxMemory bytes of
memory consumption. Users should still be aware that this limit is high and
may still be hazardous.
ReadForm now creates at most one on-disk temporary file, combining multiple
form parts into a single temporary file. The mime/multipart.File interface
type's documentation states, "If stored on disk, the File's underlying
concrete type will be an *os.File.". This is no longer the case when a form
contains more than one file part, due to this coalescing of parts into a
single file. The previous behavior of using distinct files for each form part
may be reenabled with the environment variable
GODEBUG=multipartfiles=distinct.
Users should be aware that multipart.ReadForm and the http.Request methods
that call it do not limit the amount of disk consumed by temporary files.
Callers can limit the size of form data with http.MaxBytesReader.
This is CVE-2022-41725 and Go issue https://go.dev/issue/58006.
- crypto/tls: large handshake records may cause panics
Both clients and servers may send large TLS handshake records which cause
servers and clients, respectively, to panic when attempting to construct
responses.
This affects all TLS 1.3 clients, TLS 1.2 clients which explicitly enable
session resumption (by setting Config.ClientSessionCache to a non-nil value),
and TLS 1.3 servers which request client certificates (by setting
Config.ClientAuth
> = RequestClientCert).
This is CVE-2022-41724 and Go issue https://go.dev/issue/58001.
- net/http: avoid quadratic complexity in HPACK decoding
A maliciously crafted HTTP/2 stream could cause excessive CPU consumption
in the HPACK decoder, sufficient to cause a denial of service from a small
number of small requests.
This issue is also fixed in golang.org/x/net/http2 v0.7.0, for users manually
configuring HTTP/2.
This is CVE-2022-41723 and Go issue https://go.dev/issue/57855.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Previous versions of the engine created this directory as a side-effect of the
(legacy) "key.json" file. With the removal of libtrust (and the key.json) file,
that directory is no longer created.
While the precence of this directory is not needed for the daemon to function,
users may expect it to be there, so it there should be no harm in creating it.
For scripting purposes, users are still recommended to check if the directory
exists or to create it (mkdir -p).
This patch adds a .dirs file to create the directory on installation for .deb;
https://www.debian.org/doc/manuals/maint-guide/dother.en.html#dirs
And adds a %dirs directive for .rpm packages:
http://ftp.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html#S3-RPM-INSIDE-DIR-DIRECTIVE
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Starting with 6834304feb,
building the engine no longer requires these headers, as it now uses the
kernel UAPI, which means we no longer need these packages as dependency.
Note that the static builds may still need them for containerd, but
dependencies for static builds are defined in the Dockerfile (containerd
is also in the process of migrating to use the kernel UAPI).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Aligning the plugin's version with the format used for docker-ce and
docker-ce-cli, as updated in 39772a761d
Before this patch:
deb/debbuild/
└── ubuntu-jammy
├── docker-buildx-plugin_0.10.0-1~ubuntu.22.04-jammy_arm64.deb
├── docker-ce-cli_23.0.0~rc.2-1~ubuntu.22.04~jammy_arm64.deb
├── docker-ce-rootless-extras_23.0.0~rc.2-1~ubuntu.22.04~jammy_arm64.deb
├── docker-ce_23.0.0~rc.2-1~ubuntu.22.04~jammy_arm64.deb
└── docker-compose-plugin_2.15.1~ubuntu-jammy_arm64.deb
With this patch:
deb/debbuild/
└── ubuntu-jammy
├── docker-buildx-plugin_0.10.0-1~ubuntu.22.04-jammy_arm64.deb
├── docker-ce-cli_23.0.0~rc.2-1~ubuntu.22.04~jammy_arm64.deb
├── docker-ce-rootless-extras_23.0.0~rc.2-1~ubuntu.22.04~jammy_arm64.deb
├── docker-ce_23.0.0~rc.2-1~ubuntu.22.04~jammy_arm64.deb
└── docker-compose-plugin_2.15.1-1~ubuntu.22.04-jammy_arm64.deb
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Aligning the plugin's version with the format used for docker-ce and
docker-ce-cli, as updated in 39772a761d
Before this patch:
tree deb/debbuild/
deb/debbuild/
└── ubuntu-jammy
├── docker-buildx-plugin_0.10.0~ubuntu-jammy_arm64.deb
├── docker-ce-cli_23.0.0~rc.2-1~ubuntu.22.04~jammy_arm64.deb
├── docker-ce-rootless-extras_23.0.0~rc.2-1~ubuntu.22.04~jammy_arm64.deb
├── docker-ce_23.0.0~rc.2-1~ubuntu.22.04~jammy_arm64.deb
└── docker-compose-plugin_2.15.1~ubuntu-jammy_arm64.deb
With this patch:
deb/debbuild/
└── ubuntu-jammy
├── docker-buildx-plugin_0.10.0-1~ubuntu.22.04-jammy_arm64.deb
├── docker-ce-cli_23.0.0~rc.2-1~ubuntu.22.04~jammy_arm64.deb
├── docker-ce-rootless-extras_23.0.0~rc.2-1~ubuntu.22.04~jammy_arm64.deb
├── docker-ce_23.0.0~rc.2-1~ubuntu.22.04~jammy_arm64.deb
└── docker-compose-plugin_2.15.1~ubuntu-jammy_arm64.deb
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit f8299f2021 introduced the `$pkgRevision`
in the package version, but we now actually had two separate escape hatches
for when we needed to do a packaging-only update; one before the packaging
version, and one after the distro-ID (VERSION_ID). The latter one was confusing,
as it appeared to be part of the distro-version (e.g. `22.04.0`).
This patch removes the additional version, and moves it to the start, and updates
the default to use "1", which aligns with the "_release" used for RPM packages,
and may help with warnings that the package version is not an "upstream" (debian)
version.
Comparing same version old vs new (works because we now use 1 as default):
dpkg --compare-versions "23.0.0~rc.1-1~ubuntu.22.04~jammy" ">>" "23.0.0~rc.1-0~ubuntu.22.04.0~jammy" && echo "OK" || echo "KO"
OK
Comparing newer version (new format) vs older version (old format) is ok:
dpkg --compare-versions "23.0.0~rc.2-1~ubuntu.22.04~jammy" ">>" "23.0.0~rc.1-0~ubuntu.22.04.0~jammy" && echo "OK" || echo "KO"
OK
Comparing same version, but newer $pkgRevision (either new format <-> old-format,
or new-format <-> new-format) is also ok:
dpkg --compare-versions "23.0.0~rc.1-2~ubuntu.22.04~jammy" ">>" "23.0.0~rc.1-1~ubuntu.22.04~jammy" && echo "OK" || echo "KO"
OK
dpkg --compare-versions "23.0.0~rc.1-2~ubuntu.22.04~jammy" ">>" "23.0.0~rc.1-1~ubuntu.22.04.0~jammy" && echo "OK" || echo "KO"
OK
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Starting with Docker 23.0.0, we're moving away from CalVer, instead
using SemVer(ish) versions. This aptch updates some examples used to
match the new format.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
We already had code for this in the RPM packages, but were missing this
in the deb variants. Because of this, pre-release packages used a hyphen
(-) as separator for pre-releases, which get sorted as a "higher" version
than a non-pre-release:
dpkg --compare-versions "0.10.0" ">>" "0.10.0-rc2" && echo "OK" || echo "KO"
KO
With this patch, the packages have a correctly formatted version, using
a tilde (~) as separator for the pre-release suffix:
make DOCKER_CLI_REF=f163d2441e214176db89c63ffc557012113e28d8 DOCKER_ENGINE_REF=9fd3a437a6027637301b0952f7578644d7dff321 VERSION=23.0.0-rc.2 ubuntu-jammy
tree deb/debbuild/
deb/debbuild/
└── ubuntu-jammy
├── docker-buildx-plugin_0.10.0~rc2~ubuntu-jammy_arm64.deb
├── docker-ce-cli_23.0.0~rc.2-0~ubuntu.22.04.0~jammy_arm64.deb
├── docker-ce-rootless-extras_23.0.0~rc.2-0~ubuntu.22.04.0~jammy_arm64.deb
├── docker-ce_23.0.0~rc.2-0~ubuntu.22.04.0~jammy.dsc
├── docker-ce_23.0.0~rc.2-0~ubuntu.22.04.0~jammy.tar.gz
├── docker-ce_23.0.0~rc.2-0~ubuntu.22.04.0~jammy_arm64.buildinfo
├── docker-ce_23.0.0~rc.2-0~ubuntu.22.04.0~jammy_arm64.changes
├── docker-ce_23.0.0~rc.2-0~ubuntu.22.04.0~jammy_arm64.deb
└── docker-compose-plugin_2.15.1~ubuntu-jammy_arm64.deb
Using a tilde makes sure that pre-releases are sorted correctly:
dpkg --compare-versions "0.10.0" ">>" "0.10.0~rc2" && echo "OK" || echo "KO"
OK
The version reported through `docker buildx version` still uses the version
as tagged in the repository (using a hyphen (-));
make IMAGE=ubuntu:jammy verify
+ verify_binaries
...
+ docker buildx version
github.com/docker/buildx v0.10.0-rc2 64e4c19
...
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This verification is still very "bare boned", but makes sure that
the binaries are not completely defunct, and that installation of
the package installs the expected binaries.
make IMAGE=ubuntu:jammy verify
# ...
+ verify_binaries
+ docker --version
Docker version 23.0.0-rc.2, build f163d24
++ uname -m
+ '[' aarch64 = x86_64 ']'
+ docker buildx version
github.com/docker/buildx v0.10.0 8764628
+ docker compose version
Docker Compose version v2.15.1
+ dockerd --version
Docker version 23.0.0-rc.2, build 9fd3a437
+ docker-proxy --version
docker-proxy (commit 9fd3a437) version 23.0.0-rc.2
+ containerd --version
containerd containerd.io 1.6.15 5b842e528e99d4d4c1686467debf2bd4b88ecd86
+ ctr --version
ctr containerd.io 1.6.15
+ containerd-shim --help
Usage of containerd-shim:
-address string
grpc address back to main containerd
-containerd-binary containerd publish
path to containerd binary (used for containerd publish) (default "containerd")
-criu string
path to criu binary
-debug
enable debug output in logs
-namespace string
namespace that owns the shim
-runtime-root string
root directory for the runtime (default "/run/containerd/runc")
-socket string
socket path to serve
-systemd-cgroup
set runtime to use systemd-cgroup
-workdir string
path used to storge large temporary data
+ containerd-shim-runc-v1 -v
containerd-shim-runc-v1:
Version: 1.6.15
Revision: 5b842e528e99d4d4c1686467debf2bd4b88ecd86
Go version: go1.18.9
+ containerd-shim-runc-v2 -v
containerd-shim-runc-v2:
Version: 1.6.15
Revision: 5b842e528e99d4d4c1686467debf2bd4b88ecd86
Go version: go1.18.9
+ runc --version
runc version 1.1.4
commit: v1.1.4-0-g5fd4c4d
spec: 1.0.2-dev
go: go1.18.9
libseccomp: 2.5.3
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
We'll be using VERSION_ID in other places, so adding it in the Dockerfile makes
sure it's always present, without having to depend on /etc/os-release.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Includes security fixes for net/http (CVE-2022-41717, CVE-2022-41720),
and os (CVE-2022-41720).
These minor releases include 2 security fixes following the security policy:
- os, net/http: avoid escapes from os.DirFS and http.Dir on Windows
The os.DirFS function and http.Dir type provide access to a tree of files
rooted at a given directory. These functions permitted access to Windows
device files under that root. For example, os.DirFS("C:/tmp").Open("COM1")
would open the COM1 device.
Both os.DirFS and http.Dir only provide read-only filesystem access.
In addition, on Windows, an os.DirFS for the directory \(the root of the
current drive) can permit a maliciously crafted path to escape from the
drive and access any path on the system.
The behavior of os.DirFS("") has changed. Previously, an empty root was
treated equivalently to "/", so os.DirFS("").Open("tmp") would open the
path "/tmp". This now returns an error.
This is CVE-2022-41720 and Go issue https://go.dev/issue/56694.
- net/http: limit canonical header cache by bytes, not entries
An attacker can cause excessive memory growth in a Go server accepting
HTTP/2 requests.
HTTP/2 server connections contain a cache of HTTP header keys sent by
the client. While the total number of entries in this cache is capped,
an attacker sending very large keys can cause the server to allocate
approximately 64 MiB per open connection.
This issue is also fixed in golang.org/x/net/http2 vX.Y.Z, for users
manually configuring HTTP/2.
Thanks to Josselin Costanzi for reporting this issue.
This is CVE-2022-41717 and Go issue https://go.dev/issue/56350.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.19.4
And the milestone on the issue tracker:
https://github.com/golang/go/issues?q=milestone%3AGo1.19.4+label%3ACherryPickApproved
Full diff: https://github.com/golang/go/compare/go1.19.3...go1.19.4
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
On Windows, syscall.StartProcess and os/exec.Cmd did not properly
check for invalid environment variable values. A malicious
environment variable value could exploit this behavior to set a
value for a different environment variable. For example, the
environment variable string "A=B\x00C=D" set the variables "A=B" and
"C=D".
Thanks to RyotaK (https://twitter.com/ryotkak) for reporting this
issue.
This is CVE-2022-41716 and Go issue https://go.dev/issue/56284.
This Go release also fixes https://github.com/golang/go/issues/56309, a
runtime bug which can cause random memory corruption when a goroutine
exits with runtime.LockOSThread() set. This fix is necessary to unblock
work to replace certain uses of pkg/reexec with unshared OS threads.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
From the mailing list:
We have just released Go versions 1.19.2 and 1.18.7, minor point releases.
These minor releases include 3 security fixes following the security policy:
- archive/tar: unbounded memory consumption when reading headers
Reader.Read did not set a limit on the maximum size of file headers.
A maliciously crafted archive could cause Read to allocate unbounded
amounts of memory, potentially causing resource exhaustion or panics.
Reader.Read now limits the maximum size of header blocks to 1 MiB.
Thanks to Adam Korczynski (ADA Logics) and OSS-Fuzz for reporting this issue.
This is CVE-2022-2879 and Go issue https://go.dev/issue/54853.
- net/http/httputil: ReverseProxy should not forward unparseable query parameters
Requests forwarded by ReverseProxy included the raw query parameters from the
inbound request, including unparseable parameters rejected by net/http. This
could permit query parameter smuggling when a Go proxy forwards a parameter
with an unparseable value.
ReverseProxy will now sanitize the query parameters in the forwarded query
when the outbound request's Form field is set after the ReverseProxy.Director
function returns, indicating that the proxy has parsed the query parameters.
Proxies which do not parse query parameters continue to forward the original
query parameters unchanged.
Thanks to Gal Goldstein (Security Researcher, Oxeye) and
Daniel Abeles (Head of Research, Oxeye) for reporting this issue.
This is CVE-2022-2880 and Go issue https://go.dev/issue/54663.
- regexp/syntax: limit memory used by parsing regexps
The parsed regexp representation is linear in the size of the input,
but in some cases the constant factor can be as high as 40,000,
making relatively small regexps consume much larger amounts of memory.
Each regexp being parsed is now limited to a 256 MB memory footprint.
Regular expressions whose representation would use more space than that
are now rejected. Normal use of regular expressions is unaffected.
Thanks to Adam Korczynski (ADA Logics) and OSS-Fuzz for reporting this issue.
This is CVE-2022-41715 and Go issue https://go.dev/issue/55949.
View the release notes for more information: https://go.dev/doc/devel/release#go1.19.2
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
From the mailing list:
We have just released Go versions 1.19.1 and 1.18.6, minor point releases.
These minor releases include 2 security fixes following the security policy:
- net/http: handle server errors after sending GOAWAY
A closing HTTP/2 server connection could hang forever waiting for a clean
shutdown that was preempted by a subsequent fatal error. This failure mode
could be exploited to cause a denial of service.
Thanks to Bahruz Jabiyev, Tommaso Innocenti, Anthony Gavazzi, Steven Sprecher,
and Kaan Onarlioglu for reporting this.
This is CVE-2022-27664 and Go issue https://go.dev/issue/54658.
- net/url: JoinPath does not strip relative path components in all circumstances
JoinPath and URL.JoinPath would not remove `../` path components appended to a
relative path. For example, `JoinPath("https://go.dev", "../go")` returned the
URL `https://go.dev/../go`, despite the JoinPath documentation stating that
`../` path elements are cleaned from the result.
Thanks to q0jt for reporting this issue.
This is CVE-2022-32190 and Go issue https://go.dev/issue/54385.
Release notes:
go1.18.6 (released 2022-09-06) includes security fixes to the net/http package,
as well as bug fixes to the compiler, the go command, the pprof command, the
runtime, and the crypto/tls, encoding/xml, and net packages. See the Go 1.18.6
milestone on the issue tracker for details;
https://github.com/golang/go/issues?q=milestone%3AGo1.18.6+label%3ACherryPickApproved
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
compose v2.10.1 comes with an updated Makefile, allowing us again
to use the makefile for building as part of the rpm/deb scripts.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Don't use bash to compile buildx, re-format the build script to match
other parts, and enable trimpath.
We could also consider enabling `-s -w` to strip debugging symbols, as
we do for other binaries.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The version output was missing the git-commit, because the deb build
tried to do a ``, but the source files used in the deb builds don't
include the git repository.
Before this:
+ docker buildx version
github.com/docker/buildx v0.9.1
With this patch
+ docker buildx version
github.com/docker/buildx v0.9.1 ed00243
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The Makefile did not set a `%{_buildx_gitcommit}` variable, causing the version
output to show as:
docker buildx version
github.com/docker/buildx v0.9.1 %{_buildx_gitcommit}
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Use the default proxy, to assist with LTS distros that use old git versions
but fallback on any error (instead of only on 404 and 410).
From the Go documentation; https://go.dev/ref/mod#goproxy-protocol
> List elements may be separated by commas (,) or pipes (|), which determine error
> fallback behavior. When a URL is followed by a comma, the go command falls back
> to later sources only after a 404 (Not Found) or 410 (Gone) response. When a URL
> is followed by a pipe, the go command falls back to later sources after any error,
> including non-HTTP errors such as timeouts. This error handling behavior lets a
> proxy act as a gatekeeper for unknown modules. For example, a proxy could respond
> with error 403 (Forbidden) for modules not on an approved list (see Private proxy
> serving private modules).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The build.Makefile was removed from the compose repository, so copying
the code to build the plugin here.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
On pre-releases of Fedora, the image may still have `rawhide` as distro-version,
which causes the verify script to fail (as download.docker.com does not have a
"rawhide" channel)
This patch forces the verify script to use the DIST_VERSION as specified in the
Dockerfile.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This was added as part of 6dfaf9cc43, which came
from our internal repositories, but the original commits from there didn't have
context why an upgrade was performed.
In general, it's best practice to not perform a (dist-)upgrade inside the image,
and just depend on the image maintainers to have the image being up-to-date, so
removing this step.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Update Go runtime to 1.18.5 to address CVE-2022-32189.
Full diff: https://github.com/golang/go/compare/go1.18.4...go1.18.5
--------------------------------------------------------
From the security announcement:
https://groups.google.com/g/golang-announce/c/YqYYG87xB10
We have just released Go versions 1.18.5 and 1.17.13, minor point
releases.
These minor releases include 1 security fixes following the security
policy:
encoding/gob & math/big: decoding big.Float and big.Rat can panic
Decoding big.Float and big.Rat types can panic if the encoded message is
too short.
This is CVE-2022-32189 and Go issue https://go.dev/issue/53871.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.18.5
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 28a3c26090 removed the Dockerfile
and removed it from the Jenkinsfile, but forgot to remove it from the
Makefile's default list.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.18.4 (released 2022-07-12) includes security fixes to the compress/gzip,
encoding/gob, encoding/xml, go/parser, io/fs, net/http, and path/filepath
packages, as well as bug fixes to the compiler, the go command, the linker,
the runtime, and the runtime/metrics package. See the Go 1.18.4 milestone on the
issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.18.4+label%3ACherryPickApproved
This update addresses:
CVE-2022-1705, CVE-2022-1962, CVE-2022-28131, CVE-2022-30630, CVE-2022-30631,
CVE-2022-30632, CVE-2022-30633, CVE-2022-30635, and CVE-2022-32148.
Full diff: https://github.com/golang/go/compare/go1.18.3...go1.18.4
From the security announcement;
https://groups.google.com/g/golang-announce/c/nqrv9fbR0zE
We have just released Go versions 1.18.4 and 1.17.12, minor point releases. These
minor releases include 9 security fixes following the security policy:
- net/http: improper sanitization of Transfer-Encoding header
The HTTP/1 client accepted some invalid Transfer-Encoding headers as indicating
a "chunked" encoding. This could potentially allow for request smuggling, but
only if combined with an intermediate server that also improperly failed to
reject the header as invalid.
This is CVE-2022-1705 and https://go.dev/issue/53188.
- When `httputil.ReverseProxy.ServeHTTP` was called with a `Request.Header` map
containing a nil value for the X-Forwarded-For header, ReverseProxy would set
the client IP as the value of the X-Forwarded-For header, contrary to its
documentation. In the more usual case where a Director function set the
X-Forwarded-For header value to nil, ReverseProxy would leave the header
unmodified as expected.
This is https://go.dev/issue/53423 and CVE-2022-32148.
Thanks to Christian Mehlmauer for reporting this issue.
- compress/gzip: stack exhaustion in Reader.Read
Calling Reader.Read on an archive containing a large number of concatenated
0-length compressed files can cause a panic due to stack exhaustion.
This is CVE-2022-30631 and Go issue https://go.dev/issue/53168.
- encoding/xml: stack exhaustion in Unmarshal
Calling Unmarshal on a XML document into a Go struct which has a nested field
that uses the any field tag can cause a panic due to stack exhaustion.
This is CVE-2022-30633 and Go issue https://go.dev/issue/53611.
- encoding/xml: stack exhaustion in Decoder.Skip
Calling Decoder.Skip when parsing a deeply nested XML document can cause a
panic due to stack exhaustion. The Go Security team discovered this issue, and
it was independently reported by Juho Nurminen of Mattermost.
This is CVE-2022-28131 and Go issue https://go.dev/issue/53614.
- 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 CVE-2022-30635 and Go issue https://go.dev/issue/53615.
- path/filepath: stack exhaustion in Glob
Calling Glob on a path which contains a large number of path separators can
cause a panic due to stack exhaustion.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2022-30632 and Go issue https://go.dev/issue/53416.
- io/fs: stack exhaustion in Glob
Calling Glob on a path which contains a large number of path separators can
cause a panic due to stack exhaustion.
This is CVE-2022-30630 and Go issue https://go.dev/issue/53415.
- go/parser: stack exhaustion in all Parse* functions
Calling any of the Parse functions on Go source code which contains deeply
nested types or declarations can cause a panic due to stack exhaustion.
Thanks to Juho Nurminen of Mattermost for reporting this issue.
This is CVE-2022-1962 and Go issue https://go.dev/issue/53616.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.18.3 (released 2022-06-01) includes security fixes to the crypto/rand,
crypto/tls, os/exec, and path/filepath packages, as well as bug fixes to the
compiler, and the crypto/tls and text/template/parse packages. See the Go
1.18.3 milestone on our issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.18.3+label%3ACherryPickApproved
Hello gophers,
We have just released Go versions 1.18.3 and 1.17.11, minor point releases.
These minor releases include 4 security fixes following the security policy:
- crypto/rand: rand.Read hangs with extremely large buffers
On Windows, rand.Read will hang indefinitely if passed a buffer larger than
1 << 32 - 1 bytes.
Thanks to Davis Goodin and Quim Muntal, working at Microsoft on the Go toolset,
for reporting this issue.
This is [CVE-2022-30634][CVE-2022-30634] and Go issue https://go.dev/issue/52561.
- crypto/tls: session tickets lack random ticket_age_add
Session tickets generated by crypto/tls did not contain a randomly generated
ticket_age_add. This allows an attacker that can observe TLS handshakes to
correlate successive connections by comparing ticket ages during session
resumption.
Thanks to GitHub user nervuri for reporting this.
This is [CVE-2022-30629][CVE-2022-30629] and Go issue https://go.dev/issue/52814.
- `os/exec`: empty `Cmd.Path` can result in running unintended binary on Windows
If, on Windows, `Cmd.Run`, `cmd.Start`, `cmd.Output`, or `cmd.CombinedOutput`
are executed when Cmd.Path is unset and, in the working directory, there are
binaries named either "..com" or "..exe", they will be executed.
Thanks to Chris Darroch, brian m. carlson, and Mikhail Shcherbakov for reporting
this.
This is [CVE-2022-30580][CVE-2022-30580] and Go issue https://go.dev/issue/52574.
- `path/filepath`: Clean(`.\c:`) returns `c:` on Windows
On Windows, the `filepath.Clean` function could convert an invalid path to a
valid, absolute path. For example, Clean(`.\c:`) returned `c:`.
Thanks to Unrud for reporting this issue.
This is [CVE-2022-29804][CVE-2022-29804] and Go issue https://go.dev/issue/52476.
[CVE-2022-30634]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30634
[CVE-2022-30629]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30629
[CVE-2022-30580]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30580
[CVE-2022-29804]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29804
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The existing version format for our packages use `distro-codename` in the version.
Unfortunately, `codename` cannot be used to compare versions, which means that
when a user upgrades their distro to a new version, the package won't be updated
until a new release happens.
This patch changes the format of the version to include `VERSION_ID`, which is
numeric, and can be used in version comparison.
While we're making changes, this also adds an extra `pkgRevision` number in the
version, which can allow us to do a new build/release of a package in between
upstream releases. This version is not yet configurable (which can be changed
in future).
Resulting packages are now formatted as;
- name of the package (e.g., "docker-ce")
- version (e.g., "22.10.6~beta.0")
- "-0" (mostly "best practice", and allows updating for specific situations)
- distro (e.g., "ubuntu")
- VERSION_ID (e.g. "22.04" or "11") this must be "sortable" to make sure that
packages are upgraded when upgrading to a newer distro version ("codename"
cannot be used for this, as they're not sorted)
- pkgRevision (usually "0", see above)
- SUITE ("codename"), e.g. "jammy" or "bullseye". This is mostly for convenience,
because some places refer to distro versions by codename, others by version.
we prefix the codename with a tilde (~), which effectively excludes it from
version comparison.
Note that while the `${EPOCH}${EPOCH_SEP}` is part of the version, it is not
included in the package's *filename*.
Examples:
docker-ce_22.10.6~beta.0-0~debian.11.0~bullseye_amd64.deb
docker-ce_22.10.6~beta.0-0~ubuntu.22.04.0~jammy_amd64.deb
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The script had special handling for pre-releases, because at some point we
used `-tp` ("technical preview") as suffix for pre-releases instead of the
standard `-alpha`, `-beta`, `-rc`.
The problem arised because of that, was that comparing versions wouldn't work,
as these suffixes are compared in _alphabetical_ order (which meant that `tp`
would come "after" `beta` and `rc`). To work around this, some custom code
was added to insert a numeric version _before_ the `tp`, `beta`, and `rc`.
We no longer plan to use `-tp` for pre-releases, and instead to just use the
common `alpha[.number]`, `beta[.number]`, `rc[.number]` suffixes.
This patch removes the custom handling for pre-releases, to simplify the version
that's generated.
Before:
./rpm/gen-rpm-ver . 22.06.0-beta.0
22.06.0 1.0.beta.0 3091da7 22.06.0-beta.0
./deb/gen-deb-ver . 22.06.0-beta.0
22.06.0~1.0.beta.0 22.06.0-beta.0
After:
./rpm/gen-rpm-ver . 22.06.0-beta.0
22.06.0~beta.0 1 0b5a1ae 22.06.0-beta.0
./deb/gen-deb-ver . 22.06.0-beta.0
22.06.0~beta.0 22.06.0-beta.0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This unifies the logic/code for generating pseudo-versions for
nightly builds;
- Generate pseudo-version if the source repository has uncommitted changes
- Fix code to work on macOS
- Strip "v" prefix if the passed VERSION has one
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The script assumed that pre-release suffixes used the format `-tp<number>`,
`-beta<number>` or `-rc<number>`, however, it's more common (and standard
practice in SemVer) to delimit the `alpha/beta/rc` with a `.`, which allows
SemVer comparing to first sort by pre-release version (`alpha`, `beta`, `rc`),
then by the numeric suffix.
Altogether, we should consider removing this code; using `tp` as a pre-release
*before* `alpha` / `beta` is non-standard (pre-releases are named `alpha`, `beta`,
`rc`, so that they can be sorted alphabetically. Using `tp` violates that assumption,
and adds the complexity of having to add a numeric prefix to make it sort again.
Also see https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly
Before:
./rpm/gen-rpm-ver . 22.06.0-beta0
22.06.0 1.0.beta0 6e7db7f 22.06.0-beta0
./rpm/gen-rpm-ver . 22.06.0-beta.0
22.06.0.beta.0 3 6e7db7f 22.06.0-beta.0
./deb/gen-deb-ver . 22.06.0-beta0
22.06.0~1.0.beta0 22.06.0-beta0
./deb/gen-deb-ver . 22.06.0-beta.0
22.06.0~beta.0~3 22.06.0-beta.0
After:
./rpm/gen-rpm-ver . 22.06.0-beta0
22.06.0 1.0.beta0 3091da7 22.06.0-beta0
./rpm/gen-rpm-ver . 22.06.0-beta.0
22.06.0 1.0.beta.0 3091da7 22.06.0-beta.0
./deb/gen-deb-ver . 22.06.0-beta0
22.06.0~1.0.beta0 22.06.0-beta0
./deb/gen-deb-ver . 22.06.0-beta.0
22.06.0~1.0.beta.0 22.06.0-beta.0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This reverts commit f9ac2f67a2.
as it unfortunately won't work with ubuntu 18.04, which doesn't
have debhelper-compat 12 (11 is the default, but that version
is discouraged).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This verify step is primarily intended to verify that dependencies
are defined correctly, and available on the given distro.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This integrates the verify scripts from our internal release-packaging
repository (ce-nightly branch), from commit a712afb008b56c7572e87b2bca81f1c50022ad2b
a712afb008
Strategy taken:
# install filter-repo (https://github.com/newren/git-filter-repo/blob/main/INSTALL.md)
brew install git-filter-repo
cd ~/projects
# create a temporary clone of docker
git clone https://github.com/docker/release-packaging.git release_packaging_verify
cd release_packaging_verify
git checkout ce-nightly
# remove all code, except for verify and install-containerd-helpers
git filter-repo --path verify --path install-containerd-helpers --force
# go to the target github.com/docker/docker-ce-packaging repository
cd ~/projects/docker-ce-packaging
# create a branch to work with
git checkout -b integrate_verify
# add the temporary repository as an upstream and make sure it's up-to-date
git remote add release_packaging_verify ~/projects/release_packaging_verify
git fetch release_packaging_verify
# merge the upstream code
git merge --allow-unrelated-histories --signoff -S release_packaging_verify/ce-nightly
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Use the same options for creating the symlinks as for the deb packages, and
add the `-n` and `-f` options;
-n, --no-dereference treat LINK_NAME as a normal file if
it is a symbolic link to a directory
-f, --force remove existing destination files
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This is for the upcoming 22 release, which will ship when we have
containerd.io 1.6 packages, so (as we did with previous releases),
set the minimum version to the current version.
Similar to 3f2b79d15d
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This also removes the now-obsolete upstart script and updates the "debhelper compat level" to 12 (which necessitates adding "override_dh_dwz" -- safe to remove once we can update to debhelper-compat 13+).
(See also https://lists.debian.org/debian-devel-announce/2020/02/msg00000.html)
Signed-off-by: Tianon Gravi <admwiggin@gmail.com>
The Dockerfile for 20.10 and earlier used RUNC_COMMIT, later versions
use RUNC_VERSION. We can remove RUNC_COMMIT going forward.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `apparmor` and `selinux` buildtags have been deprecated in runc, and are now
always enabled.
`seccomp` is enabled by default, but can be disabled by explicitly setting an
empty `BUILDTAGS` when building [1] however the Moby script used to build the
static `runc` binary already takes care of that [2]
[1]: 89c108b1be
[2]: 888c618c15/hack/dockerfile/install/runc.installer (L15)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The https://honnef.co/go/tools domain looks to be offline, causing projects that
do not use vendoring to fail:
go: downloading google.golang.org/protobuf v1.27.1
go: downloading github.com/matttproud/golang_protobuf_extensions v1.0.2-0.20181231171920-c182affec369
go: google.golang.org/grpc@v1.44.0 requires
google.golang.org/genproto@v0.0.0-20200526211855-cb27e3aa2013 requires
honnef.co/go/tools@v0.0.0-20190523083050-ea95bdfd59fc: unrecognized import path "honnef.co/go/tools": reading https://honnef.co/go/tools?go-get=1: 502 Bad Gateway
make: *** [Makefile:71: manpages] Error 1
For now, let's use the GOPROXY (we should look at making this a build-arg probably)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
macOS uses the BSD flavor of `date`, which does not support the `--date` option
to set a custom time. Previously, we were using an alpine container to provide a
GNU flavor of date, which was a bit of a hack.
This patch rewrites the script to work on macOS directly, without the need of
a container:
./static/gen-static-ver . v1.2.3-dev
0.0.0-20220404154104-b815498
docker run --rm -v $(pwd):/src -w /src golang bash -c './static/gen-static-ver . v1.2.3-dev'
0.0.0-20220404154104-b815498
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This adds a "weak" dependency on the docker-compose-plugin, per the
recommendations in https://debian-handbook.info/browse/stable/sect.package-meta-information.html#id-1.8.6.7.10.10
The "recommends" dependency will be installed by default, but does allow users to opt-out
using `--no-install-recommends` to perform a lightweight installation for setups that only
need basic functionality of docker;
> (...) the “recommended” dependencies, the most important, considerably improve
> the functionality offered by the package but are not indispensable to its operation.
> (...) You should always install the “recommended” packages, unless you know exactly
> why you do not need them. This is now also the default for APT unless configured
> otherwise.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This fixes a problem when installing the packages from local files instead of
from the package repository. The current packages had a strong dependency set
in both directions (`docker-ce-cli` requires `docker-scan-plugin`, and vice-
versa). This caused a circular dependency, which could not be resolved when
trying to install the packages offline (from downloaded rpm files);
yum install ./docker-scan-plugin-0.17.0-3.fc35.x86_64.rpm
Last metadata expiration check: 1:09:40 ago on Tue Mar 8 08:30:47 2022.
Error:
Problem: conflicting requests
- nothing provides docker-ce-cli needed by docker-scan-plugin-0.17.0-3.fc35.x86_64
(try to add '--skip-broken' to skip uninstallable packages)
yum install ./docker-ce-cli-20.10.13-3.fc35.x86_64.rpm
Last metadata expiration check: 1:10:23 ago on Tue Mar 8 08:30:47 2022.
Error:
Problem: conflicting requests
- nothing provides docker-scan-plugin(x86-64) needed by docker-ce-cli-1:20.10.13-3.fc35.x86_64
(try to add '--skip-broken' to skip uninstallable packages)
This patch
- changes the `docker-scan-plugin` to `Enhances
- changes the `docker-ce-cli` package to mark the scan plugin as `Recommends`,
with the exception of CentOS/RHEL 7, which do not yet support weak dependencies.
For those, we continue to use `Requires`.
The `Recommends` dependency should be installed by default, but users can opt-out
by passing `--setopt=install_weak_deps=False` to `dnf`.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This removes the "require" docker-ce-cli, so that the package can be installed
stand-alone (withouth the docker cli itself installed).
Unlike "deb" packages, rpm package do not have "soft" requirement ("enhances",
"recommends"), so having a "requires" makes the docker-cli a hard requirement.
While in most situations, the plugin would be installed together with the docker
cli, the plugin _is_ able to run standalone:
/usr/libexec/docker/cli-plugins/docker-compose up
[+] Running 2/2
⠿ Network test_default Created 4.3s
⠿ Container test_web_1 Started 2.1s
Attaching to web_1
web_1 | 10-listen-on-ipv6-by-default.sh: Getting the checksum of /etc/nginx/conf.d/default.conf
web_1 | 10-listen-on-ipv6-by-default.sh: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
web_1 | /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
web_1 | /docker-entrypoint.sh: Configuration complete; ready for start up
This removes the "Requires" annotation from the package, to simplify the dependency
graph, and to allow installing the package separately (which could be for testing
purposes, or for a minimal install).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Fixes an error reported by rpmlint:
docker-ce.x86_64: E: description-line-too-long they can run anywhere, from your laptop to the largest cloud compute instance and
docker-ce-cli.x86_64: E: description-line-too-long they can run anywhere, from your laptop to the largest cloud compute instance and
Your description lines must not exceed 80 characters. If a line is exceeding
this number, cut it to fit in two lines.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
CentOS 7 comes with a very old (1.8) version of git, which is not compatible
with go modules. We previously applied this fix to individual build scripts
for rootless-extras and the scan-cli-plugin, but now that other bits are
failing as well, lets move this to the Dockerfile for this distro, so that
for other distros we can use "direct" and fetch from GitHub.
Without this, the build of docker/cli (master branch) failed with:
+ ./scripts/vendor init
+ go mod edit -modfile=vendor.mod -require=github.com/cpuguy83/go-md2man/v2@v2.0.1
+ cp man/tools.go .
+ ./scripts/vendor update
+ go mod tidy -modfile=vendor.mod
go: github.com/theupdateframework/notary@v0.7.1-0.20210315103452-bf96a202a09a requires
github.com/docker/go@v1.5.1-1.0.20160303222718-d30aec9fd63c: invalid pseudo-version: git fetch --unshallow -f origin in /go/pkg/mod/cache/vcs/48fbd2dfabec81f4c93170677bfc89087d4bec07a2d08f6ca5ce3d17962677ee: exit status 128:
fatal: git fetch-pack: expected shallow list
make: *** [manpages] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.aKncVr (%build)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Includes security fixes for crypto/elliptic (CVE-2022-23806), math/big (CVE-2022-23772),
and cmd/go (CVE-2022-23773).
go1.16.14 (released 2022-02-10) includes security fixes to the crypto/elliptic,
math/big packages and to the go command, as well as bug fixes to the compiler,
linker, runtime, the go command, and the debug/macho, debug/pe, net/http/httptest,
and testing packages. See the Go 1.16.14 milestone on our issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.16.14+label%3ACherryPickApproved
full diff: https://github.com/golang/go/compare/go1.16.13...go1.16.14
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `image` field in the Jenkinsfile is not really used in this repository
(other than to name the stage), but in our internal pipeline, the equivalent
is used for some validation steps (to be upstreamed to this repository).
Let's update the Jenkinsfile to match our internal one, and to make sure
we don't forget updating it when we upstream some of those validation steps.
Relates to 49ff911349
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This was a bit of an oversight in 49ff9113494665d7aff0496a6aacf54a96bc344a;
when checking if the `$SUITE` variable was used elsewhere, I searched for
`$SUITE`, and not for `${SUITE}`. While it looks like the variable is not
used for any of the rpm-related build-scripts, it _is_ used in deb-related
scripts.
Let's change it back to the previous value; just in case it will be used
somewhere and causing side-effects.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
CentOS 8 reached EOL on December 31, 2021 (https://www.centos.org/centos-linux-eol/)
Repositories have moved to vault.centos.org, causing builds to fail;
Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist
Update the Dockerfile to use quay.io/centos/centos:stream8
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This brings the Jenkinsfile slightly closer to the one in our internal
build pipeline (still some things to sort out).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This allows easier building without having to specify if an "rpm" or "deb"
needs to be built.
Before this patch:
make -C rpm centos-8
make -C deb ubuntu-focal
With this patch applied:
make centos-8
make ubuntu-focal
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Ubuntu 21.10 switched the default compression for .deb packages to use zstd.
While this change may bring some performance improvement, it is non-standard,
and not all deb-related tooling currently support zstd compression. One of those
tools, dpkg-sig, has not (yet) been modified to support zstd compression; we use
this tool to sign our packages (and verify that packages are signed), which
currently fails if packages use zstd compression;
dpkg-sig --verify ./containerd.io_1.4.11-1_amd64.deb
Processing ./containerd.io_1.4.11-1_amd64.deb...
BADSIG _gpgbuilder
It should be noted that signing individual packages is *optional* [1], and that
dpkg-sig has not received updates since 2006 [2] (possibly better replaced with
debsigs / debsig-verify), but changing would be a potential breaking change, as
these tools are not interchangeable [3]
[1]: https://www.debian.org/doc/manuals/securing-debian-manual/deb-pack-sign.en.html
[2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995113
[3]: https://raphaelhertzog.com/2010/09/17/how-to-create-debian-packages-with-alternative-compression-methods/
This patch hard-codes the compression to use in the debian rules, instead of using
the default that's used by the distro.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.16.9 (released 2021-10-07) includes a security fix to the linker and misc/wasm
directory, as well as bug fixes to the runtime and to the text/template package.
See the Go 1.16.9 milestone on our issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.16.9+label%3ACherryPickApproved
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This allows passing `CONTAINERD_VERSION` and `RUNC_VERSION` make vars
to override the default version in the upstream repository's Dockerfile.
With this, it's easier to make the static packages match the latest
released `containerd.io` deb/rpm (which are used by the .deb and .rpm
docker-ce packages), without having to modify the upstream moby repository.
Currently, this uses the DOCKER_BUILD_OPTS make variable, which is available
in the moby Makefile, but work is in progress to add `CONTAINERD_VERSION`
and `RUNC_VERSION` make variables in the upstream repository. Once those
changes are merged, we can update the makefile in this repository accordingly.
With this patch:
If `RUNC_VERSION` and `CONTAINERD_VERSION` are not passed, the defaults are used:
$ make \
DOCKER_BUILD_PKGS=static-linux \
REF=v20.10.8 \
VERSION=v20.10.8 \
static
$ docker run --rm -v $(pwd)/static/build/linux/docker/:/docker alpine sh -c '/docker/containerd --version && /docker/runc --version'
containerd github.com/containerd/containerd v1.4.9 e25210fe30a0a703442421b0f60afac609f950a3
runc version 1.0.1
commit: v1.0.1-0-g4144b638
spec: 1.0.2-dev
go: go1.16.8
libseccomp: 2.4.4
Passing the `RUNC_VERSION` and `CONTAINERD_VERSION` vars overrides the version
of containerd and runc:
$ make \
DOCKER_BUILD_PKGS=static-linux \
REF=v20.10.8 \
VERSION=v20.10.8 \
RUNC_VERSION=v1.0.2 \
CONTAINERD_VERSION=v1.4.10 \
static
$ docker run --rm -v $(pwd)/static/build/linux/docker/:/docker alpine sh -c '/docker/containerd --version && /docker/runc --version'
containerd github.com/containerd/containerd v1.4.10 8848fdb7c4ae3815afcc990a8a99d663dda1b590
runc version 1.0.2
commit: v1.0.2-0-g52b36a2d
spec: 1.0.2-dev
go: go1.16.8
libseccomp: 2.4.4
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This includes additional fixes for CVE-2021-39293.
go1.16.8 (released 2021-09-09) includes a security fix to the archive/zip package,
as well as bug fixes to the archive/zip, go/internal/gccgoimporter, html/template,
net/http, and runtime/pprof packages. See the Go 1.16.8 milestone on the issue
tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.16.8+label%3ACherryPickApproved
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This was introduced in 09541b553c, which fixed the
source-location of the docker-proxy binary, but accidentally used "dockerd.exe"
as target.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This fix was previously included in the rootlesskit install script
in moby, but should've been addressed by Go 1.14 and up. Unfortunately,
this does not appear the case, and go modules without proxy is still
broken on older versions of git, such as the version of git used by
CentOS 7.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
On Debian, `dbus-user-session` is not installed by default.
The lack of `dbus-user-session` results in a cryptic error on rootless+cgroup2+systemd:
`read unix @->/run/systemd/private: read: connection reset by peer: unknown.`
ref: moby/moby issue 42793
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
go1.16.7 (released 2021-08-05) includes a security fix to the net/http/httputil
package, as well as bug fixes to the compiler, the linker, the runtime, the go
command, and the net/http package. See the Go 1.16.7 milestone on the issue
tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.16.7+label%3ACherryPickApproved
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The buildkit vendor in buildx contains an incorrect `//import` comment, which
causes compile to fail if go modules are disabled.
Without `GO111MODULE` set (but with `-mod=vendor`:
echo $GO111MODULE
export PKG=github.com/docker/buildx
export LDFLAGS="-X ${PKG}/version.Version=$(git describe --match 'v[0-9]*' --always --tags) -X ${PKG}/version.Revision=$(git rev-parse HEAD) -X ${PKG}/version.Package=${PKG}"
GOFLAGS=-mod=vendor go build -o bin/docker-buildx -ldflags "${LDFLAGS}" ./cmd/buildx
bin/docker-buildx version
github.com/docker/buildx v0.6.0 d9ee3b134cbc2d09513fa7fee4176a3919e05887
When setting `GO111MODULE=off`, it fails on the incorrect import path in the
vendored file (looks like GO111MODULE=on ignores import-path comments?):
export GO111MODULE=off
root@5a55ec1c1eed:/go/src/github.com/docker/buildx# GOFLAGS=-mod=vendor go build -o bin/docker-buildx -ldflags "${LDFLAGS}" ./cmd/buildx
vendor/github.com/moby/buildkit/client/client.go:20:2: code in directory /go/src/github.com/docker/buildx/vendor/github.com/moby/buildkit/util/tracing/otlptracegrpc expects import "go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc"
vendor/go.opentelemetry.io/otel/exporters/otlp/otlptrace/internal/connection/connection.go:33:2: found import comments "go.opentelemetry.io/otel/exporters/otlp/internal/otlpconfig" (options.go) and "go.opentelemetry.io/otel/exporters/otlp/otlptrace/internal/otlpconfig" (optiontypes.go) in /go/src/github.com/docker/buildx/vendor/go.opentelemetry.io/otel/exporters/otlp/otlptrace/internal/otlpconfig
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 928a8f2b57 added a check for binary
version set through build-time variables, but I messed up, and forgot to
add a non-zero exit code. As a result the exit code was the exit code of
the "echo", which would always be successful.
This also revealed a missing check for "target architecture": the scan
cli plugin is only built on x86, so the version check should not be
performed on other architectures.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Not sure why, but looks like the path used `<arch>-daemon` (instead of just `<arch>`).
However, it's not consistent either, because `containerutility.exe` is in `<arch>`?
When running:
make REF=master checkout
make REF=master DOCKER_BUILD_PKGS=cross-win static
The build failed:
mkdir -p build/win/amd64/docker
cp /Users/sebastiaan/go/src/github.com/docker/docker-ce-packaging/src/github.com/docker/cli/build/docker-windows-amd64.exe build/win/amd64/docker/docker.exe
cp /Users/sebastiaan/go/src/github.com/docker/docker-ce-packaging/src/github.com/docker/docker/bundles/cross/windows/amd64/dockerd-0.0.0-20210629140245-4a6fe51.exe build/win/amd64/docker/dockerd.exe
cp: /Users/sebastiaan/go/src/github.com/docker/docker-ce-packaging/src/github.com/docker/docker/bundles/cross/windows/amd64/dockerd-0.0.0-20210629140245-4a6fe51.exe: No such file or directory
make[1]: *** [cross-win] Error 1
make: *** [static] Error 2
This is what's in bundles:
tree /Users/sebastiaan/go/src/github.com/docker/docker-ce-packaging/src/github.com/docker/docker/bundles/
/Users/sebastiaan/go/src/github.com/docker/docker-ce-packaging/src/github.com/docker/docker/bundles/
└── cross
└── windows
├── amd64
│ └── containerutility.exe
└── amd64-daemon
├── docker-proxy-0.0.0-20210629140245-4a6fe51.exe
├── docker-proxy-0.0.0-20210629140245-4a6fe51.exe.md5
├── docker-proxy-0.0.0-20210629140245-4a6fe51.exe.sha256
├── docker-proxy.exe -> docker-proxy-0.0.0-20210629140245-4a6fe51.exe
├── dockerd-0.0.0-20210629140245-4a6fe51.exe
├── dockerd-0.0.0-20210629140245-4a6fe51.exe.md5
├── dockerd-0.0.0-20210629140245-4a6fe51.exe.sha256
└── dockerd.exe -> dockerd-0.0.0-20210629140245-4a6fe51.exe
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Trying to fix
+ echo 'Install tini version de40ad007797e0dcd8b7126f27bb87401d224240'
+ git clone https://github.com/krallin/tini.git /go/tini
Install tini version de40ad007797e0dcd8b7126f27bb87401d224240
Cloning into '/go/tini'...
+ cd /go/tini
+ git checkout -q de40ad007797e0dcd8b7126f27bb87401d224240
+ cmake .
cmake: symbol lookup error: cmake: undefined symbol: archive_write_add_filter_zstd
error: Bad exit status from /var/tmp/rpm-tmp.Dl5CDf (%build)
According to https://bugs.centos.org/view.php?id=18212, upgrading to libarchive-3.3.3-1.el8.x86_64
should resolve the problem.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
libnetwork has been integrated in the docker/docker (moby) repository,
and now is compiled as part of hack/make.sh dynbinary.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Make sure that these versions are set, and match the expected versions
DEB:
debian/rules override_dh_auto_test
make[1]: Entering directory '/root/build-deb'
ver="$(engine/bundles/dynbinary-daemon/dockerd --version)"; \
test "$ver" = "Docker version 0.0.0-20210531142756-1c174ced, build 7c6a9484" && echo "PASS: daemon version OK" || echo "FAIL: daemon version ($ver) did not match"
PASS: daemon version OK
ver="$(cli/build/docker --version)"; \
test "$ver" = "Docker version 0.0.0-20210531142756-1c174ced, build 1c174ced" && echo "PASS: cli version OK" || echo "FAIL: cli version ($ver) did not match"
PASS: cli version OK
# FIXME: --version currently doesn't work as it makes a connection to the daemon, so using the plugin metadata instead
ver="$(/usr/libexec/docker/cli-plugins/docker-scan docker-cli-plugin-metadata | awk '{ gsub(/[",:]/,"")}; $1 == "Version" { print $2 }')"; \
test "$ver" = "v0.8.0" && echo "PASS: docker-scan version OK" || echo "FAIL: docker-scan version ($ver) did not match"
PASS: docker-scan version OK
RPM:
Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.SIDNvr
+ umask 022
+ cd /root/rpmbuild/BUILD
+ cd src
++ engine/bundles/dynbinary-daemon/dockerd --version
+ ver='Docker version 0.0.0-20210531142756-1c174ced, build 7c6a9484'
+ test 'Docker version 0.0.0-20210531142756-1c174ced, build 7c6a9484' = 'Docker version 0.0.0-20210531142756-1c174ced, build 7c6a9484'
+ echo 'PASS: daemon version OK'
+ exit 0
PASS: daemon version OK
...
Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.jKzBxw
+ umask 022
+ cd /root/rpmbuild/BUILD
+ cd src
++ cli/build/docker --version
PASS: cli version OK
+ ver='Docker version 0.0.0-20210531142756-1c174ced, build 1c174ced'
+ test 'Docker version 0.0.0-20210531142756-1c174ced, build 1c174ced' = 'Docker version 0.0.0-20210531142756-1c174ced, build 1c174ced'
+ echo 'PASS: cli version OK'
+ exit 0
...
Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.5KN9vp
+ umask 022
+ cd /root/rpmbuild/BUILD
+ cd src
++ /root/rpmbuild/BUILDROOT/docker-scan-plugin-0.8.0-0.el8.x86_64/usr/libexec/docker/cli-plugins/docker-scan docker-cli-plugin-metadata
++ awk '{ gsub(/[",:]/,"")}; $1 == "Version" { print $2 }'
PASS: docker-scan version OK
+ ver=v0.8.0
+ test v0.8.0 = v0.8.0
+ echo 'PASS: docker-scan version OK'
+ exit 0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When building rpm (and deb) packages, binaries are built from a source tarball.
Source tarballs will only include the raw source code, but do not include the
git repository; c4c2d89b4e/rpm/Makefile (L110-L116)
tar -C / -c -z -f /v/scan-cli-plugin.tgz --exclude .git scan-cli-plugin
Because of this, the makefile used to build the scan-cli-plugin binaries will
not be able to determine the "commit" (and version) to set as build-time variable
to include in the `--version` output; 3eaac3e884/builder.Makefile (L5-L19)
resulting in both `version` and `git commit` to be empty in the version output:
docker scan --version
Version:
Git commit:
Provider: Snyk (1.563.0 (standalone))
This patch updates the RPM spec to add variables for passing this information,
and collects the commit and version from the host to pass it to the build-
container in which the RPMs are built, similar to how they're passed for the
equivalent "deb" build-containers (which use env-vars for this);
c4c2d89b4e/deb/Makefile (L36-L37)
Before:
docker scan --version
Version:
Git commit:
Provider: Snyk (1.563.0 (standalone))
docker info
Client:
Context: default
Debug Mode: false
Plugins:
app: Docker App (Docker Inc., v0.9.1-beta3)
buildx: Build with BuildKit (Docker Inc., v0.5.1-docker)
scan: Docker Scan (Docker Inc.)
...
After:
docker scan --version
Version: v0.8.0
Git commit: 35651ca
Provider: Snyk (1.563.0 (standalone))
docker info
Client:
Context: default
Debug Mode: false
Plugins:
app: Docker App (Docker Inc., v0.9.1-beta3)
buildx: Build with BuildKit (Docker Inc., v0.5.1-docker)
scan: Docker Scan (Docker Inc., v0.8.0)
...
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
We should never build packages for "sid", which is a codename for "unstable",
and instead use the codename that it's currently referring to (codename of
next stable release).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Debian "sid" is not an actual distro version. Sid represents the "unstable"
channel ("next stable in-progress"). Currently, it is equivalent to "bullseye",
but once "bullseye" is stable, it becomes "bookworm", "trixy", etc (see the
list of Debian releases at https://wiki.debian.org/DebianReleases).
We should fix this hard-coded override, and instead try to get this name from
information in /var/lib/apt/lists/.
Also see https://github.com/docker/containerd-packaging/pull/219 for details.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The packaging repository was maintaining its own version of the systemd units.
These files were originally based on the units in the upstream docker / moby
repository, but diverged.
PR https://github.com/moby/moby/pull/42373 merged back the units from this
repository to upstream, so we can now consume those files instead of the
ones that were maintained in this repository.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
In https://github.com/docker/cli/pull/2993, Makefile target dynbinary
changed from a host script not depending on docker to a dockerized script.
Instead call the underlying script directly for deb/rpm.
I still think we should build deb/rpms using docker.
Signed-off-by: Tibor Vass <tibor@docker.com>
Since we are building arm on arm64 machines we have to specify the desired platform
and not rely on the host's architecture.
Also when building arm on arm64 machines, there can be issues with cgo.
So this patch makes sure CGO_ENABLED env var gets passed on as a build arg.
Signed-off-by: Tibor Vass <tibor@docker.com>
- now that we added the '--no-upgrades' option in 60abadbc04,
we no longer need the hack from 960961e76b
- add more comments, describing each step of the verify script, because
it may not be obvious why we do some steps.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
If download-stage.docker.com already contains a previous build
of docker-ce/docker-ce-cli, apt attempts to install that version,
only to discover that it's an older build (and considered a "downgrade")
This patch (hopefully) fixes that case, by not attempting to upgrade.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Verify was failing, because we did a test-build to staging:
docker-ce is already the newest version (5:0.0.0-20210401100358-59fd6f0-0~ubuntu-xenial).
docker-ce-rootless-extras is already the newest version (5:0.0.0-20210401100358-59fd6f0-0~ubuntu-xenial).
docker-ce-cli is already the newest version (5:0.0.0-20210401100358-59fd6f0-0~ubuntu-xenial).
The following additional packages will be installed:
containerd.io iptables libnfnetlink0 libxtables11
The following NEW packages will be installed:
containerd.io iptables libnfnetlink0 libxtables11
The following packages will be DOWNGRADED:
docker-scan-plugin
What's happening is that;
- first, we `dpkg-install` docker-ce, docker-ce-cli, and docker-scan-plugin
from the packages we just built
- then, we `apt-get install` to verify that dependencies (`containerd`)
are installed
However, we have `docker-scan-plugin` 0.7 on staging, which it then tries to
install, but sees it's an older build, so a _downgrade_
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It tries to make a daemon connection, which fails in this case;
docker scan --accept-license --version
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Makefile:193: recipe for target 'verify' failed
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Override the package version manually until we have properly separated the
control files (etc.) for each package that we build.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Need to separate this more, because currently, it will inherit
the package version from the cli/engine.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This allows building from a source tar.gz if the needed variables (COMMIT,
TAG_NAME, PLATFORM_BINARY) are set.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Alternative solution was to update git on centos7 in /rpm/SPEC/docker-ce-cli.spec:
```
if [ "$SUITE" == "7" ]; then
yum install -y http://opensource.wandisco.com/centos/7/git/x86_64/wandisco-git-release-7-2.noarch.rpm
yum install -y git
fi
```
But rather not changing what is installed on the CEnTOS bistro for the entire CI pipeline
Signed-off-by: Guillaume Tardif <guillaume.tardif@gmail.com>
This is to avoid duplicate codepaths.
Note that this completes the move of the tar.gz logic from
release-packaging to docker-ce-packaging only for the deb/rpm cases.
Static Linux, Windows and Mac were not touched.
Also I still think this whole bundles tar.gz thing is useless,
but this is what release-repo is currently consuming.
This also makes rpms work, as the path structure changed in docker-ce-packaging
to include distro.
Signed-off-by: Tibor Vass <tibor@docker.com>
This fixes a discrepancy between the rpmbuild and debbuild directory structure
and allows for a simple bundles archive target ready to be uploaded and consumed
by release-repo.
release-packaging could call these instead directly instead.
Example:
```
$ cd rpm && make rpmbuild/bundles-ce-centos-8-amd64.tar.gz
```
Signed-off-by: Tibor Vass <tibor@docker.com>
Seen this error from a bug-report;
dpkg: error processing package docker-ce (--configure):
installed docker-ce package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of docker-ce-rootless-extras:
docker-ce-rootless-extras depends on docker-ce; however:
Package docker-ce is not configured yet.
dpkg: error processing package docker-ce-rootless-extras (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
docker-ce
docker-ce-rootless-extras
E: Sub-process /usr/bin/dpkg returned an error code (1)
Looking through the possible options in the debian documantion:
https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends
We could pick `Pre-Depends` to wait with installing until `docker-ce` is fully
installed and configured, but but that's quite a strong relation, and from the
documentation:
unlike with Depends, Pre-Depends does not permit circular dependencies to be
broken. If a circular dependency is encountered while attempting to honor
Pre-Depends, the installation will be aborted.
To prevent installations from being aborted, I picked `Enhances`;
Enhances
This field is similar to Suggests but works in the opposite direction. It
is used to declare that a package can enhance the functionality of another package.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
dh-systemd has been integrated into debhelper, starting with version 9.20160709,
and has been removed in Debian 11 "bullseye"
This patch updates the control file to not require it as a dependency
on current versions of debian that ship with that version of debhelper
Related discussions:
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822670
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958585
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This reverts commit 36bb01538e,
which caused the docker service to not be starting, or delayed
starting the service in certain conditions.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
relates to https://github.com/docker/for-linux/issues/678
When using the BindTo directive, Docker is permanently stopped by systemd
when containerd is temporarily killed and restarted;
Using `Requires` achieves mostly the same, but defines a weaker dependency;
https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Requires=
> Requires=
>
> .. If this unit gets activated, the units listed will be activated as well.
> If one of the other units fails to activate, and an ordering dependency
> After= on the failing unit is set, this unit will not be started. Besides,
> with or without specifying After=, this unit will be stopped if one of the
> other units is explicitly stopped.
We may want to look into using `Wants=` instead of `Requires=`, because
that allows docker to continue running if containerd is restarted, quoting
the systemd documentation:
> Often, it is a better choice to use Wants= instead of Requires= in order
> to achieve a system that is more robust when dealing with failing services.
Given that docker will likely still fail if the containerd socket is not
present, startup will fail if containerd is not running, but if containerd
is restarted, the docker daemon may be able to try reconnecting.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Docker v20.10 ships with containerd.io v1.4.x, so setting the minimum
required version to v1.4.1 (current containerd.io release), as we won't
test / support older versions of containerd (and runc).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
e.g.-
for rpm- RHEL_RELEASES= CENTOS_RELEASES= FEDORA_RELEASES=centos-8 make rpm
for deb- RASPBIAN_VERSIONS= UBUNTU_VERSIONS= DEBIAN_VERSIONS=ubuntu-xenial make deb
Signed-off-by: Alok Kumar <alok232549@gmail.com>
dockerd currently sets the oom-score-adjust itself. This functionality
was added when we did not yet run dockerd as a systemd service.
Now that we do, it's better to instead have systemd handle this.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The engine now defaults to the "io.containerd.runc.v2" shim,
which is only available in containerd v1.3.0 and up.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
mk-build-deps does not seem to be updating the cache by itself, and
because of that may be installing packages using an outdated package index
if the previous layer is in the build-cache:
#6 [stage-1 2/8] RUN apt-get update && apt-get install -y curl devscripts e...
#6 CACHED
#8 [stage-1 3/8] COPY common /root/build-deb/debian
#8 CACHED
#9 [stage-1 4/8] RUN mk-build-deps -t "apt-get -o Debug::pkgProblemResolver...
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diff: https://github.com/docker/buildx/compare/v0.4.1...v0.4.2
- bake: fix parsing json config with hcl v2
- bake: update go-cty to pull in more stdlib funcs
- bake: ensure --builder is wired from root options
- build: support cacheonly exporter
- build: improve error checking on load
- build: remove warning for multi-platform iidfile
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Some features of buildx may still be "experimental" / non-final,
but we can call those out individually if needed.
This change removes the requirement to enable "experimental" mode
in the cli configuration file, so that it's easier for users to
try buildx.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
fetching a tag ref does not download the tag itself.
This patch makes sure that the tag (or branch) is downloaded otherwise
fallsback to fetching the commit hash as it did before.
Co-Authored-By: Tibor Vass <tibor@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Before this change:
make clean
time make checkout
git clone -q "https://github.com/docker/cli.git" src/github.com/docker/cli
git clone -q "https://github.com/docker/docker.git" src/github.com/docker/docker
69.16 real 15.69 user 9.69 sys
After this change:
make clean
time make checkout
...
From https://github.com/docker/docker
* branch HEAD -> FETCH_HEAD
git -C src/github.com/docker/docker checkout -q FETCH_HEAD
14.73 real 1.35 user 2.37 sys
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Debian did not have AppArmor available until Debian 7 "Wheezy", and not have it
enabled by _default_ until Debian 10 "Buster". The packaging scripts did not
add AppArmor as recommended dependency for that reason.
Now that Debian 10 "Buster" is the current stable, and older releases reached
EOL, we can remove the special handling for Debian/Ubuntu, and unconditionally
add apparmor as a recommended dependency.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
$ dpkg -c ./docker-ce-rootless-extras_0.0.0-20200611183532-31822ff745-0~ubuntu-eoan_amd64.deb
drwxr-xr-x root/root 0 2020-06-12 15:55 ./
drwxr-xr-x root/root 0 2020-06-12 15:55 ./usr/
drwxr-xr-x root/root 0 2020-06-12 15:55 ./usr/bin/
-rwxr-xr-x root/root 11724 2020-06-12 15:55 ./usr/bin/dockerd-rootless-setuptool.sh
-rwxr-xr-x root/root 3138 2020-06-12 15:55 ./usr/bin/dockerd-rootless.sh
-rwxr-xr-x root/root 15741392 2020-06-12 15:55 ./usr/bin/rootlesskit
-rwxr-xr-x root/root 9344264 2020-06-12 15:55 ./usr/bin/rootlesskit-docker-proxy
drwxr-xr-x root/root 0 2020-06-12 15:55 ./usr/share/
drwxr-xr-x root/root 0 2020-06-12 15:55 ./usr/share/doc/
drwxr-xr-x root/root 0 2020-06-12 15:55 ./usr/share/doc/docker-ce-rootless-extras/
-rw-r--r-- root/root 160 2020-06-12 15:55 ./usr/share/doc/docker-ce-rootless-extras/changelog.Debian.gz
NOTE: VPNKit is not included (yet), as it takes a lot of time for
compilation. We could use prebuilt VPNKit binary as we use in the static
tgz, but it is only available for amd64 and in Docker image currently.
This is not problematic for Ubuntu >= 19.10 and Debian >= 11, because
slirp4netns is apt-installable instead of VPNKit.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
This allows running the verify step in situations where containerd.io
has not yet been pushed to the production package repo.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
add optional requirement for nftables on RHEL8+ derivatives
(cherry picked from commit cfc7f43d3e)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The release branches have moved back to the upstream docker/docker
repository, so we should use that as source instead of the docker/engine
fork (and rely on it being synced with upstream)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
dpkg-source: warning: no source format specified in debian/source/format, see dpkg-source(1)
...
dpkg-source: info: using source format '1.0'
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This repository is only specified in the aarch64 (arm64) images,
and therefore was not caught in CI.
Bringing back the fix that was previously there, to prevent failures:
#9 [stage-1 4/6] RUN yum-builddep -y /root/rpmbuild/SPECS/*.spec
#9 0.982 Loaded plugins: fastestmirror, ovl
#9 1.177 Enabling base-source repository
#9 1.177 Enabling extras-source repository
#9 1.178 Enabling updates-source repository
#9 1.179 Loading mirror speeds from cached hostfile
#9 1.181 * base: d36uatko69830t.cloudfront.net
#9 1.182 * extras: d36uatko69830t.cloudfront.net
#9 1.182 * updates: d36uatko69830t.cloudfront.net
#9 2.272 http://vault.centos.org/altarch/7/extras/Source/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found
#9 2.272 Trying other mirror.
#9 2.273 To address this issue please refer to the below wiki article
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Use the [built-in macros][1] and env-vars for some paths:
- Use `%{_libexecdir}` macro, instead of `/usr/libexec`
- Use `%{_datadir}` instead of `/usr/share`
- Use `%{_specsdir}` instead of `/root/rpmbuild/SPECS`
- Use `$RPM_BUILD_DIR` instead of `/root/rpmbuild/BUILD`
- Use `$RPM_SOURCE_DIR` instead of `/root/rpmbuild/SOURCES`
[1]: https://rpm.org/user_doc/macros.html
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The built-in macros for paths all have a leading slash, so removing
slashes that were manually added before them.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
From the [RPM mailinglist][1]:
> `$RPM_BUILD_ROOT` is the official, supported, mechanism for getting the
> value of the configured build root in a build scriptlet.
>
> `%{buildroot}` may be changed in the future w/o warning. Not that I'm planning
> on that, but you've been warned.
[1]: https://www.redhat.com/archives/rpm-list/2002-July/msg00121.html
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
once we build from upstream repositories, CLI and Engine
will have different git commits; prepare for those changes
by making the variable name more generic.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
DEB_VERSION and STATIC_VERSION are a macro (evaluated/expanded when
called), so renaming them makes it more clear that they're expanded
at that point. GEN_*_VER is also in line with the equivalent
GEN_RPM_VERSION in the rpm/Makefile.
The environment variable used in the container (and scripts) is
kept as DEB_VERSION.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Sync formatting, and add RUN_FLAGS for rpm (it was available
for deb), so allow adding custom flags, without having to
define the whole RUN command.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This should prevent situations where the target directory
does not yet exist when make is called.
given the following makefile:
DIRECT := $(realpath ./direct)
LAZY = $(realpath ./lazy)
clean:
@rm -rf ./direct ./lazy
source:
@mkdir -p direct lazy
build: source
@echo DIRECT is $(DIRECT)
@echo LAZY is $(LAZY)
Running the below, will show that only "LAZY" shows the
correct path:
make clean && make build
DIRECT is
LAZY is /Users/sebastiaan/Projects/test/lazy
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- expand `PLUGINS_DIR` when "used" instead of when declared
- consistently use CLI_DIR to determin GITCOMMIT. When building from
the docker/docker-ce monorepo, this should make no difference, but
when building from the upstream repositories, this prevents the
rpm and deb packages to have a different commit specified.
- only set GO_IMAGE if it's not yet defined
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
PartOf deactivates the socket whenever the service get deactivated.
The socket unit however should be active nevertheless, so that the
docker service can be started again through socket activation.
Based on the original patch in upstream moby/moby by Max Harmathy.
Co-authored-by: Max Harmathy <max.harmathy@web.de>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Debian Buster is now the current "stable", and will be the
default baseimage for Golang images going forward.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
ca-certs was not installed (or outdated) in the raspbian
images, so explicitly install it.
Also adding "--no-install-recommends" flag, to force explicitly
including packages we need, instead of the implicitly
being installed.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Move the `ARCH` variable to the containerd script, as that's where it's
used
use the `pkg_config_manager` variable, which is not strictly nescessary
(main use of the variable looks to be for `install_rpm_containerd`),
but using the variable prevents linting warnings.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Use the --force-depends in case other dependencies are
added in future, which would make dpkg -i fail.
Also bring back --no-install-recommmends to make install
slightly faster, and document the steps we're doing in
this script:
Install the locally built packages using 'dpkg' because installing with
'apt-get' would attempt to install dependency packages (such as the CLI)
from download.docker.com instead of the locally built CLI package. Given
that 'dpkg -i' does not install any dependency (but will fail if depen-
dencies are missing), we use the '--ignore-depends' option to ignore
packages we know to be missing at this stage, and '--force-depends' to
only warn about any other missing dependency.
Afterwards, we run 'apt-get install' with the '--fix-broken' option to
trigger installation of the dependencies, which should succceed succesfully.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 7da772e08ba12a09471650dc5b6d311c39470668)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 3880335d06a5960bc5754d4dc9c5c796ae06885b)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diff: https://github.com/golang/go/compare/go1.12.15...go1.12.16
go1.12.16 (released 2020/01/28) includes two security fixes. One mitigates the
CVE-2020-0601 certificate verification bypass on Windows. The other affects only
32-bit architectures.
https://github.com/golang/go/issues?q=milestone%3AGo1.12.16+label%3ACherryPickApproved
- X.509 certificate validation bypass on Windows 10
A Windows vulnerability allows attackers to spoof valid certificate chains when
the system root store is in use. These releases include a mitigation for Go
applications, but it’s strongly recommended that affected users install the
Windows security update to protect their system.
This issue is CVE-2020-0601 and Go issue golang.org/issue/36834.
- Panic in crypto/x509 certificate parsing and golang.org/x/crypto/cryptobyte
On 32-bit architectures, a malformed input to crypto/x509 or the ASN.1 parsing
functions of golang.org/x/crypto/cryptobyte can lead to a panic.
The malformed certificate can be delivered via a crypto/tls connection to a
client, or to a server that accepts client certificates. net/http clients can
be made to crash by an HTTPS server, while net/http servers that accept client
certificates will recover the panic and are unaffected.
Thanks to Project Wycheproof for providing the test cases that led to the
discovery of this issue. The issue is CVE-2020-7919 and Go issue golang.org/issue/36837.
This is also fixed in version v0.0.0-20200124225646-8b5121be2f68 of golang.org/x/crypto/cryptobyte.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Update Golang 1.12.15
-------------------------------
full diff: https://github.com/golang/go/compare/go1.12.14...go1.12.15
go1.12.15 (released 2020/01/09) includes fixes to the runtime and the net/http
package. See the Go 1.12.15 milestone on the issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.12.15+label%3ACherryPickApproved
Update Golang 1.12.14
-------------------------------
go1.12.14 (released 2019/12/04) includes a fix to the runtime. See the Go 1.12.14
milestone on our issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.12.14+label%3ACherryPickApproved
Update Golang 1.12.13
-------------------------------
go1.12.13 (released 2019/10/31) fixes an issue on macOS 10.15 Catalina where the
non-notarized installer and binaries were being rejected by Gatekeeper. Only macOS
users who hit this issue need to update.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
I'm leaving Docker Inc. so it'd probably be best to remove me from the
automerge capabilities. I've also taken the liberty to remove other old
maintainers.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Re-use these build-args, so that there's only one place to set them per Dockerfile.
To verify this change:
Check if the env-vars are set on the image:
```bash
make UBUNTU_VERSIONS=ubuntu-bionic DEBIAN_VERSIONS="" RASPBIAN_VERSIONS="" CLI_DIR=$GOPATH/src/github.com/docker/cli ENGINE_DIR=$GOPATH/src/github.com/docker/docker deb
docker image inspect debbuild-ubuntu-bionic/x86_64 --format '{{json .Config.Env }}' | jq .
```
Which should output something like;
```json
[
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/go/bin:/go/bin",
"GOPROXY=direct",
"GO111MODULE=off",
"GOPATH=/go",
"DOCKER_BUILDTAGS=apparmor seccomp selinux",
"RUNC_BUILDTAGS=apparmor seccomp selinux",
"DISTRO=ubuntu",
"SUITE=bionic"
]
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
was not entirely sure if this was needed, but given
that they are scripts, I assume they should be executable
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Golang 1.12.12
-------------------------------
go1.12.12 (released 2019/10/17) includes fixes to the go command, runtime,
syscall and net packages. See the Go 1.12.12 milestone on our issue tracker for
details.
https://github.com/golang/go/issues?q=milestone%3AGo1.12.12
Golang 1.12.11 (CVE-2019-17596)
-------------------------------
go1.12.11 (released 2019/10/17) includes security fixes to the crypto/dsa
package. See the Go 1.12.11 milestone on our issue tracker for details.
https://github.com/golang/go/issues?q=milestone%3AGo1.12.11
[security] Go 1.13.2 and Go 1.12.11 are released
Hi gophers,
We have just released Go 1.13.2 and Go 1.12.11 to address a recently reported
security issue. We recommend that all affected users update to one of these
releases (if you're not sure which, choose Go 1.13.2).
Invalid DSA public keys can cause a panic in dsa.Verify. In particular, using
crypto/x509.Verify on a crafted X.509 certificate chain can lead to a panic,
even if the certificates don't chain to a trusted root. The chain can be
delivered via a crypto/tls connection to a client, or to a server that accepts
and verifies client certificates. net/http clients can be made to crash by an
HTTPS server, while net/http servers that accept client certificates will
recover the panic and are unaffected.
Moreover, an application might crash invoking
crypto/x509.(*CertificateRequest).CheckSignature on an X.509 certificate
request, parsing a golang.org/x/crypto/openpgp Entity, or during a
golang.org/x/crypto/otr conversation. Finally, a golang.org/x/crypto/ssh client
can panic due to a malformed host key, while a server could panic if either
PublicKeyCallback accepts a malformed public key, or if IsUserAuthority accepts
a certificate with a malformed public key.
The issue is CVE-2019-17596 and Go issue golang.org/issue/34960.
Thanks to Daniel Mandragona for discovering and reporting this issue. We'd also
like to thank regilero for a previous disclosure of CVE-2019-16276.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diff: https://github.com/golang/go/compare/go1.12.9...go1.12.10
```
Hi gophers,
We have just released Go 1.13.1 and Go 1.12.10 to address a recently reported security issue. We recommend that all affected users update to one of these releases (if you're not sure which, choose Go 1.13.1).
net/http (through net/textproto) used to accept and normalize invalid HTTP/1.1 headers with a space before the colon, in violation of RFC 7230. If a Go server is used behind an uncommon reverse proxy that accepts and forwards but doesn't normalize such invalid headers, the reverse proxy and the server can interpret the headers differently. This can lead to filter bypasses or request smuggling, the latter if requests from separate clients are multiplexed onto the same upstream connection by the proxy. Such invalid headers are now rejected by Go servers, and passed without normalization to Go client applications.
The issue is CVE-2019-16276 and Go issue golang.org/issue/34540.
Thanks to Andrew Stucki, Adam Scarr (99designs.com), and Jan Masarik (masarik.sh) for discovering and reporting this issue.
Downloads are available at https://golang.org/dl for all supported platforms.
Alla prossima,
Filippo on behalf of the Go team
```
From the patch: 6e6f4aaf70
```
net/textproto: don't normalize headers with spaces before the colon
RFC 7230 is clear about headers with a space before the colon, like
X-Answer : 42
being invalid, but we've been accepting and normalizing them for compatibility
purposes since CL 5690059 in 2012.
On the client side, this is harmless and indeed most browsers behave the same
to this day. On the server side, this becomes a security issue when the
behavior doesn't match that of a reverse proxy sitting in front of the server.
For example, if a WAF accepts them without normalizing them, it might be
possible to bypass its filters, because the Go server would interpret the
header differently. Worse, if the reverse proxy coalesces requests onto a
single HTTP/1.1 connection to a Go server, the understanding of the request
boundaries can get out of sync between them, allowing an attacker to tack an
arbitrary method and path onto a request by other clients, including
authentication headers unknown to the attacker.
This was recently presented at multiple security conferences:
https://portswigger.net/blog/http-desync-attacks-request-smuggling-reborn
net/http servers already reject header keys with invalid characters.
Simply stop normalizing extra spaces in net/textproto, let it return them
unchanged like it does for other invalid headers, and let net/http enforce
RFC 7230, which is HTTP specific. This loses us normalization on the client
side, but there's no right answer on the client side anyway, and hiding the
issue sounds worse than letting the application decide.
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 9a5aabdaff removed the fixed
version for this plugin, and changed it to install from "master",
which made the build non-reproducible.
This patch pins the plugin to a specific tag/release again, but allow
overriding by setting the `BUILDX_COMMIT` env-var.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Noticed this failing in internal e2e tests on CentOS:
```
sudo docker engine activate --license /tmp/docker.lic
unable to determine the installed engine version. Specify which engine image to update with --engine-image: open /var/lib/docker-engine/distribution_based_engine.json: no such file or directory
```
Looks lik 09b3ac888d changed the name of this
file from `distribution_based_engine-ce.json` to `distribution_based_engine.json`
(without `-ce` suffix) for the `.deb` packages, but did not update
the RPM packages accordingly.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.12.8 (released 2019/08/13) includes security fixes to the net/http and net/url packages.
See the Go 1.12.8 milestone on our issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.12.8
- net/http: Denial of Service vulnerabilities in the HTTP/2 implementation
net/http and golang.org/x/net/http2 servers that accept direct connections from untrusted
clients could be remotely made to allocate an unlimited amount of memory, until the program
crashes. Servers will now close connections if the send queue accumulates too many control
messages.
The issues are CVE-2019-9512 and CVE-2019-9514, and Go issue golang.org/issue/33606.
Thanks to Jonathan Looney from Netflix for discovering and reporting these issues.
This is also fixed in version v0.0.0-20190813141303-74dc4d7220e7 of golang.org/x/net/http2.
net/url: parsing validation issue
- url.Parse would accept URLs with malformed hosts, such that the Host field could have arbitrary
suffixes that would appear in neither Hostname() nor Port(), allowing authorization bypasses
in certain applications. Note that URLs with invalid, not numeric ports will now return an error
from url.Parse.
The issue is CVE-2019-14809 and Go issue golang.org/issue/29098.
Thanks to Julian Hector and Nikolai Krein from Cure53, and Adi Cohen (adico.me) for discovering
and reporting this issue.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Instead of dynamically getting list of distros to build for,
rely on the corresponding targets in sub-Makefiles. This also
ensures that deb/Makefile and rpm/Makefile will have up-to-date
list of distros included.
This also fixes the following bug:
> $ make deb
> for p in raspbian-stretch ubuntu-bionic ubuntu-disco ubuntu-xenial debbuild/ubuntu-disco ubuntu-cosmic debian-buster debian-stretch; do \
> ...
As you can see, `debbuild/ubuntu-disco` should not be included but it
is. Could be prevented by using `-maxdepth 1` argument to `find`.
While at it, amend the sub-Makefiles to print out the distro
that we build for.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
1. A symbol % is not working as expected in PHONY targets, so
e.g. fedora-30 was not being rebuild each time, because
fedora-30 directory exists. The fix is to explicitly mark
every fedora-NN target as phony.
2. Remove code duplication for making packages for different distros.
3. As a side effect, bash completion now lists all the distros
to be build.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
1. A symbol % is not working as expected in PHONY targets, so
e.g. ubuntu-cosmic was not being rebuild each time, because
ubuntu-cosmic directory exists. The fix is to explicitly mark
every ubuntu-whatever target as phony.
2. Remove code duplication for making packages for different distros.
3. Add missing ubuntu (cosmic, disco) and debian (buster) to the
appropriate targets.
4. As a side effect, bash completion now lists all the distros
to be build.
5. Exclude raspbian from deb target as it can only be built on ARM.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Instead of relying on the main Makefile to pass DOCKER_BUILD_PKGS as
an argument to {rpm,deb}/Makefile, use the sub-makefile directly.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
The dh_installman script calls "man" and captures its output to convert manpages
to utf8:
8523120dcc/dh_installman (L298-L316)
however, on minimized Ubuntu systems, man is overridden by a script that outputs
a warning message ("This system has been minimized by removing packages and
content ..").
As a result, all man-pages were be overwritten by that message.
This patch restores the actual `man` command before building to
work around this issue.
addresses docker/for-linux#639
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
On some distros we were encountering errors where `$1` was not being populated
for the 'pre' and 'posttrans' rpm macros, upon closer inspection it
isn't exactly clear why the pre and posttrans macro scripts were exactly
useful since the `%systemd_postun_with_restart` does exactly what those
scripts were doing.
I've tidied up the systemd macros to use `docker.service` instead of
`docker` which seems to function as we'd expect.
taken from downstream commit 62d8413b550659a0b5318346ee2e3d7e4a50bfe1
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- systemd-units -> systemd (taken from 8bb1f0a7a395dfd979cd410b26ef47e55433de32)
- some wording changes (taken from a8c522a7c22c34dc354e91941377a4aadc3ddc4c)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
version 2.9 is really old; this sets the same minimal version
as is used for the containerd.io package
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Restores previous behavior when it comes to building the daemon plus its
dependencies (docker-proxy, docker-init)
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Signed-off-by: Eli Uriegas <seemethere101@gmail.com>
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Restores previous behavior when it comes to building the daemon plus its
dependencies (docker-proxy, docker-init)
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
containerd is now running as a separate service, and should
no longer be started as a managed child-process of dockerd.
The dockerd service already specifies that it should be started
`After` the containerd.service, but there is still a race
condition, where containerd is started, but its socket is not yet
created.
In that situation, `dockerd` detects that the containerd socket
is missing, and will start a new instance of containerd (as a
managed child-process), which causes live-restore to fail.
This patch explicitly sets the `--containerd` daemon option.
If this option is set, `dockerd` will not start a new instance
of containerd.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
During the migration to "image based builds", some dependencies
were removed.
This patch brings back those dependencies.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit a6ff66f1a5)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This requirement was originally added in 86f76496ce,
but got removed in the migration to the new image-based packaging.
Commit f2ceca9882 added this requirement
back for `.deb` packages, but did not include the same changes for
RPMs.
This patch adds back the requirement for RPM packages as well.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 86ed6eb2ce)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.11.3 (released 2018/12/14)
- crypto/x509: CPU denial of service in chain validation golang/go#29233
- cmd/go: directory traversal in "go get" via curly braces in import paths golang/go#29231
- cmd/go: remote command execution during "go get -u" golang/go#29230
See the Go 1.11.3 milestone on the issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.11.3
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Without this the docker.socket would not start by default when starting
the docker.service leading to failures to start.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Removes the systemd drop-in unit file for socket activation and instead
prefers socket activation by default for both RHEL based and DEBIAN
based distributions.
Socket activation for RHEL based distributions was tested on CentOS 7 and Fedora 28.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
We don't use these spec files to actually build from anymore so we
should just go through and remove them.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
The RPM packages list containerd as a hard dependency. While
having containerd installed allows certain features (e.g., allow
you to run `docker engine activate`), this should not be a requirement
for installing the Docker CLI, as it limits the use of this package
for situations where the CLI is installed to connect to a remote
daemon.
This patch removes the containerd dependency from the RPM packages
(the deb packages don't have this dependency, so no change is needed
in those packages)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The CLI package does not provide the functionality of the
"selinux" and "engine" packages (it does _conflict_ with
older engine packages though).
This removes the "obsoletes" from the CLI package, as the
Engine package already obsoletes the other ones.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
While testing on older ubuntu images we discovered
we do depend on a newer version of libseccomp2.
Signed-off-by: Daniel Hiltgen <daniel.hiltgen@docker.com>
(cherry picked from commit f2ceca9882)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These files are not used, and having them in repo is misleading.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit fca673ad80)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Packages are no longer built for Ubuntu 17.10 since
commit eb635bdb30, so
remove it from the README as well
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Nightly builds wouldn't install correctly since our versioning scheme
for nightly builds is 0.0.0~ and 0 < 18.
Should be backwards compatible with 18.09 builds so there's no need to
actually backport this to 18.09.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
This should ensure we don't produce builds without a valid "Built:"
field in the the version payload.
Signed-off-by: Daniel Hiltgen <daniel.hiltgen@docker.com>
(cherry picked from commit 9a071a3fbe)
Signed-off-by: Daniel Hiltgen <daniel.hiltgen@docker.com>
People blow away `/var/lib/docker` all the time so we probably shouldn't
store important data there.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Set the PATH to what appears to be the standard on latest Ubuntu (18.04)
and Debian (9), fixing the following two issues:
1. PATH did not contain /bin (leading to ContainerTop/ps not working
on newer distros, among the other things).
2. $PATH can't be specified in Environment directives in .service files.
While at it, also:
3. Remove the comment about RPM as it looks misleading on deb-based
systems.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
devicemapper cannot be enabled on a statically compiled binary so we
dynamically compile it on a rhel based distribution in order to enable
devicemapper usage.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
osusergo build tag is needed for better chances to have
a proper static binary when Go >= 1.11 is used, and is
harmless otherwise.
seccomp build tag is needed so the resulting dockerd binary
has seccomp support.
[v2: install libseccomp-dev package]
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This is set in a top-level makefile, but apparently
isn't getting passed all the way through as expected.
Signed-off-by: Daniel Hiltgen <daniel.hiltgen@docker.com>
(cherry picked from commit a5ad547141)
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Should generate correct bits whether or not the suffix is present.
Working example:
❯ ./gen-deb-ver . 18.09.0-beta1
18.09.0~1.1.beta1 18.09.0-beta1
❯ ./gen-deb-ver . 18.09.0-ce-beta1
18.09.0~ce~1.1.beta1 18.09.0-ce-beta1
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
This will make it easier for anybody to build with a specific version of a distro they want to build on.
They could lock into a specific sha of a docker image if they wanted, as an example.
Signed-off-by: corbin-coleman <corbin.coleman@docker.com>
This should accomodate the new versioning fix
Signed-off-by: Daniel Hiltgen <daniel.hiltgen@docker.com>
(cherry picked from commit be00095e1d)
Signed-off-by: Daniel Hiltgen <daniel.hiltgen@docker.com>
Removes the need for the offline installer to install the shim process
and instead installs the shim process as part of the packaging.
May be easier in the future to just package the shim process on it's own
but that'll come after this 18.09 release
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
It's generally bad-form to generate two identically named package files
that are actually different, so we should name our packages based on
the distro and version, not just the distro.
Signed-off-by: Daniel Hiltgen <daniel.hiltgen@docker.com>
Note that StartLimit* options were moved from "Service" to "Unit" in systemd 229
(6bf0f408e4)
both the old, and new location are accepted by systemd 229 and up, so using the old location
to make them work for either version of systemd.
StartLimitInterval was renamed to StartLimitIntervalSec in systemd 230
(f0367da7d1)
both the old, and new name are accepted by systemd 230 and up, so using the old name to make
this option work for either version of systemd.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This adds support for reloading the docker daemon
(SIGHIUP) so that changes in '/etc/docker/daemon.json'
can be loaded at runtime by reloading the service
through systemd ('systemctl reload docker')
Before this change, systemd would output an error
that "reloading" is not supported for the docker
service;
systemctl reload docker
Failed to reload docker.service: Job type reload is not applicable for unit docker.service.
After this change, the docker daemon can be reloaded
through 'systemctl reload docker', which reloads
the configuration;
journalctl -f -u docker.service
May 02 03:49:20 testing systemd[1]: Reloading Docker Application Container Engine.
May 02 03:49:20 testing docker[28496]: time="2016-05-02T03:49:20.143964103-04:00" level=info msg="Got signal to reload configuration, reloading from: /etc/docker/daemon.json"
May 02 03:49:20 testing systemd[1]: Reloaded Docker Application Container Engine.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Change the kill mode to process so that systemd does not kill container
processes when the daemon is shutdown but only the docker daemon
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
We need to add delegate yes to docker's service file so that it can
manage the cgroups of the processes that it launches without systemd
interfering with them and moving the processes after it is reloaded.
Delegate=
Turns on delegation of further resource control partitioning to
processes of the unit. For unprivileged services (i.e. those
using the User= setting), this allows processes to create a
subhierarchy beneath its control group path. For privileged
services and scopes, this ensures the processes will have all
control group controllers enabled.
This is the proper fix for issue moby/moby#20152
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Systemd sets a default of 512 tasks, which is far
too low to run many containers.
Note that TasksMax is only supported on systemd 226
and above.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
There is a not-insignificant performance overhead for all containers (if
containerd is a child of Docker, which is the current setup) if systemd
sets rlimits on the main Docker daemon process (because the limits
propogate to all children).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
set LimitCORE=infinity to ensure complete core creation,
allows extraction of as much information as possible.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Includes fixes to the go command, linker, and the net/http, mime/multipart,
ld/macho, bytes, and strings packages. See the Go 1.10.4 milestone on the
issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.10.4
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This adds a build date using the same pattern as upstream
https://github.com/moby/moby/blob/master/hack/make.sh#L69
Signed-off-by: Daniel Hiltgen <daniel.hiltgen@docker.com>
(cherry picked from commit c443439189)
Signed-off-by: Daniel Hiltgen <daniel.hiltgen@docker.com>
This encodes the platform as "Docker Engine - Community"
for community engines
Signed-off-by: Daniel Hiltgen <daniel.hiltgen@docker.com>
(cherry picked from commit 4d9fd7d17f)
Signed-off-by: Daniel Hiltgen <daniel.hiltgen@docker.com>
This should make it easier to change downstream builds
to change the scope.
Signed-off-by: Daniel Hiltgen <daniel.hiltgen@docker.com>
(cherry picked from commit 7240669124)
Signed-off-by: Andrew Hsu <andrewhsu@docker.com>
Should rely on list in the daemon
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
(cherry picked from commit 605758124d)
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Was reporting 404's using the old url for some reason, might have to
refactor this in the future to just use a git clone...
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Allows us to switch out debian files and rpm specs on the fly and also
gives us an out to have ARCH specific dockerfiles if we need them for
RPM's. The same strategy can be used for DEB's if need be
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Get's rid of architecture specific dockerfiles (yay manifest lists),
also follows very closely to what the RPM makefile does with the
sources.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Old versions of things on CentOS 7 strike again!
infinity is not a thing for TimeoutSec on systemd < 229
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Also split off containerd.mk into it's own thing since most of this
stuff will be re-used with debian packaging anyways.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Splits out the docker-ce package and docker-ce-cli package into their
own things.
Still TODO: need to have a cleanup on the dependencies for the
Dockerfiles
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Also moved package deps into spec file BuildRequires. Had to hard-code
Epoch in spec file in order to realize deps with yum-builddep.
Signed-off-by: Andrew Hsu <andrewhsu@docker.com>
Also moved package deps into spec file BuildRequires. Had to hard-code
Epoch in spec file in order to realize deps with yum-builddep.
Signed-off-by: Andrew Hsu <andrewhsu@docker.com>
Also moved package deps into spec file BuildRequires. Had to hard-code
Epoch in spec file in order to realize deps with yum-builddep.
Signed-off-by: Andrew Hsu <andrewhsu@docker.com>
Looks like yum-builddep will only work if rpmlint passed on the spec
file and the spec file errors out on Epoch not being hardcoded.
Signed-off-by: Andrew Hsu <andrewhsu@docker.com>
This splits out the CLI into a discrete package and removes
the engine from the engine package. Instead the engine
is initialized via a post-inst script using the new CLI UX.
For the Q3 release the names will be refined slightly, and "ce" will no
longer be used - it's now just the docker engine, with "community" or
"enterprise" at the end if disambiguation is needed.
based on golang's pseudo-version: https://groups.google.com/forum/#!topic/golang-dev/a5PqQuBljF4
> using a "pseudo-version" of the form v0.0.0-yyyymmddhhmmss-abcdefabcdef,
> where the time is the commit time in UTC and the final suffix is the prefix
> of the commit hash. The time portion ensures that two pseudo-versions can
> be compared to determine which happened later, the commit hash identifes
> the underlying commit, and the v0.0.0- prefix identifies the pseudo-version
> as a pre-release before version v0.0.0, so that the go command prefers any
> tagged release over any pseudo-version.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Switches dev versioning from being based on a set version like
`18.06.0-dev` to being based purely on the git commit timestamp / git
commit sha.
This should give us a bit more flexibility in terms of nightlies not
being tied to specific versions.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
It's not longer supported since Debian Jessie is now an LTS release as
of June 17, 2018. LTS releases of Debian only support i386, amd64, armel and armhf
Sources:
* https://wiki.debian.org/LTS
* https://wiki.debian.org/LTS/FAQ
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
go1.10.3 (released 2018/06/05) includes fixes to the go command, and the
crypto/tls, crypto/x509, and strings packages. In particular, it adds minimal
support to the go command for the vgo transition. See the Go 1.10.3 milestone
on our issue tracker for details;
https://github.com/golang/go/issues?q=milestone%3AGo1.10.3
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
`btrfs-progs` doesn't actually contain the files we need, since we only
need the headers for btrfs, which `libbtrfs-dev` now provides.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
btrfs-tools is being deprecated in favor of btrfs-progs, will only
matter for debian versions >= buster
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
The pigz binary is used to improve performance when
pulling images, but is not available in the default
CentOS package repositories.
Given that RPM's don't have a "recommends" option,
it's better to remove it as a requirement for now,
instead of failing to install for some users.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Use a variable in the Makefile to set the GO_VERSION for the builds.
GO_VERSION is defaulted in all Makefiles as `1.10.2`, but can be set when running make: `make GO_VERSION=1.10.1 deb`.
Signed-off-by: corbin-coleman <corbin.coleman@docker.com>
Debian Wheezy will be EOL on 31-05-2018 per the official documentation,
https://wiki.debian.org/LTS
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
The hardcoded values make it so that we have to update this everytime we
add/subtract something which is sometimes followed/not followed.
This makes it so that we no longer have to update this.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
go1.9.5 (released 2018/03/28) includes fixes to the compiler, go command, and
net/http/pprof package. See the Go 1.9.5 milestone on the issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.9.5
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Found a bug where a number was being appended to the nightly dev builds
package name causing the latest packages not to be considered as the
latest packages by the package manager.
This makes it so that the nubmer is not included on dev builds.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
There was a lot of repeated parts in this Makefile, I moved them to a
common variable so that if / when we decide to change how things are run
then it's easy to do so.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Enables the usage of a new versioning scheme for test builds:
* tp -> Technical Previews
* beta -> Beta Releases
* rc -> Release Candidates
* ga -> General Availability Releases
This PR fixes the versioning order for both `deb` and `rpm` packages
when it relates to the new versioning scheme (which may or may not be
used).
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Scripts were changed around to do static by default, this changes so
that we have "dynamic" inserted where it needs to be inserted
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Binary installation was broken after the
hack/dockerfile/install-binaries script was removed.
This remedies that.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Zesty is EOL and doesn't even have a subdirectory in the `deb` directory of this repo. There's no need to have it as a default.
Signed-off-by: Corbin <corbin.coleman@docker.com>
This fixes a vulnerability in `go get` (CVE-2018-6574, http://golang.org/issue/23672),
but shouldn't really affect our code, but it's good to keep in sync.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Dev builds for debian packages previously had system time inserted into
their packaging names while both static and rpm builds instead had the
git commit time.
This commit remedies that by pushing the generation of the debian
package version into a separate script to mirror what is being done in
static and rpm builds.
To give you an idea of what it looks like take the following examples:
```
❯ ./gen-deb-ver ~/work/docker-ce/components/engine/ $(cat ~/work/docker-ce/VERSION)
18.03.0~ce~dev~git20180202.170651.0.e232737
```
```
❯ ./gen-rpm-ver ~/work/docker-ce/components/engine $(cat ~/work/docker-ce/VERSION)
18.03.0.ce 0.0.dev.git20180202.170651.0.e232737 e232737
```
```
❯ ./gen-static-ver ~/work/docker-ce/components/engine/ $(cat ~/work/docker-ce/VERSION)
18.03.0-ce-dev-20180202.170651-e232737
```
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Adds git date plus git commit sha to static builds if the version being
built for is a development version
Output is similar to: `docker-18.02.0-ce-dev-20180120.170357-fa4fb35.tgz`
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Since systemd version 228, a new setting, `TasksMax`, has appeared,
which limits the number of tasks used by a service (via pids cgroup
controller). Unfortunately, a default for this setting, `DefaultTaskMax`,
is set to 512. In systemd version 231 it is changed to 15% which
practically is 4195, as the value from /proc/sys/kernel/pid_max is
treated like 100%).
Either 512 or 4195 is severily limited value for Docker Engine,
as it can run thousands of containers with thousands of tasks in each,
and the number of tasks limit should be set on a per-container basis
by the Docker user. So, the most reasonable setting for `TasksMax`
is `unlimited`.
Unfortunately, older versions of systemd warn about unknown `TasksMax`
parameter in `docker.service` file, and the warning is rather annoying,
therefore this setting is commented out by default, and is supposed
to be uncommented by the user.
The problem with that is, once the limit is hit, all sorts of bad things
happen and it's not really clear even to an advanced user that this
setting is the source of issues.
Now, `rules` file already contain a hack to check for the systemd
version (during build time) and in case the version is greater than 227,
uncomment the `TasksMax=unlimited` line. Alas, it does not work
during normal builds, the reason being systemd is not installed
into build environments.
An obvious fix would be to add systemd to the list of installed
packages in all Dockerfiles used to build debs. Fortunately,
there is a simpler way, as libsystemd-dev is installed, and
it's a subpackage of systemd built from the same source and
carrying the same version, so it can also be checked.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Since systemd version 228, a new setting, `TasksMax`, has appeared, which
limits the number of tasks used by a service (via pids cgroup
controller). Unfortunately, a default for this setting, `DefaultTaskMax`,
is set to 512. In systemd version 231 it is changed to 15% which
practically is 4195, as the value from /proc/sys/kernel/pid_max is
treated like 100%).
Either 512 or 4195 is severily limited value for Docker Engine, as it
can run thousands of containers with thousands of tasks in each, and
the number of tasks limit should be set on a per-container basis by the
Docker user. So, the most reasonable setting for `TasksMax` is `unlimited`.
Unfortunately, older versions of systemd warn about unknown `TasksMax`
parameter in `docker.service` file, and the warning is rather annoying,
therefore this setting is commented out by default, and is supposed to
be uncommented by the user.
The problem with that is, once the limit is hit, all sorts of bad things
happen and it's not really clear even to an advanced user that this
setting is the source of issues.
As Fedora 25 ships systemd 231, it (and later Fedora releases) support
TasksMax, so it makes total sense to uncomment the setting, this is what
this commit does.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
-dev was being removed, per legacy code, but we'd like to add it back
into the naming so that deb / rpm packages will look mostly the same
when compiled with a `-dev` version.
RPMS end up looking like:
docker-ce-18.02.0.ce-0.0.dev.git20180120.170357.0.fa4fb35.el7.centos.x86_64.rpm
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
This change is in response to https://github.com/moby/moby/pull/35697
It adds pigz to the recommended binaries that should be installed with
docker-ce.
Signed-off-by: Sargun Dhillon <sargun@sargun.me>
Was getting annoying to have to write it into one spot so moved them to
above the targets that they specify.
Signed-off-by: Eli Uriegas <seemethere101@gmail.com>
Relates to an upgrade in `rpm` to `14.4.0`, where missing build-ids now
cause builds to self-terminate. May be needed in other distros if/when
the `rpm` package is updated in those repos.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
When building we should default to a dummy version unless otherwise
specified so we don't get ourselves confused over what is official and
what is not.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Failed out otherwise:
```
---> Making bundle: dynbinary (in bundles/dynbinary)
Building: bundles/dynbinary-daemon/dockerd-17.09.0-dev
Package libudev was not found in the pkg-config search path.
```
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Seems `docker-edge` was removed as label on jenkins.dockerproject.org.
This removes that label and just puts the x86_64 label
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
* add aarch64 support
* use go 1.9 for arm64 support
* fixtypo
* add backports on jessie
* fix path
* delet yakkety
* rm golang-go
* use arm64v8/ images
* fix error made in merge
* remove double architecture
* use arm64v8/
* use go 1.8.5
* Update aarch64 builds to 1.9.2
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Setting to something that will not be confused with a version number
that will ever be released. Also, this is required for the deb packages
to build properly
Signed-off-by: Andrew Hsu <andrewhsu@docker.com>
Was getting 404's with the old one, consider this one temporary until
canonical fixes their stuff.
Related:
https://bugs.launchpad.net/cloud-images/+bug/1711735
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
The "armhf" images on Docker Hub are deprecated
in favor of the "arm32v7" and "arm32v6" images.
Note that the Alpine image is built for arm32v6,
which is compatible for both arm32v6 and arm32v7.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Adds the seccomp buildtag for ubuntu-yakkety on s390x
Note: s390x requires libseccomp-dev 2.3.1 at the moment which is only available
only yakkety and later. This change is also consistent with the s390x yakkety
deb dockerfile in moby/moby.
Signed-off-by: Christopher Jones <tophj@linux.vnet.ibm.com>
these examples are not nescessary for day-to-day
use of docker, so don't have to be included in
the packages.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The completion scripts have been moved to the
docker/cli repository, so should be taken from
that directory.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
* Prefixes documentation files per component
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
* Remove reliance on basename
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
These are replaced by `container-selinux` on fedora-25 and centos-7.
Marking these packages as obsolete makes the installation process a bit
smoother, otherwise the user will have to manually uninstall the older
packages to install the new one.
Also makes fedora24 use container-selinux which is now supports labeling
the `dockerd` binary correctly.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
# force packages to be built with xz compression, as Ubuntu 21.10 and up use
# zstd compression, which is non-standard, and breaks 'dpkg-sig --verify'
override_dh_builddeb:
dh_builddeb -- -Zxz
# Determine the Go module mode based on the presence of vendor.mod or go.mod
override_dh_auto_build: GOMOD := $(if $(wildcard engine/vendor.mod),off,$(if $(wildcard engine/go.mod),on,$(error "No go.mod or vendor.mod found in engine directory")))
# Override the default dh_auto_build target
override_dh_auto_build:
cd engine && ./hack/make.sh dynbinary
cd cli && LDFLAGS="" make VERSION=$(VERSION) dynbinary
# ./man/md2man-all.sh runs outside the build container (if at all), since we don't have go-md2man here
# Build the daemon and dependencies
cd engine && GO111MODULE=$(GOMOD) DOCKER_GITCOMMIT=$(ENGINE_GITCOMMIT) PRODUCT=docker ./hack/make.sh dynbinary
cd engine && TMP_GOPATH="/go" hack/dockerfile/install/install.sh tini
cd engine && TMP_GOPATH="/go" hack/dockerfile/install/install.sh rootlesskit dynamic
# build man-pages
make -C engine/man
# Build the CLI
make -C /go/src/github.com/docker/cli DISABLE_WARN_OUTSIDE_CONTAINER=1 VERSION=$(VERSION) GITCOMMIT=$(CLI_GITCOMMIT) LDFLAGS='' dynbinary manpages shell-completion
test "$$ver" = "Docker version $(VERSION), build $(ENGINE_GITCOMMIT)" && echo "PASS: daemon version OK" || (echo "FAIL: daemon version ($$ver) did not match" && exit 1)
ver="$$(cli/build/docker --version)"; \
test "$$ver" = "Docker version $(VERSION), build $(CLI_GITCOMMIT)" && echo "PASS: cli version OK" || (echo "FAIL: cli version ($$ver) did not match" && exit 1)
test "$$ver" = "$(MODEL_VERSION)" && echo "PASS: docker-model version OK" || (echo "FAIL: docker-model version ($$ver) did not match" && exit 1)
override_dh_strip:
# Go has lots of problems with stripping, so just don't
# http://manpages.debian.org/dh_dwz
override_dh_dwz:
# dh_dwz in debhelper versions less than 13 has issues with files that are missing debug symbols (once we update to debhelper-compat 13+ this can be removed)
make -C /go/src/github.com/docker/cli DISABLE_WARN_OUTSIDE_CONTAINER=1 VERSION=%{_origversion} GITCOMMIT=%{_gitcommit_cli} dynbinary manpages shell-completion
%check
ver="$(cli/build/docker --version)"; \
test "$ver" = "Docker version %{_origversion}, build %{_gitcommit_cli}" && echo "PASS: cli version OK" || (echo "FAIL: cli version ($ver) did not match" && exit 1)
test "$ver" = "Docker version %{_origversion}, build %{_gitcommit_engine}" && echo "PASS: daemon version OK" || (echo "FAIL: daemon version ($ver) did not match" && exit 1)