We are replacing the very outdated redigo Go module with the official
redis Go module, go-redis.
Signed-off-by: Milos Gajdos <milosthegajdos@gmail.com>
For some reason we let these be ungrouped and mixed all over the place.
This commit groups direct and indirect Go module dependencies.
Signed-off-by: Milos Gajdos <milosthegajdos@gmail.com>
This commit removes `oss` storage driver from distribution as well as
`alicdn` storage middleware which only works with the `oss` driver.
There are several reasons for it:
* no real-life expertise among the maintainers
* oss is compatible with S3 API operations required by S3 storage driver
Signed-off-by: Milos Gajdos <milosthegajdos@gmail.com>
This commit removes swift storage driver from distribution.
There are several reasons for it:
* no real life expertise among the maintainers
* swift is compatible with S3 API operations required by S3 storage driver
This will also remove depedencies that are also hard to keep up with.
Signed-off-by: Milos Gajdos <milosthegajdos@gmail.com>
Co-authored-by: Nicolas De Loof <nicolas.deloof@gmail.com>
Co-authored-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
Microsoft has updated the golang Azure SDK significantly. Update the
azure storage driver to use the new SDK. Add support for client
secret and MSI authentication schemes in addition to shared key
authentication.
Implement rootDirectory support for the azure storage driver to mirror
the S3 driver.
Signed-off-by: Kirat Singh <kirat.singh@beacon.io>
Co-authored-by: Cory Snider <corhere@gmail.com>
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>
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>
Go 1.13 and up enforce import paths to be versioned if a project
contains a go.mod and has released v2 or up.
The current v2.x branches (and releases) do not yet have a go.mod,
and therefore are still allowed to be imported with a non-versioned
import path (go modules add a `+incompatible` annotation in that case).
However, now that this project has a `go.mod` file, incompatible
import paths will not be accepted by go modules, and attempting
to use code from this repository will fail.
This patch uses `v3` for the import-paths (not `v2`), because changing
import paths itself is a breaking change, which means that the
next release should increment the "major" version to comply with
SemVer (as go modules dictate).
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>
