The 1.16 `io/fs` compatibility code was being built on 1.18 and 1.19.
Drop it completely as 1.16 is long EOL, and additionally drop 1.17 as it
has been EOL for a month and 1.18 is both the minimum Go supported by
the 20.10 branch, as well as a very easy jump from 1.17.
Signed-off-by: Bjorn Neergaard <bneergaard@mirantis.com>
A copy of Go's archive/tar packge was vendored with a patch applied to
mitigate CVE-2019-14271. Vendoring standard library packages is not
supported by Go in module-aware mode, which is getting in the way of
maintenance. A different approach to mitigate the vulnerability is
needed which does not involve vendoring parts of the standard library.
glibc implements name service lookups such as users, groups and DNS
using a scheme known as Name Service Switch. The services are
implemented as modules, shared libraries which glibc dynamically links
into the process the first time a function requiring the module is
called. This is the crux of the vulnerability: if a process linked
against glibc chroots, then calls one of the functions implemented with
NSS for the first time, glibc may load NSS modules out of the chrooted
filesystem.
The API underlying the `docker cp` command is implemented by forking a
new process which chroots into the container's rootfs and writes a tar
stream of files from the container over standard output. It utilizes the
Go standard library's archive/tar package to write the tar stream. It
makes use of the tar.FileInfoHeader function to construct a tar.Header
value from an fs.FileInfo value. In modern versions of Go on *nix
platforms, FileInfoHeader will attempt to resolve the file's UID and GID
to their respective user and group names by calling the os/user
functions LookupId and LookupGroupId. The cgo implementation of os/user
on *nix performs lookups by calling the corresponding libc functions. So
when linked against glibc, calls to tar.FileInfoHeader after the
process has chrooted into the container's rootfs can have the side
effect of loading NSS modules from the container! Without any
mitigations, a malicious container image author can trivially get
arbitrary code execution by leveraging this vulnerability and escape the
chroot (which is not a sandbox) into the host.
Mitigate the vulnerability without patching or forking archive/tar by
hiding the OS-dependent file info from tar.FileInfoHeader which it needs
to perform the lookups. Without that information available it falls back
to populating the tar.Header with only the information obtainable
directly from the FileInfo value without making any calls into os/user.
Fixes#42402
Signed-off-by: Cory Snider <csnider@mirantis.com>
The hack/vendor.sh script is used to (re)vendor dependencies. However, it did
not run `go mod tidy` before doing so, wheras the vendor _validation_ script
did.
This could result in vendor validation failing if go mod tidy resulted in
changes (which could be in `vendor.sum`).
In "usual" situations, this could be easily done by the user (`go mod tidy`
before running `go mod vendor`), but due to our (curent) uses of `vendor.mod`,
and having to first set up a (dummy) `go.mod`, this is more complicated.
Instead, just make the script do this, so that `hack/vendor.sh` will always
produce the expected result.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- use `vendor.mod` instead of `go.mod` to avoid issues to do with
use of CalVer, not SemVer
- ensure most of the dependency versions do not change
- only zookeeper client has to change (via docker/libkv#218) as
previously used version is no longer maintained and has missing
dependencies
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Golang '.0' releases are released without a trailing .0 (i.e. go1.17
is equal to go1.17.0). For the base image, we want to specify the go
version including their patch release (golang:1.17 is equivalent to
go1.17.x), so adjust the script to also accept the trailing .0, because
otherwise the download-URL is not found:
hack/vendor.sh archive/tar
update vendored copy of archive/tar
downloading: https://golang.org/dl/go1.17.0.src.tar.gz
curl: (22) The requested URL returned error: 404
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Fix the error message in hack/validate/vendor to specify that
hack/vendor.sh should be run instead of vndr.
- Fix hack/vendor.sh to also match on Windows paths for the whitelist.
This allows the script to be run on Windows via Git Bash.
Signed-off-by: Kevin Parsons <kevpar@microsoft.com>
This version avoids doing name lookups on creating tarball that
should be avoided in to not hit loading glibc shared libraries.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
(cherry picked from commit aa6a9891b0)
Signed-off-by: Tibor Vass <tibor@docker.com>
This is especially important for distributions like NixOS where `/bin/bash` doesn't exist, or for MacOS users who've installed a newer version of Bash than the one that comes with their OS.
Signed-off-by: Andrew "Tianon" Page <admwiggin@gmail.com>
This adds a metrics packages that creates additional metrics. Add the
metrics endpoint to the docker api server under `/metrics`.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Add metrics to daemon package
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
api: use standard way for metrics route
Also add "type" query parameter
Signed-off-by: Alexander Morozov <lk4d4@docker.com>
Convert timers to ms
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
This fix revendor swarmkit to 0ec7c6ee4b3185ec4e3d6bd65f8f5542b1761421.
Related docker PR and issues:
(#27567)
(#25437)
(#26988)
(#25644)
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
This vendors a fork of logrus with fixes to deal with errors generated
by the github.com/pkg/errors package. Without these fixes, the errors
are mishandled when passed to WithError:
- When printing to a terminal (colors enabled), stack traces are
included in the error fields on a log line.
- When printing to a file (or with colors disabled), the error value is
missing entirely.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
This fixes a regression bug not to connect the destination node twice or more.
That regression was brought by v1.2.0, and it also makes many goroutines for
first reconnection (these will finish after first reconnection established).
Signed-off-by: Satoshi Tagomori <tagomoris@gmail.com>
