golang.org/x/net contains a fix for CVE-2022-41717, which was addressed
in stdlib in go1.19.4 and go1.18.9;
> net/http: limit canonical header cache by bytes, not entries
>
> An attacker can cause excessive memory growth in a Go server accepting
> HTTP/2 requests.
>
> HTTP/2 server connections contain a cache of HTTP header keys sent by
> the client. While the total number of entries in this cache is capped,
> an attacker sending very large keys can cause the server to allocate
> approximately 64 MiB per open connection.
>
> This issue is also fixed in golang.org/x/net/http2 v0.4.0,
> for users manually configuring HTTP/2.
full diff: https://github.com/golang/net/compare/v0.2.0...v0.4.0
other dependency updates (due to (circular) dependencies):
- golang.org/x/sys v0.3.0: https://github.com/golang/sys/compare/3c1f35247d10...v0.3.0
- golang.org/x/text v0.5.0: https://github.com/golang/text/compare/v0.3.7...v0.5.0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This package was only used for the deprecated "shortid" syntax. Now that
support for this syntax was removed, we can also remove this package.
This patch deprecates and removes the package, adding temporary aliases pointing
to the new location to ease migration from docker/distribution to the new
distribution/distribution/v3. We should remove those aliases in a future update.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
We were using v1.0.0 of Cobra as newer versions added spf13/viper as dependency,
which came with many indirect dependencies. Cobra v1.6.0 and up no longer depend
on viper, so we can now safely upgrade to the latest version.
full diff: https://github.com/spf13/cobra/compare/v1.0.0...v1.6.1
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Instead of letting the cache grow without bound, use a LRU to impose a
size limit.
The limit is configurable through a new `blobdescriptorsize` config key.
Signed-off-by: Aaron Lehmann <alehmann@netflix.com>
Go 1.16 reached end of life, so update to the current version of Go, but also
run CI on the previous version (which is still supported).
We should probably also decide wether or not we want the Dockerfiles to pin to
a specific minor version; this makes the releases more deterministic.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This replace rule is to prevent unwanted updates of grpc and jwt-go. When updating
spf13/cobra, we noticed that google.golang.org/grpc got updated.
Doing a search to find which modules (note here that `go mod graph` only looks
at dependencies from a `go modules` perspective, and not all the (current version)
of our dependencies use go modules).
And I found that the only _modules_ depending on it are `github.com/spf13/viper`
and `github.com/grpc-ecosystem/grpc-gateway`:
```bash
$ go mod graph | grep ' google.golang.org/grpc'
github.com/spf13/viper@v1.4.0 google.golang.org/grpc@v1.21.0
github.com/grpc-ecosystem/grpc-gateway@v1.9.0 google.golang.org/grpc@v1.19.0
```
Of those, `github.com/grpc-ecosystem/grpc-gateway` is a dependency of
`github.com/spf13/viper`:
```bash
$ go mod graph | grep ' github.com/grpc-ecosystem/grpc-gateway'
github.com/spf13/viper@v1.4.0 github.com/grpc-ecosystem/grpc-gateway@v1.9.0
```
So looking at that one, it's a dependency of cobra:
```bash
$ go mod graph | grep ' github.com/spf13/viper@v1.4.0'
github.com/spf13/cobra@v1.0.0 github.com/spf13/viper@v1.4.0
```
Ironically, while both `github.com/spf13/viper` and `github.com/grpc-ecosystem/grpc-gateway`,
depend on `google.golang.org/grpc` and (through their `go.mod`) are responsible
for `go mod` to update the dependency version of grpc, none of them are used:
```bash
cat vendor/modules.txt | grep github.com/spf13/viper
cat vendor/modules.txt | grep github.com/grpc-ecosystem/grpc-gateway
```
Unfortunately, `go modules` looks at `go.mod` to determine the *minimum version*
required; _even if the parts of the modules specifying it in the `go.mod` are unused_.
This patch adds a `replace` rule in go.mod to prevent updating grpc based on
other dependencies that _declare_ `google.golang.org/grpc` as a dependency,
but are not used and, hence, should not influence the minumum version.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upgrade the aws golang SDK to 1.42.27 to add the new options for
configuring S3 dualstack endpoints.
Signed-off-by: Adam Kaplan <adam.kaplan@redhat.com>
Newer versions contain fixes for recent Go versions, and this removes
the dependency on github.com/konsorten/go-windows-terminal-sequences
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This updates the package to a version to include the security fixes in v2.2.3.
Version 2.3.0 was known introduce a breaking change for some users, so using
the latest (v2.4.0)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Fixes#3223 by bumping logrus to v1.6.0, which in turn bumps
github.com/konsorten/go-windows-terminal-sequences to v1.0.3
wherein the fix to bad pointer is found.
Signed-off-by: Andreas Hassing <andreas@famhassing.dk>
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>
