On 12/16/2019 3:32 AM, Arnaud Rebillout wrote:
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?
Absolutely, yes, you should, and please reference it in issue #105
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...
It would be wonderful if debian and docker devs could work together to
fix this for real, because the upstream docker behavior is clearly
broken regardless, and I was unable to convince docker devs otherwise.
