Integrate with Gnome Keyring

Camino is doing exactly this, a similar implementation could be used.

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.

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.

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.

I'm going to work on this, feel free to contact me if you want to help.

Created an attachment (id=270527)
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).

Created an attachment (id=270611)
version 0.2

Forgot to unregister the category, and fixed an unused variable warning.

This went low priority for me, feel free to take this over.

*** Bug 410674 has been marked as a duplicate of this bug. ***

Does GNOME keyring replace Firefox internal password manager?
If not, it should.

(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.

Exactly the same situation with some non-duped bugs I've filed.

This bug is not only firefox related. It's a core bug.

I agree, it should rather be toolkit related (password manager is in toolkit/components/passwordmgr), but there's no Toolkit/Password Manager component.

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.]

(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.

*** Bug 435207 has been marked as a duplicate of this bug. ***

Created an attachment (id=336264)
Updated patch to compile against firefox 3

I've modified the patch lightly to get it to compile on Firefox 3.

Created an attachment (id=336498)
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?

I have simple question: does this include migration?

The current code doesn't include any migration support.

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.

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?

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?

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.

(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)

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.

(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.

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).

(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.

(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?

(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.

(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..."

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!

> 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.

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.

(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.

(In reply to jhorak from comment #104)
> do the libsecret supports KDE right now?

https://wiki.gnome.org/Libsecret says it does.

(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.

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

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

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.

Created attachment 790711
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?

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?

(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 :)

(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. :/

(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.

(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.

> 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.

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.

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.

(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 pissing 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.

(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.

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.

(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.

(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.

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.

(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

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?

Hey who will bake a ten year anniversary cake for this bug report? I'm no longer gonna wait and decided to move on. typing my master password ten times a day pisses me of enough to search for a solution and seeing no progress made on a fundamental shortcoming gives me enough motivation to search for another solution.

bye.

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

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 :(

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?

(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.

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

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 on attachment 713868
Store Master Password by using libsecret to Gnome Keyring patch v2

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

Please integrate this feature into Firefox, so that the old legacy GNOME add-ons for this task are obsolete. It would be nice to fix this before FF 57, when only WebExtensions are supported.

12 years on, we're back to square zero with firefox 57, as the available extensions became incompatible. So depressing.

The madest thing for me is that now other browsers integrate with platform keyring. Why not Firefox ?
 - Since other browsers have it, political arguments are weak
 - Since Quantum overhaul, technical one are weak too. Mozilla had an opportunity to deal with is issue that is a *major* usability and security issue.

Let's say FF displays the profile in a corner like Google Chrome. Let's say this could be associated with a FF Sync account. On profile switch, it could ask for password or not, depending on a user profile locking pref.
We already know the OS user is able to unlock all FF identifier stores, because this is how keyring work. But with a live (vs on startup) profile management, FF could offer the opportunity to manage switching.

Just my 2 cents, but 12 years on, it is time to look at what other successful browser are doing...

I totally agree. Just imagine that Firefox still saves all your passwords unencrypted to your disc in it's default configuration. Who else does that in our times?
The refusal to deal with this major security flaw is absolutely unacceptable! And I think it's a sign of poor leadership. They concentrate on total crap like pocket, just an other cloud shit, that no one will ever need, instead of concentrating on privacy an security.

I am restricting this bug to users with the editbugs permissions. We understand that some people are unhappy about this missing feature but the "metoo" comments are not helping.

At this point I wouldn't take a patch to implement this as it would be a significant cost with per-platform support. Extension APIs (which I know aren't yet available) would be the solution for implementing this if there is enough demand.

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