Actually, what is weird is that docker tries to use the secret service
backend, even though it's not instructed to do so.
From the documentation at
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
You need to specify the credentials store in
|$HOME/.docker/config.json| to tell the docker engine to use it. The
value of the config property should be the suffix of the program to
use (i.e. everything after |docker-credential-|).
So installing golang-docker-credential-helpers shouldn't have any
consequence, until you add `"credsStore": "secretservice"` to
`~/.docker/config.json`.
But what I observe is different: from the moment the credential helpers
are installed, docker tries to use it, and fails of course if there's no
display.
Am I missing something here? Should we open a bug upstream regarding
this behavior?
Please fix the dependencies for this package.
https://github.com/docker/docker-credential-helpers/issues/105#issuecomment-561573736
In this thread, some users suggest to add `pass` as a dependency of the
golang-docker-credential-helpers.
I'm not sure it will work, because if you look at the code in
docker-cli, at cli/config/credentials/default_store_linux.go, you will
see that docker gives preference to pass over libsecret. I'm afraid that
if we do that, we break all existing users that rely on libsecret.
Well, unless docker behaved as documented, but apparently it's more
complicated, so I'm a bit reluctant. Adding "Suggests: pass" would be
fine though...
Another possibility would be that the python-docker dependency tree
stops depending on docker-credential-helpers, and instead only Suggests
or Recommends it? I'm not familiar with those packages though, so I
can't say. Ondřej Nový <https://salsa.debian.org/onovy>, what do you think?
