Includes security fixes for crypto/elliptic (CVE-2022-23806), math/big (CVE-2022-23772),
and cmd/go (CVE-2022-23773).
go1.17.7 (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, and net/http/httptest
packages. See the Go 1.17.7 milestone on our issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.17.7+label%3ACherryPickApproved
full diff: https://github.com/golang/go/compare/go1.17.6...go1.17.7
Update Go to 1.17.6
go1.17.6 (released 2022-01-06) includes fixes to the compiler, linker, runtime,
and the crypto/x509, net/http, and reflect packages. See the Go 1.17.6 milestone
on our issue tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.17.6+label%3ACherryPickApproved
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diff: https://github.com/fsnotify/fsnotify/compare/v1.4.9...v1.5.1
Relevant changes:
- Fix unsafe pointer conversion
- Drop support/testing for Go 1.11 and earlier
- Update x/sys to latest
- add //go:build lines
- add go 1.17 to test matrix
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Prior to running the `kube-node-installation.service`, the containerd
installation should be complete as the k8s installation may have
dependencies on containerd and related binaries (e.g ctr). Add
wants/after systemd directives to ensure
`kube-node-installation.service` will only start after containerd
installation completes.
Signed-off-by: David Porter <porterdavid@google.com>
For testing and possibly other operations go might need elevated
permissions. Some parts of documentation and the BUILDING.md mention
using `sudo go` but does not explain how to achieve this. This commit
inserts instructions to the BUILDING.md as a small note. Note mentions
systemwide and local solutions.
Signed-off-by: Mete Durlu <mete.durlu@ibm.com>
I noticed the logo was not correct in dark mode and was hard to see, here is some fancy mark down to make the white logo appear in dark mode and the dark logo appear in light mode
Signed-off-by: James Gordon <james.gordon1628@gmail.com>
The .github/workflows/release/Dockerfile will use working dir as docker
build context. But the .dockerignore will ignore the .github/release/...
and cause dirty. We should remove it and verify git working tree after
build.
Fix: #6484
Signed-off-by: Wei Fu <fuweid89@gmail.com>
For some runtimes, the container is not ready for exec until the
initial container task has been started (as opposed to just having the task created).
More specifically, running containerd-stress with --exec would break
with Kata Container shim, since the sandbox is not created until a
start is issued. By starting the container's primary task before adding
exec's, we can avoid:
```
error="cannot enter container exec-container-1, with err Sandbox not running, impossible to enter the container: unknown"
```
Signed-off-by: Eric Ernst <eric_ernst@apple.com>
With the release of hcsshim v0.9.2, this test should pass without
issues on Windows.
Signed-off-by: Gabriel Adrian Samfira <gsamfira@cloudbasesolutions.com>
We were not properly ignoring errors from
gorestrl.rdt.ContainerClassFromAnnotations() causing the config option
to be ineffective, in practice.
Signed-off-by: Markus Lehtonen <markus.lehtonen@intel.com>
With the cgroupv2 configuration employed by Kubernetes, the pod cgroup (slice)
and container cgroup (scope) will both have the same memory limit applied. In
that situation, the kernel will consider an OOM event to be triggered by the
parent cgroup (slice), and increment 'oom' there. The child cgroup (scope) only
sees an oom_kill increment. Since we monitor child cgroups for oom events,
check the OOMKill field so that we don't miss events.
This is not visible when running containers through docker or ctr, because they
set the limits differently (only container level). An alternative would be to
not configure limits at the pod level - that way the container limit will be
hit and the OOM will be correctly generated. An interesting consequence is that
when spawning a pod with multiple containers, the oom events also work
correctly, because:
a) if one of the containers has no limit, the pod has no limit so OOM events in
another container report correctly.
b) if all of the containers have limits then the pod limit will be a sum of
container events, so a container will be able to hit its limit first.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
When the cgroup is removed, EventChan is closed (this was pulled in by
8d69c041c5). This results in a nil error
being received. Don't log an error in that case but instead return.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
