Specify base64url rather than base64. Also correct other links to the base64url section of RFC4648
Signed-off-by: Mike Bush <mpbush@gmail.com>
(cherry picked from commit f282dde877)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The latest `ltsc2019` image (`10.0.17763.1039`) appear to be broken,
and even a `RUN Write-Host hello` hangs.
Temporarily switching back to an older version so that CI doesn't fail.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit fa2417984b)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Before the collection goroutine wakes up every 1 second (as configured).
This sleep interval is in case there are no stats to collect we don't
end up in a tight loop.
Instead use a condition variable to signal that a collection is needed.
This prevents us from waking the goroutine needlessly when there is no
one looking for stats.
For now I've kept the sleep just moved it to the end of the loop, which
gives some space between collections.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit e75e6b0e31)
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
The thirteenth patch release for `containerd` 1.2 fixes a regression introduced
in v1.2.12 that caused container/shim to hang on single core machines, fixes an
issue with blkio, and updates the Golang runtime to 1.12.17.
* Fix container pid race condition
* Update containerd/cgroups dependency to address blkio issue
* Set octet-stream content-type on PUT request
* Pin to libseccomp 2.3.3 to preserve compatibility with hosts that do not have libseccomp 2.4 or higher installed
* Update Golang runtime to 1.12.17, which includes a fix to the runtime
full diff: https://github.com/containerd/containerd/compare/v1.2.12...v1.2.13
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Support for these constraints was added in docker 1.13.0
(API v1.25), but never documented.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit ed439e4a31)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Now that we do check if overlay is working by performing an actual
overlayfs mount, there's no need in extra checks for the kernel version
or the filesystem type. Actual mount check is sufficient.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit e226aea280)
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Before this commit, overlay check was performed by looking for
`overlay` in /proc/filesystem. This obviously might not work
for rootless Docker (fs is there, but one can't use it as non-root).
This commit changes the check to perform the actual mount, by reusing
the code previously written to check for multiple lower dirs support.
The old check is removed from both drivers, as well as the additional
check for the multiple lower dirs support in overlay2 since it's now
a part of the main check.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit 649e4c8889)
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
This moves supportsMultipleLowerDir() to overlayutils
so it can be used from both overlay and overlay2.
The only changes made were:
* replace logger with logrus
* don't use workDirName mergedDirName constants
* add mnt var to improve readability a bit
This is a preparation for the next commit.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
(cherry picked from commit d5687079ad)
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
(cherry picked from commit 074eca1d79)
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
`--userland-proxy-path` is automatically set by dockerd: e6c1820ef5/cmd/dockerd/config_unix.go (L46)
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
(cherry picked from commit 9bd1ae024a)
Signed-off-by: Akihiro Suda <akihiro.suda.cz@hco.ntt.co.jp>
full diff: https://github.com/containerd/containerd/compare/v1.2.11...v1.2.12
Welcome to the v1.2.12 release of containerd!
The twelfth patch release for containerd 1.2 includes an updated runc with
a fix for CVE-2019-19921, an updated version of the opencontainers/selinux
dependency, which includes a fix for CVE-2019-16884, an updated version of the
gopkg.in/yaml.v2 dependency to address CVE-2019-11253, and a Golang update.
Notable Updates
- Update the runc vendor to v1.0.0-rc10 which includes a mitigation for CVE-2019-19921.
- Update the opencontainers/selinux which includes a mitigation for CVE-2019-16884.
- Update Golang runtime to 1.12.16, mitigating the CVE-2020-0601 certificate verification
bypass on Windows, and CVE-2020-7919, which only affects 32-bit architectures.
- Update Golang runtime to 1.12.15, which includes a fix to the runtime (Go 1.12.14,
Go 1.12.15) and and the net/http package (Go 1.12.15)
- A fix to prevent SIGSEGV when starting containerd-shim containerd/containerd#3960
- Fixes to exec containerd/containerd#3755
- Prevent docker exec hanging if an earlier docker exec left a zombie process
- Prevent High system load/CPU utilization with liveness and readiness probes
- Prevent Docker healthcheck causing high CPU utilization
CRI fixes:
- Update the gopkg.in/yaml.v2 vendor to v2.2.8 with a mitigation for CVE-2019-11253
API
- Fix API filters to properly handle and return parse errors containerd/containerd#3950
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
full diff: 88737f569e...69ecbb4d6d
Includes 69ecbb4d6d
(forward-port of 8b5121be2f),
which fixes CVE-2020-7919:
- 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.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit b606c8e440)
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>
