After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 784992 - ephy does not trigger asking user to get password from ring if not opened yet
ephy does not trigger asking user to get password from ring if not opened yet
Status: RESOLVED WONTFIX
Product: epiphany
Classification: Core
Component: Passwords, Cookies, & Certificates
3.22.x (obsolete)
Other Linux
: Normal enhancement
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-07-16 03:45 UTC by Dan Jacobson
Modified: 2017-08-04 00:51 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dan Jacobson 2017-07-16 03:45:31 UTC
ephy triggers the default keyring when needing to store a password.
And then the keyring asks us for the keyring password, and we enter it, and the password is stored.

But let's assume the above has not yet happened, and ephy wants to read a password from the ring to enter it into a field.

Well in this no password will be gotten out of the ring, because ephy is embarrased to dig it out of a ring not opened yet.

I.e., if earlier in the session we have opened the ring by storing a password, then passwords can be retrieved, but not before that.

The above behavior is all a guess.
Comment 1 Dan Jacobson 2017-07-22 11:16:48 UTC
Every day after I boot, the first time ephy wants to save a password, I am asked again for the keyring password also. What a drag.
Comment 2 Michael Catanzaro 2017-07-22 15:48:30 UTC
It's a distribution bug for the keyring to not be unlocked automatically at startup. If you're using GDM (the only display manager that we support) then this should happen automatically, presuming your distribution has configured its PAM modules correctly for gnome-keyring. If your PAM is configured correctly, then it *should* work just fine with other display managers too.
Comment 3 Dan Jacobson 2017-07-23 01:57:19 UTC
I use nodm, wherein I the user never have to type a password from boot till shutdown. Hence I suppose I am out of luck.
Comment 4 Dan Jacobson 2017-07-23 02:20:25 UTC
https://wiki.gnome.org/Projects/GnomeKeyring/Pam says how to do something via Pam. Tampering with that I would surely regret. https://wiki.archlinux.org/index.php/GNOME/Keyring#Without_a_display_manager mentions how to fix it via .xinitrc, alas that also doesn't work.
Comment 5 Dan Jacobson 2017-07-23 02:47:03 UTC
(In reply to Michael Catanzaro from comment #2)
> It's a distribution bug for the keyring to not be unlocked automatically at startup.
OK I created https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869399 . Thanks.
Comment 6 Dan Jacobson 2017-07-23 03:19:54 UTC
WHEREIN I Document how today it backfired. NEVER TAMPER WITH PAM.

I am back to 0 solutions. I would be more than happy to turn off all security, as I live in a forest. If --- you are sure it would work.
Comment 7 Dan Jacobson 2017-08-01 23:12:16 UTC
Nodm bugs take an average of 10 years to get fixed.

Is there some workaround I can use in the meantime?

I am zero percent worried about security, and would be fine with an unencrypted list, whatever.
Comment 8 Dan Jacobson 2017-08-04 00:51:58 UTC
Also this will trigger repeated asking:

User browses site A which ask for password.
Epiphany asks shall I save the password.
The keyring dialog comes up and user enters the password to unlock the
keyring.

Several days (reboots) later, the user browses the same site, and the
whole sequence is repeated!

This is clearly epiphany's problem.

It knows to call up the keyring when saving a password.

But it does not know to call up the keyring (properly) to retrieve (or
check for) passwords already stored! ... when it is the first action of
the session i.e., we have not already saved any keys this session.

When testing, the developers probably never tested in the sequence I
mentioned.

Anyway, the above problem is revealed when the user is a "ask once for
keyring password per session" user.

OK I will try to make it so that I will never see another keyring
prompt... maybe somehow one day.