For the past 8.5 years, the standard workaround for bug 177175 was to install my addon StartupMaster (or a similar one, called Master Password+). They hook into the startup sequence and block until the master password is entered, thus preventing concurrent threads or processes from spawning several master password dialogs at the same time. While the proper fix for bug 177175 is still waiting for a complete rewrite of the master password code, changes in Firefox 57 will break the current workaround in a way that is impossible to correct from extension code. This seems to affect roughly 50 000 users. I suggest a two-part approach. First, add a component to Toolkit that asks for the master password on startup if a certain preference is enabled. Second, expose this preference via an API to WebExtensions. I already filed bug 1359182 for the latter, but it makes sense to factor out the former one as a separate bug.
Created attachment 8864293 [details] [diff] [review] Preliminary version of proposed fix (no comments & unit tests yet)
I don't think we should do this, for two reasons: 1) AIUI, this problem should go away in 57, as 3rd party addons won't be able to trigger this by querying logins any more. (I'm not sure of the state on a possible WebExt API for logins, if one exists we should just make it fail if a query is made while the .uiBusy == true). 2) There are few strong reasons to use a master password now. I would suggest, instead, to either: * Use a 3rd party password manager * Use no Master Password but enable OS disk encryption.
Thanks for your feedback. 1. Sorry, I do not believe bug 177175 will just go away with Firefox 57. It's a really complex beast, one of the most frequently reported bugs with many independent causes. It has been linked to password autofill when restoring several tabs after a browser crash, extension updates through a password-protected proxy server, concurrent SSL handshakes with FIPS enabled, combination of client certs with meta refresh, using a master password with Firefox Sync, setting up several IMAP accounts with OAuth2 in Thunderbird, using Thunderbird's integrated calendar and many other intermittent cases both with Firefox and Thunderbird which don't fall into the previous categories, lots of them without any addons. There are also random regressions popping up in new versions of Firefox and Thunderbird. I find it highly unlikely that all of these will disappear without touching the PSM directly. 2. I see your point here and I'm well aware of the limitations of the master password. I do use disk encryption myself, but I still consider master passwords as good enough casual protection for non-essential passwords on shared computers where you don't have too much control over the environment. Also some lower-end machines are significantly slowed down by disk encryption and the integration of 3rd party password managers on Linux is pretty fragile. I'm sure several of my users have their own use cases as well. Anyway, if Mozilla were to deprecate master passwords, I would understand. IIRC Chrome chose not to incorporate them as users would expect a higher level of security and they didn't want them to shoot themselves in the foot. So the main question is about Mozilla's policy going forward. Are we going to deprecate master passwords? If yes, is there some official statement about this that I can point my users to? If not, as I would imply from your bug 1271851, I think there should be some stop-gap measures taken so that they don't suddenly break with the release of Firefox 57.
Unfortunately I don't have more to add here.