Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 335758 - Enabling chosing passoword storage backend for www-client/chromium
Summary: Enabling chosing passoword storage backend for www-client/chromium
Status: RESOLVED UPSTREAM
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Chromium Project
URL: http://code.google.com/p/chromium/iss...
Whiteboard: ht-wanted
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-03 07:49 UTC by Rahul Jain
Modified: 2010-12-11 04:52 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rahul Jain 2010-09-03 07:49:33 UTC
From the thread of the Chromium google groups (mentioned in the bug URL):

I've recently committed r50475 which adds a new flag,
--password-store, that lets you request GNOME Keyring or (KDE) KWallet
instead of the built-in unencrypted password store.

There are three possible values:
--password-store=gnome
--password-store=kwallet
--password-store=detect (this will eventually be the default)


However, under Gentoo, the www-client/chromium ebuilds specifically depend on gnome-keyring.

DEPEND="${RDEPEND}
        ... 
        >=gnome-base/gnome-keyring-2.28.2
        ..."

Can we have an update of the ebuild to allow choosing the password storage backend.



Reproducible: Always
Comment 1 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2010-10-09 12:25:45 UTC
Okay. What would you suggest in particular?

The dependency on gnome-keyring is fully optional now, even at compile time. Should we add a dependency on kwallet when USE=kde?

Should we update the launcher script to add --password-store=detect flag? Or maybe the value of the flag should be dependent on the USE flags? If so, then what should happen when USE="gnome kde"?

Those are just questions about details. I generally like the idea.
Comment 2 Mike Gilbert gentoo-dev 2010-10-11 01:57:42 UTC
My vote would be to add --password-store=detect to the launcher. This has been working fairly well for me using gnome-keyring for around a month.

On the USE flag topic: I believe kwallet support is always enabled since it uses a pure dbus implementation without dependencies on other libraries. An RDEPEND on kwallet seems a bit pointless in that case, unless there is a gyp define to disable it completely.
Comment 3 Fatih 2010-10-20 05:29:00 UTC
I have no gnome-keyring enabled but I added --password-store=detect switch to .desktop file to test on kwallet

On some random occasion it does not trigger the kwallet until restart chromium. Without restart chromium behaves as if no password-stote switch was given --i.e askes to save the password after loging/signing-in; if new username/password is entered it is merged to kwallet on next restart/trigger of the kwallet.

But in general I am happy about it. I would be much happier if data was not binary and could be edited inside kwallet. 
Comment 4 Mike Gilbert gentoo-dev 2010-10-20 14:07:55 UTC
(In reply to comment #3)
> I have no gnome-keyring enabled but I added --password-store=detect switch to
> .desktop file to test on kwallet
> 
> On some random occasion it does not trigger the kwallet until restart chromium.

Did you create a copy of the desktop file to test? Are you sure you are always launching chromium using that desktop file? It sounds like you may be occasionally launching the browser without the --password-store switch.
Comment 5 Fatih 2010-10-20 14:20:40 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > I have no gnome-keyring enabled but I added --password-store=detect switch to
> > .desktop file to test on kwallet
> > 
> > On some random occasion it does not trigger the kwallet until restart chromium.
> 
> Did you create a copy of the desktop file to test? Are you sure you are always
> launching chromium using that desktop file? It sounds like you may be
> occasionally launching the browser without the --password-store switch.
> 

It is saved automagically when the app icon on the panel is edited:

$ grep Exec .local/share/applications/chromium-chromium.desktop 
Exec=chromium --purge-memory-button --password-store=detect --new-wrench-menu --disable-accelerated-compositing %U
TryExec=chromium

The fallback is with no switch but, when the thing happened, I remembered to check the switches on about:version or ps. 
Note: I have not experienced it on 8.0.552.0 *yet*.
Comment 6 Fatih 2010-10-25 05:56:04 UTC
(In reply to comment #5)
> Note: I have not experienced it on 8.0.552.0 *yet*.
> 

I just have. Here is the command line:
/usr/lib/chromium-browser/chrome --extra-plugin-dir=/usr/lib/nsbrowser/plugins --purge-memory-button --password-store=detect --new-wrench-menu --disable-accelerated-compositing

Steps to reproduce: 
1. Run chromium with the above switches
2. Go to any login page

Expected: kdewallet password prompt should come up. (gnome-keyring aint installed here)
Actual: kdewallet password prompt does not come up.

Reproducible: Not always but randomly

FWIW, running kdewallet by hand and/or changing detect to kwallet won't help and saved passwords of chromium window/list is empty.
Comment 7 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2010-10-25 06:24:27 UTC
Could you report the problem upstream (http://new.crbug.com) and post the link here?

Even if it's not always reproducible, upstream may have more suggestions about what info is needed to help track down the bug.
Comment 8 Fatih 2010-10-25 07:56:41 UTC
(In reply to comment #7)
> Could you report the problem upstream (http://new.crbug.com) and post the link
> here?
> 
> Even if it's not always reproducible, upstream may have more suggestions about
> what info is needed to help track down the bug.
> 

Thanks, done.
http://code.google.com/p/chromium/issues/detail?id=60524
Comment 9 Mike Gilbert gentoo-dev 2010-12-11 04:52:34 UTC
*** Bug 348402 has been marked as a duplicate of this bug. ***