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
update golang to 1.17.11
go1.17.11 (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
crypto/tls package. See the Go 1.17.11 milestone on our issue tracker for details.
https://github.com/golang/go/issues?q=milestone%3AGo1.17.11+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>
Go 1.18 is released. Go 1.16 is no longer supported by the Go team.
golangci-lint is updated since 1.44.2 doesn't support Go 1.18.
Signed-off-by: Kazuyoshi Kato <katokazu@amazon.com>
go1.17.3 (released 2021-11-04) includes security fixes to the archive/zip and
debug/macho packages, as well as bug fixes to the compiler, linker, runtime, the
go command, the misc/wasm directory, and to the net/http and syscall packages.
See the Go 1.17.3 milestone on our issue tracker for details.
From the announcement e-mail:
[security] Go 1.17.3 and Go 1.16.10 are released
We have just released Go versions 1.17.3 and 1.16.10, minor point releases.
These minor releases include two security fixes following the security policy:
- archive/zip: don't panic on (*Reader).Open
Reader.Open (the API implementing io/fs.FS introduced in Go 1.16) can be made
to panic by an attacker providing either a crafted ZIP archive containing
completely invalid names or an empty filename argument.
Thank you to Colin Arnott, SiteHost and Noah Santschi-Cooney, Sourcegraph Code
Intelligence Team for reporting this issue. This is CVE-2021-41772 and Go issue
golang.org/issue/48085.
- debug/macho: invalid dynamic symbol table command can cause panic
Malformed binaries parsed using Open or OpenFat can cause a panic when calling
ImportedSymbols, due to an out-of-bounds slice operation.
Thanks to Burak Çarıkçı - Yunus Yıldırım (CT-Zer0 Crypttech) for reporting this
issue. This is CVE-2021-41771 and Go issue golang.org/issue/48990.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
go1.17.2 (released 2021-10-07) includes a security fix to the linker and misc/wasm
directory, as well as bug fixes to the compiler, the runtime, the go command, and
to the time and text/template packages. See the Go 1.17.2 milestone on our issue
tracker for details:
https://github.com/golang/go/issues?q=milestone%3AGo1.17.2+label%3ACherryPickApproved
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Looking at how this image is used, I think we don't even need the
source in the final image, so we can build containerd in a separate
stage, and copy the binaries.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Not critical for intermediate stages, but a minor optimization to
reduce the image cache. Ideally, this would use cache-mounts for this,
but those may not be supported by podman, so taking the traditional
approach.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Building critools only requires the install script and the critools-version
file (to determin the version to build). Moving it to a separate stage
prevents rebuilding it if unrelated changes are made in the code.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Building cni only requires the install script, and the go.mod (to determin
the version to install). Moving it to a separate stage prevents it from
being rebuilt if unrelated changes were made in the codebase.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This allows for easier copying artifacts from stages, by just copying
the directory content to the stage where it's used. These stages are
not used to be run individually so do not have to be "runnable".
Each stage is "responsible" for colllecting all aftifacts in the directory,
so that "consumer" stages do not have to be aware of what needs to be copied.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This makes the following changes:
- The containerd/config.toml, and docker-entrypoint.sh only occasionally change,
so copy them before copying the source code to allow them to be cached.
- The cri-in-userns stage does not need files from proto3, so do not copy them
- The dev environment does need the file from the proto3 stage, so copy them there.
- Change the order of stages. Our CI uses `podman build` which (I think) does not
skips stages that are not used for the specified target (like BuildKit does).
So I moved stages that are not used for the `cri-in-userns` after that stage.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `cri-in-userns` stage is for testing "CRI-in-UserNS", which should be used in conjunction with "Kubelet-in-UserNS":
https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2033-kubelet-in-userns-aka-rootless
This feature is mostly expected to be used for `kind` and `minikube`.
Requires Rootless Docker/Podman/nerdctl with cgroup v2 delegation: https://rootlesscontaine.rs/getting-started/common/cgroup2/
(Rootless Docker/Podman/nerdctl prepares the UserNS, so we do not need to create UserNS by ourselves)
Usage:
```
podman build --target cri-in-userns -t cri-in-userns -f contrib/Dockerfile.test .
podman run -it --rm --privileged cri-in-userns
```
The stage is tested on CI with Rootless Podman on Fedora 34 on Vagrant.
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Note that this is the code in containerd that uses runc (as almost
a library). Please see the other commit for the update to runc binary
itself.
Signed-off-by: Davanum Srinivas <davanum@gmail.com>
This moves the runc version to build to scripts/setup/runc-version,
which makes it easier for packagers to find the default version
to use.
The RUNC_VERSION environment variable can still be used to override
the version, which can be used (e.g.) to test against different versions
in our CI.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Now that the dependency on runc (libcontaienr) code has been reduced
considerably, it is probbaly ok to cut the version dependency between
libcontainer and the runc binary that is supported.
This patch separates the runc binary version from the version of
libcontainer that is defined in go.mod, and updates the documentation
accordingly.
The RUNC_COMMIT variable in the install-runc script is renamed to
RUNC_VERSION to encourage using tagged versions, and the Dockerfile
in contrib is updated to allow building with a custom version.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diff: https://github.com/golang/go/compare/go1.13.6...go1.13.7
go1.13.7 (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.13.7+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>
