Bug#800617: Fails to provide secrets

[Dmitry Shachnev]

Hi Mikhail,

On Mon, 19 Oct 2015 13:38:38 +0200, Mikhail Morfikov wrote:
> I can confirm that the behavior has changed with the new version of the gnome-
> keyring package. I downgraded the gnupg packages as well, so I could check
> whether the new version of gnome-keyring works.
>
> I still get the following messages when I type ssh command into a terminal:
>
> Oct 19 13:23:41 morfikownia gnome-keyring-daemon[5140]: The Secret Service was
> already initialized
> Oct 19 13:23:41 morfikownia org.freedesktop.secrets[5189]:
> SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
>
> There's also the lag.

I don't want to reopen this bug for the third time, and the symptoms you are
experiencing differ from those of the original bug submitter.

Can you please file a new bug for that? If you forward it upstream, that would
make it even better.

Thanks!

--
Dmitry Shachnev

signature.asc
Description: OpenPGP digital signature

Bug#800617: Fails to provide secrets

[Mikhail Morfikov]

Package: gnome-keyring
Version: 3.18.1-1
Followup-For: Bug #800617

I can confirm that the behavior has changed with the new version of the gnome-
keyring package. I downgraded the gnupg packages as well, so I could check
whether the new version of gnome-keyring works.

I still get the following messages when I type ssh command into a terminal:

Oct 19 13:23:41 morfikownia gnome-keyring-daemon[5140]: The Secret Service was
already initialized
Oct 19 13:23:41 morfikownia org.freedesktop.secrets[5189]:
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

There's also the lag.

The order of issuing commands (ssh or gajim) doesn't matter now, and ssh
command always gets the lag, whereas gajim works just fine all the time.

That't the only difference I can observe.

Bug#800617: Fails to provide secrets

[Mikhail Morfikov]

Package: gnome-keyring
Followup-For: Bug #800617

I can do it.

Bug#800617: Fails to provide secrets

[Andreas Kurth]

Package: gnome-keyring
Version: 3.18.0-4
Followup-For: Bug #800617

Hi,

for me this bug is not fixed.

I use gnome-keyring to store SVN credentials. When calling "svn up" or
other server related commands, svn waits endlessly without returning.

This behaviour was introduced with 3.18.0-1 and can be "fixed" by
downgrading to 3.16.0-4.

Please advise how I can help debugging the issue.


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.3 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-keyring depends on:
ii  dbus-x11 1.10.0-3
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gcr  3.18.0-1
ii  libc62.19-22
ii  libcap-ng0   0.7.7-1
ii  libcap2-bin  1:2.24-12
ii  libgck-1-0   3.18.0-1
ii  libgcr-base-3-1  3.18.0-1
ii  libgcrypt20  1.6.3-2
ii  libglib2.0-0 2.46.0-2
ii  p11-kit  0.23.1-3
ii  pinentry-gnome3  0.9.6-2

Versions of packages gnome-keyring recommends:
ii  libpam-gnome-keyring  3.18.0-4

gnome-keyring suggests no packages.

-- no debconf information

Processed: Re: Bug#800617: Fails to provide secrets

[Debian Bug Tracking System]

Processing control commands:

> reopen -1
Bug #800617 {Done: Dmitry Shachnev } [gnome-keyring] Fails 
to provide secrets
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions gnome-keyring/3.18.0-3.
> notfixed -1 gnome-keyring/3.18.0-3
Bug #800617 [gnome-keyring] Fails to provide secrets
Ignoring request to alter fixed versions of bug #800617 to the same values 
previously set

-- 
800617: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800617
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#800617: Fails to provide secrets

[Dmitry Shachnev]

Control: reopen -1
Control: notfixed -1 gnome-keyring/3.18.0-3

Hi Andreas,

On Wed, Oct 14, 2015 at 12:29:57PM +0200, Andreas Kurth wrote:
> Hi,
> 
> for me this bug is not fixed.
> 
> I use gnome-keyring to store SVN credentials. When calling "svn up" or
> other server related commands, svn waits endlessly without returning.
> 
> This behaviour was introduced with 3.18.0-1 and can be "fixed" by
> downgrading to 3.16.0-4.
> 
> Please advise how I can help debugging the issue.

Thanks for the confirmation. I have notified the upstream developers that
the new patch still does not fix the bug.

I am trying to do my best to get it fixed, but please try to stick to
the testing version if the unstable one is broken for you.

--
Dmitry Shachnev

Bug#800617: Fails to provide secrets

[Mikhail Morfikov]

Package: gnome-keyring
Version: 3.18.0-4
Followup-For: Bug #800617

It looks like the patch doesn't work either -- it's the exact same situation.
But there's another thing that can be helpful.

There's another bug (#796931) in debian concerning the gnupg-agent package.
When I first installed the sid version of that package, I was unable to access
my ssh keys at all. After switching to the testing version of the following
packages: gnupg-agent gnupg2 gpgsm scdaemon , the issue disappeared, so I was
using the testing version of the packages all the time.

When I noticed the problems with gnome-keyring, I didn't even realize that the
two things could be connected in some way. But it looks like they are.

First of all, I upgraded the packages in question. Then I did the trick
described in the aforementioned bug, which was to add some code to the
..bashrc/.zshrc file:

if [ "$PS1" ]; then
unset GPG_AGENT_INFO
unset SSH_AGENT_PID
if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
  export SSH_AUTH_SOCK="${HOME}/.gnupg/S.gpg-agent.ssh"
fi
fi
export GPG_TTY=`tty`

After reboot, the message "The Secret Service was already initialized" in the
log disappeared. Running gajim and ssh command in the same session no longer
gives the lag when executing the second application. There's no error/messages
in the log, and my ssh keys work just fine.

Bug#800617: Fails to provide secrets

[Mikhail Morfikov]

Package: gnome-keyring
Version: 3.18.0-2
Followup-For: Bug #800617

Another observation that can prove useful.

First of all, the process that spawns along with my openbox (/usr/bin/gnome-
keyring-daemon --daemonize --login) lives about 2 minutes, not one minute --
I've just measured it. When it's gone, the /run/user/1000/keyring/ directory
also disappears.

The next thing concerns opening, for instance gajim, when the process
disappeared. In that case, I get a password prompt in order to unlock the
keyring, and also bunch of logs (http://pastebin.com/GrqQA6gy).

After entering the password, the keyring is unlocked and the app starts
normally without asking for any other passwords. There's just one process
concerning gnome-keyring:

$ ps aux | grep gnome
morfik98603  0.0  0.3 216092  5784 ?Sl   14:14   0:00 /usr/lib/at-
spi2-core/at-spi2-registryd --use-gnome-session
morfik   100411  0.0  0.4 352536  8096 ?SLl  14:17   0:00 /usr/bin
/gnome-keyring-daemon --start --foreground --components=secrets

The rest of issues that I described earlier stay the same.

Bug#800617: Fails to provide secrets

[Mikhail Morfikov]

Package: gnome-keyring
Version: 3.18.0-2
Followup-For: Bug #800617

I've just upgraded the gnome-keyring package, and I think that didn't solve my
issues. I think it's the same situation as it was before, but there's another
thing worth mentioning.

When my openbox starts I have the following processes:

$ ps aux | grep gnome
morfik16743  0.0  0.0 122748   516 ?Sl   09:52   0:00 /usr/bin
/gnome-keyring-daemon --daemonize --login
morfik16891  0.0  0.2 216104  5676 ?Sl   09:52   0:00 /usr/lib/at-
spi2-core/at-spi2-registryd --use-gnome-session

When I do nothing, after a minute or so, the first process disappears. I'm not
sure whether this should happen or not, so I'm just sharing my observations
with you.

Anyways, I have two apps that I often use: gajim and ssh. When I type in a
terminal "gajim" after logging into my system, everything works just fine. I
mean the above processes stay the same, and there's no lag when the app starts.
I don't have to type any passwords manually in order to log into my jabber
accounts, so the keyring works. When I close the app and reopen it again, it
also works as expected. The problem is when I want to issue ssh command -- I
get lag here and the message in the log:

Oct 08 09:53:47 morfikownia gnome-keyring-daemon[16743]: The Secret Service was
already initialized

Still, gajim (when restarted) works just fine, but issuing ssh command again
gives the lag. It looks like they're separated somehow.

The funniest thing is that when I switch the order of issuing the two commands,
so in this case the ssh command would be the fist one after login, it works
just fine, with no lag and any message in the log. But when I start gajim after
that, there's a lag and the message in the log, and of course password prompts.

So it looks like there's just only one process (the first one started after
login) that can work just fine with gnome-keyring, and the others get a lag
when started.

Another observation is that I get doubled process when the lagged application
is starting:

$ ps aux | grep gnome
morfik16743  0.0  0.3 205072  7292 ?Sl   09:52   0:00 /usr/bin
/gnome-keyring-daemon --daemonize --login
morfik16891  0.0  0.2 216104  5676 ?Sl   09:52   0:00 /usr/lib/at-
spi2-core/at-spi2-registryd --use-gnome-session
morfik17825  0.0  0.2  48992  4260 ?S09:53   0:00 /usr/bin
/gnome-keyring-daemon --start --foreground --components=secrets
morfik17933  0.0  0.2  48992  4268 ?S09:53   0:00 /usr/bin
/gnome-keyring-daemon --start --foreground --components=secrets

The doubled process (17933) disappears after a minute or so.

I was testing this with and without the autostart files, and it's the same in
both cases.



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-keyring depends on:
ii  dbus-x11 1.10.0-3
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gcr  3.16.0-1
ii  libc62.19-22
ii  libcap-ng0   0.7.7-1
ii  libcap2-bin  1:2.24-12
ii  libgck-1-0   3.16.0-1
ii  libgcr-base-3-1  3.16.0-1
ii  libgcrypt20  1.6.3-2
ii  libglib2.0-0 2.46.0-2
ii  p11-kit  0.23.1-3
ii  pinentry-gnome3  0.9.6-2

Versions of packages gnome-keyring recommends:
ii  libpam-gnome-keyring  3.18.0-2

gnome-keyring suggests no packages.

-- Configuration Files:
/etc/xdg/autostart/gnome-keyring-pkcs11.desktop [Errno 2] No such file or 
directory: u'/etc/xdg/autostart/gnome-keyring-pkcs11.desktop'
/etc/xdg/autostart/gnome-keyring-secrets.desktop [Errno 2] No such file or 
directory: u'/etc/xdg/autostart/gnome-keyring-secrets.desktop'
/etc/xdg/autostart/gnome-keyring-ssh.desktop [Errno 2] No such file or 
directory: u'/etc/xdg/autostart/gnome-keyring-ssh.desktop'

-- no debconf information

Bug#800617: Fails to provide secrets

[Michael Biebl]

Am 08.10.2015 um 10:25 schrieb Mikhail Morfikov:
> Package: gnome-keyring
> Version: 3.18.0-2
> Followup-For: Bug #800617
> 
> I've just upgraded the gnome-keyring package, and I think that didn't solve my
> issues. I think it's the same situation as it was before, but there's another
> thing worth mentioning.

...

> -- Configuration Files:
> /etc/xdg/autostart/gnome-keyring-pkcs11.desktop [Errno 2] No such file or 
> directory: u'/etc/xdg/autostart/gnome-keyring-pkcs11.desktop'
> /etc/xdg/autostart/gnome-keyring-secrets.desktop [Errno 2] No such file or 
> directory: u'/etc/xdg/autostart/gnome-keyring-secrets.desktop'
> /etc/xdg/autostart/gnome-keyring-ssh.desktop [Errno 2] No such file or 
> directory: u'/etc/xdg/autostart/gnome-keyring-ssh.desktop'

If you removed the autostart files, I don't see how gnome-keyring can
work properly.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#800617: Fails to provide secrets

[Dmitry Shachnev]

Hi Mikhail,

On Thu, 08 Oct 2015 10:25:43 +0200, Mikhail Morfikov wrote:
> I've just upgraded the gnome-keyring package, and I think that didn't solve my
> issues. I think it's the same situation as it was before, but there's another
> thing worth mentioning.
[...]

Thanks for the feedback, I have forwarded a link to your comment to upstream
developers (see the linked upstream bug). I hope they will look at it shortly.

If someone else can confirm that this bug is not fixed for them, feel free to
reopen it. There is anyway another RC bug (#800660) that prevents gnome-keyring
from migration to testing.

--
Dmitry Shachnev

signature.asc
Description: OpenPGP digital signature

Bug#800617: Fails to provide secrets

[Mikhail Morfikov]

Package: gnome-keyring
Version: 3.18.0-2
Followup-For: Bug #800617

I explicitly said: "I was testing this with and without the autostart files,
and it's the same in both cases."



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-keyring depends on:
ii  dbus-x11 1.10.0-3
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gcr  3.16.0-1
ii  libc62.19-22
ii  libcap-ng0   0.7.7-1
ii  libcap2-bin  1:2.24-12
ii  libgck-1-0   3.16.0-1
ii  libgcr-base-3-1  3.16.0-1
ii  libgcrypt20  1.6.3-2
ii  libglib2.0-0 2.46.0-2
ii  p11-kit  0.23.1-3
ii  pinentry-gnome3  0.9.6-2

Versions of packages gnome-keyring recommends:
ii  libpam-gnome-keyring  3.18.0-2

gnome-keyring suggests no packages.

-- no debconf information

Bug#800617: Fails to provide secrets

[peter]

On Sat, 03 Oct 2015 22:04:21 +0200 Mikhail Morfikov 
 wrote:

> Package: gnome-keyring
> Version: 3.18.0-1
> Followup-For: Bug #800617

> So I upgraded everything to sid version as it was before, and then I
> noticed that there's a new version of config files in
> /etc/xdg/autostart/ -- those with gnome* in their name. I had also
> some files in the ~/.config/autostart/ directory, so I removed them
> completely. After reboot, everything seems to be working as it supposed
> to.
>


Thanks for the information

After upgrading I removed  3 /etc/xdg/autostart/ -- those with gnome* in 
their name files


I did not have any  ~/.config/autostart/  files applicable to gnome*

I too seem to have everything ok now with browser and shutdown

cheers

Peter

Bug#800617: Fails to provide secrets

[Peter Newey]

Package: gnome-keyring
Version: 3.18.0-1
Followup-For: Bug #800617

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***



-- System Information:
Debian Release: stretch/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.2-towo.1-siduction-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-keyring depends on:
ii  dbus-x11 1.10.0-3
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gcr  3.16.0-1
ii  libc62.19-22
ii  libcap-ng0   0.7.7-1
ii  libcap2-bin  1:2.24-12
ii  libgck-1-0   3.16.0-1
ii  libgcr-base-3-1  3.16.0-1
ii  libgcrypt20  1.6.3-2
ii  libglib2.0-0 2.46.0-2
ii  p11-kit  0.23.1-3
ii  pinentry-gnome3  0.9.5-4

Versions of packages gnome-keyring recommends:
ii  libpam-gnome-keyring  3.18.0-1

gnome-keyring suggests no packages.









I have exactly the same log messages

my problems using this update are :

1. my cinnamon desktop takes longer to open

2. my chromium browser takes much longer to open up to a web page

3. when I shut down my computer with systemctl shutdown I get " a stop job is
running for session c1 of user peter " which takes 90 seconds to clear .

none of these problems exist when I return to gnome-keyring_3.16.0-4_amd64.deb

cheers

Peter

Bug#800617: Fails to provide secrets

[Mikhail Morfikov]

Package: gnome-keyring
Version: 3.18.0-1
Followup-For: Bug #800617

I had similar issue after today's upgrade. The package gnome-keyring
was upgraded as well, so I thought it could be involved. The first
thing I noted after upgrade was the lag when I was running ssh command
-- after 10-15s I was able to enter password unlocking my ssh keys. Besides
that, everything seemed to be right except the following log in the
journal:

gnome-keyring-daemon[2185]: The Secret Service was already initialized
org.freedesktop.secrets[2234]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh

I downgraded the gnome-keyring package to the testing version, but the
lag didn't disappear. I tried to downgrade every package with the
version of 3.18.0-1, but that also didn't help.

So I upgraded everything to sid version as it was before, and then I
noticed that there's a new version of config files in
/etc/xdg/autostart/ -- those with gnome* in their name. I had also
some files in the ~/.config/autostart/ directory, so I removed them
completely. After reboot, everything seems to be working as it supposed
to.

I get the following processes, when my openbox starts:

$ ps aux | grep gnome
morfik 2223  0.0  0.1 122748  2776 ?Sl   21:39   0:00 /usr/bin
/gnome-keyring-daemon --daemonize --login
morfik 2401  0.0  0.3 216104  5780 ?Sl   21:39   0:00 /usr/lib/at-
spi2-core/at-spi2-registryd --use-gnome-session

When I issue ssh command, I get the prompt for the password without any
lag. There's also another process:

$ ps aux | grep gnome
morfik 2223  0.0  0.3 205072  6520 ?Sl   21:39   0:00 /usr/bin
/gnome-keyring-daemon --daemonize --login
morfik 2401  0.0  0.3 216104  5780 ?Sl   21:39   0:00 /usr/lib/at-
spi2-core/at-spi2-registryd --use-gnome-session
morfik 3322  0.0  0.2  48992  4172 ?S21:40   0:00 /usr/bin
/gnome-keyring-daemon --start --foreground --components=secrets



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (130, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.2.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-keyring depends on:
ii  dbus-x11 1.10.0-3
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gcr  3.16.0-1
ii  libc62.19-22
ii  libcap-ng0   0.7.7-1
ii  libcap2-bin  1:2.24-12
ii  libgck-1-0   3.16.0-1
ii  libgcr-base-3-1  3.16.0-1
ii  libgcrypt20  1.6.3-2
ii  libglib2.0-0 2.46.0-2
ii  p11-kit  0.23.1-3
ii  pinentry-gnome3  0.9.6-1

Versions of packages gnome-keyring recommends:
ii  libpam-gnome-keyring  3.18.0-1

gnome-keyring suggests no packages.

-- no debconf information

Bug#800617: Fails to provide secrets

[Josh Triplett]

Package: gnome-keyring
Version: 3.18.0-1
Severity: grave

Since upgrading gnome-keyring from 3.16.0-4 to 3.18.0-1, applications
trying to retrieve secrets from gnome-keyring no longer can.  I see log
messages like the following:

Oct 01 10:36:37 jtriplet-mobl1 gnome-keyring-daemon[5801]: couldn't access 
control socket: /run/user/1000/keyring/control: No such file or directory
Oct 01 10:36:37 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't access 
control socket: /run/user/1000/keyring/control: No such file or directory
Oct 01 10:36:37 jtriplet-mobl1 gnome-keyring-daemon[5803]: couldn't access 
control socket: /run/user/1000/keyring/control: No such file or directory
Oct 01 10:36:37 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't access 
control socket: /run/user/1000/keyring/control: No such file or directory
[...]
Oct 01 10:36:38 jtriplet-mobl1 gnome-keyring-daemon[5808]: couldn't register in 
session: Timeout was reached
Oct 01 10:36:38 jtriplet-mobl1 gnome-keyring-daemon[5803]: couldn't communicate 
with already running daemon: Timeout was reached
Oct 01 10:36:38 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't 
communicate with already running daemon: Timeout was reached
Oct 01 10:36:38 jtriplet-mobl1 gnome-session[5731]: 
SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
Oct 01 10:36:39 jtriplet-mobl1 gnome-keyring-daemon[5844]: couldn't register in 
session: Timeout was reached
[...]
Oct 01 10:37:03 jtriplet-mobl1 gnome-keyring-daemon[5808]: couldn't request 
name 'org.freedesktop.secrets' on session bus: Timeout was reached
[...]
Oct 01 10:48:34 jtriplet-mobl1 org.gnome.evolution.dataserver.Sources4[5783]: 
server_side_source_credentials_lookup_cb: Failed to lookup password: Error 
calling StartServiceByName for org.freedesktop.secrets: Timeout was reached
Oct 01 10:48:35 jtriplet-mobl1 org.gnome.seahorse.Application[5783]: 
(seahorse:8293): seahorse-WARNING **: gkr-backend.vala:85: couldn't connect to 
secret service: Error calling StartServiceByName for org.freedesktop.secrets: 
Timeout was reached

In addition to that, it also looks like every time an application tries to
access the org.freedesktop.secrets service, dbus spawns an instance of
gnome-keyring with the --foreground option, likely based on
/usr/share/dbus-1/services/org.freedesktop.secrets.service ; does this conflict
with the instance already run via /etc/xdg/autostart?

- Josh Triplett

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-keyring depends on:
ii  dbus-x11 1.10.0-3
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gcr  3.16.0-1
ii  libc62.19-22
ii  libcap-ng0   0.7.7-1
ii  libcap2-bin  1:2.24-11
ii  libgck-1-0   3.16.0-1
ii  libgcr-base-3-1  3.16.0-1
ii  libgcrypt20  1.6.3-2
ii  libglib2.0-0 2.46.0-2
ii  p11-kit  0.23.1-3
ii  pinentry-gnome3  0.9.5-4

Versions of packages gnome-keyring recommends:
ii  libpam-gnome-keyring  3.18.0-1

gnome-keyring suggests no packages.

-- no debconf information

Processed: Re: Bug#800617: Fails to provide secrets

[Debian Bug Tracking System]

Processing control commands:

> tags -1 moreinfo unreproducible
Bug #800617 [gnome-keyring] Fails to provide secrets
Added tag(s) unreproducible and moreinfo.

-- 
800617: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800617
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#800617: Fails to provide secrets

[Michael Biebl]

Control: tags -1 moreinfo unreproducible

Am 01.10.2015 um 19:54 schrieb Josh Triplett:
> Package: gnome-keyring
> Version: 3.18.0-1
> Severity: grave
> 
> Since upgrading gnome-keyring from 3.16.0-4 to 3.18.0-1, applications
> trying to retrieve secrets from gnome-keyring no longer can.  I see log
> messages like the following:
> 
> Oct 01 10:36:37 jtriplet-mobl1 gnome-keyring-daemon[5801]: couldn't access 
> control socket: /run/user/1000/keyring/control: No such file or directory
> Oct 01 10:36:37 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't 
> access control socket: /run/user/1000/keyring/control: No such file or 
> directory
> Oct 01 10:36:37 jtriplet-mobl1 gnome-keyring-daemon[5803]: couldn't access 
> control socket: /run/user/1000/keyring/control: No such file or directory
> Oct 01 10:36:37 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't 
> access control socket: /run/user/1000/keyring/control: No such file or 
> directory
> [...]
> Oct 01 10:36:38 jtriplet-mobl1 gnome-keyring-daemon[5808]: couldn't register 
> in session: Timeout was reached
> Oct 01 10:36:38 jtriplet-mobl1 gnome-keyring-daemon[5803]: couldn't 
> communicate with already running daemon: Timeout was reached
> Oct 01 10:36:38 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't 
> communicate with already running daemon: Timeout was reached
> Oct 01 10:36:38 jtriplet-mobl1 gnome-session[5731]: 
> SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
> Oct 01 10:36:39 jtriplet-mobl1 gnome-keyring-daemon[5844]: couldn't register 
> in session: Timeout was reached
> [...]
> Oct 01 10:37:03 jtriplet-mobl1 gnome-keyring-daemon[5808]: couldn't request 
> name 'org.freedesktop.secrets' on session bus: Timeout was reached
> [...]
> Oct 01 10:48:34 jtriplet-mobl1 org.gnome.evolution.dataserver.Sources4[5783]: 
> server_side_source_credentials_lookup_cb: Failed to lookup password: Error 
> calling StartServiceByName for org.freedesktop.secrets: Timeout was reached
> Oct 01 10:48:35 jtriplet-mobl1 org.gnome.seahorse.Application[5783]: 
> (seahorse:8293): seahorse-WARNING **: gkr-backend.vala:85: couldn't connect 
> to secret service: Error calling StartServiceByName for 
> org.freedesktop.secrets: Timeout was reached
> 
> In addition to that, it also looks like every time an application tries to
> access the org.freedesktop.secrets service, dbus spawns an instance of
> gnome-keyring with the --foreground option, likely based on
> /usr/share/dbus-1/services/org.freedesktop.secrets.service ; does this 
> conflict
> with the instance already run via /etc/xdg/autostart?
> 

Works fine here. Is this maybe a D-Bus problem? Do you use
dbus-user-session/kdbus? Any custom config?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#800617: Fails to provide secrets

[Josh Triplett]

On Fri, Oct 02, 2015 at 12:39:36AM +0200, Michael Biebl wrote:
> Control: tags -1 moreinfo unreproducible
> 
> Am 01.10.2015 um 19:54 schrieb Josh Triplett:
> > Package: gnome-keyring
> > Version: 3.18.0-1
> > Severity: grave
> > 
> > Since upgrading gnome-keyring from 3.16.0-4 to 3.18.0-1, applications
> > trying to retrieve secrets from gnome-keyring no longer can.  I see log
> > messages like the following:
> > 
> > Oct 01 10:36:37 jtriplet-mobl1 gnome-keyring-daemon[5801]: couldn't access 
> > control socket: /run/user/1000/keyring/control: No such file or directory
> > Oct 01 10:36:37 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't 
> > access control socket: /run/user/1000/keyring/control: No such file or 
> > directory
> > Oct 01 10:36:37 jtriplet-mobl1 gnome-keyring-daemon[5803]: couldn't access 
> > control socket: /run/user/1000/keyring/control: No such file or directory
> > Oct 01 10:36:37 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't 
> > access control socket: /run/user/1000/keyring/control: No such file or 
> > directory
> > [...]
> > Oct 01 10:36:38 jtriplet-mobl1 gnome-keyring-daemon[5808]: couldn't 
> > register in session: Timeout was reached
> > Oct 01 10:36:38 jtriplet-mobl1 gnome-keyring-daemon[5803]: couldn't 
> > communicate with already running daemon: Timeout was reached
> > Oct 01 10:36:38 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't 
> > communicate with already running daemon: Timeout was reached
> > Oct 01 10:36:38 jtriplet-mobl1 gnome-session[5731]: 
> > SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
> > Oct 01 10:36:39 jtriplet-mobl1 gnome-keyring-daemon[5844]: couldn't 
> > register in session: Timeout was reached
> > [...]
> > Oct 01 10:37:03 jtriplet-mobl1 gnome-keyring-daemon[5808]: couldn't request 
> > name 'org.freedesktop.secrets' on session bus: Timeout was reached
> > [...]
> > Oct 01 10:48:34 jtriplet-mobl1 
> > org.gnome.evolution.dataserver.Sources4[5783]: 
> > server_side_source_credentials_lookup_cb: Failed to lookup password: Error 
> > calling StartServiceByName for org.freedesktop.secrets: Timeout was reached
> > Oct 01 10:48:35 jtriplet-mobl1 org.gnome.seahorse.Application[5783]: 
> > (seahorse:8293): seahorse-WARNING **: gkr-backend.vala:85: couldn't connect 
> > to secret service: Error calling StartServiceByName for 
> > org.freedesktop.secrets: Timeout was reached
> > 
> > In addition to that, it also looks like every time an application tries to
> > access the org.freedesktop.secrets service, dbus spawns an instance of
> > gnome-keyring with the --foreground option, likely based on
> > /usr/share/dbus-1/services/org.freedesktop.secrets.service ; does this 
> > conflict
> > with the instance already run via /etc/xdg/autostart?
> > 
> 
> Works fine here. Is this maybe a D-Bus problem? Do you use
> dbus-user-session/kdbus? Any custom config?

No custom configuration, and not using kdbus or dbus-user-session.  It
certainly seems possible that the fault lies with DBus; any additional
information I could supply to evaluate that?

- Josh triplett

Bug#800617: Fails to provide secrets

[Josh Triplett]

On Thu, Oct 01, 2015 at 04:27:01PM -0700, Josh Triplett wrote:
> On Fri, Oct 02, 2015 at 12:39:36AM +0200, Michael Biebl wrote:
> > Control: tags -1 moreinfo unreproducible
> > 
> > Am 01.10.2015 um 19:54 schrieb Josh Triplett:
> > > Package: gnome-keyring
> > > Version: 3.18.0-1
> > > Severity: grave
> > > 
> > > Since upgrading gnome-keyring from 3.16.0-4 to 3.18.0-1, applications
> > > trying to retrieve secrets from gnome-keyring no longer can.  I see log
> > > messages like the following:
> > > 
> > > Oct 01 10:36:37 jtriplet-mobl1 gnome-keyring-daemon[5801]: couldn't 
> > > access control socket: /run/user/1000/keyring/control: No such file or 
> > > directory
> > > Oct 01 10:36:37 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't 
> > > access control socket: /run/user/1000/keyring/control: No such file or 
> > > directory
> > > Oct 01 10:36:37 jtriplet-mobl1 gnome-keyring-daemon[5803]: couldn't 
> > > access control socket: /run/user/1000/keyring/control: No such file or 
> > > directory
> > > Oct 01 10:36:37 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't 
> > > access control socket: /run/user/1000/keyring/control: No such file or 
> > > directory
> > > [...]
> > > Oct 01 10:36:38 jtriplet-mobl1 gnome-keyring-daemon[5808]: couldn't 
> > > register in session: Timeout was reached
> > > Oct 01 10:36:38 jtriplet-mobl1 gnome-keyring-daemon[5803]: couldn't 
> > > communicate with already running daemon: Timeout was reached
> > > Oct 01 10:36:38 jtriplet-mobl1 gnome-session[5731]: ** Message: couldn't 
> > > communicate with already running daemon: Timeout was reached
> > > Oct 01 10:36:38 jtriplet-mobl1 gnome-session[5731]: 
> > > SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
> > > Oct 01 10:36:39 jtriplet-mobl1 gnome-keyring-daemon[5844]: couldn't 
> > > register in session: Timeout was reached
> > > [...]
> > > Oct 01 10:37:03 jtriplet-mobl1 gnome-keyring-daemon[5808]: couldn't 
> > > request name 'org.freedesktop.secrets' on session bus: Timeout was reached
> > > [...]
> > > Oct 01 10:48:34 jtriplet-mobl1 
> > > org.gnome.evolution.dataserver.Sources4[5783]: 
> > > server_side_source_credentials_lookup_cb: Failed to lookup password: 
> > > Error calling StartServiceByName for org.freedesktop.secrets: Timeout was 
> > > reached
> > > Oct 01 10:48:35 jtriplet-mobl1 org.gnome.seahorse.Application[5783]: 
> > > (seahorse:8293): seahorse-WARNING **: gkr-backend.vala:85: couldn't 
> > > connect to secret service: Error calling StartServiceByName for 
> > > org.freedesktop.secrets: Timeout was reached
> > > 
> > > In addition to that, it also looks like every time an application tries to
> > > access the org.freedesktop.secrets service, dbus spawns an instance of
> > > gnome-keyring with the --foreground option, likely based on
> > > /usr/share/dbus-1/services/org.freedesktop.secrets.service ; does this 
> > > conflict
> > > with the instance already run via /etc/xdg/autostart?
> > > 
> > 
> > Works fine here. Is this maybe a D-Bus problem? Do you use
> > dbus-user-session/kdbus? Any custom config?
> 
> No custom configuration, and not using kdbus or dbus-user-session.  It
> certainly seems possible that the fault lies with DBus; any additional
> information I could supply to evaluate that?

Some further investigation produced interesting results.

With ps, I observed two separate gnome-keyring-daemon processes running
with --components=secrets (in addition to those for ssh and pkcs11).
One sat in the same group as the other components, while the other
appeared to have launched separately and used --foreground, consistent
with getting dynamically launched from DBus.

If I killed the process launched with --foreground, and re-attempted
something that looked for secrets, the process with --foreground
reappeared, and I still couldn't obtain those secrets.

However, if I killed the process launched *without* --foreground first,
then the one launched with --foreground, and re-attempted something that
looked for secrets, the process with --foreground reappeared and I could
obtain the secrets successfully.

So, it looks like those two processes conflicted.  Somehow, programs
looking for the secrets interface couldn't talk to the
gnome-keyring-daemon process launched as part of the session, only the
one launched by dbus; and the one launched by dbus didn't work until I
stopped the one launched as part of the session first.

- Josh Triplett