Last Comment Bug 309807 - Integrate Password Manager with Gnome Keyring Manager
: Integrate Password Manager with Gnome Keyring Manager
Status: NEW
[see extensions in comment 128]
: helpwanted
Product: Toolkit
Classification: Components
Component: Password Manager (show other bugs)
: unspecified
: All Linux
: P5 enhancement with 123 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Matthew N. [:MattN] (PM me if requests are blocking you)
Mentors:
: 410674 435207 (view as bug list)
Depends on: 386533
Blocks: 1321508
  Show dependency treegraph
 
Reported: 2005-09-23 14:42 PDT by Marius Scurtescu
Modified: 2016-12-04 07:30 PST (History)
116 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
version 0.1 (30.83 KB, patch)
2007-07-01 16:03 PDT, Sylvain Pasche
no flags Details | Diff | Splinter Review
version 0.2 (31.28 KB, patch)
2007-07-02 11:42 PDT, Sylvain Pasche
no flags Details | Diff | Splinter Review
Updated patch to compile against firefox 3 (33.54 KB, patch)
2008-08-31 13:00 PDT, Matt Lavin
no flags Details | Diff | Splinter Review
Fixes for interaction with form login (34.93 KB, patch)
2008-09-02 08:56 PDT, Matt Lavin
no flags Details | Diff | Splinter Review
Tarball to be extracted in mozilla source directory (6.86 KB, application/gzip)
2009-07-12 09:25 PDT, luca
no flags Details
New verson for firefox 3.5 (7.71 KB, application/gzip)
2009-07-17 09:58 PDT, luca
no flags Details
Firefox 3.5 extension packaged for building outside of Firefox source tree (8.21 KB, application/x-gzip)
2009-07-17 11:17 PDT, Matt Lavin
no flags Details
Makes keyring name customizable, fixes some possible leaks (27.98 KB, text/x-c++src)
2009-07-18 18:00 PDT, luca
no flags Details
Patch for GnomeKeyring.cpp and Makefile (2.40 KB, patch)
2010-03-12 08:39 PST, Leo von Klenze (TNG Technology Consulting GmbH)
no flags Details | Diff | Splinter Review
Store Master Password to Gnome Keyring patch v1 (17.85 KB, patch)
2013-01-25 05:08 PST, Jan Horak
no flags Details | Diff | Splinter Review
Store Master Password to Gnome Keyring patch v2 (17.87 KB, patch)
2013-01-28 02:50 PST, Jan Horak
no flags Details | Diff | Splinter Review
Store Master Password to Gnome Keyring patch v3 (20.07 KB, patch)
2013-02-01 05:37 PST, Jan Horak
no flags Details | Diff | Splinter Review
Store Master Password by using libsecret to Gnome Keyring patch v1 (17.17 KB, patch)
2013-02-13 06:13 PST, Jan Horak
no flags Details | Diff | Splinter Review
Store Master Password by using libsecret to Gnome Keyring patch v2 (18.75 KB, patch)
2013-02-14 04:43 PST, Jan Horak
no flags Details | Diff | Splinter Review
Modified patch to be applied to mozilla-central, but it won't compile (14.29 KB, patch)
2013-07-25 02:51 PDT, Adrien
no flags Details | Diff | Splinter Review
Refreshed patch (18.81 KB, patch)
2013-08-03 07:41 PDT, Gabriele Svelto [:gsvelto]
no flags Details | Diff | Splinter Review
Refreshed patch (18.80 KB, patch)
2013-08-15 03:03 PDT, Gabriele Svelto [:gsvelto]
no flags Details | Diff | Splinter Review

Description Marius Scurtescu 2005-09-23 14:42:55 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Firefox/1.0.4 (Ubuntu package 1.0.7)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Firefox/1.0.4 (Ubuntu package 1.0.7)

It would be nice if the Password Manager was integrate with the Gnome Keyring
Manager:
http://gnomesupport.org/wiki/index.php/GNOME_Keyring_Manager_Wiki

The mozilla-firefox-gnome-support module seems to be the right place to do this.

Reproducible: Always

Steps to Reproduce:



Expected Results:  
Instead of setting a mastter password to encript stored passwords the gnome
keyring should be used.
Comment 1 Marius Scurtescu 2005-10-08 16:02:50 PDT
Camino is doing exactly this, a similar implementation could be used.
Comment 2 Martin Meyer 2005-11-27 13:24:33 PST
I like the idea of integrating the password manager with Gnome, but is it possible to make it so that any password manager application could be made to plug into Firefox's password management system?  It would be nice to use Norton Password Manager on Windows, or whatever comercial program the user happens to like and have Firefox use it directly.  This would be a good thing for integration with operating environments and other applications.
Comment 3 Justin Dolske [:Dolske] 2007-06-03 02:32:31 PDT
Now that the Login Manager rewrite has landed on trunk for Firefox 3, writing a module to implement this support should be much easier. Basically, someone needs to write a component implementing the nsILoginManagerStorage interfaces, and that component would interact with the Gnome Keyring as needed.

This interface is described here: http://mxr.mozilla.org/seamonkey/source/toolkit/components/passwordmgr/public/nsILoginManagerStorage.idl

This task isn't currently on my to-do list, but I'd be happy to help explain the Login Manager interaction if someone wants to take a shot at this.
Comment 4 Sylvain Pasche 2007-06-04 03:52:16 PDT
One potential issue I'm seeing is that nsILoginManagerStorage makes synchronous requests, which will freeze the UI while Gnome Keyring is asking for the password.

I'm not completely sure, but I also have the feeling the OS X Keychain API blocks the calling thread while waiting for the password (SecKeychainFindInternetPassword). That would mean the same issue happens for the OS X implementation.
Comment 5 Sylvain Pasche 2007-06-12 00:21:10 PDT
I'm going to work on this, feel free to contact me if you want to help.
Comment 6 Sylvain Pasche 2007-07-01 16:03:45 PDT
Created attachment 270527 [details] [diff] [review]
version 0.1

First version. There are some issues when used with the password manager, like asking to save password more that necessary, or not updating password if changed.

See the XXX for other things to improve. There is no caching involved, so there are round-trips to the gnome-keyring-daemon for every page containing a form, which could be bad for performances.

I can confirm the issue where the UI is frozen in case gnome-keyring daemon is asking for confirmation. I saw that this is also happening with Camino+Keychain, but that's less an issue on OS X as the window content is buffered, unlike on X11 where it is not refreshed if we move another window above (ok, that should not be the case when using a compositing window manager).
Comment 7 Sylvain Pasche 2007-07-02 11:42:14 PDT
Created attachment 270611 [details] [diff] [review]
version 0.2

Forgot to unregister the category, and fixed an unused variable warning.
Comment 8 Sylvain Pasche 2007-09-23 06:47:53 PDT
This went low priority for me, feel free to take this over.
Comment 9 Dave Townsend [:mossop] 2008-01-03 11:57:02 PST
*** Bug 410674 has been marked as a duplicate of this bug. ***
Comment 10 Jakub 'Livio' Rusinek 2008-01-03 12:36:20 PST
Does GNOME keyring replace Firefox internal password manager?
If not, it should.
Comment 11 Sylvain Pasche 2008-01-03 13:05:40 PST
(In reply to comment #10)
> Does GNOME keyring replace Firefox internal password manager?

no

> If not, it should.

That's what this bug is about, but no one is working on it right now.

Comment 12 Jakub 'Livio' Rusinek 2008-01-03 14:16:12 PST
Exactly the same situation with some non-duped bugs I've filed.
Comment 13 dan_500 2008-02-21 06:22:50 PST
This bug is not only firefox related. It's a core bug.
Comment 14 Sylvain Pasche 2008-02-21 08:38:19 PST
I agree, it should rather be toolkit related (password manager is in toolkit/components/passwordmgr), but there's no Toolkit/Password Manager component.
Comment 15 Justin Dolske [:Dolske] 2008-02-21 12:12:44 PST
There's been much discussion on reorganizing Bugzilla (eg, the thread rooted at http://groups.google.com/group/mozilla.dev.planning/msg/5c973137356768b0). It's been deferred for a variety of reasons, but should eventually happen. In the meantime, it's understood that a number of components in Firefox are effectively in Toolkit, so it's not really an issue. [The code is, in fact, in /toolkit.]
Comment 16 Thomas K. (:tom) 2008-03-28 17:54:54 PDT
(In reply to comment #1)
> Camino is doing exactly this, a similar implementation could be used.
> 

That's a different bug, the mac only bug 106400.
Comment 17 Justin Dolske [:Dolske] 2008-05-24 14:13:40 PDT
*** Bug 435207 has been marked as a duplicate of this bug. ***
Comment 18 Matt Lavin 2008-08-31 13:00:30 PDT
Created attachment 336264 [details] [diff] [review]
Updated patch to compile against firefox 3

I've modified the patch lightly to get it to compile on Firefox 3.
Comment 19 Matt Lavin 2008-09-02 08:56:18 PDT
Created attachment 336498 [details] [diff] [review]
Fixes for interaction with form login

While testing the latest path, I noticed that it didn't properly store and retrieve passwords saved in forms.  I've attached an updated patch that works for me.  

There are some more things that could be improved about the code, but what are the steps to get this included in Firefox proper?
Comment 20 Jakub 'Livio' Rusinek 2008-09-02 10:02:02 PDT
I have simple question: does this include migration?
Comment 21 Matt Lavin 2008-09-02 10:13:43 PDT
The current code doesn't include any migration support.
Comment 22 Matt Lavin 2008-09-02 17:43:03 PDT
I've uploaded an installable version of this extension to https://addons.mozilla.org/en-US/firefox/addon/8737 to enable more people to test out the integration.  Hopefully, some people will be able to give some good feedback to improve it.
Comment 23 Jens 2008-09-03 12:37:46 PDT
I've tried the extension.

When it's installed I'm unable to store passwords.
The prompt "Would you like firefox to remember this password" stays visible after I click on "save password". No passwords is added to my keyring.

How can I debug this?
Comment 24 Matt Lavin 2008-09-03 12:41:02 PDT
What are you using to verify that the password was added to the keyring?  If you return to the same page again, is the password automatically filled in?  Are there any errors in the Tools -> Error Console page?
Comment 25 Jens 2008-09-03 13:20:41 PDT
I get this exeption in the console:

Fel: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsILoginManagerStorage.addLogin]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: file:///usr/lib/xulrunner-1.9.0.1/components/nsLoginManager.js :: anonymous :: line 388"  data: no]

The password I tried to add does not appear in firefox password list, nor in seahorse (g-k-m frontend).

Im using Ubuntu 8.04 with a keyring that is automatically unlocked on login.
Comment 26 Sylvain Pasche 2008-09-03 13:57:45 PDT
(In reply to comment #19)
> There are some more things that could be improved about the code, but what are
> the steps to get this included in Firefox proper?

Hi Matt, thanks for your work on this. The steps would be to find someone to review this. There are instructions on http://developer.mozilla.org/en/Getting_your_patch_in_the_tree how to find the right reviewer.

Another more general question is to know if this should be part of Firefox or should live as an extension.

On a more technical side, is the issue raised in comment 4 still there? That would be nice to have it addressed (it may not be trivial, if the API has to change to get asynchronous).

I was a bit worried about performance (comment 6). It could be interesting to see how having the addon enabled can impact performance when browsing pages with passwords (https://wiki.mozilla.org/StandaloneTalos is one of the tool for measuring regressions). Caching could help if the performance is an issue.

The current patch implements nsILoginManagerStorage directly in C++. Another approach I thought about would be to wrap the low-level Gnome Keyring API in a C++ component and then implement nsILoginManagerStorage in JS. That should make things simpler for adding caching (if needed), managing preferences (keyring name is hardcoded right now for instance) or others. (https://wiki.mozilla.org/JSctypes could be useful here but I don't think it's ready yet)
Comment 27 Justin Dolske [:Dolske] 2008-09-03 18:05:05 PDT
I think I'd sort of like to see more experience with people using this as an extension, first. One of the things that I want to be cautious about is moving where we store things (mozStorage vs keyring/keychain) without compelling value... The pessimistic view here is that most users won't care, and it incurs code maintenance costs.

One variation that would also be interesting to pursue is leaving the password storage where it is now, but using the keyring/keychain for storing a decryption key (sort of like a master password). For users that don't want the annoyance of a master password (as we currently implement it), pulling a decryption key from a system DB that's secured with the user's *login credentials* would be an improvement.
Comment 28 Matt Lavin 2008-09-03 18:48:30 PDT
(In reply to comment #25)
> I get this exeption in the console:

I've uploaded a new version of the extension that enables some logging to get extra information about your failure.  You can see the extra logging by running firefox from a command line like "NSPR_LOG_MODULES=GnomeKeyringLog:5  firefox -no-remote"

You should see a message or two like:
-1211177280[805ca10]: GK_ENSURE_SUCCESS(2) failed

In the console, and that will help us figure out why you can't safe passwords.
Comment 29 Matt Lavin 2008-09-03 18:55:53 PDT
Thanks for all the feedback.  I'll keep an eye on performance problems.  About the screen repaint issue, I just got prompted to allow access to the keyring and Firefox had no problem repainting in the background.

I was personally motivated to fix get the gnome-keyring integration out there because I wanted to reduce the number of unencrypted passwords on my drive.  Since that's my main goal, I don't mind if this feature lives as an extension or as part of the standard packaging as long as I can use it =).

As for the relative value of the keyring integration, it's all about security (although something like your suggestion would have worked as well). The argument that "that most users won't care" should really be re-phrased to say "that most users won't care, until they sell their machine and the buyer uses their passwords left on disk".  Leveraging something like gnome-keyring to get the password encryption for free seemed like a easy win for me (and Sylvain had done most of the work already).
Comment 30 Sylvain Pasche 2008-09-04 00:16:40 PDT
(In reply to comment #27)
> One variation that would also be interesting to pursue is leaving the password
> storage where it is now, but using the keyring/keychain for storing a
> decryption key (sort of like a master password). For users that don't want the
> annoyance of a master password (as we currently implement it), pulling a
> decryption key from a system DB that's secured with the user's *login
> credentials* would be an improvement.

That seems a good way to go. At the time, I started writing an extension to store the master password in the Gnome Keyring (however I didn't finish it). The idea was to have an option when setting the master password like "Generate and store Master Password in Keyring". Then a component would set it automatically during startup.
Comment 31 Jens 2008-09-04 05:05:45 PDT
(In reply to comment #28)
> You can see the extra logging by running
 firefox from a command line like "NSPR_LOG_MODULES=GnomeKeyringLog:5  firefox
> -no-remote"
> 
> You should see a message or two like:
> -1211177280[805ca10]: GK_ENSURE_SUCCESS(2) failed
> 
> In the console, and that will help us figure out why you can't safe passwords.

I just tried this on another computer and it worked without any errors.
However, the passwords are only visible in firefox, not seahorse. Is that correct?
Comment 32 Matt Lavin 2008-09-04 05:08:48 PDT
(In reply to comment #31)
> However, the passwords are only visible in firefox, not seahorse. Is that
> correct?

That's because the passwords are stored in the 'default' keyring, and not the 'login' keyring.  Apparently, Seahorse only shows the passwords in the 'login' keyring.
Comment 33 Jens 2008-09-04 05:40:58 PDT
(In reply to comment #32)
> (In reply to comment #31)
> > However, the passwords are only visible in firefox, not seahorse. Is that
> > correct?
> 
> That's because the passwords are stored in the 'default' keyring, and not the
> 'login' keyring.  Apparently, Seahorse only shows the passwords in the 'login'
> keyring.

Ah, I see!

The entry may look nicer to the user in the sehorse password listing if the type GNOME_KEYRING_ITEM_NETWORK_PASSWORD is used. Also, the display name is currently set to "Mozilla keyring entry". It should probably be the url, or something like "User at http://hostname..."
Comment 34 Leo von Klenze 2008-09-28 02:15:54 PDT
Hello!

I've downloaded the patch and compiled it successfully under my 64-bit Ubuntu. After installation the extension is displayed by firefox as active extension.

I used the command from comment #28 but I don't see any log messages that might belong to the gnome keyring extension. The passwords are saved but I think they are saved by the firefox password manager, because I can't see them in seahorse, even after setting the keyring to 'login'.

Missed I something?
Thanks!
Comment 35 legolas558 2008-11-23 03:52:02 PST
This feature is a win-win! How long should it take before I can see it as an extension?

Thanks
Comment 36 Sylvain Pasche 2008-11-23 09:48:45 PST
(In reply to comment #35)
> This feature is a win-win! How long should it take before I can see it as an
> extension?

Not very long: https://addons.mozilla.org/en-US/firefox/addon/8737 (see comment 22)
Comment 37 wlallemand 2009-01-21 03:06:47 PST
Hello ! 
I've installed the last 0.2 firefox plugin.
That doesn't seem to work.
I'm using firefox 3.0.5 on ubuntu 8.10.

 NSPR_LOG_MODULES=GnomeKeyringLog:5 firefox -no-remote
-1210722624[95d8638]: Num items: 0
-1210722624[95d8638]: Num items: 0
-1210722624[95d8638]: GK_ENSURE_SUCCESS(4) failed
-1210722624[95d8638]: Num items: 0
-1210722624[95d8638]: GK_ENSURE_SUCCESS(4) failed

Gnome doesn't ask me to authorize firefox to use gnome-keyring.
When I click on "Add Password" on the bar, that do nothing, I have to click on "never" or "not now" for see the bar disappear.
Comment 38 Jesper Zedlitz 2009-05-18 01:33:43 PDT
(In reply to comment #37)
> -1210722624[95d8638]: GK_ENSURE_SUCCESS(4) failed
>
Error code 4 means "no such keyring". The add-on uses the keyring "default" instead of Gnome's default keyring "login". You can create a new keyring using Gnome's seahorse program.
Comment 39 Jens 2009-06-22 04:10:26 PDT
Unfortunately, this extension does not play well with xmarks bookmarks and password synchronization extension (http://www.xmarks.com).

If I install this extension after having used xmarks for a while, no stored passwords shows up and the master password for xmarks is gone.
Comment 40 John Vivirito 2009-07-08 13:33:18 PDT
Is this going to be implemented in Xulrunner or in an extension? I would like to not have to add extension to make this work. I dont use too many extensions but i know people with 10+ installed adn the risk of crashes is fairly high at that point adding another isnt the best way to fix this IMHO
Comment 41 luca 2009-07-12 09:25:33 PDT
Created attachment 388144 [details]
Tarball to be extracted in mozilla source directory

Hi,
I tried to iron away some problems with the extension:
* I set it to use its own keyring, named mozilla. Since items' attributes are tailored to fit mozilla login manager, it seems to me this makes more sense than cluttering the default keyring. This way, one can also decide whether to unlock it on log in or not independently from the default keyring.
* Most importantly, I made the component create the keyring if it doesn't exist.
I think this should make it work for most of the people that were unable to save passwords.
* The item name is now the hostname for which the password is saved (makes more sense than "Mozilla keyring entry" for every item)
* I took the liberty to add Matt Lavin and myself to the contributors.

These are the most prominent issues that I feel should be addressed next:
* The component still builds with the mozilla build sistem, I'd like to make it a separate extension but I don't know how to do it...
* I still have to move to firefox 3.5, I don't know if it works with it.
* It would be very nice to be able to migrate logins from and back to the built-in login manager, maybe prompting the user whether they want to delete logins from the unused login manager.
* Even when using gnome-keyring as login manager, you still get asked for the master password if you want to see the passwords on the "saved passwords" window. This only happens if the master password is set. I think this is firefox's fault.

By now, what I think is most important is to build it as an extension and to make it compatible with firefox 3.5
Help is appreciated...
Comment 42 luca 2009-07-17 09:58:41 PDT
Created attachment 389136 [details]
New verson for firefox 3.5

This is the new version for firefox 3.5, it doesn't work for firefox 3.0 because the interface has changed.
I plan to build an extension out of it and upload it on amo in the next days.
Comment 43 Matt Lavin 2009-07-17 11:17:26 PDT
Created attachment 389159 [details]
Firefox 3.5 extension packaged for building outside of Firefox source tree

Thanks for the updates to support 3.5.  Sometime during the 3.5 cycle I made changes to my local files to support building outside of the Firefox development tree.  I've attached a version of that build environment that includes your fixes.  That should allow easier building of the extension by other people.
Comment 44 luca 2009-07-18 18:00:53 PDT
Created attachment 389337 [details]
Makes keyring name customizable, fixes some possible leaks

The Makefile provided by Matt works perfectly, just note that if you compile for amd64 you need to add -fPIC to CPPFLAGS and put /Linux_x86_amd64-gcc3 everywhere you read Linux_x86-gcc3.
This new version makes keyring name customizable, you need to create a string preference entry named extensions.gnome-keyring.keyringName to change it.
Note that logins you've already saved will still be used, because gnome-keyring searches through all unlocked keyrings, not just the one we're using.
Comment 45 Matt Lavin 2009-07-20 08:36:17 PDT
I just started a github project that holds my source tree.  I've added the changes from luca in comment 44, along with adding the -fPIC compile flag by default.

The github URL is http://github.com/mdlavin/firefox-gnome-keyring/tree/master.  If somebody would like to make the Makefile more flexible to handle the "Linux_x86_amd64-gcc3" / "Linux_x86-gcc3" changes automatically, that would be great.
Comment 46 guillermoadrianmolina@hotmail.com 2009-11-13 12:20:34 PST
Hello, I've created a new extension based on this one. It is useful to connect to kde's kwallet. My questions are:
Am I violating any license issue?, in other words, am i allowed to create a new extension based on this one?
Where do I commit this extension?, should I use https://addons.mozilla.org/ ? or as a new bug request here?

Thanks in advance.
Comment 47 Jesse Glick 2009-11-13 13:53:56 PST
(In reply to comment #27)
> leav[e] the password storage where it is now, but us[e] the keyring/keychain
> for storing a decryption key (sort of like a master password)

Agreed. I would rather have such an option than the current extension, even if it added a password migration feature (the lack of which prevents usage for someone like me with hundreds of entries). The built-in password manager is fine except for the need to type in a master password every session. Is there any interface for an extension to replace just the "Enter Master Password" dialog?
Comment 48 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2009-11-13 14:06:04 PST
(In reply to comment #47)
I filed bug 496660 (essentially what Dolske proposed in comment #27) a while ago. That's OSX specific, but no implementation is done. There's some work being done in other bugs to separate out the dependence on the master password as is.
Comment 49 Alexey Fisher 2009-11-16 11:50:06 PST
Looks like this plugin do not working for me. Installed, but password are stored to mozilla storage - not to gnome-keyring.
Comment 50 Leo von Klenze (TNG Technology Consulting GmbH) 2010-03-12 08:39:48 PST
Created attachment 432158 [details] [diff] [review]
Patch for GnomeKeyring.cpp and Makefile

Hello,

I found a bug in GnomeKeyring.cpp. The following line is wrong
   const char* tempHostname = NS_ConvertUTF16toUTF8(s).get();
because the NS_ConvertUTF16toUTF8 object is destroyed just after this statement. That causes the pointer tempHostname to be invalid. In some cases the memory of this pointer was overidden by subsequent calls before the value was stored in the attribute list.

The changes in install.rdf just enable the extension for thunderbird and newer firefox version which works great on my machine.

Hope this helps,
 Leo
Comment 51 yury.sobolev 2010-05-24 00:06:02 PDT
(In reply to comment #26)
> The current patch implements nsILoginManagerStorage directly in C++. Another
> approach I thought about would be to wrap the low-level Gnome Keyring API in a
> C++ component and then implement nsILoginManagerStorage in JS. That should make
> things simpler for adding caching (if needed), managing preferences (keyring
> name is hardcoded right now for instance) or others.
> (https://wiki.mozilla.org/JSctypes could be useful here but I don't think it's
> ready yet)

If there is interest, I have a mostly working version written in pyxpcom. It is not quite compatible with the C++ version, but that can be easily changed. I do not think it is especially useful, since it does require the python extensions, but it may be handy for prototyping.
Comment 53 legolas558 2010-06-24 13:30:09 PDT
Wow, 2 years have elapsed, I was using Gentoo then and now I am using Arch. Glad that it is available now, opting out
Comment 54 Mildred Ki'Lya 2010-09-21 00:27:09 PDT
Is there any information about Firefox support for gnome-keyring?
Currently, the extension http://github.com/nougad/firefox-gnome-keyring isn't supposed to work on Firefox 4 and I have no idea if the porting work is difficult or straightforward.
Comment 55 Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2010-10-29 14:40:58 PDT
(In reply to comment #54)
> Is there any information about Firefox support for gnome-keyring?

Our support hasn't changed. We don't have any support for it natively but overriding the login storage module with an extension should continue to work.

> Currently, the extension http://github.com/nougad/firefox-gnome-keyring isn't
> supposed to work on Firefox 4 and I have no idea if the porting work is
> difficult or straightforward.

The extension probably needs to be updated to handle the changes in XPCOM component registration: https://developer.mozilla.org/en/XPCOM/XPCOM_changes_in_Gecko_2.0#Component_registration
Comment 56 Launchpad 2012-01-02 10:35:08 PST
typo added the following comment to Launchpad bug report 217300:

Use case:
I like to encrypt all my credentials (website/username/password entries) with a password. But I don't like to enter too many passwords when I use my computer. So i'd like to unlock my keyring with my login password like LightDM and Seahorse do it right know quite well. ("login" keyring) But sadly Firefox doesn't support this feature, so that I have to enter my password a second time.

-- 
http://launchpad.net/bugs/217300
Comment 57 Jesse Glick 2012-01-03 14:41:52 PST
FWIW Chrome on Ubuntu Oneiric seems to use the login keyring out of the box - and on first start will offer to import your Firefox passwords, copying them to the native keyring.
Comment 58 Jean-Alexandre Anglès d'Auriac 2012-02-08 14:56:09 PST
I think this would be much better included in Firefox that as an extension, as both Firefox himself and other extensions can tr
Comment 59 Jan Horak 2013-01-08 02:34:17 PST
So what is current Mozilla point of view to incorporate this enhancement to Firefox directly (without extension)? And if so what is more preferable:
1. store all saved password in keyring
2. store only master password in keyring.
Comment 60 Justin Dolske [:Dolske] 2013-01-13 14:34:06 PST
I guess I would say that it's not clear to me that integration with the system keystore provides significant value (cost/benefit), and so I don't see this happening any time soon. I'd also be concerned about it adding complexity for Sync.

The master password is a whole 'nother ball ox wax, still up in the air.
Comment 61 bustervill 2013-01-13 23:37:50 PST
Well, the benefit would be a single store for passwords/keys instead of every application having its own.
Firefox is not the center of the universe, you know.
If this feature won't be implemented, then you should close this bug report.
What is the benefit of keeping a feature request open for 7 years if you "don't see this happening any time soon"?
Comment 62 Romain Chossart 2013-01-14 01:15:03 PST
This is my own experience, but at the moment Firefox is the only application I use where I need to type a password each time I fire it, due to this lack of keychain integration.

At a time where firefox needs to distinguish itself from his concurrents, it is easy to see the benefits (although I understand the costs might be too high).
Comment 63 Murz 2013-01-14 01:20:42 PST
Expiring same problem too. For KDE environment this issue can be fixed via extension https://addons.mozilla.org/ru/firefox/addon/kde-wallet-password-integratio/ but there are no easy-to-install way for Gnome. 

So most of users stores Firefox passwords non-secured like as plain text, this is large security hole! 

Using master password is not good solution, because users will must enter it after each restart firefox.

Google Chrome have build-in support for Gnome Keyring and KDE Wallet, so will be good if Firefox can have this support too!
Comment 64 Mikko Rantalainen 2013-01-14 05:33:58 PST
For Gnome compatible environments: there's no ready-made extension at addons.mozilla.org but you can fetch the latest version from https://github.com/infinity0/mozilla-gnome-keyring or if you use Ubuntu, you can add PPA from https://launchpad.net/~fat-lobyte9/+archive/ppa-public and install package called "mozilla-gnome-keyring" which will add password integration for both Firefox and Thunderbird.
Comment 65 Johannes [:tschoie] 2013-01-14 05:52:12 PST
(In reply to Mikko Rantalainen from comment #64)
> For Gnome compatible environments: there's no ready-made extension at
> addons.mozilla.org but you can fetch the latest version from
> https://github.com/infinity0/mozilla-gnome-keyring or if you use Ubuntu, you
> can add PPA from https://launchpad.net/~fat-lobyte9/+archive/ppa-public and
> install package called "mozilla-gnome-keyring" which will add password
> integration for both Firefox and Thunderbird.

This is only partly correct as this does not seem to work on Ubuntu >= 12.10. [1] Now I know that Ubuntu is not the only GNOME-based distro and Mozilla doesn't seem to be the one to blame for these particular difficulties, but I as a user of both Ubuntu and Firefox would love to see an implementation of this feature...

[1] https://github.com/infinity0/mozilla-gnome-keyring/issues/26
Comment 66 Jan Horak 2013-01-14 05:54:23 PST
Storing only master password in (Gnome/KDE) keyring could be less complicated in this case and it would still work with Mozilla's Sync, wouldn't it?
Comment 67 Launchpad 2013-01-15 03:41:34 PST
nodiscc added the following comment to Launchpad bug report 41179:

> This is only partly correct as this does not seem to work on Ubuntu >= 12.10.
You should try the official debian package at
http://packages.debian.org/experimental/xul-ext-gnome-keyring

2013/1/14 Jhorak <41179@bugs.launchpad.net>:
> Storing only master password in (Gnome/KDE) keyring could be less
> complicated in this case and it would still work with Mozilla's Sync,
> wouldn't it?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/41179
>
> Title:
>   Integrate with Gnome Keyring
>
> Status in The Mozilla Firefox Browser:
>   Confirmed
> Status in “firefox” package in Ubuntu:
>   Won't Fix
> Status in “xulrunner-1.9” package in Ubuntu:
>   Won't Fix
> Status in “xulrunner-1.9.1” package in Ubuntu:
>   Triaged
>
> Bug description:
>   For a really good Gnome integration, it would be great to have the
>   ability to save passwords in the Gnome keyring.
>
>   A similar thing has been proposed for Epiphany: see
>   https://launchpad.net/malone/bugs/3467.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/firefox/+bug/41179/+subscriptions


-- 
http://launchpad.net/bugs/41179
Comment 68 Johannes [:tschoie] 2013-01-15 04:08:27 PST
(In reply to Launchpad from comment #67)
> nodiscc added the following comment to Launchpad bug report 41179:
> 
> > This is only partly correct as this does not seem to work on Ubuntu >= 12.10.
> You should try the official debian package at
> http://packages.debian.org/experimental/xul-ext-gnome-keyring
> 

Thanks, but this package has an iceweasel/icedove dependency...
Comment 69 Matěj Cepl 2013-01-15 04:46:02 PST
(In reply to Murz from comment #63)
> So most of users stores Firefox passwords non-secured like as plain text,
> this is large security hole! 

No, it doesn't ... Firefox native password store is of course heavily encrypted (although with only optional password, true).

Otherwise, +1 to comment 66 ... unless the solution works with Firefox Sync (and thus with all those smartphones/tables) it couldn't be IMHO a part of the native Firefox.
Comment 70 Murz 2013-01-15 05:09:58 PST
(In reply to Matej Cepl from comment #69)
> (In reply to Murz from comment #63)
> > So most of users stores Firefox passwords non-secured like as plain text,
> > this is large security hole! 
> 
> No, it doesn't ... Firefox native password store is of course heavily
> encrypted (although with only optional password, true).

How Firefox can heavily encrypt them if user set empty password? As I see, most of users don't want to enter additional password on each open browser, and also many users even don't know about this feature (because Firefox don't suggest to encrypt passwords on install or first start).

So in most of Firefox installs passwords are not encrypted, and any other user can view it (for example via PasswordFox application).

In Google Chrome passwords are encrypted by default in windows via user password (Chrome uses a Windows provided API function which makes the encrypted data only decipherable by the Windows user account used to encrypt the password. So essentially, your master password is your Windows account password), on Gnome - stored in Keyring, on KDE - in KWallet, so user must not enter password on browser start and passwords are stored in encrypted format.

Will be glad to see something solution like in Chrome for password encryption by-default in Firefox.
Comment 71 Alexander Korsunsky 2013-01-15 10:38:56 PST
(In reply to Justin Dolske [:Dolske] from comment #60)
> I guess I would say that it's not clear to me that integration with the
> system keystore provides significant value (cost/benefit)
As it has been made clear already, the benefit is
1) that on a usual Desktop, multiple applications need to store passwords and it would be a very intelligent idea to handle all these passwords in one place and 
2) that the "Master password" prompt is extremely annoying, especially if one used both Firefox and Thunderbird. Quite frankly, I do not understand why Mozilla devs are so neglecting towards password security! The master password prompt is inconvenient and broken (see [4]) and the only remedy would be to store the passwords in plain text.


(In reply to Launchpad from comment #67)
> > This is only partly correct as this does not seem to work on Ubuntu >= 12.10.
> You should try the official debian package at
> http://packages.debian.org/experimental/xul-ext-gnome-keyring
This is not going to work. The Debian package is linked against libxul, and requires the libxul headers and libraries. These do not exist on Ubuntu >= 12.10. If you try to build it yourself, you will get FTBFS; if you try to use the binary, it simply won't work because of missing libraries.

(In reply to Mikko Rantalainen from comment #64)
> For Gnome compatible environments: there's no ready-made extension at
> addons.mozilla.org but you can fetch the latest version from
> https://github.com/infinity0/mozilla-gnome-keyring or if you use Ubuntu, you
> can add PPA from https://launchpad.net/~fat-lobyte9/+archive/ppa-public and
> install package called "mozilla-gnome-keyring" which will add password
> integration for both Firefox and Thunderbird.
As already mentioned, this will not work on Ubuntu >= 12.10.

Let me explain the situation:
By copying the cool kinds on the block (G. Chrome) and introducing the rapid release cycle for Firefox, Mozilla really made things hard for developers.

Our extension is a binary one (we need to link against libgnomekeyring), so we need to rebuild the extensions for every new Firefox release.
Ubuntu, in an attempt to follow the rapid release cycle, dropped the "xulrunner" library, and build Firefox and Thunderbird seperately. They (understandably) don't want to maintain binary extensions and they (not understandably) removed all headers from the firefox-dev and thunderbird-dev packages [1][2]).
They argue that extension devs should either make their extensions non-binary or that they be integrated into Firefox itself [2].
Now (as I understand correctly) Mozilla is saying they don't actually care?


Let me get this clear. People need this functionality. I can tell you that because otherwise this bug report would not exist for 8(!!!) years and have 70 replies, and most of all because [3] does have a fair amount of users.
Most of the code already exists[3]. Are you (Mozilla devs) saying (or implying by silence) that Mozilla does not give a f*ck about your Users on GNOME?
What happened to "listening to feedback" and "caring about users"? Or do you actually mean "caring about the average Windows users"?


[1] https://lists.ubuntu.com/archives/ubuntu-motu/2011-May/007088.html
[2] https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1030504
[3] https://github.com/infinity0/mozilla-gnome-keyring
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=536140
Comment 72 Burrito Bazooka 2013-01-15 15:10:18 PST
I posted earlier in this thread (probably so long ago that I can't find it :U)

I'd like to reiterate my motion that this is a needed feature. I believe, as an end user, and an experienced computer user, who knows a fair bit about securing end user stuff, I believe that Firefox will be forever incomplete if it does not integrate with the major operating systems' secure password storage systems.

Implement it, please, into Mozilla Firefox itself, so that all users can have a good, easy, and slightly more secure experience in using Mozilla Firefox. As mentioned above, the code is already there. Or, state directly (meaning straight from the developers' mouthes) the major and crippling disadvantage that means that it cannot be implemented. Feel free to use as much technical language as you wish, in order to convince us that your way is correct, so that we can end this 8 year long struggle for one simple feature, one way or another.

Seriously, this is equal to how Yahoo Mail hasn't used HTTPS for ages, until AccessNow made a little noise.
Comment 73 Burrito Bazooka 2013-01-15 15:36:37 PST
Oh, looks like I only subscribed, not posted.
Comment 74 Gabriele Svelto [:gsvelto] 2013-01-16 00:06:53 PST
I think the idea of using the native keyring to store the master password is sound. I'd be glad to try and implement it for gnome-keyring once I've got some spare time on my hands.
Comment 75 guillermoadrianmolina@hotmail.com 2013-01-17 04:34:54 PST
Hi there, I've made a new extension to store passwords on keyring. It is based on another extension (written by me) that uses kde wallet manager, which was based on the original extension named here. It is being checked right now, but you can download and test it from: http://www.guillermomolina.com.ar/index.php/es/archivos/category/2-firefox-gnome-keyring-extension?download=20:firefox-gnome-keyring-extension-version-0-1

Cheers.
Comment 76 Burrito Bazooka 2013-01-17 07:33:51 PST
I'm very glad that this is making progress, I'm sure others are too :)
Comment 77 Jan Horak 2013-01-25 05:08:52 PST
Created attachment 706354 [details] [diff] [review]
Store Master Password to Gnome Keyring patch v1

I've made a patch for storing Master password to Gnome Keyring. Not sure who ask for review. I'm trying you neil as long as I see you as peer on Passwords & Permissions module.
Comment 78 neil@parkwaycc.co.uk 2013-01-25 05:26:50 PST
Comment on attachment 706354 [details] [diff] [review]
Store Master Password to Gnome Keyring patch v1

You need build system and PSM reviews, so I'll just comment on code patterns.

>+      PRUnichar *password = nullptr;
>+      nsAutoString promptString;
>+      
>+      // Get prompt message for Gnome Keyring master password
>+      nsCOMPtr<nsINSSComponent> nssComponent(do_GetService(kNSSComponentCID, &rv));
>+      if (NS_FAILED(rv))
>+        return;
>+
>+      const PRUnichar* formatStrings[1] = { 
>+        ToNewUnicode(NS_LITERAL_STRING("Gnome Keyring"))
>+      };
NS_NAMED_LITERAL_STRING gnomeKeyring("Gnome Keyring");
const PRUnichar* formatStrings[] = { gnomeKeyring.get() };
Or since this is linux-only, MOZ_LL, NS_LL or u"Gnome Keyring" might work.
This avoids having to free the string manually.

>+        // Return if promp was closed without confirmation or password is wrong
Typo: prompt

>+        if (value)
[I had to look up the .idl to find out what this value meant.]

>+          nsCString utf8password;
>+          utf8password = NS_ConvertUTF16toUTF8(password);
>+          NS_Free(password);
>+          password = nullptr;
>+          if (gnome_keyring_unlock_sync(NULL, utf8password.get()) == GNOME_KEYRING_RESULT_OK)
gnome_keyring_unlock_sync(NULL, NS_ConvertUTF16toUTF8(password).get())

>+        mResult = g_strdup(keyringRecord->secret);
[Does this get freed with g_free?]
Comment 79 Jan Horak 2013-01-25 07:58:19 PST
(In reply to neil@parkwaycc.co.uk from comment #78)
> Comment on attachment 706354 [details] [diff] [review]
> Store Master Password to Gnome Keyring patch v1
> 
> You need build system and PSM reviews, so I'll just comment on code patterns.
> 
> >+      PRUnichar *password = nullptr;
> >+      nsAutoString promptString;
> >+      
> >+      // Get prompt message for Gnome Keyring master password
> >+      nsCOMPtr<nsINSSComponent> nssComponent(do_GetService(kNSSComponentCID, &rv));
> >+      if (NS_FAILED(rv))
> >+        return;
> >+
> >+      const PRUnichar* formatStrings[1] = { 
> >+        ToNewUnicode(NS_LITERAL_STRING("Gnome Keyring"))
> >+      };
> NS_NAMED_LITERAL_STRING gnomeKeyring("Gnome Keyring");
> const PRUnichar* formatStrings[] = { gnomeKeyring.get() };
> Or since this is linux-only, MOZ_LL, NS_LL or u"Gnome Keyring" might work.
> This avoids having to free the string manually.

Thanks for feedback.
The u"str" or NS_LL is char16_t*. I'm not sure if I can safely cast it to PRUnichar), can I?
Comment 80 Mike Hommey [:glandium] 2013-01-25 08:43:31 PST
(In reply to jhorak from comment #79)
> Thanks for feedback.
> The u"str" or NS_LL is char16_t*. I'm not sure if I can safely cast it to
> PRUnichar), can I?

Note you can't use u"" because that's only supported in c++11 mode, and we still support not building in that mode.
Comment 81 Jan Horak 2013-01-28 02:50:19 PST
Created attachment 707001 [details] [diff] [review]
Store Master Password to Gnome Keyring patch v2

Fixed patch, asking for review from PSM.
The patch has one drawback though. In Saved Passwords list the master password is not required to show password for each record. However Gnome keyring also allows to show password without typing master password too - user is supposed to lock his screen when leaving his computer alone...
Comment 82 Jan Horak 2013-02-01 05:37:31 PST
Created attachment 709034 [details] [diff] [review]
Store Master Password to Gnome Keyring patch v3

Changes
 - Prompt user if he wants to store master password to Gnome Keyring.
 - rewritten patch a bit to avoid a lot of nested ifs.
Changing reviewer as long as Kai showed some interest in this patch. Thanks.
Comment 83 Jan Horak 2013-02-13 06:13:04 PST
Created attachment 713377 [details] [diff] [review]
Store Master Password by using libsecret to Gnome Keyring patch v1
Comment 84 Stef Walter 2013-02-13 08:08:00 PST
Comment on attachment 713377 [details] [diff] [review]
Store Master Password by using libsecret to Gnome Keyring patch v1

Review of attachment 713377 [details] [diff] [review]:
-----------------------------------------------------------------

Overall looks good. Haven't tested. Just a few comments.

::: configure.in
@@ +4989,5 @@
> +
> +    if test "$MOZ_ENABLE_LIBSECRET"
> +    then
> +        PKG_CHECK_MODULES(MOZ_LIBSECRET, libsecret-1 >= $LIBSECRET_VERSION,[
> +            MOZ_LIBSECRET_LIBS=`echo $MOZ_LIBSECRET_LIBS | sed 's/-llinc\>//'`

Are you sure you need this? If so, I'd be interested to know on which platform libsecret has that in its pkg-config file.

::: security/manager/ssl/src/nsNSSCallbacks.cpp
@@ +751,5 @@
> +on_lookup_finished(GObject *source,
> +                   GAsyncResult *result,
> +                   gpointer data)
> +{
> +  gchar *pwd =  secret_password_lookup_finish(result, nullptr);

Is it worth retrieving the error and logging it if things fail? May make our lives easier in the future if people run into problems and we have to diagnose them remotely.

@@ +803,5 @@
> +  nsCString keyDescription;
> +  keyDescription.Assign(MOZ_APP_NAME);
> +  keyDescription.Append(" - ");
> +  keyDescription.Append(profileName);
> +  mRunning = true;

May I suggest using (the equivalent of):

MOZ_APP_NAME + " Master Password - " + profileName

So that it's clear in the password manager what this is?

@@ +808,5 @@
> +
> +  secret_password_lookup(MOZILLA_SECRET_SCHEMA, nullptr, on_lookup_finished, this,
> +                         "application", MOZ_APP_NAME,
> +                         "profile", profileName.get(),
> +                         NULL);

Are you sure you need to do this as async? I don't understand all aspects of how SyncRunnableBase works, but if this is a separate thread, you could just use secret_password_lookup_sync().

::: security/manager/ssl/src/nsPK11TokenDB.cpp
@@ +388,5 @@
> +  };
> +  return &the_schema;
> +}
> +
> +#define MOZILLA_SECRET_SCHEMA  get_mozilla_secret_schema()

Is there a reason the above function and macro can't be shared between nsNSSCallbacks.cpp and nsPK11TokenDB.cpp?

@@ +400,5 @@
> +on_libsecret_password_stored(GObject *source,
> +                             GAsyncResult *result,
> +                             gpointer data)
> +{
> +  secret_password_store_finish (result, nullptr);

Is it worth retrieving the error and logging it if things fail? May make our lives easier in the future if people run into problems and we have to diagnose them remotely.

@@ +416,5 @@
> +on_libsecret_password_cleared(GObject *source,
> +                              GAsyncResult *result,
> +                              gpointer data)
> +{
> +  secret_password_clear_finish(result, nullptr);

Ditto about the error.
Comment 85 Mike Hommey [:glandium] 2013-02-13 08:21:45 PST
Comment on attachment 713377 [details] [diff] [review]
Store Master Password by using libsecret to Gnome Keyring patch v1

Review of attachment 713377 [details] [diff] [review]:
-----------------------------------------------------------------

::: security/manager/ssl/src/nsNSSCallbacks.cpp
@@ +800,5 @@
> +  rv = profileDir->GetNativeLeafName(profileName);
> +  if (rv != NS_OK)
> +    return;
> +  nsCString keyDescription;
> +  keyDescription.Assign(MOZ_APP_NAME);

You don't want to use MOZ_APP_NAME here. Use nsIXULAppInfo data.
Comment 86 Jan Horak 2013-02-14 04:43:03 PST
Created attachment 713868 [details] [diff] [review]
Store Master Password by using libsecret to Gnome Keyring patch v2

Thanks Stef for feedback. I've fixed mentioned issues.
(In reply to Stef Walter from comment #84)
> @@ +808,5 @@
> > +
> > +  secret_password_lookup(MOZILLA_SECRET_SCHEMA, nullptr, on_lookup_finished, this,
> > +                         "application", MOZ_APP_NAME,
> > +                         "profile", profileName.get(),
> > +                         NULL);
> 
> Are you sure you need to do this as async? I don't understand all aspects of
> how SyncRunnableBase works, but if this is a separate thread, you could just
> use secret_password_lookup_sync().
> 
The secret_password_lookup is called on main thread, so we have to use async function to update gui.
Comment 87 Stef Walter 2013-03-21 05:55:12 PDT
(In reply to jhorak from comment #86)
> The secret_password_lookup is called on main thread, so we have to use async
> function to update gui.

Makes sense.
Comment 88 Adrien 2013-07-04 22:46:48 PDT
I've compiled it for Firefox 22 and it seems to work according a Gnome user point of view (but I don't know how to check if my passwords are well encrypted).

Did some Kwallet user try it ? And what will be next step to include this patch in future Firefox release ?
Comment 89 David Keeler [:keeler] (use needinfo?) 2013-07-08 10:06:46 PDT
Adrien - here's some steps you can take:
* Does it apply/compile for mozilla-central? (`hg clone https://hg.mozilla.org/mozilla-central`, `cd mozilla-central`, [apply patch], `./mach build`)
* It still needs (at least) a review from a PSM peer. As far as I know, Kai is unavailable to do PSM reviews. Other peers are listed here: https://wiki.mozilla.org/Modules/All (search for "PSM")
* There are a few build config changes, so it should probably get a review from a build peer (search that same page for "build config" - it's the one related to Gecko)
* You might consider marking old patches obsolete in this bug just to clean it up
Comment 90 Adrien 2013-07-25 02:49:35 PDT
Ok, I've tried to clone mozilla-central, apply patch and compile, but it wasn't successful.

In fact, I wasn't able to apply the patch and so I've tried to apply manually the changes, but it was a little bit as black magic for me. That's why I've got this compilation error I think : https://pbin.adorsaz.ch/?1b5e8a6be1f8052f#oqW8wBbbIW+kqyleweKWkSlQOEzThNoSfxzaMVofCCY=

I'll attach my patch file, but it doesn't work and it certainly doesn't respect your standards.
Comment 91 Adrien 2013-07-25 02:51:36 PDT
Created attachment 780879 [details] [diff] [review]
Modified patch to be applied to mozilla-central, but it won't compile
Comment 92 David Keeler [:keeler] (use needinfo?) 2013-08-02 15:32:01 PDT
Adrien - if you're looking to continue development on this patch, you can see if someone in #developers (see https://wiki.mozilla.org/IRC ) might be able to help you with the compilation issues. At a glance, it looks like you need to add some #includes (specifically, #include "nsDirectoryServiceUtils.h" and maybe #include "nsIFile.h" in this case).
Comment 93 Gabriele Svelto [:gsvelto] 2013-08-03 07:41:38 PDT
Created attachment 785385 [details] [diff] [review]
Refreshed patch

This is a refreshed version of attachment 713868 [details] [diff] [review]; the changes were fairly minimal as noted in comment 91 and comment 92. Besides adjusting a few rejections it was just a matter of importing nsIFile.h to get it working.

I've done some light testing on my box, adding and removing the master password as well as externally deleting it from the key-ring and it seems to work fine.

Adrien, if you want to pick this up you can start working using this patch; otherwise I'd be keen on finishing this myself as this is a feature I've been sorely missing.
Comment 94 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2013-08-03 09:12:47 PDT
(In reply to David Keeler (:keeler) from comment #89)
> * It still needs (at least) a review from a PSM peer. As far as I know, Kai
> is unavailable to do PSM reviews. Other peers are listed here:
> https://wiki.mozilla.org/Modules/All (search for "PSM")

I am the PSM module owner but I am not even a peer in the toolkit or Firefox modules where the password manager lives. I am very interested in removing all the master password prompts on all platforms. 

I know very little about Linux compared to most of the people CC'd on this bug; please be patient with me if I say something stupid.

1) I see in the patch that this is a build option that is off by default. I would prefer it to be ON by default for all Linux desktop builds, and if libsecret isn't available at runtime, then we just don't use it and we disable the Firefox UI related to the Gnome Keyring. Is there anything inherently wrong with doing it this way?

2) The patch contains a prompt that asks "Do you want to save master password to system password manager?" But, this seems like the wrong question. I think, instead, the "Change Password" dialog box should look something like this:

    (*) Protect my data with my system password (recommended)
    ( ) Use a master password:
        New Password:     [           ]
        Confirm Password: [           ]
    ( ) Don't protect my data

If we did it this way, then we wouldn't need that separate prompt. Also, this UI would work for all operating systems, AFAICT. (Note: I am not a UX person and in theory a UX person should design the UI for this. However, this may get blocked for a long time if we wait for a UX person to design it, so I suggest you build a prototype UI and have the UX people review it. If it works well on Linux then we could port the same UI to other platforms.)

3) The Gnome keyring should never store/protect a password that the user entered. Instead, it should store a randomly-generated key (e.g. 32 bytes of randomness from nsIRandomGenerator, or similar). NSS's protection of the master password is very weak, and also users will almost always choose relatively weak passwords, so using a random key as the NSS password is important.

4) Some people at Mozilla are working on this "Sign into the browser" / "Profile in the Cloud" thing, of which Sync is a part. See https://wiki.mozilla.org/Identity/AttachedServices. I think it is important to make sure that the people working on this feature discuss it with the the Identity people to make sure that this work and that work is compatible/complementary.
Comment 95 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2013-08-03 09:19:07 PDT
(In reply to Brian Smith (:briansmith), was bsmith@mozilla.com (:bsmith) from comment #94)
> 2) The patch contains a prompt that asks "Do you want to save master
> password to system password manager?" But, this seems like the wrong
> question. I think, instead, the "Change Password" dialog box should look
> something like this:
> 
>     (*) Protect my data with my system password (recommended)
>     ( ) Use a master password:
>         New Password:     [           ]
>         Confirm Password: [           ]
>     ( ) Don't protect my data
> 
> If we did it this way, then we wouldn't need that separate prompt.

Now, let me argue against myself.

Shouldn't the users that care about protecting their passwords be using full-disk encryption with a system password already? Why don't we just remove the master password mechanism on Linux completely, and rely on users use of operating-system-level protection of their whole profile? That is, wouldn't the best UI be this?:

      Mozilla recommends that you use a system password
      and full-disk encryption to protect your data; if
      you do that, then a master password is not very
      helpful. We still support using a master password 
      for now, but we highly recommend against using
      one, and we may remove this misfeature in a
      future version.
     
      [ ] Use a master password:
          New Password:     [           ]
          Confirm Password: [           ]
Comment 96 Gabriele Svelto [:gsvelto] 2013-08-03 10:09:24 PDT
(In reply to Brian Smith (:briansmith), was bsmith@mozilla.com (:bsmith) from comment #95)
> Shouldn't the users that care about protecting their passwords be using
> full-disk encryption with a system password already? Why don't we just
> remove the master password mechanism on Linux completely, and rely on users
> use of operating-system-level protection of their whole profile?

Full-disk encryption won't be available to whoever is storing its data on a computer he/she doesn't control. For example you might have to keep your profile on a shared drive when working in an office (alas that's a situation I have been in multiple times) and for those use cases providing a way to encrypt your saved passwords is very important.
Comment 97 Gabriele Svelto [:gsvelto] 2013-08-03 10:33:08 PDT
(In reply to Brian Smith (:briansmith), was bsmith@mozilla.com (:bsmith) from comment #94)
> 1) I see in the patch that this is a build option that is off by default. I
> would prefer it to be ON by default for all Linux desktop builds, and if
> libsecret isn't available at runtime, then we just don't use it and we
> disable the Firefox UI related to the Gnome Keyring. Is there anything
> inherently wrong with doing it this way?

It shouldn't be a problem if we can dynamically load the library at runtime.

> 3) The Gnome keyring should never store/protect a password that the user
> entered. Instead, it should store a randomly-generated key (e.g. 32 bytes of
> randomness from nsIRandomGenerator, or similar). NSS's protection of the
> master password is very weak, and also users will almost always choose
> relatively weak passwords, so using a random key as the NSS password is
> important.

This has a drawback however: if for some reason you lose your keyring then you loose all your saved passwords. It also means that you can't move your profile across machines unless you also move the keyring (or write down the random-generated password). If the master password by itself is week wouldn't it be better to generate a random salt and store it in plain-text in the profile and then use the master password + salt for the encryption? That would improve the effectiveness of the resulting encryption while keeping a password that cannot be remembered by the user. Would there be any downsides to doing it this way?
Comment 98 MartinSchroeder 2013-08-04 07:09:33 PDT
What are the downsides of completely relying on libsecret for storing passwords instead of a proprietary solution? Then a user had all his passwords in his keyring and wouldn't have to care about other locations where passwords are stored.
Comment 99 Jan Horak 2013-08-05 01:40:26 PDT
(In reply to Brian Smith (:briansmith), was bsmith@mozilla.com (:bsmith) from comment #94)
> 4) Some people at Mozilla are working on this "Sign into the browser" /
> "Profile in the Cloud" thing, of which Sync is a part. See
> https://wiki.mozilla.org/Identity/AttachedServices. I think it is important
> to make sure that the people working on this feature discuss it with the the
> Identity people to make sure that this work and that work is
> compatible/complementary.
AFAIK this has nothing to do with master password. Master password is not send to Sync service and user is not required to set master password on other Firefox instances, but it's good to keep Sync in mind.

(In reply to MartinSchroeder from comment #98)
> What are the downsides of completely relying on libsecret for storing
> passwords instead of a proprietary solution? Then a user had all his
> passwords in his keyring and wouldn't have to care about other locations
> where passwords are stored.
This is also an option but it requires more libsecret binding:
Getting list of passwords for Saved Passwords dialog and allow to remove individual records if we want to keep Saved Passwords and Sync working.

Personally I would stay with currently easiest solution which is storing user defined master password to libsecret's keyring. It's up to user to set strong password for Firefox and Keyring. They have probably weak password now because they have to retype it frequently. If they didn't have to they would eventually set stronger password. It's also smaller change to introduce new bugs since we're doing lesser change.
Comment 100 Jesse Glick 2013-08-05 06:37:16 PDT
(In reply to Brian Smith (:briansmith), was bsmith@mozilla.com (:bsmith) from comment #94)
> The Gnome keyring should never store/protect a password that the user
> entered. Instead, it should store a randomly-generated key

Agreed that it feels unnatural to have to define a master password when you are using the native keyring. But bear in mind that the whole approach of continuing to use proprietary password storage, and keeping only a single decryption key in the native keyring, is unnatural to users and has the sole merit (I presume) of requiring fewer code changes. Proper integration means storing all passwords as regular entries in the native (login) keyring, where they can be inspected and even edited using standard tools like seahorse. This is what Chrome seems to do, and what you would expect any polite application to do.
Comment 101 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2013-08-05 08:39:37 PDT
(In reply to Jesse Glick from comment #100)
> Agreed that it feels unnatural to have to define a master password when you
> are using the native keyring. But bear in mind that the whole approach of
> continuing to use proprietary password storage, and keeping only a single
> decryption key in the native keyring, is unnatural to users and has the sole
> merit (I presume) of requiring fewer code changes. Proper integration means
> storing all passwords as regular entries in the native (login) keyring,
> where they can be inspected and even edited using standard tools like
> seahorse. This is what Chrome seems to do, and what you would expect any
> polite application to do.

Let's please tone down the rhetoric regarding "proprietary" a little bit. The Gnome keyring is no less proprietary than any part of Firefox is.

I am not opposed to Firefox doing what you suggest if it isn't problematic to do so. But, please explain how a user would switch from Linux to Windows and bring their passwords with them; then please explain how a user would switch from Windows to Linux and get their passwords in the Gnome keystore. Right now a Firefox user can just copy their profile directory over to the new platform and they're done. With the "random master password" mechanism, they would have to first change from the random password to a user-entered password before copying the profile files over. With the "all passwords stored in the OS keyring directly" approach...I am not sure; help me understand what would happen.

Also, syncing of passwords across devices is a must-have requirement. So, any solution for this bug must support Firefox Sync, and must not complicate the implementation of the upcoming improvements to Firefox Sync.
Comment 102 Jesse Glick 2013-08-05 12:13:25 PDT
> explain how a user would switch from Linux to Windows and bring their passwords with them

Same way you would for secrets used by any other application: enter them again. This is an OS/desktop issue, not the responsibility of an individual application. Of course if you have decided to use cloud password storage like Sync then that would be your means of sharing secrets across machines.

By the way Windows seems to have no general service comparable to GNOME Keyring or KDE Wallet or OS X Keychain. It does have CryptProtectData, meaning that on Windows it is appropriate for Firefox to store its own passwords so long as it uses this API to prevent them from being kept on disk in cleartext.
Comment 103 MartinSchroeder 2013-08-05 13:00:56 PDT
Sorry for introducing the "proprietary" term. I didn't assign any judgement to it.

Wouldn't it be optimal, if Sync would be able to store and load into and from a file? Then the data could be brought everywhere without storing it online. This way the differences between systems wouldn't matter.
Comment 104 Jan Horak 2013-08-06 06:04:06 PDT
(In reply to Jesse Glick from comment #102)
> > explain how a user would switch from Linux to Windows and bring their passwords with them
> 
> Same way you would for secrets used by any other application: enter them
> again. This is an OS/desktop issue, not the responsibility of an individual
> application. Of course if you have decided to use cloud password storage
> like Sync then that would be your means of sharing secrets across machines.

Why not make it still possible? I see no benefit in retyping password when copying profiles. IMO profile should contain all data user wants it to store (ie. also list of passwords). Anyway do the libsecret supports KDE right now? If it doesn't we could probably cut password store support by this change for KDE users or implement another kwalletd backend. 

I think storing master password in system keyring manager is making things more loosely coupling. In case system keyring manager doesn't provide master password then we fallback to user input of master password. In case we saved all passwords to keyring and for some reason keyring won't be available users wouldn't have a change to have they passwords pre-filled.
Comment 105 Jesse Glick 2013-08-06 07:27:18 PDT
(In reply to jhorak from comment #104)
> do the libsecret supports KDE right now?

https://wiki.gnome.org/Libsecret says it does.
Comment 106 MartinSchroeder 2013-08-06 09:09:47 PDT
(In reply to Jesse Glick from comment #105)
> (In reply to jhorak from comment #104)
> > do the libsecret supports KDE right now?
> 
> https://wiki.gnome.org/Libsecret says it does.

The site says that libsecret supports ksecretservice. And ksecretservice is not working very well and is not included by default (AFAIK).

But what is the problem with using libsecret under Gnome and Firefox' own storage under KDE? Then it's like before under KDE until they have a freedesktop.org compatible key storage.
Comment 107 Stef Walter 2013-08-07 12:03:53 PDT
Hey guys, just wanted to give a heads up here...

I gave a talk at GUADEC which presented an alternate password storage model, where the secret service provides a master key to apps (like firefox) via standard interfaces like the linux kernel keyring. Apps can use this key to encrypt their own password storage database.

The above works well in the case of sandboxing. I think it also fits really well within the firefox model. You don't have to worry about things like async access for each password to another daemon.

I feel bad posting this here without more details, but over the next few days I'm going to clean up my slides, and do some blog posts about this. 

You can see a bit of history here:

http://lists.freedesktop.org/archives/authentication/2013-May/000267.html
Comment 108 MartinSchroeder 2013-08-07 12:29:58 PDT
I think we have to differenciate between two levels:
- The ability to *securely* store passwords (with a master password or a key provided by the system's key manager)
- The ability to securely *store passwords in the system's key manager*, where all my passwords live.

I favor the second option. I'm not concerned about moving passwords between different systems (that should happen rarely). And if I happen to use multiple devices: That's what Sync is for.
I am concerned about storing my passwords in a way that I trust: my system's key ring (storing keys is it's only purpose and I think it should be good at it).

Of course the thoughts in the link posted above[1] are also good ones.

[1] 
http://lists.freedesktop.org/archives/authentication/2013-May/000267.html
Comment 109 Jan Horak 2013-08-15 01:07:53 PDT
Okay, it seems that we're moving in circles. Who's going to decide which approach to choice? I can implement storing password to system keyrings but I won't do this without clear statement from Mozilla what they would like more. I still prefer storing only master password because of loose coupling.
Comment 110 Gabriele Svelto [:gsvelto] 2013-08-15 03:03:20 PDT
Created attachment 790711 [details] [diff] [review]
Refreshed patch

(In reply to jhorak from comment #109)
> Okay, it seems that we're moving in circles. Who's going to decide which
> approach to choice? I can implement storing password to system keyrings but
> I won't do this without clear statement from Mozilla what they would like
> more. I still prefer storing only master password because of loose coupling.

I am also in favor of storing the master password in the keyring as it seems the less intrusive approach and the most likely to land soon. It might not be a perfect solution but it improves the usability of the master password a lot. Besides once the harness is in place it will be easier to change the behavior (to store a random password, add a salt or whatever else). The only thing that we might want to change compared with the existing patch (of which I'm reattaching a refreshed version again) is probably in the UI part where we probably want the option to be shown in the same dialog as the master password instead of on a separate pop-up.

I've looked at the password manager log and it seems to me that Justin Dolske comes up often both as a contributor and a reviewer so I'm needinfo'ing him here as he's both a Firefox and Toolkit peer in the hope he's the right person to ask. Justin could you have a look at the approach we're taking here or point us to someone who could help out with this?
Comment 111 Dave Webber 2013-08-15 17:37:01 PDT
Regarding the UI: If you go with the master password option (for now if not permanently), I would suggest adding two features to the Master Password dialogue: a checkbox to store the password in the user’s key{ring|chain}, and a button to generate a random password. The button would lead to an additional UI, which would include a checkbox to toggle showing the password. The “show password” box would default to the logical inverse of state of the “store in my key*” box (since it makes no sense to generate a random password and then neither store it nor show it). 

Does this sound reasonable?
Comment 112 Gabriele Svelto [:gsvelto] 2013-08-16 02:07:32 PDT
(In reply to David Webb from comment #111)
> Does this sound reasonable?

Yes, it sounds like a good idea but also material for a follow-up. Let's open a separate bug for that so that we don't make the patch here too large or we'll never be done with it :)
Comment 113 Justin Dolske [:Dolske] 2013-08-20 15:38:32 PDT
(In reply to Gabriele Svelto [:gsvelto] from comment #110)

> I've looked at the password manager log and it seems to me that Justin
> Dolske comes up often both as a contributor and a reviewer so I'm
> needinfo'ing him here as he's both a Firefox and Toolkit peer in the hope
> he's the right person to ask. Justin could you have a look at the approach
> we're taking here or point us to someone who could help out with this?

It's a NSS/PSM patch, so that would be Brian Smith. But I'd have some of the same concerns he's noted in previous comments.

In general, I'd say that (1) the existing master password stuff is a giant mess that doesn't address modern threat models (2) we shouldn't pile more onto that shaky foundation and (3) neither the master password nor extensible nsILoginManagerStorage interface are very successful features.

So, I don't think we should invest time into supporting this, and it would be better implemented as an add-on for those who want it. Sorry. :/
Comment 114 Alexander Korsunsky 2013-08-23 00:07:48 PDT
(In reply to Justin Dolske [:Dolske] from comment #113)
> So, I don't think we should invest time into supporting this, and it would
> be better implemented as an add-on for those who want it. Sorry. :/

This HAS been implemented as an addon: https://github.com/infinity0/mozilla-gnome-keyring

The problem is that it has to be a binary add-on and is therefor next to impossible to maintain with Firefox' rapid release cycle. Some Linux distributions don't even ship Firefox development headers anymore, and comment it with "this should be integrated into Firefox, please contact upstream".


This is a pledge from a user: PLEASE integrate this patch. This is functionality that is wanted and needed (since the Master-password stuff is indeed a giant mess) by a lot of people and you even have a patch provided and people willing to maintain it.
Comment 115 Mike Hommey [:glandium] 2013-08-23 00:58:14 PDT
(In reply to Alexander Korsunsky from comment #114)
> This HAS been implemented as an addon:
> https://github.com/infinity0/mozilla-gnome-keyring
> 
> The problem is that it has to be a binary add-on (...)

This isn't true. jsctypes can be used to call whatever APIs the binary addon uses.
Comment 116 Romain Chossart 2013-08-23 01:07:34 PDT
> So, I don't think we should invest time into supporting this, and it would
> be better implemented as an add-on for those who want it. Sorry. :/

I would have thought you should invest time on what matters to users. This feature has a fair amount of votes and the absence of this feature is one of the most obvious and annoying thing on Firefox compared to Chrome: I am sure many users have had to type their master password thousands of times so far because of this. Also this is my own opinion, but I find this popup _soooo_ annoying.

Also, were there an up-to-date add-on, I would not trust it as much as if it was built-in. Such security features should be built-in IMO.
Comment 117 Justin Dolske [:Dolske] 2013-08-23 12:22:45 PDT
Investing time is always a tradeoff. I have a long list of projects to dramatically improve Firefox for users, and unfortunately the feature this bug about ranks poorly against that list. The number of users using a master password and linux is relatively tiny, and there are number hurdles to even making this a feature suitable to ship (see Brain's previous posts for a few). That's why an add-on is the right route to take.
Comment 118 Burrito Bazooka 2013-08-23 16:47:19 PDT
I don't know much about the internal workings of the Firefox Project, but I'm willing to bet that those people using Linux AND using a master password AND Firefox are of a demographic that would be resistant to sending anonymous usage data.
Comment 119 Joachim Rousseau 2013-08-24 06:41:08 PDT
(In reply to Justin Dolske [:Dolske] from comment #117)
> Investing time is always a tradeoff. I have a long list of projects to
> dramatically improve Firefox for users, and unfortunately the feature this
> bug about ranks poorly against that list. The number of users using a master
> password and linux is relatively tiny, and there are number hurdles to even
> making this a feature suitable to ship (see Brain's previous posts for a
> few). That's why an add-on is the right route to take.

You made a wrong assumption. This feature is not only for master password users. I don't use it be cause it is stupid. I have a session password on my OS, and I expect it to protect everything else. I don't want to have thousands of passwords to manually keep in a text file or a third party keayring software.
The master password and the lack of native keyring support are 2 reasons leading me to switch to Chrome on all of my non-home or mobile devices.
On my Ubuntu home desktop, I tried to use an encrypted home dir, but FF is using I/O too much, so it was too slow and laggy.
The most secure is my MacBook Pro whose disk is fully encrypted and whose web browser (Chrome) is using keyring.

Using the keyring is exactly what I expect from ANY application, thus Firefox, that need a secret key to protect data without **** me off with one more password. This is a seamless solution for every non-technical, IT-ignorant user. Those user are not using master password, so keyring would be a great solution to add protection without increasing complexity.

I know that there is some technical challenges to add keyring stuff to FF, but whining is not a solution, and believing there is more important UX stuff to do before is an error. This is a security concern, perhaps the #1 security concern in FF. Or if you prefer being troll-flammed by newpapers (http://www.theguardian.com/technology/2013/aug/07/google-chrome-password-security-flaw)...

I have not the C/C++ skills and the FF code base knowledge to help you so I can only encourage you and critisize reluctant attitudes that are legions in Mozilla organization (and sometime at a high hierarchy level... I had a bad experience with Tristant Nitot leading a big French bank switching from IE6 to IE8 instead of FF).

Please get into the future with implementing the keyring. Future is not only HTML5/CSS3 and Co.
Comment 120 derickson.e 2013-08-26 17:59:51 PDT
(In reply to Justin Dolske [:Dolske] from comment #117)
> Investing time is always a tradeoff. I have a long list of projects to
> dramatically improve Firefox for users, and unfortunately the feature this
> bug about ranks poorly against that list. The number of users using a master
> password and linux is relatively tiny, and there are number hurdles to even
> making this a feature suitable to ship (see Brain's previous posts for a
> few). That's why an add-on is the right route to take.

Applications should always make security easy. If a user has already taken the step of selecting an OS with a keyring function, FF should honor her decision and use that keyring, without extra steps required.

FF has been a keystone of exposing users to the quality that the open-source ecosystem can create. It's THE default browser of the most popular GNU operating systems. I'm not a developer (yet), and I can't make these changes myself (yet), I can't force anyone else to, and I greatly appreciate the time that has gone into making FF what it is. But if we want FF to continue to be the foundation of the FOSS ecosystem that it has become, then it should make security easy. As is, users have these choices: 

* install an addon ("Why doesn't this software come with essential features already installed?")
* use a master password ("Another password? I just made a system password!")
* do nothing and use the password store w/out master password (user thinks she is secure; she isn't)
* copy/paste from the system keyring or another software (like an addon, only less convenient)
* disable password storage altogether and use sticky notes on the monitor

The default browser on Mac OS already provides a secure, convenient password experience. The default browser in Ubuntu, on the other hand, doesn't reach the bar set by many FOSS projects in leveraging *existing* tools, waiting to be used, instead re-inventing the wheel and forcing redundant user actions.

GNU operating systems are trying to reach out to less-technical users. Firefox should help these efforts by at least meeting the standard of security set by the competition, as a standard feature. Not as an addon.
Comment 121 nodiscc 2014-01-20 13:08:16 PST
Is there any update/ongoing work on this?

There are several attacks out in the wild that allow extracting passwords from the firefox store. As it has been said before, non-technical users will not use the master password (I don't use it either because it bugs me with yet another password prompt). Implementing this would be a major step forward in improving users' security.
Comment 122 Eric Toombs 2014-02-10 13:27:54 PST
(In reply to Mike Hommey [:glandium] from comment #115)
> (In reply to Alexander Korsunsky from comment #114)
> > This HAS been implemented as an addon:
> > https://github.com/infinity0/mozilla-gnome-keyring
> > 
> > The problem is that it has to be a binary add-on (...)
> 
> This isn't true. jsctypes can be used to call whatever APIs the binary addon
> uses.

And just which javascript api has access to my gnome keyring? God willing, none! If there is a hope in hell for this thing to be secure, it can't be done in javascript. So, yeah. It has to be a binary plugin.
Comment 123 :Gavin Sharp [email: gavin@gavinsharp.com] 2014-02-12 17:13:42 PST
(In reply to Eric Toombs from comment #122)

You should give https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes a read - JS used in Firefox add-ons is privileged and can use JS-ctypes to interact with system libraries.
Comment 124 Mark Haferkamp 2014-09-06 11:46:34 PDT
In response to claims of Chrome's superior password management, I just lived through a use case where keeping the browser's passwords decoupled from the system is much easier to work with.

Short version: Changing Linux distros broke Chromium's access to my saved passwords. Please don't introduce such a fragile dependency in Firefox. I don't want to be locked in to my current OS just to keep using the same cross-platform browser.


Long version:

I had been using Chromium on Chakra Linux for a few years. Chakra is a "half-rolling" distro built around KDE, so it gets the latest KDE stuff faster than most other distros. Then I lived somewhere with metered Internet access for a couple months, so I switched to Firefox, using the lazy tab loading on start-up to reduce bandwidth use.

(off topic: It was really annoying manually importing passwords to Firefox since it doesn't have the feature. I miss Chrome's process-per-tab model that keeps the rest of the browser fast when one tab is busy. At least NoScript mostly keeps tabs from getting too busy in the first place. Also Firefox's Tree Style Tab add-on makes it much easier to keep a zillion tabs organized.)

Now that I'm living somewhere with unmetered Internet again, I've decided it's about time to do some distro-hopping and see how things have changed. Switching between various distros and desktop environments/window managers, Firefox has consistently given me access to my passwords via the master password, even when Firefox's version got shuffled back and forth.

Eventually, I ended up settling on OpenSUSE 13.1 using KDE, but apparently with a slightly older and incompatible version of kwallet. I just opened Chromium for the first time since July. Since all my log-ins have expired, it wants to access saved passwords. However, despite using the same browser and desktop environment I had been in July, with both within a year of the other, Chromium cannot access my saved passwords. I'm stuck with kwallet giving me an "Error code -4: Unsupported file format revision" message. So much for Chromium. Maybe it'll work again on OpenSUSE 13.2 in a couple months?

I guess I'll use Chromium for all the complicated "web 2.0" stuff that Firefox's single process chokes on. Firefox still seems best for not randomly losing abilities and for being widely extensible.
Comment 125 666f6f 2014-09-21 11:46:05 PDT
(In reply to Mike Hommey [:glandium] (out from Sep 6 to Sep 22) from comment #115)
> (In reply to Alexander Korsunsky from comment #114)
> > This HAS been implemented as an addon:
> > https://github.com/infinity0/mozilla-gnome-keyring
> > 
> > The problem is that it has to be a binary add-on (...)
> 
> This isn't true. jsctypes can be used to call whatever APIs the binary addon
> uses.

Right, and this has been implemented as a pure JavaScript addon:
https://github.com/swick/moz-gnome-keyring-integration
Comment 126 derickson.e 2014-09-21 15:25:30 PDT
Note that https://bugzilla.mozilla.org/show_bug.cgi?id=106400 is the counterpart for Mac OS X. It has a little under twice the votes and twice the age of this bug. Any work on one of these bugs would likely benefit the other. Maybe there should be an OS-neutral metabug for the two?
Comment 127 info 2015-06-08 07:32:53 PDT Comment hidden (advocacy)
Comment 128 Matthew N. [:MattN] (PM me if requests are blocking you) 2015-06-08 14:05:18 PDT
Here are extensions that implement this functionality so you don't need to wait for it to be built-in:
* https://addons.mozilla.org/en-US/firefox/addon/gnome-keyring-integration-1/
* https://addons.mozilla.org/en-US/firefox/addon/gnome-keyring-integration/
* https://addons.mozilla.org/en-US/firefox/addon/kde-wallet-password-integratio/

Please keep comments constructive and see the Bugzilla Etiquette guide: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Comment 129 Murz 2015-06-08 23:28:17 PDT
I already try to use those extensions, especially KDE Wallet password integration but it works bad: it broke password sync feature and produce browser crashes, and author don't know how to fix this. So native support for password managers will be much better.
At now I remove master password and forced to store Firefox passwords unsecured :(
Comment 130 Jan Horak 2015-06-09 04:40:19 PDT
Can someone summarize conclusion from Mozilla's site? I can work on it but not until there's a clear what is required.

[:gsvelto] are you willing to participate on the reviews?
Comment 131 Gabriele Svelto [:gsvelto] 2015-06-09 07:53:23 PDT
(In reply to Jan Horak from comment #130)
> [:gsvelto] are you willing to participate on the reviews?

I'd love to help but I'm not a peer of this part of our codebase so I can't review patches for it. Reading Brian Smith's and Justin Dolske's comments I think that we'd like to address bug 973759 first so that the master password does actually provide reasonable protection.

Personally I'm a user of this particular feature and I'd like to see something like comment 94 being implemented but I'm not the one calling the shots here.
Comment 132 antistress 2015-06-09 09:15:30 PDT
It seems that Frederic Crozat is working on it ?
see https://hackweek.suse.com/12/projects/746 & https://github.com/swick/moz-gnome-keyring-integration/issues/2#issuecomment-107093071
Comment 133 sebastian 2015-12-18 07:10:31 PST
The move to WebExtensions (with the currently exposed and planned API) would make the all the addons providing gnome/KDE/libsecret keyring support impossible.

Are there plans to provide those APIs?

If not could we take another look at implementing the support directly into firefox?
Comment 134 Matthew N. [:MattN] (PM me if requests are blocking you) 2016-07-14 22:18:15 PDT
Comment on attachment 713868 [details] [diff] [review]
Store Master Password by using libsecret to Gnome Keyring patch v2

Clearing ancient review flag on a patch I assume doesn't apply anymore.

Note You need to log in before you can comment on or make changes to this bug.