Required for distros that wanna use their local version and
can't have some (possibly failing) git commands being run here.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
There still was one place that's calling the `go` command directly
instead of using the $(GO) variable.
Fixes: 9ea25634bd
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We have been using Cirrus CI for running vagrant workloads
as the standard runners of GHA lacks nested virtualization,
but it looks like GHA with the "larger" runners support nested
virtualization.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
In the sbserver we should not use the GOOS, as windows hosts can run
linux containers. On the sbserver we should use the platform param.
Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
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
go1.19.12 (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.19.12 milestone on our issue tracker for details.
- https://github.com/golang/go/issues?q=milestone%3AGo1.19.12+label%3ACherryPickApproved
- full diff: https://github.com/golang/go/compare/go1.19.11...go1.19.12
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>
Before this PR, if a stdin/stdout/stderr stream is nil,
and the corresponding FIFO is not an empty string,
a panic will occur when Read/Write of the nil stream is invoked in io.CopyBuffer.
Signed-off-by: Hsing-Yu (David) Chen <davidhsingyuchen@gmail.com>
Runc 1.1 throws a warning when using rel destination paths, and runc 1.2
is planning to thow an error (i.e. won't start the container).
Let's just make this an abs path in the only place it might not be: the
mounts created due to `VOLUME` directives in the Dockerfile.
Signed-off-by: Rodrigo Campos <rodrigoca@microsoft.com>
[`logrus.SetLevel()`][1], [`logrus.GetLevel()`][2] and [`logrus.SetFormatter()`][3]
are all convenience functions to configure logrus' standardlogger, which is the
logger to which we hold a reference in the Entry configured on [`log.L`][4].
This patch:
- swaps calls to `logrus.SetLevel`, `logrus.GetLevel` and `logrus.SetFormatter`
for their equivalents on `log.L`. This makes it clearer what `SetLevel` does,
and makes sure that we set the log-level of the logger / entry we define in
our package (even if that would be swapped with a different instance).
- removes the use of `logrus.NewEntry` with directly constructing a `Entry`,
using the local `Entry` alias (anticipating we can swap that type in future).
[1]: dd1b4c2e81/exported.go (L34C1-L37)
[2]: dd1b4c2e81/exported.go (L39-L42)
[3]: dd1b4c2e81/exported.go (L23-L26)
[4]: dd1b4c2e81/exported.go (L9-L16)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add a package doc to (try to) describe the purpose of this package, and
to describe the purpose (and expectations) of aliases provided by the
package.
> Package log provides types and functions related to logging, passing
> loggers through a context, and attaching context to the logger.
>
> # Transitional types
>
> This package contains various types that are aliases for types in [logrus].
> These aliases are intended for transitioning away from hard-coding logrus
> as logging implementation. Consumers of this package are encouraged to use
> the type-aliases from this package instead of directly using their logrus
> equivalent.
>
> The intent is to replace these aliases with locally defined types and
> interfaces once all consumers are no longer directly importing logrus
> types.
>
> IMPORTANT: due to the transitional purpose of this package, it is not
> guaranteed for the full logrus API to be provided in the future. As
> outlined, these aliases are provided as a step to transition away from
> a specific implementation which, as a result, exposes the full logrus API.
> While no decisions have been made on the ultimate design and interface
> provided by this package, we do not expect carrying "less common" features.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `G` variable is exported, and not expected to be overwritten
externally. Defining it as a function also documents it as a function
on https://pkg.go.dev, instead of a variable; https://pkg.go.dev/github.com/containerd/containerd@v1.6.22/log#pkg-variables
Note that (while the godoc suggests otherwise) I made `GetLogger` an alias
for `G`, as `G` is the most commonly used function (not the other way round),
although I don't think there's a performance gain in doing so.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
While other log-levels are not currently used in containerd itself,
they can be returned by `GetLevel()`, and are accepted (no error) by
`SetLevel()`. We should either accept those values, or produce an
error (in `SetLevel()`), but given that there's other ways to set the
log-level, we should probably acknowledge that this package is a transitional
package, and still closely tied to logrus (for the time being).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Testify was only used for a basic assertion. Remove the dependency,
in preparation of (potentially) moving this package to a separate
module.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The rpc only reports one field, i.e. the cgroup driver, to kubelet.
Containerd determines the effective cgroup driver by looking at all
runtime handlers, starting from the default runtime handler (the rest in
alphabetical order), and returning the cgroup driver setting of the
first runtime handler that supports one. If no runtime handler supports
cgroup driver (i.e. has a config option for it) containerd falls back to
auto-detection, returning systemd if systemd is running and cgroupfs
otherwise.
This patch implements the CRI server side of Kubernetes KEP-4033:
https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/4033-group-driver-detection-over-cri
Signed-off-by: Markus Lehtonen <markus.lehtonen@intel.com>
Previously, we would return the first non-404 error from a host.
This is logical, however, it can result in confusing errors to the
user:
- e.g. we have an HTTP host, and an HTTPS host.
If the image does not exist, we return "http: server gave HTTP
response to HTTPS client". This is technically correct, however, the
user is easily confused - the most relevant error in this case is the
404 error.
- e.g. we have a broken HTTP host that returns 5XX errors, and a HTTP
host with authentication.
On the request for an image, we return the 5XX error directly.
However, we have a host later on which returned an authentication
error which is now hidden from the user.
Note: this *can* be resolved by changing the order of hosts passed in,
however this requires 1. knowing ahead of time which hosts are going to
return certain errors and 2. this is often not desirable, we'd prefer
to use HTTPS if it's available, and only then fallback to HTTP.
To resolve this, we assign each possible error during resolution a
"priority" that marks how far through the image resolution process a
host/path combo got. Then we return the error with the highest priority,
which is much more likely to be the most relevant error to the user.
The ranking of priority then is (from lowest to highest):
- Underlying transport errors (TLS, TCP, etc)
- 404 errors
- Other 4XX/5XX errors
- Manifest rejection (due to max size exceeded)
Signed-off-by: Justin Chadwell <me@jedevc.com>
