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>
