(No comment was entered for this change.)

Passwords should at least be obscured.

(No comment was entered for this change.)

The system infrastructure to support this is in transition right now, so effort here 
may just need to be repeated. This should definitely block a Linux release, but 
shouldn't block a Beta. Unless someone has strong feelings otherwise, pushing this to 
Mstone-5.

(No comment was entered for this change.)

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=34193 

------------------------------------------------------------------------
r34193 | evan@chromium.org | 2009-12-09 13:43:02 -0800 (Wed, 09 Dec 2009) | 7 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/encryptor_linux.cc?r1=34193&r2=34192
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/webdata/web_database.cc?r1=34193&r2=34192

linux: remove a NOTIMPL since we have a bug on it

Also, update some comments to use the new bug number.

BUG=8205,25404

Review URL: http://codereview.chromium.org/483003
------------------------------------------------------------------------

Replacing labels:
   Area-BrowserBackend by Area-Internals

Since we're unlikely to get past hardy, we're unlikely to be able to fix this by using 
gnome-password or whatever.

(No comment was entered for this change.)

Preemptively assigning to mdm, I htink we can use the KDE pw manager via dbus

It would seem that I will be working on AdSense and not Chrome, so I won't be able to do this right away. 
Perhaps if it can wait I can throw some 20% time at it later, but definitely not for Mstone-5.

There is disabled code to use both GNOME keyring and KWallet, although it needs to be brushed off to compile 
again. (In particular some new virtual methods have been added that need to be implemented.) Perhaps rather 
than using these directly, and introducing a dependency, it wouldn't be too hard to tweak this code to load 
them dynamically? Then we can use whatever's available and fall back to the unencrypted version only if 
neither is installed.

As an aside I personally agree with the reasoning that merely obscuring passwords is not a good idea since it 
provides a false sense of the level of security actually present.

If anyone feels strongly enough about changing this behavior for mstone:5, who doesn't have any P1 bugs, 
please feel free to take a swing.

Mac as well. I just removed   NOTIMPLEMENTED(); in encryptor_mac.mm, so it does the
same thing as encryptor_linux.cc: just copies the data. But the person implementing
it should remember about mac as well.

The mac doesn't store passwords in the database. Why did you remove the NOTIMPLEMENTED? If anyone ever 
starts using encryptor_mac we need to know, because that would be bad.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=44984 

------------------------------------------------------------------------
r44984 | georgey@chromium.org | 2010-04-19 16:28:32 -0700 (Mon, 19 Apr 2010) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/encryptor_mac.mm?r1=44984&r2=44983

Removed NOTIMPLEMENTED() from Encryptor::EncryptString() and Encryptor::DecryptString() in
chrome/browser/password_manager/encryptor_mac.mm, so it does exactly the same thing as on Linux: copies unencrypted text.
BUG=25404
TEST=Filling out Autofill for CC on Mac should not assert.
Review URL: http://codereview.chromium.org/1613024
------------------------------------------------------------------------

In the comments for Encryptor it says that it is needs to be implemented for Linux
and Mac (see comment from thestig @ line 28 in web_database.cc). As it I added use of
general Encryptor to encode CC numbers stored locally, I removed NOTIMPLEMENTED(), so
it does not assert on Mac. We *do* need to implement it eventually, as not only
passwords need to be encrypted.

IMO, we shouldn't be designing around Encryptor as a cross-platform concept at all. On the Mac, the solution for 
sensitive data should be to use the Keychain, rather than re-inventing something for secure local storage.

Is web_database used on Mac? Because if it is the password there is saved through the
Encryptor and not through the Keychain.

Password storage via WebDatabase is deprecated, and shortly no platform will use it. PasswordStore is the 
abstraction for password management, and does not delegate to WDS on the Mac. I wrote the entire 
PasswordStore implementation for the Mac, and I guarantee it doesn't use Encryptor.

The fundamental problem with Encryptor is that it "abstracts" a Windows API only in that it abstracts the 
platform call. It still assumes that secure local storage on all platforms will have basically the structure that it 
has on Windows. That's not the case.

I strongly feel that at least on the Mac (maybe on Linux; I don't know what the right platform solution is there), 
Encryptor shouldn't even be defined. If we need non-password secure local storage, we should figure out the 
right abstraction that actually works for all platforms, rather than encouraging new clients of a Windows-ism.

I filed  bug 42038  to continue this discussion, so as not to totally hijack this Linux bug.

Continuing discussion from  bug #8205 : there has been near zero progress in the design 
of a unified dbus API for keyrings. While I agree that such an API would be the right 
way to go, I reckon that we need a solution *right now* for not storing passwords in 
clear text in Linux. It does not make sense to be indefinetely stalled by a new API 
that nobody is actively working on.

If the only issue with the existing GNOME keyring code (aside some little bitrot) is 
that of dependency, rewriting it to use dlopen() should solve it.

How does this issue differ from  issue 12351 , where we want to turn on the integration 
with gnome-keyring and kwallet?

Is this about doing encrypted storage ourselves when neither of those is available?  If 
not, it seems like this should just close in favor of the other bug.

This bug is about doing *something* on Linux.  At the time this bug was filled 12351 
was closed as WontFix and had a different summary.

It looks like kwallet and gnome-keyring integration are possible now.  A remaining 
question for this bug: is the market of linux users without either big enough for us 
to provide our own fallback?  I suspect Chrome OS doesn't plan to use either kwallet 
or gnome-keyring, so what ever solution they have in mind is probably the resolution 
to this question.

I'm not sure, but I think they're planning to use hardware (TPM chips etc), so I wouldn't count on the Chrome OS 
solution being generalizable for LInux.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=48983 

------------------------------------------------------------------------
r48983 | mdm@chromium.org | 2010-06-04 15:21:13 -0700 (Fri, 04 Jun 2010) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store.h?r1=48983&r2=48982
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_gnome.cc?r1=48983&r2=48982
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_gnome.h?r1=48983&r2=48982
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_kwallet.cc?r1=48983&r2=48982
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_kwallet.h?r1=48983&r2=48982

Linux: bring GNOME Keyring and KWallet integration back into a compilable state. Still disabled, however.
BUG=12351,25404
TEST=both now seem to work correctly when enabled (but this CL does not enable them)

Review URL: http://codereview.chromium.org/2407001
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=48996 

------------------------------------------------------------------------
r48996 | mdm@chromium.org | 2010-06-04 19:50:51 -0700 (Fri, 04 Jun 2010) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_gnome.cc?r1=48996&r2=48995

Linux: make GNOME keyring password store able to use libgnome-keyring via dlopen. The GNOME keyring password store is still disabled.
BUG=25404
TEST=gnome keyring password store can be loaded with dlopen

Review URL: http://codereview.chromium.org/2696002
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=49110 

------------------------------------------------------------------------
r49110 | mdm@chromium.org | 2010-06-07 15:34:40 -0700 (Mon, 07 Jun 2010) | 4 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/build/install-build-deps.sh?r1=49110&r2=49109

Linux: add gnome-keyring packages to build dependencies. It will not be a runtime dependency: it will be dlopen()ed to avoid that.
BUG=25404
TEST=none
Review URL: http://codereview.chromium.org/2700002
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=49135 

------------------------------------------------------------------------
r49135 | mdm@chromium.org | 2010-06-07 18:25:58 -0700 (Mon, 07 Jun 2010) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi?r1=49135&r2=49134
   M http://src.chromium.org/viewvc/chrome/trunk/src/build/linux/system.gyp?r1=49135&r2=49134
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_browser.gypi?r1=49135&r2=49134

Linux: enable compiling GNOME Keyring and KWallet integration. It's still unused.
BUG=12351,25404
TEST=GNOME Keyring and KWallet get compiled, but add no new library dependencies

Review URL: http://codereview.chromium.org/2718001
------------------------------------------------------------------------

(No comment was entered for this change.)

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=49370 

------------------------------------------------------------------------
r49370 | mdm@chromium.org | 2010-06-09 22:45:01 -0700 (Wed, 09 Jun 2010) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/build/common.gypi?r1=49370&r2=49369
   M http://src.chromium.org/viewvc/chrome/trunk/src/build/linux/system.gyp?r1=49370&r2=49369
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_browser.gypi?r1=49370&r2=49369

Reland r49135: Linux: enable compiling GNOME Keyring and KWallet integration. It's still unused.
BUG=12351,25404
TEST=GNOME Keyring and KWallet get compiled, but add no new library dependencies

Review URL: http://codereview.chromium.org/2774002
------------------------------------------------------------------------

(No comment was entered for this change.)

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=50034 

------------------------------------------------------------------------
r50034 | mdm@chromium.org | 2010-06-16 14:33:16 -0700 (Wed, 16 Jun 2010) | 4 lines
Changed paths:
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/native_backend_gnome_x.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/native_backend_gnome_x.h
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/native_backend_kwallet_x.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/native_backend_kwallet_x.h
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_default.cc?r1=50034&r2=50033
   D /trunk/src/chrome/browser/password_manager/password_store_gnome.cc
   D /trunk/src/chrome/browser/password_manager/password_store_gnome.h
   D /trunk/src/chrome/browser/password_manager/password_store_kwallet.cc
   D /trunk/src/chrome/browser/password_manager/password_store_kwallet.h
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_x.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_x.h
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_x_unittest.cc
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_browser.gypi?r1=50034&r2=50033
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_tests.gypi?r1=50034&r2=50033

Linux: refactor GNOME Keyring and KWallet integration to allow migration from the default store, and add unit tests. Still disabled.
BUG=12351, 25404
TEST=unit tests work
Review URL: http://codereview.chromium.org/2806002
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=50475 

------------------------------------------------------------------------
r50475 | mdm@chromium.org | 2010-06-22 10:22:08 -0700 (Tue, 22 Jun 2010) | 4 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/profile.cc?r1=50475&r2=50474
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.cc?r1=50475&r2=50474
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.h?r1=50475&r2=50474

Linux: allow using GNOME Keyring and KWallet for password storage via a command line flag, disabled by default.
BUG=12351, 25404, 45896
TEST=still uses default password store unless --password-store is given with a value of detect, gnome, or kwallet
Review URL: http://codereview.chromium.org/2730008
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=51094 

------------------------------------------------------------------------
r51094 | mdm@chromium.org | 2010-06-28 20:20:40 -0700 (Mon, 28 Jun 2010) | 4 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/app/sql/meta_table.cc?r1=51094&r2=51093
   M http://src.chromium.org/viewvc/chrome/trunk/src/app/sql/meta_table.h?r1=51094&r2=51093
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/login_database.cc?r1=51094&r2=51093
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/login_database.h?r1=51094&r2=51093
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_default.h?r1=51094&r2=51093
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_x.cc?r1=51094&r2=51093
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/password_store_x_unittest.cc?r1=51094&r2=51093

Linux: delete the unencrypted login database file after a successful password store migration, since otherwise fragments of password data may be left in it.
BUG=25404
TEST=the "Login Data" file should get deleted and recreated from scratch after migration
Review URL: http://codereview.chromium.org/2866023
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=52729 

------------------------------------------------------------------------
r52729 | mdm@chromium.org | 2010-07-16 13:30:42 -0700 (Fri, 16 Jul 2010) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/native_backend_gnome_x.cc?r1=52729&r2=52728
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/password_manager/native_backend_gnome_x.h?r1=52729&r2=52728

Linux: access GNOME Keyring on the GLib main thread, rather than the DB thread.
I was unable to reproduce the crash, but it's happening to a lot of people and the web suggests that moving access to GNOME Keyring to the GLib main thread should fix the problem.
BUG=48343, 25404
TEST=hopefully it won't crash for some people any more
Review URL: http://codereview.chromium.org/2953006
------------------------------------------------------------------------

Hopefully this should now be supported, just not the default. Updating the bug title and pushing default support to M7.

FWIW, I've been using it since you implemented the migration of the passwords to the store, and it works wonderfully for me.

Thanks!

Let's give this a bit longer to bake, and turn it on by default after we branch for M7.

So basically this will not be on by default in Chrome 6 but only in Chrome 7?

 Bug 53  seems to be a dupe, or at least its concerns are addressed by this fix.

No, master password requests are about the UI, not the on-disk storage.

I was just about to commit http://codereview.chromium.org/3326010/show to finish this a while back, but I discovered an important bug that should really be fixed first. So, pushing this back just a bit more.

Moving P2s with an owner to Mstone 10, bring back to M9 if you think it's important and you don't have higher priority work.

P2 bugs with an owner that are not marked as started are being automatically moved to mstone:11.

I don't understand. The resolution of this bug is delayed and delayed again. This is the main issue that prevents me and a lot of other people to use Chrome on Linux on a daily basis.

Google developers working on a Linux machine, how do you store your passwords in Chrome? Do you let them in clear text in the SQLite database? Do you encrypt your home directory? Do you use something like LastPass?

I am curious to know the recommended way to use Chrome under Linux regarding password storage.

Your advice is welcome.

You can use --password-store=detect to get secure password storage in Gnome Keyring or KWallet. There's just an important bug having to do with accessing passwords after an upgrade but before restarting that isn't fixed yet, so it's not the default setting.

Thank you for your anwser. I've just tried --password-store=detect and it works. Passwords are stored in Gnome Keyring and not in the SQLite database anymore. I will test it in the next few days. I hope this option will become the default soon for users uncomfortable with the command line :) Thank you again for your help.

Using GNOME Keyring / KWallet should be the default in the next dev channel. Not sure why bugdroid didn't post the commit: http://src.chromium.org/viewvc/chrome?view=rev&revision=70431

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=70431

------------------------------------------------------------------------
r70431 | mdm@chromium.org | Tue Jan 04 11:53:07 PST 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/profiles/profile_impl.cc?r1=70431&r2=70430&pathrev=70431

Linux: detect the native (encrypted) password store to use by default.
The basic, unencrypted store is still available with --password-store=basic.
BUG=25404
TEST=on gnome, kde 4, and probably xfce we should now use system-level stores
Review URL: http://codereview.chromium.org/3326010
------------------------------------------------------------------------

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

(No comment was entered for this change.)

(No comment was entered for this change.)