Test case for d3f6867e4d
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 3c78069240)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was names slightly confusing, as it returns a fakeStore,
and it didn't do any constructing, so didn't provide value above just
constructing the type.
I'm planning to add more functionality to the fakeStore, but don't want
to maintain a full-fledged constructor for all of that, so let's remove
this utility.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 0dd6f7f1b3)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Before this change, the config-file was always updated, even if there
were no changes to save. This could cause issues when the config-file
already had credentials set and was read-only for the current user.
For example, on NixOS, this poses a problem because `config.json` is a
symlink to a write-protected file;
$ readlink ~/.docker/config.json
/home/username/.config/sops-nix/secrets/ghcr_auth
$ readlink -f ~/.docker/config.json
/run/user/1000/secrets.d/28/ghcr_auth
Which causes `docker login` to fail, even if no changes were to be made;
Error saving credentials: rename /home/derek/.docker/config.json2180380217 /home/username/.config/sops-nix/secrets/ghcr_auth: invalid cross-device link
This patch updates the code to only update the config file if changes
were detected. It there's nothing to save, it skips updating the file,
as well as skips printing the warning about credentials being stored
insecurely.
With this patch applied:
$ docker login -u yourname
Password:
WARNING! Your credentials are stored unencrypted in '/root/.docker/config.json'.
Configure a credential helper to remove this warning. See
https://docs.docker.com/go/credential-store/
Login Succeeded
$ docker login -u yourname
Password:
Login Succeeded
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit d3f6867e4d)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 27b2797f7d added a local implementation
of this function, so let's use the local variant to (slightly) reduce the
dependency on moby's registry package.
Also made some minor cleanups.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This will return the ServerAddress property when using the NativeStore.
This happens when you use docker credential helpers, not the credential
store.
The reason this fix is needed is because it needs to be propagated
properly down towards `moby/moby` project in the following logic:
```golang
func authorizationCredsFromAuthConfig(authConfig registrytypes.AuthConfig) docker.AuthorizerOpt {
cfgHost := registry.ConvertToHostname(authConfig.ServerAddress)
if cfgHost == "" || cfgHost == registry.IndexHostname {
cfgHost = registry.DefaultRegistryHost
}
return docker.WithAuthCreds(func(host string) (string, string, error) {
if cfgHost != host {
logrus.WithFields(logrus.Fields{
"host": host,
"cfgHost": cfgHost,
}).Warn("Host doesn't match")
return "", "", nil
}
if authConfig.IdentityToken != "" {
return "", authConfig.IdentityToken, nil
}
return authConfig.Username, authConfig.Password, nil
})
}
```
This logic resides in the following file :
`daemon/containerd/resolver.go` .
In the case when using the containerd storage feature when setting the
`cfgHost` variable from the `authConfig.ServerAddress` it will always be
empty. Since it will never be returned from the NativeStore currently.
Therefore Docker Hub images will work fine, but anything else will fail
since the `cfgHost` will always be the `registry.DefaultRegistryHost`.
Signed-off-by: Eric Bode <eric.bode@foundries.io>
Initialize AuthConfigs map if it's nil before returning it.
This fixes fileStore.Store nil dereference panic when adding a new key
to the map.
Signed-off-by: Danial Gharib <danial.mail.gh@gmail.com>
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
the "golang.org/x/sys/execabs" package was introduced to address a security
issue on Windows, and changing the default behavior of os/exec was considered
a breaking change. go1.19 applied the behavior that was previously implemented
in the execabs package;
from the release notes: https://go.dev/doc/go1.19#os-exec-path
> Command and LookPath no longer allow results from a PATH search to be found
> relative to the current directory. This removes a common source of security
> problems but may also break existing programs that depend on using, say,
> exec.Command("prog") to run a binary named prog (or, on Windows, prog.exe)
> in the current directory. See the os/exec package documentation for information
> about how best to update such programs.
>
> On Windows, Command and LookPath now respect the NoDefaultCurrentDirectoryInExePath
> environment variable, making it possible to disable the default implicit search
> of “.” in PATH lookups on Windows systems.
With those changes, we no longer need to use the execabs package, and we can
switch back to os/exec.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
defaultCredentialsStore() on Linux does an exec.LookPath() for "pass", but
if a custom credential-store is passed to DetectDefaultStore, the result
of that won't be used.
This patch changes the logic to return early if a custom credential-store
is passed.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Some tests were using domain names that were intended to be "fake", but are
actually registered domain names (such as mycorp.com).
Even though we were not actually making connections to these domains, it's
better to use domains that are designated for testing/examples in RFC2606:
https://tools.ietf.org/html/rfc2606
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
On Windows, the os/exec.{Command,CommandContext,LookPath} functions
resolve command names that have neither path separators nor file extension
(e.g., "git") by first looking in the current working directory before
looking in the PATH environment variable.
Go maintainers intended to match cmd.exe's historical behavior.
However, this is pretty much never the intended behavior and as an abundance of precaution
this patch prevents that when executing commands.
Example of commands that docker.exe may execute: `git`, `docker-buildx` (or other cli plugin), `docker-credential-wincred`, `docker`.
Note that this was prompted by the [Go 1.15.7 security fixes](https://blog.golang.org/path-security), but unlike in `go.exe`,
the windows path lookups in docker are not in a code path allowing remote code execution, thus there is no security impact on docker.
Signed-off-by: Tibor Vass <tibor@docker.com>
'CheckInitialized' in the credential-helper library actually invokes
`pass`, which isn't desirable (see #699).
This moves the check to be simpler, and then pass will only be invoked
when it's needed (such as for `docker login` or when pulling from a
private registry).
This logic could also reasonably live in the credential-helper library,
but it's simple enough it seems fine in either location.
Signed-off-by: Euan Kemp <euank@euank.com>
Sebastiaan van Stijn
Carston Schilds
Eric Bode
Danial
Sebastiaan van Stijn
Tibor Vass
Tonis Tiigi
Euan Kemp
Vincent Demeester
Daniel Nephin
Ivan Markin
Tycho Andersen
Daniel Nephin