GNOME Bugzilla – Bug 736640
Server trust exceptions cannot be stored
Last modified: 2019-01-10 06:53:43 UTC
Created attachment 286158 [details] A screenshot of the error message. Using a self-hosted email service I have to deal with self-signed certificates and therefore add a trust exception for our server. Doing that does not work in Geary 6.3 as I receive the message "Unable to store server trust exception - Couldn't find a place to store the pinned certificate". I am using Linux Mint 17 with XFCE, but have Gnome services running (e.g. gnome-keyring).
It sounds like gnome-keyring-daemon isn't running. Can you check with System Monitor or ps that the daemon is executing in the background?
Hi Jim, thanks for your answer! ps x | grep gnome-keyring returns: 1948 ? SLl 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login That looks rather promising, doesn't it? By the way I pulled the sources from git and built the current master (0.7.2), but the problem persists. Certificate storage does work in Evolution, in case that makes a difference. I will probably investigate into that issue in a few weeks when my exams are over and try different setups and constellations and give you feedback if I find something out. Best, mank319
I'm unaware how Evolution stores certificates. The key here is that Geary uses gcr-3 for storing (pinning) certificates. The error you're reporting is coming from gcr-3 (which is due to the backing store reporting an error). If you could do a little more looking and testing, that would be helpful.
To make sure the problem has not been caused by some of my system modifications I tried it again with a fresh Linux Mint 17 XFCE installation - without success. Of course GNOME services and everything related to gnome-keyring was set to autostart (in the XFCE settings manager). Now that I have installed Xubuntu 14.04, geary's certificate pinning works as expected! That being said, the problem still occurs if I try to start geary after the system was suspended at least once. In this case I get asked to unlock my keyring, which is followed by the aforementioned error message. I assume that during a suspend/resume cycle some required backend service gets locked or stopped. Geary instances that have been started before suspending the machine continue to work as long as they remain open. Fiddling around with gnome-keyring I recognized one more thing: On Mint I was not even able to import certificates via gnome-keyring import or Seahorse, so I assume the general certificate storage is somewhat broken.
It does sound like something's not configured or installed correctly. Geary doesn't really make heavy use of gcr-3. Basically, it merely queries if a certificate is pinned, and if the user requests it, Geary will pin a certificate. That's it.
I just saw this. I was running geary remotely using 'ssh -X'. When I run it locally, certificate pinning seems to work fine. So this might be related to gnome-keyring not working in this situation.
*** Bug 749600 has been marked as a duplicate of this bug. ***
Hi Jim, I'm experiencing this issue too. Can thi be related to the fact there are two instance of gnome-keyring running on my system? -> ps x | grep gnome-keyring 396 ? SLl 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login 629 ? S 0:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets 1546 pts/0 S+ 0:00 grep gnome-keyring
A little update: Apparently "gnome-keyring-daemon --login" was being run by PAM and gnome-keyring daemon needs to be run after that too. When I click Geary's icon to run it the "gnome-keyring-daemon --start --foreground --components=secrets" is being called but not working for some reason. I've put a simple "gnome-keyring-daemon" in my startup and now it works as expected.
Hi all, Is anyone still experiencing this issue? It looks more like a system configuration issue than a Geary bug?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!
Hey! I'm still getting the same bug, running GNOME 3.28.0 and Geary 0.12.1 on Antergos/Arch. I tried restarting the keyring daemon without any additional options as in comment 9, but Geary is still unable to store the certificate.
Hi hfel, Thanks for letting us know. For GCR to use gnome-keyring-daemon for pinning certificates, it needs to be started either without the -c/--components command line options, or with at least "pkcs11". Can you verify if storing a trust exception works when gnome-keyring-daemon is started using "gnome-keyring-daemon --start --foreground --components=pkcs11"? If not, please install Bustle <https://www.freedesktop.org/wiki/Software/Bustle/>, start recording a log just before you are prompted to trust the certificate, and stop it after the error dialog has appeared. Save the log, and either attach it here, or if it contains confidential information, email it to me directly. Cheers!
Two things: 1. Be careful about posting Bustle logs that contain calls to org.freedesktop.Secret, since that may contain your password. 2. Another way to get some debugging info about this is to start geary using the command: GCR_DEBUG='all' geary Can people please try that and let me know if what gets printed out when the "Unable to store server trust exception" message pops up?
Hello Michael! I am another user having this exact issue . result of GCR_DEBUG='all' geary : Gck-Message: 14:41:59.890: couldn't open session on module while enumerating objects: The device is write protected Gck-Message: 14:41:59.890: couldn't open session on module while enumerating objects: The device is write protected (geary:1361): Gck-CRITICAL **: 14:41:59.890: gck_modules_token_for_uri: assertion 'uri != NULL' failed
Hi, I am experiencing this issue on Fedora 28: geary-0.12.1-1.fc28.x86_64 I see in seahorse that Geary is successfully storing my IMAP passwords in the keyring. I tried launching with GCR_DEBUG='all' geary It becomes a Heisenbug because I can't reproduce it that way. Oddly (is this expected?) it didn't have my accounts when I started it this way so I had to reconfigure the account having the cert issues when running it with GCR_DEBUG. (if i run it the normal way, both accounts I had configured come back.)
Hi all, since a few people have reported this issue with F28 this seems like a regression there, however to look into it properly I'd need an account on server which uses a self-signed cert for SMTP and/or IMAP. Since I don't currently have one, it'll be a lot faster if anyone can create a temp one on such a server that I can test against.
Hi Michael, I'm happy to set one up for you. I'll send you the details to your GNOME BZ listed email address?
Thanks Máirín, I received the login details fine, will try to repo asap.
Hi, I also observe the problem on Fedora 28. Michael, do you need more information to analyse the bug ?
(In reply to ZeHiro from comment #20) > Hi, > > I also observe the problem on Fedora 28. > > Michael, do you need more information to analyse the bug ? I'm still trying to work out why Fedora 28 is triggering this all of a sudden, so yeah, some more information would be good. Can you let me know the following: - The host name of your IMAP and/or SMTP server - Which p11-kit packages do you have installed? - What is the output of running "p11-kit list-modules"? (In reply to infin1ty from comment #15) > > result of GCR_DEBUG='all' geary : > > Gck-Message: 14:41:59.890: couldn't open session on module while enumerating > objects: The device is write protected > Gck-Message: 14:41:59.890: couldn't open session on module while enumerating > objects: The device is write protected > > (geary:1361): Gck-CRITICAL **: 14:41:59.890: gck_modules_token_for_uri: > assertion 'uri != NULL' failed This definitely indicates a problem with GCR/GCK and/or p11-kit. The "couldn't open session" error is from GCK, and is printed when a call to the PKCS #11 C_OpenSession() function fails. So something is likely wrong with your p11-kit installation and/or configuration. If someone could run geary using strace and see if they can find out what p11-kit/PCKS#11 files and/or modules are being opened, that might help? infin1ty: What Linux distribution and version are you running? hfel: Do you have any p11-kit packages installed? This is really starting to look like a bug or configuration problem with GCR/GCK and/or p11-kit. Similar warnings are showing up for other apps as well, e.g: https://bugs.launchpad.net/midori/+bug/1638671
(In reply to Michael Gratton from comment #21) > (In reply to ZeHiro from comment #20) > > Hi, > > > > I also observe the problem on Fedora 28. > > > > Michael, do you need more information to analyse the bug ? > > I'm still trying to work out why Fedora 28 is triggering this all of a > sudden, so yeah, some more information would be good. > > Can you let me know the following: > > - The host name of your IMAP and/or SMTP server > - Which p11-kit packages do you have installed? > - What is the output of running "p11-kit list-modules"? > > (In reply to infin1ty from comment #15) > > > > result of GCR_DEBUG='all' geary : > > > > Gck-Message: 14:41:59.890: couldn't open session on module while enumerating > > objects: The device is write protected > > Gck-Message: 14:41:59.890: couldn't open session on module while enumerating > > objects: The device is write protected > > > > (geary:1361): Gck-CRITICAL **: 14:41:59.890: gck_modules_token_for_uri: > > assertion 'uri != NULL' failed > > This definitely indicates a problem with GCR/GCK and/or p11-kit. The > "couldn't open session" error is from GCK, and is printed when a call to the > PKCS #11 C_OpenSession() function fails. So something is likely wrong with > your p11-kit installation and/or configuration. > > If someone could run geary using strace and see if they can find out what > p11-kit/PCKS#11 files and/or modules are being opened, that might help? > > infin1ty: What Linux distribution and version are you running? > > hfel: Do you have any p11-kit packages installed? > > This is really starting to look like a bug or configuration problem with > GCR/GCK and/or p11-kit. Similar warnings are showing up for other apps as > well, e.g: https://bugs.launchpad.net/midori/+bug/1638671 I have libp11-kit installed.
Some more information: This related bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799963 points to this Midori FAQ about the exact same problem: http://midori-browser.org/faqs/#security_features That notes that gnome-keyring-pkcs11.so must be installed, and also gnome-keyring-daemon running correctly. So, can people also check these things by running the following commands: sudo find / -name gnome-keyring-pkcs11.so and: ps ax | grep gnome-keyring-daemon And report back here the result of both. Thanks.
$ sudo find / -name gnome-keyring-pkcs11.so find: ‘/run/user/1000/gvfs’: Permiso denegado /usr/lib64/pkcs11/gnome-keyring-pkcs11.so $ ps ax | grep gnome-keyring-daemon 640 ? SLl 0:30 /usr/bin/gnome-keyring-daemon --daemonize --login 29598 pts/0 S+ 0:00 grep gnome-keyring-daemon
(In reply to Michael Gratton from comment #21) > (In reply to ZeHiro from comment #20) > > Hi, > > > > I also observe the problem on Fedora 28. > > > > Michael, do you need more information to analyse the bug ? > > I'm still trying to work out why Fedora 28 is triggering this all of a > sudden, so yeah, some more information would be good. > > Can you let me know the following: > > - The host name of your IMAP and/or SMTP server > - Which p11-kit packages do you have installed? > - What is the output of running "p11-kit list-modules"? > > (In reply to infin1ty from comment #15) > > > > result of GCR_DEBUG='all' geary : > > > > Gck-Message: 14:41:59.890: couldn't open session on module while enumerating > > objects: The device is write protected > > Gck-Message: 14:41:59.890: couldn't open session on module while enumerating > > objects: The device is write protected > > > > (geary:1361): Gck-CRITICAL **: 14:41:59.890: gck_modules_token_for_uri: > > assertion 'uri != NULL' failed > > This definitely indicates a problem with GCR/GCK and/or p11-kit. The > "couldn't open session" error is from GCK, and is printed when a call to the > PKCS #11 C_OpenSession() function fails. So something is likely wrong with > your p11-kit installation and/or configuration. > > If someone could run geary using strace and see if they can find out what > p11-kit/PCKS#11 files and/or modules are being opened, that might help? > > infin1ty: What Linux distribution and version are you running? > > hfel: Do you have any p11-kit packages installed? > > This is really starting to look like a bug or configuration problem with > GCR/GCK and/or p11-kit. Similar warnings are showing up for other apps as > well, e.g: https://bugs.launchpad.net/midori/+bug/1638671 I am running Manjaro 17.1.10 MATE
(In reply to Michael Gratton from comment #21) > (In reply to ZeHiro from comment #20) > > Hi, > > > > I also observe the problem on Fedora 28. > > > > Michael, do you need more information to analyse the bug ? > > I'm still trying to work out why Fedora 28 is triggering this all of a > sudden, so yeah, some more information would be good. > > Can you let me know the following: > > - The host name of your IMAP and/or SMTP server > - Which p11-kit packages do you have installed? > - What is the output of running "p11-kit list-modules"? > > (In reply to infin1ty from comment #15) > > > > result of GCR_DEBUG='all' geary : > > > > Gck-Message: 14:41:59.890: couldn't open session on module while enumerating > > objects: The device is write protected > > Gck-Message: 14:41:59.890: couldn't open session on module while enumerating > > objects: The device is write protected > > > > (geary:1361): Gck-CRITICAL **: 14:41:59.890: gck_modules_token_for_uri: > > assertion 'uri != NULL' failed > > This definitely indicates a problem with GCR/GCK and/or p11-kit. The > "couldn't open session" error is from GCK, and is printed when a call to the > PKCS #11 C_OpenSession() function fails. So something is likely wrong with > your p11-kit installation and/or configuration. > > If someone could run geary using strace and see if they can find out what > p11-kit/PCKS#11 files and/or modules are being opened, that might help? > > infin1ty: What Linux distribution and version are you running? > > hfel: Do you have any p11-kit packages installed? > > This is really starting to look like a bug or configuration problem with > GCR/GCK and/or p11-kit. Similar warnings are showing up for other apps as > well, e.g: https://bugs.launchpad.net/midori/+bug/1638671 - Hostname: access.mail.gandi.net - p11-kit: p11-kit-0.23.10-1.fc28.x86_64 - p11-kit list-modules: p11-kit-trust: p11-kit-trust.so library-description: PKCS#11 Kit Trust Module library-manufacturer: PKCS#11 Kit library-version: 0.23 token: System Trust manufacturer: PKCS#11 Kit model: p11-kit-trust serial-number: 1 hardware-version: 0.23 flags: write-protected token-initialized token: Default Trust manufacturer: PKCS#11 Kit model: p11-kit-trust serial-number: 1 hardware-version: 0.23 flags: write-protected token-initialized
Not tested, but a workaround would be: $ mkdir -p ~/.config/pkcs11/modules $ curl https://gitlab.gnome.org/GNOME/gnome-keyring/raw/ff229abca62db366c84dfe58035324f6d8ca6059/pkcs11/rpc-layer/gnome-keyring.module.in > ~/.config/pkcs11/modules/gnome-keyring.module
(In reply to Daiki Ueno from comment #27) > Not tested, but a workaround would be: > > $ mkdir -p ~/.config/pkcs11/modules > $ curl > https://gitlab.gnome.org/GNOME/gnome-keyring/raw/ > ff229abca62db366c84dfe58035324f6d8ca6059/pkcs11/rpc-layer/gnome-keyring. > module.in > ~/.config/pkcs11/modules/gnome-keyring.module It does the work. Thanks :)
(In reply to Daiki Ueno from comment #27) > Not tested, but a workaround would be: > > $ mkdir -p ~/.config/pkcs11/modules > $ curl > https://gitlab.gnome.org/GNOME/gnome-keyring/raw/ > ff229abca62db366c84dfe58035324f6d8ca6059/pkcs11/rpc-layer/gnome-keyring. > module.in > ~/.config/pkcs11/modules/gnome-keyring.module Working like a charm,thank you!
Michael my output the same as comment 24 (just language difference.) Is the workaround in comment 27 something we should be using? What are the implications of that to get this fixed downstream?
And FWIW the workaround in comment 27 doesn't work for me in Fedora 28. :(
The workaround doesn't work for me either on Solus 3.9999.
Do you see the "User Key Storage" token in the p11tool output after the workaround? $ p11tool --list-tokens ... Token 6: URL: pkcs11:model=1.0;manufacturer=Gnome%20Keyring;serial=1%3aXDG%3aDEFAULT;token=User%20Key%20Storage Label: User Key Storage Type: Generic token Manufacturer: Gnome Keyring Model: 1.0 Serial: 1:XDG:DEFAULT Module: gnome-keyring-pkcs11.so
(In reply to Daiki Ueno from comment #33) > Do you see the "User Key Storage" token in the p11tool output after the > workaround? > > $ p11tool --list-tokens > ... > Token 6: > URL: > pkcs11:model=1.0;manufacturer=Gnome%20Keyring;serial=1%3aXDG%3aDEFAULT; > token=User%20Key%20Storage > Label: User Key Storage > Type: Generic token > Manufacturer: Gnome Keyring > Model: 1.0 > Serial: 1:XDG:DEFAULT > Module: gnome-keyring-pkcs11.so Nope: $ p11tool --list-tokens Token 0: URL: pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust Label: System Trust Type: Trust module Flags: uPIN uninitialized Manufacturer: PKCS#11 Kit Model: p11-kit-trust Serial: 1 Module: p11-kit-trust.so
The workaround in comment 27 works for me on fedora 28 too. Output before workaround: $ p11tool --list-tokens Token 0: URL: pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust Label: System Trust Type: Trust module Flags: uPIN uninitialized Manufacturer: PKCS#11 Kit Model: p11-kit-trust Serial: 1 Module: p11-kit-trust.so Token 1: URL: pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=Default%20Trust Label: Default Trust Type: Trust module Flags: uPIN uninitialized Manufacturer: PKCS#11 Kit Model: p11-kit-trust Serial: 1 Module: p11-kit-trust.so Output after workaround: $ p11tool --list-tokens Token 0: URL: pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust Label: System Trust Type: Trust module Flags: uPIN uninitialized Manufacturer: PKCS#11 Kit Model: p11-kit-trust Serial: 1 Module: p11-kit-trust.so Token 1: URL: pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=Default%20Trust Label: Default Trust Type: Trust module Flags: uPIN uninitialized Manufacturer: PKCS#11 Kit Model: p11-kit-trust Serial: 1 Module: p11-kit-trust.so Token 2: URL: pkcs11:model=1.0;manufacturer=Gnome%20Keyring;serial=1%3aSSH%3aHOME;token=SSH%20Keys Label: SSH Keys Type: Generic token Flags: Requires login, External PIN Manufacturer: Gnome Keyring Model: 1.0 Serial: 1:SSH:HOME Module: gnome-keyring-pkcs11.so Token 3: URL: pkcs11:model=1.0;manufacturer=Gnome%20Keyring;serial=1%3aSECRET%3aMAIN;token=Secret%20Store Label: Secret Store Type: Generic token Flags: Requires login, External PIN Manufacturer: Gnome Keyring Model: 1.0 Serial: 1:SECRET:MAIN Module: gnome-keyring-pkcs11.so Token 4: URL: pkcs11:model=1.0;manufacturer=Gnome%20Keyring;serial=1%3aUSER%3aDEFAULT;token=Gnome2%20Key%20Storage Label: Gnome2 Key Storage Type: Generic token Flags: Requires login, External PIN Manufacturer: Gnome Keyring Model: 1.0 Serial: 1:USER:DEFAULT Module: gnome-keyring-pkcs11.so Token 5: URL: pkcs11:model=1.0;manufacturer=Gnome%20Keyring;serial=1%3aXDG%3aDEFAULT;token=User%20Key%20Storage Label: User Key Storage Type: Generic token Flags: External PIN, uPIN uninitialized Manufacturer: Gnome Keyring Model: 1.0 Serial: 1:XDG:DEFAULT Module: gnome-keyring-pkcs11.so
Thanks for the extra information, everyone. Daiki, I don't know my way around the gnome crypto/p11kit stuff very well, and Geary's use is limited to simply calling gcr_trust_add_pinned_certificate, gcr_trust_is_certificate_pinned and gcr_trust_remove_pinned_certificate on the assumption the infrastructure should just work. Since your workaround works for some people on F28 and not others is this likely to be in part a packaging issue? If so, do you know what needs to be installed to get this fixed? If it's also because of Bug 791401, what should applications now use for secure certificate pinning if not GCR?
(In reply to Daiki Ueno from comment #27) > Not tested, but a workaround would be: > > $ mkdir -p ~/.config/pkcs11/modules > $ curl > https://gitlab.gnome.org/GNOME/gnome-keyring/raw/ > ff229abca62db366c84dfe58035324f6d8ca6059/pkcs11/rpc-layer/gnome-keyring. > module.in > ~/.config/pkcs11/modules/gnome-keyring.module Works for me (Fedora 28)
Hi all, just an update, I'm currently landing a work around for this over at: https://gitlab.gnome.org/GNOME/geary/merge_requests/80 This should fix any problems for both people who a) don't have the GNOME-keyring PCKS#11 module (gnome-keyring-pkcs11.so) installed - commonly those who aren't running Geary under GNOME, and also b) people that run GNOME 3.28 or later and hence were missing gnome-keyring.module. It's looking like GCR and gnome-keyring will re-enable support for this again in 3.32, in the mean time the work around will make it in to Geary 0.13, which hopefully will be out in a week or two. Thanks for your patience!