Bug#910822: golang-docker-credential-helpers: headless gnome-keyring failure

[Nye Liu]

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.

Bug#910822: golang-docker-credential-helpers: headless gnome-keyring failure

[Arnaud Rebillout]

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ý , what do you think?

Bug#910822: golang-docker-credential-helpers: headless gnome-keyring failure

[Nye Liu]

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910823

Is there anyone actually maintaining this package?

Bug#910822: golang-docker-credential-helpers: headless gnome-keyring failure

[Nye Liu]

Sorry, missed the rest of the log:

Oct 11 20:07:15  dbus-daemon[29865]: [session uid=1012 pid=29865] 
Activating service name='org.gnome.keyring.SystemPrompter' requested by 
':1.34' (uid=1012 pid=1611 comm="/usr/bin/gnome-keyring-daemon --start 
--foreground")
Oct 11 20:07:15  org.gnome.keyring.SystemPrompter[29865]: Unable to 
init server: Could not connect: Connection refused

Oct 11 20:07:15  gcr-prompter[1783]: cannot open display:
Oct 11 20:07:15  dbus-daemon[29865]: [session uid=1012 pid=29865] 
Activated service 'org.gnome.keyring.SystemPrompter' failed: Process 
org.gnome.keyring.SystemPrompter exited with status 1
Oct 11 20:07:15  gnome-keyring-daemon[1611]: couldn't initialize 
prompt: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: 
Process org.gnome.keyring.SystemPrompter exited with status 1
Oct 11 20:07:15  gnome-keyring-d[1611]: couldn't initialize prompt: 
GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process 
org.gnome.keyring.SystemPrompter exited with status 1

Bug#910822: golang-docker-credential-helpers: headless gnome-keyring failure

[Nye Liu]

Likely due to gnome-keyring needing d-bus to have a DISPLAY:

gnome-keyring-daemon[1611]: couldn't initialize prompt: 
GDBus.Error:org.freedesktop.DBus.Error.Spawn.ChildExited: Process 
org.gnome.keyring.SystemPrompter exited with status 1


This is fundamentally broken with respect to headless systems.