This commit updates golangci-lint to v1.44.0.
It also removes deprecated golint in favour of revive linter.
Finally, it addresses an issue reported by linter.
Signed-off-by: Milos Gajdos <milosthegajdos@gmail.com>
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>
This commit removes the following cipher suites that are known to be insecure:
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
And this commit deletes the tlsVersions of tls1.0 and tls1.1. The tls1.2 is the minimal supported tls version for creating a safer tls configuration.
Signed-off-by: david.bao <baojn1998@163.com>
This code was outdated and no longer maintained, and mainly
used to pre-flight docs changes before publishing to docs.docker.com
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Allow the storage driver to optionally use AWS SDK's dualstack mode.
This allows the registry to communicate with S3 in IPv6 environments.
Signed-off-by: Adam Kaplan <adam.kaplan@redhat.com>
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>
If you set an env var with non-yaml content but accidentally collides with a possible configuration env var,...
The current error is
```configuration error: error parsing /etc/docker/registry/config.yml: yaml: unmarshal errors:
line 1: cannot unmarshal !!str `tcp://1...` into configuration.Parameters```
With this change we can see at least which is the problematic env var.
Some orchestrators such as docker-compose set env vars on top on user env vars, so debugging can be tricky if you are not passing vars, and the error is pointing you to a problably valid config file.
Signed-off-by: Rober Morales-Chaparro <rober@rstor.io>
Signed-off-by: Rober Morales-Chaparro <rober.morales@ebury.com>
Trevor Wood
Milos Gajdos
CrazyMax
João Pereira
Hayley Swimelar
Sebastiaan van Stijn
Milos Gajdos
baojiangnan
baojiangnan
Paul Cacheux
Usha Mandya
Usha Mandya
libo.huang
Adam Kaplan
Steve Lasker
AdamKorcz
Rober Morales-Chaparro
Rober Morales-Chaparro