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 624638 - pdm-dialog: Rethink password management in epiphany
pdm-dialog: Rethink password management in epiphany
Status: RESOLVED DUPLICATE of bug 720239
Product: epiphany
Classification: Core
Component: Passwords, Cookies, & Certificates
git master
Other Linux
: Normal major
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
: 620886 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-07-17 21:46 UTC by johannes.kingma
Modified: 2013-12-11 11:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
pdm-dialog: correctly query the keyring passwords (3.30 KB, patch)
2010-08-19 02:42 UTC, Diego Escalante Urrelo (not reading bugmail)
none Details | Review

Description johannes.kingma 2010-07-17 21:46:55 UTC
Personal Data / Passwords is empty Yet, passwords and logins are filled in on certaim websites for instance mail.google.com

Passwords and logins are still filled in after
1) Selecting Clear All.. and selecting Saved passwords.
2) rm -r ~/.gnome2/epiphany
Comment 1 Reinout van Schouwen 2010-07-18 10:51:12 UTC
Related to bug 620886.
Comment 2 Diego Escalante Urrelo (not reading bugmail) 2010-08-19 02:42:32 UTC
*** Bug 620886 has been marked as a duplicate of this bug. ***
Comment 3 Diego Escalante Urrelo (not reading bugmail) 2010-08-19 02:42:38 UTC
Created attachment 168254 [details] [review]
pdm-dialog: correctly query the keyring passwords

Passwords dialog was empty because GNOME Keyring doesn't consider our "network
passwords" as such anymore, hence, our query is retrieving and empty set.
Instead of relaying on the item type we filter based on what the item contains.
Similar to what we do in embed/ephy-embed-single.c

Bug #624638
Comment 4 Xan Lopez 2010-08-30 05:18:37 UTC
I cannot reproduce this, so I think the assesment made in comment #3 cannot be completely correct. What's going on here?
Comment 5 Diego Escalante Urrelo (not reading bugmail) 2010-08-30 07:26:44 UTC
(In reply to comment #4)
> I cannot reproduce this, so I think the assesment made in comment #3 cannot be
> completely correct. What's going on here?

Well, that's interesting to know... I guess this means a few hours of checking out what the hell is wrong in gnome-keyring
Comment 6 Vilius Normantas 2010-09-27 15:26:45 UTC
I have the same problem - storing passwords works fine, but the list in Personal Data -> Passwords is empty. Version: 2.30.5 on Arch linux.
Any ideas how to fix this?
Comment 7 Emilio Pozuelo Monfort 2011-03-13 22:31:34 UTC
I sometimes get an empty password list in the personal data.
Comment 8 Pacho Ramos 2011-03-15 18:41:28 UTC
Some of our users are also suffering this:
http://bugs.gentoo.org/show_bug.cgi?id=359021

Personally, I cannot reproduce... but looks like password manager doesn't work ok always, sometimes I am unable to read passwords when setting it to show them, others I can see them without problems... :-/
Comment 9 Diego Escalante Urrelo (not reading bugmail) 2013-01-04 21:09:16 UTC
Comment on attachment 168254 [details] [review]
pdm-dialog: correctly query the keyring passwords

Due to the libsecret migration this API would be obsolete, yet the patch could make sense to fix our not-associated passwords.

See bug #685694 for the non association, and bug #679918 for the migration.
Comment 10 Emilio Pozuelo Monfort 2013-01-11 12:45:01 UTC
This might give some hints.

The other day, after a reboot, I opened epiphany and the passwords window was empty. Then I opened chromium and when going to a site for which it had stored my password, it asked me for the gnome-keyring (I think) password. After this, I went back to ephy and checked the passwords window, which contained my passwords.

I haven't tried to reproduce this again, but I could if necessary.
Comment 11 Adam Dingle 2013-04-02 12:01:06 UTC
I'm seeing this bug now: the passwords tab is empty, even though I've saved at least one password in Epiphany (and it is visible in Seahorse).  The situation persists even after I log out and log in again.

I'm running Epiphany built from git master on Ubuntu 13.04.
Comment 12 Adam Dingle 2013-04-02 14:37:07 UTC
In fact I'm also seeing an empty passwords tab on a Fedora machine running Epiphany 3.8.0.  So maybe this is just plain broken right now.
Comment 13 Xan Lopez 2013-04-02 14:45:52 UTC
(In reply to comment #12)
> In fact I'm also seeing an empty passwords tab on a Fedora machine running
> Epiphany 3.8.0.  So maybe this is just plain broken right now.

It's not, it works here (also Fedora 18), so I'm not sure of what's the issue. Is the password saving working at all? Since you say it shows up in Seahorse I assume it is. Any warning in console or anything, it would seem the code fetching the passwords from the keyring to show them in the PDM is broken in your case...
Comment 14 Adam Dingle 2013-04-02 14:59:38 UTC
I see this problem on two machines.  On both machines the Personal Data->Passwords tab is empty but passwords show up in Seahorse.  On one machine (Fedora 19), Epiphany fills in saved passwords when I visit a web page, and on the other (Ubuntu 13.04) it doesn't.

I have these library versions:

Ubuntu 13.04: libsecret 0.15-0ubuntu1, gnome-keyring 3.7.92-0ubuntu1~raring1
Fedora 19: libsecret-0.15-1.fc19, gnome-keyring-3.8.0-1.fc19

Xan, what versions do you have?
Comment 15 Adam Dingle 2013-04-02 15:03:11 UTC
Also, since you asked: I get no console warnings when I visit the Passwords tab or save a password.
Comment 16 Claudio Saavedra 2013-04-02 15:23:26 UTC
Is it a HTTPS password or credentials in a form? Ephy is no longer showing the HTTPS passwords in the pdm-dialog.
Comment 17 Adam Dingle 2013-04-02 16:03:12 UTC
I'm seeing this bug with various sites, all of which uses credentials in a form (on a page which is itself typically retrieved via HTTPS).  In other words, these sites don't use HTTP authentication.
Comment 18 Adam Dingle 2013-04-02 16:08:00 UTC
Actually it turns out I was running Epiphany 3.8.0 on Fedora 19 and git master on Ubuntu.  3.8.0 fills in saved passwords when I visit a web page, but git master does not (which is likely related to https://bugzilla.gnome.org/show_bug.cgi?id=666326#c8).  Neither of these versions is showing saved passwords in Personal Data->Passwords.
Comment 19 Emilio Pozuelo Monfort 2013-04-04 11:30:55 UTC
(In reply to comment #10)
> This might give some hints.
> 
> The other day, after a reboot, I opened epiphany and the passwords window was
> empty. Then I opened chromium and when going to a site for which it had stored
> my password, it asked me for the gnome-keyring (I think) password. After this,
> I went back to ephy and checked the passwords window, which contained my
> passwords.
> 
> I haven't tried to reproduce this again, but I could if necessary.

I can reproduce this by logging out of my session and back in.

Note this means that gdm is not unlocking my 'default' keyring, but in any case, ephy should unlock the locked keyring if needed (as chromium does).
Comment 20 Kat 2013-07-01 22:19:35 UTC
(In reply to comment #11)
> I'm seeing this bug now: the passwords tab is empty, even though I've saved at
> least one password in Epiphany (and it is visible in Seahorse).

I am having exactly this problem on 3.8.2, any suggestions for a work around? It's a bit difficult to document the passwords dialog if there aren't any passwords there :)
Comment 21 tim 2013-10-19 20:04:57 UTC
Same here: Epiphany 3.10.1.
Comment 22 Kat 2013-10-21 19:50:46 UTC
Claudio explained to me that only HTTP-Auth passwords are stored in the Epiphany passwords dialog…
Comment 23 Reinout van Schouwen 2013-10-22 08:51:29 UTC
(In reply to comment #22)
> Claudio explained to me that only HTTP-Auth passwords are stored in the
> Epiphany passwords dialog…

Why aren't these stored in the Gnome keyring as well, so that we can offload the entire stored passwords management to Seahorse?
Comment 24 Claudio Saavedra 2013-10-22 08:55:29 UTC
(In reply to comment #23)
> (In reply to comment #22)
> > Claudio explained to me that only HTTP-Auth passwords are stored in the
> > Epiphany passwords dialog…
> 
> Why aren't these stored in the Gnome keyring as well, so that we can offload
> the entire stored passwords management to Seahorse?

They are stored in the keyring too. You can manage all of the ephy passwords in seahorse. We probably need to rethink how passwords are managed in ephy if we manage them at all.
Comment 25 Kat 2013-10-22 08:57:00 UTC
Sorry, that was bad wording on my part. Show there, yes, but I don't know where they are stored (maybe in seahorse anyway?) and I have no way to test.
Comment 26 Kat 2013-10-22 08:59:03 UTC
Claudio, from a documentation point of view, there would be less to document if they were only manageable through seahorse.

On the other hand, it strikes me as slightly more user friendly if they can be managed through epiphany.
Comment 27 Claudio Saavedra 2013-10-22 09:24:36 UTC
Seahorse is just a UI to manage secrets. The secrets are stored in a backend, which could be the gnome-keyring, for instance. We use libsecret (and so does Seahorse) to access the secrets.

I believe that delegating secrets entirely on Seahorse is bad, particularly if we don't make it clear. People will always look for a way to manage their passwords from Ephy. But we can always instead make it possible to launch Seahorse from Epiphany if that's a good and consistent UX; we could also reuse some part of the Seahorse UI in Ephy; or rewrite this dialog with a renewed UI. I think we should aim to come up with the most consistent and user friendly experience first and then move from there.
Comment 28 Reinout van Schouwen 2013-10-22 14:44:45 UTC
(In reply to comment #27)

> I believe that delegating secrets entirely on Seahorse is bad, particularly if
> we don't make it clear. People will always look for a way to manage their
> passwords from Ephy. But we can always instead make it possible to launch
> Seahorse from Epiphany if that's a good and consistent UX; 

"Prior art" in this context is launching gedit from the Preferences to edit a user stylesheet.
Comment 29 William Jon McCann 2013-12-11 11:59:29 UTC

*** This bug has been marked as a duplicate of bug 720239 ***