From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.5) Gecko/20011015 BuildID: 2001101516 Mozilla stores passwords (either from the http/ftp password protocol or a secure form) and other sensitive data (auto-fill data for example) in an insecure fashion. http/ftp/pop/imap passwords can be stored in a standard fashion in the keychain so other apps like Interarchy, Fetch, OmniWeb, iCab, etc. can use them. This would also keep them secure from other users or trojans (the user has to explicitly allow each app to access each sensitive datum). It's also very convenient for the user. Reproducible: Always Steps to Reproduce: 1. Save a http or ftp password in mozilla Actual Results: Data is stored insecurely and isn't available to the user's other apps. Expected Results: Something better
Confirming as an RFE; editing Summary and changing Component to Security: General.
Clearing URL and also setting OS=All.
reporter: your bug reports consistently include bad generalizations and blatantly wrong assertions, which makes using them hard. 1. Mozilla can encrypt the data it stores for users. I'm going to correct your expected results: s/better/different/ brought to you by apple. Think Different. This messy request affects Cookies/Form Manager [morse] + PSM [lord]
I suggest the first step of MacOS keychain integration is to allow the (optional) password Mozilla uses to encrypt personal information (passwords, certs, etc) to be stored/fetched from the MacOS keychain. That gets 95% of the benefit of MacOS keychain (OS-wide single-sign-on) without the pain of trying to re-architect Mozilla's storage for personal information around an OS-specific service. I'm honestly not sure it's worth the effort to get that other 5% of functionality (share certs and web passwords between web browsers). I certainly would put other MacOS/Mozilla integration problems (Internet Config, Page Setup, Java menus, UI consistancy) at a much higher priority.
This integration was already done by Apple and it was working in gromit. Then when we changed the codebase, Apple dropped out of the picture and hence the integration work that they did suffered bit rot. If anybody wants to see what they have, and to pick it up off the floor and get it working, take a look at extensions/wallet/src/singsign.cpp and search for the compile-time variable APPLE_KEYCHAIN. Currently that variable is turned off.
It would be nice to see this on Mac OS X too. I agree the most sensible first step is to implement some sort of "Retrieve master password from Mac OS keychain" option.
Future...unless someone else wants to take it. I won't be working on this anytime soon.
This would be a great addition. Leave Platform as Mac but change OS to ALL since both Mac OS 9.x and Mac OS X 10.x use Keychain. Keychain is not included on Mac OS versions before 9.0. I don't have the programming tools/time/knowledge to fix this myself but I would encourage those of you who do have the time and the resources to work on this. Voting for this RFE...
Chimera does this - maybe we could use code from there. Steve, any interest in hooking up Password Manager to the Mac (OS X) password storage system?
As you noted Chimera does use the Keychain (the patch came mostly from an external developer I believe) and it's gotten lots of positive feedback so yes, we should do it for Mozilla. Putting on my list but keeping the future milestone for now. I wonder if I can con, er, persuade Apple into resurrecting the code they wrote once before :-)
As Dagley mentioned, it was done once before, but it all got killed along with the death of gromit and never resurrected. It was done by an apple employee assigned to the netscape campus. Her code is still in the password manager module but is commented out and has suffered severe bit-rot during the intervening years.
Changing OS to OSX since this seems to still be wanted and support for mac classic is dead.
I strongly disagree that 95% of the benefit of keychain is what you've described. Keychain allows groups of or all passwords to be locked or unlocked on a timed interval. That is useful, but the major benefit for me is using the same stored passwords between different internet applications, with the user's permission. Whenever I need to reset Mozilla or Firefox, all the passwords are lost. When resetting Camino, the passwords are still there. Also, it is silly to make up data like "95% percent of the benefit". Statements like those have no credibility. In reply to comment #4) > I suggest the first step of MacOS keychain integration is to allow the (optional) > password Mozilla uses to encrypt personal information (passwords, certs, etc) to > be stored/fetched from the MacOS keychain. That gets 95% of the benefit of MacOS > keychain (OS-wide single-sign-on) without the pain of trying to re-architect > Mozilla's storage for personal information around an OS-specific service. > > I'm honestly not sure it's worth the effort to get that other 5% of functionality > (share certs and web passwords between web browsers). I certainly would put > other MacOS/Mozilla integration problems (Internet Config, Page Setup, Java > menus, UI consistancy) at a much higher priority.
*** Bug 240927 has been marked as a duplicate of this bug. ***
adding a URL for some sample code from Apple for manipulating the keychain. Something to keep in mind would be multiple user profiles for the same user, so if one were to store the master password you might want to use something like: "org.mozilla.browser.SoftwareSecurityDevice.$ProfileName.MasterPassword" for a service name where $ProfileName is the name of the active profile, otherwise multiple profiles would step on each other. I don't see a mechanism for dealing with this directly, so it would be necessary to pick a convention and stick to it. I'd take a stab but I'm stuck on pots dialup for the time being...
Mozilla (and Firefox for that matter) should make use of existing keychain entries, not merely add their passwords to keychain. There are some browsers which will automatically recognize existing keychain passwords, even immediately after being installed. There are some others which use the keychain to store their own passwords, but do not recognize the existing passwords. These require that the user manually enter the passwords for each web site even though the password for the site is sitting there which is an inferior implementation in my view. Though not a part of this bug, Mozilla should use other OS X unique features such as "services"
<AOL>Me too</AOL> This would also increase the default security, because the Apple keychain has a password by default, and there are tools that will do things like locking the keychain after a time or after a screensaver is run.
I'm not sure if this should be entered as a separate bug, but, ideally, once Mozilla has been integrated with the keychain, there should be some migration tool that will basically export stored passwords from Mozilla to the Mac OS X Keychain, either as a separate utility or automatically (upon first run?). This has several benefits, but mainly that users can use Mozilla apps now without having to worry about manually migrating passwords to keychains later. Any such tool should take probably into account some of the points raised in comment 16.
(In reply to comment #15) > Something to keep in mind would be multiple user profiles for the same user [...] I'm a bit unclear as to why one would care about the master password for multiple user profiles when relying on the Mac OS X keychain for password management? Instead, I would suggest that the security prefs for a keychain-enabled Mozilla app should allow the user to select the keychain(s) to use with that profile. The default for all profiles would be to use the "login" keychain. Users could then specify whether to create/use a new, different keychain (with its own password) for individual profiles on an as-needed basis.
how about this? 1) upon profile creation, a master password is created (user-defined or random) and stored in the login keychain. this is retrieved by FF when loaded each time, and used to decrypt the passwords etc stored by FF during normal use. this could be the default setting, and mean that all info is secure "out of the box". 2) option to change that password / use a different keychain 3) in Camino, all passwords are stored as individual entries in the keychain. this allows other apps to acces & use them (with the users approval) but does lead to a very full keychain. (and the other apps need to know how to read them) i think that as long as the encryption used by FF in its password file is solid, then just having the master password in the keychain is sufficient.
(In reply to comment #20) > how about this? > > 3) in Camino, all passwords are stored as individual entries in the keychain. > this allows other apps to acces & use them (with the users approval) but does > lead to a very full keychain. (and the other apps need to know how to read > them) i think that as long as the encryption used by FF in its password file > is solid, then just having the master password in the keychain is sufficient. Storing the FF master password in a keychain is not an appealing solution. A fully-integrated solution akin to Camino's would be preferable to most Mac users. Benefits to proper keychain integration on Mac OS X include: * It's possible to store some items in non-login keychains that have their own passwords. This allows some passwords to be secured at a * Users can more easily take advantage of tools such as the Password Assistant for generating unique and strong passwords. * Keychain Access is a much better UI for browsing stored account info than Firefox's similar UI. * Using keychains at a fine-grained level enables overall better integration with the Mac OS X platform and other keychain aware applications and tools in a way that just storing the master password cannot. Also, the idea of a "very full" keychain isn't really relevant. I know, I've got one. ;-) Keychains are either used as a database by apps that interface to them (e.g. browsers), in which case size is irrelevant because the app automatically handles lookup. Users browsing keychains directly will use Keychain Access, which has great and fast search functionality that makes it trivial to find the desired keychain item(s).
(In reply to comment #21) > Also, the idea of a "very full" keychain isn't really relevant. I know, I've > got one. ;-) I'll second that - the only way your keychain becomes large is because you're logging on in many places. If you have that many different accounts to keep track of you really want to have a database handling it and the value of sharing that database among every application (particularly other browsers and applications like newsreaders which include browsing functions) only becomes greater.
> * Keychain Access is a much better UI for browsing > stored account info than Firefox's similar UI. I don't accept this as a reason to use Mac OS X's Keychain system. It just means Firefox's UI needs to be fixed. ;-) (I agree with everything else though, and would love to see Firefox fully support Keychain!)
(In reply to comment #21) > * It's possible to store some items in non-login keychains that have their > own passwords. This allows some passwords to be secured at a Oops, that thought finishes: "... secured at a higher level than the typical default to allow FF automatic access to items in the login keychain for the logged-in user." (In reply to comment #23) > It just means Firefox's UI needs to be fixed. ;-) That too, but that's another bug. :)
*** Bug 339615 has been marked as a duplicate of this bug. ***
I would also argue that integrating Mozilla's/Thunderbird's/Firefox's security system with the Mac Keychain provides an additional bit of security just through improving its consistency with the rest of the OS. For example: a Mac can be set to lock the Keychain upon entering sleep (or even, with a third-party add-on, locked when the screensaver is activated). In this case when waking the Mac, everything is locked up - except for running Mozilla processes, which will be in the same state they were in before the machine was put to sleep. It does not seem particularly reasonable to expect the user to use the "clear private data" option, or to shut down all Mozilla processes, prior to sleep - that largely defeats the purpose of using sleep mode.
Considering: - the age of this bug - the high number of votes - Camino aleady has this feature -- which proves that an integration w/ shared Mozilla codebase is possible - Camino (open) source code has the same licence as Firefox source code -- which would make lifting code from Camino code base to Firefox code base possible An info: will be in Firefox 1.x, 2.x, or 3.x would be a great start
I realize this is not a particularly original thought, but it would be good - if it's practical - to do this in an extensible way so Firefox/Thunderbird/etc. on other platforms could take advantage of this enhancement without having to completely start from scratch. For example, it might be possible/desirable to tie this in with the Gnome keyring manager on Linux, down the road.
In response to Comment 28: Yes it would be great. But *please* implement the OS/X feature now and figure out how to genericise it later. Don't make us wait another 5 years to come up with a generic solution.
I don't think Firefox's password stuff should be switched to Keychain. It would cause a dialog to appear on every app update, and it would hurt users trying to use Firefox on multiple OSes or switch between OSes. I'm not convinced that Keychain provides any real security, given that apps can fiddle with each others' address spaces, config/profile files, and executables.
Unless you have found a security exploit that is unpublished, Keychain is as secure as the password you use. I can not imagine how you think that implementing this would impair use of Firefox on other platforms (please explain if you wish). Keychain also has the ability to manually add a web site which Firefox does not yet. There are also any number of web sites that, for one reason or another, do not show up in Firefox with their password. Part of the benefit of using Keychain is that the browser should access existing Keychain User ID/password information, as a number of other browsers presently do. (In reply to comment #30) > I don't think Firefox's password stuff should be switched to Keychain. It > would cause a dialog to appear on every app update, and it would hurt users > trying to use Firefox on multiple OSes or switch between OSes. > > I'm not convinced that Keychain provides any real security, given that apps can > fiddle with each others' address spaces, config/profile files, and executables. >
> Unless you have found a security exploit that is unpublished, Keychain is as > secure as the password you use. I'm just guessing based on seeing that gdb can attach to processes, vim can edit files in my Firefox profile, etc. I haven't tried to put together a complete exploit; it just seems obvious to me that an operating system that doesn't carefully protect applications from each other can't have secure per-application storage. (And that's ignoring the fact that on the occasions when Keychain does show a warning dialog, such as application update, the dialog doesn't give you enough information to decide if it's a legitimate update.) > I can not imagine how you think that > implementing this would impair use of Firefox on other platforms (please > explain if you wish). Currently, users can move Firefox profiles from Mac to Windows without losing their passwords. They might even be able to use a single profile from multiple OSes for an extended period of time. Storing passwords on Mac outside of the profile would partially defeat those use cases.
> Currently, users can move Firefox profiles from Mac to Windows without losing > their passwords. They might even be able to use a single profile from > multiple OSes for an extended period of time. Storing passwords on Mac > outside of the profile would partially defeat those use cases. That's a good point, but hardly a deal-breaker. The reason why I don't use Firefox on the Mac is that it doesn't feel or behave like a Mac application. This is something everyone notices as soon as they try Firefox on the Mac. I would have to guess that this is much more relevant to most users than being able to copy Firefox configuration files from platform to platform. Obviously, Keychain integration won't solve the entire problem, but it's a step in the right direction. But let's suppose you're right, i.e. that there are a significant number of people who will not use Firefox because it's more important for them to share their data with Firefox on another OS than with other apps on the Mac. Isn't this functionality part of the cross-platform library? Can't we just make a preference "use firefox/use keychain"? Not wanting to take it out doesn't doesn't seem like a valid reason not to implement Keychain support.
(In reply to comment #32) > complete exploit; it just seems obvious to me that an operating system that > doesn't carefully protect applications from each other can't have secure > per-application storage. (And that's ignoring the fact that on the occasions The Keychain is not perfect but any application will share those flaws; it does have key advantages over Firefox's current implementation thanks to the lock on sleep/screensaver option and offers some protection in the event of a less than total compromise (e.g. my online banking password can be set to prompt before each use so an attacker who can run JS can't try to silently load things in the background). The big reason for this, however, isn't security since all desktop operating systems share this problem. The win comes from interoperability and the better keychain UI: I'm a geek who actually cares about things like better features, interesting extensions, etc. and I still find myself using Firefox mostly for web development because it's inconvenient to have to re-enter all of my passwords or deal with a non-searchable UI. Safari, OmniWeb, and Opera have closed the standards gap significantly and are quite competitive on performance so this is actually a fairly significant competitive disadvantage for the Mozilla products.
> The reason why I don't use Firefox on the Mac is that > it doesn't feel or behave like a Mac application. Let's not make Firefox worse just to make it "feel more like a Mac application". > I still find myself using Firefox mostly for web development because > it's inconvenient to have to re-enter all of my passwords You have to do that when switching from Firefox to Safari too. I don't see how that puts Firefox at a competitive disadvantage.
(In reply to comment #32) > > Unless you have found a security exploit that is unpublished, Keychain is as > > secure as the password you use. > > I'm just guessing based on seeing that gdb can attach to processes, vim can > edit files in my Firefox profile, etc. I haven't tried to put together a > complete exploit; it just seems obvious to me that an operating system that > doesn't carefully protect applications from each other can't have secure > per-application storage. (And that's ignoring the fact that on the occasions > when Keychain does show a warning dialog, such as application update, the > dialog doesn't give you enough information to decide if it's a legitimate > update.) There is always Apple Feedback <http://www.apple.com/macosx/feedback/> if you think that Keychain is not secure. You won't get an answer as such as Apple does not comment on security maters, but it should be reviewed by the right people. > > I can not imagine how you think that > > implementing this would impair use of Firefox on other platforms (please > > explain if you wish). > > Currently, users can move Firefox profiles from Mac to Windows without losing > their passwords. They might even be able to use a single profile from multiple > OSes for an extended period of time. Storing passwords on Mac outside of the > profile would partially defeat those use cases. OK, fair enough. I thought you were getting at something else. As I understand it, the proposal is to allow the option to use Keychain instead of the Firefox password saver which would let the user choose. Still, it would be useful to be able to export passwords and such in a Firefox format in much the same way that bookmarks can be exported. I do not know if this capability has been discussed as a part of the proposal. Cheers
> Let's not make Firefox worse just to make it "feel more like a Mac > application". Is that a serious comment? Clearly most of the people here are arguing that Keychain is far superior to what Firefox currently provides. But the argument about what is "better" or "worse" is misguided. If Mac users are not using Firefox because it doesn't behave naturally or intuitively to them, isn't that something the development team should be concerned about? Regardless of whether they feel those users are stupid or not?
(In reply to comment #35) > > I still find myself using Firefox mostly for web development because > > it's inconvenient to have to re-enter all of my passwords > > You have to do that when switching from Firefox to Safari too. I don't see how > that puts Firefox at a competitive disadvantage. Firefox is not the default browser - that means it's best to provide fewer annoyances for people considering a switch. It's also the only major Mac browser which doesn't use the Keychain so it's really a divide between Firefox and most other Internet-facing Mac apps (OmniWeb, Opera, most newsreaders, FTP clients, etc.), not just Safari.
(In reply to comment #38) > (In reply to comment #35) > > > I still find myself using Firefox mostly for web development because > > > it's inconvenient to have to re-enter all of my passwords > > > > You have to do that when switching from Firefox to Safari too. I don't see how > > that puts Firefox at a competitive disadvantage. > > Firefox is not the default browser - that means it's best to provide fewer > annoyances for people considering a switch. It's also the only major Mac > browser which doesn't use the Keychain so it's really a divide between Firefox > and most other Internet-facing Mac apps (OmniWeb, Opera, most newsreaders, FTP > clients, etc.), not just Safari. > Any update? Is there any plan to add keychain support? I try to use Firefox because of the Adblock plugin. But I have to use Camino or Safari when logging into sites. Another alternative is for Camino to support adblock plugin.
What I like most about Keychain is that it keeps all your password and related data in one place. You do not have to enter the same password into 5 different browsers and other applications for a particular website -- just add it once and you're done. It's just plain annoying when you have to enter it over and over and over again. Other strengths of Keychain have already been mentioned. > Currently, users can move Firefox profiles from Mac to Windows without losing > their passwords. They might even be able to use a single profile from > multiple OSes for an extended period of time. Storing passwords on Mac > outside of the profile would partially defeat those use cases. Nothing prevents an implementation to store passwords in two different places and/or provide an exporter.
(In reply to comment #40) > What I like most about Keychain is that it keeps all your password and related > data in one place. ... and that place can be a removable device so your passwords can be removed if the machine is sent in for repair, or shipped, or has to leave your hands at any time.
It looks to me like there's two reasonable use cases when firefox is running on a mac. For a typical Mac user, it would be convienent for firefox to use the system keychain. However for someone who's bouncing around between a bunch of different operating systems, using the current firefox keychain looks to be more useful. Should this be handled by a preference on the privacy->password tab or should it be a hidden option or some other solution?
I suggest using Keychain by default (for the typical Mac user), with a hidden preference to use the cross-platform Password Manager. Users who are advanced enough to be sharing their saved passwords across multiple platforms ought to be able to handle setting a hidden preference, as long as it's clearly documented somewhere.
I have invested dozens of web site, POP/IMAP, and ftp/sftp passwords into my keychain through Safari, Mail.app, Transmit and other apps. I have my keychain automatically backed up to a remote server regularly. If Firefox and Thunderbird supported the keychain, then I could freely pop back and forth between apps. As it stands, I will not choose to switch to Firefox. What's the big quandry? Give the user an option to synchronize any accessed password between the Mac OS Keychain and Mozilla's password database -- store them all in both places (and later any cookie, form data, bookmark, etc.). Those who want to can then switch freely between Safari, Firefox/Mac and Firefox/*nix. This can be extended to other OS keychains: Mozilla software can be the bridge that lets me move freely between platforms.
PS: I just posted that last comment with Camino for the heck of it, and it's lovely the way it grabbed the login and password I had established using Safari. Cheers.
(In reply to comment #44) > store > them all in both places (and later any cookie, form data, bookmark, etc.). That's fine if it's optional. My keychain is on a CF card. I don't want copies of those passwords anywhere else.
(In reply to comment #36) > There is always Apple Feedback <http://www.apple.com/macosx/feedback/> if you > think that Keychain is not secure. You won't get an answer as such as Apple > does not comment on security maters, but it should be reviewed by the right > people. > A better location to report issues is http://bugreporter.apple.com. It requires a adc account (free), but you get a report id and an audit trail. It's not as responsive as bugzilla, but it's definitely a step up from the feedback form
Just a note for those who require this functionality now. I just tried 1passwd and it works beautifully: http://1passwd.com/ Hope that helps some folks. Chris
So I just found this slip after looking to see if anything existed yet to allow me to use the mac os x keychain with firefox. I have put off using firefox for several years because of this issue. Once keychain was born I have refused to let my passwords get all spread out again. I can sync them between machines with .mac, find them with any app, look them up with keychain access, etc. It is great. As a mac user, this whole debate seems ridiculous and the issue seems cut and dry. Firefox NEEDS keychain integration. I can see, though, how as a firefox user someone could have concerns over firefox portability. That is legitimate. However, on OSX there needs to be a way to choose this option for those who wish it, and I dare say it should be default behavior, as most of the computer n00bs out there only see it as annoying to have to enter passwords twice. The issue of portability affects only a few geeks who understand how to do that sort of thing, know that it's possible, etc. Hidden preference, drop down/radio button choice of "Mac OS Keychain" or "Firefox Password Manager", whatever.
(In reply to comment #49) > As a mac user, this whole debate seems ridiculous and the issue seems cut and > dry. Firefox NEEDS keychain integration. Hear, hear! The few people I've tried to convert from Safari to Firefox have balked at this. They have a lot invested in their existing keychains. Happy Birthday, BUG106400, you're 5 now! I understand that there must be other priorites, but this one seems pretty important if getting Mac users to switch is considered to be important. (Is it? Maybe not...)
(In reply to comment #27) > - Camino aleady has this feature The way Camino does it I end up with separate keychain entries for Camino and Safari. Ideally there'd be only one entry per site, and all browsers would use it.
> I understand that there must be other > priorites, but this one seems pretty important if getting Mac users to switch > is considered to be important. (Is it? Maybe not...) Myself and another developer are currently working on an implementation to this bug. :)
(In reply to comment #51) > (In reply to comment #27) > > - Camino aleady has this feature > > The way Camino does it I end up with separate keychain entries for Camino and > Safari. Ideally there'd be only one entry per site, and all browsers would use > it. That's now (partially) fixed in Camino. Unless you are working on fixing this bug, please do not comment here. It wastes the developers' time and is generally unhelpful. Please see https://bugzilla.mozilla.org/page.cgi?id=etiquette.html Thank you.
it looks like there is some work being done on this already http://zenit.senecac.on.ca/wiki/index.php/OS_X_Keychain_integration
Created attachment 271239 [details] starting code (.cpp file) These two files should be a good start for anyone interested in tackling this bug. I don't foresee myself having any time to work on this.
(In reply to comment #56) > These two files should be a good start for anyone interested in tackling this > bug. I don't foresee myself having any time to work on this. I would add that the patch in bug 309807 can be a useful resource too (equivalent bug for Gnome Keyring).
I think the optimal solution would be to find a way for Weave to have access to the OS X keychain. This would kill two birds with one stone. In OS X the keychain would be the main repository for secure password storage, but it would also be accessible to Firefox on other platforms. This could either be transparent for Mac users or be a hidden preference so that Firefox users that prefer the built in password manager could continue to do so. I'm surprised that Weave hasn't ben brought up in this discussion, but it looks like it's been awhile since anyones commented on this issue. Pipe dream?
Comment on attachment 271239 [details] starting code (.cpp file) fwiw.... if (scheme.EqualsLiteral("http")) return kSecProtocolTypeHTTP; else if (scheme.EqualsLiteral("ftp")) you should lose the |else| for each of these. nsCString serverName = NS_ConvertUTF16toUTF8(aHostname); is definitely not good style. if it isn't mutable, you could do: NS_ConvertUTF16toUTF8 serverName(aHostname);
Anybody are to work on this? Would a bounty help advance this? I'm not sure I can get bounty money for it, but I'm willing to try if someone tells me they can work on it if funded.
I decided to try implementing this as an Extension. It's not totally complete yet but it's basically useable so I put up a pre-release version: https://addons.mozilla.org/en-US/firefox/addon/13509 The major missing feature at the moment is the ability to import your existing FF passwords. You won't have access to your existing FF passwords as long as the extension is enabled (you will have access to Safari's saved passwords though). It also tends to over-prompt for permission to access a stored login even in cases where it doesn't really need the password; this is a challenge of the existing login manager API that I haven't quite found a workaround for yet. You won't really see any evidence that the extension is loaded except that passwords will now be saved in the default Keychain. Should work on OS X 10.3 (I think) and up, Intel or PPC, and FF 3.x. I'd appreciate feedback if you get it working or have problems (don't post it here - either on the Mozilla Addons page or by email, please).
Thanks for the work. Does it support certificates and -authorities too?
No. It implements the nsILoginManagerStorage interface, which does not, as far as I can see, deal with either certificates or authorities. I suppose if there is an appropriate API for providing those, that would be a natural thing to add to the extension at some point but it's not a priority for me right now.
Thanks so much for working on this issue, it is the one reason I don't use FF on the Mac. I just tried the extension, Mac OS 10.5.7, FF 3.0.11. In the two minutes I've tried it, it worked great on Facebook and Google, but oddly enough didn't populate the bugzilla.mozilla.org signin page. It did prompt me for access to the keychain for it, but it didn't work, even though Safari did remember the information. I'll keep testing it, but so far, great work. If it could push into the Keychain in a way compatible with Safari, I'd be all set!
Indeed... ah, I see. A typo was causing all new keychain items to be created as the "default" type, which is not correct for form logins. My guess is that your facebook and google logins were already in the keychain from Safari but you added the bugzilla one with the extension? I'm pushing 1.0a7 out, which works for me, but you'll have to delete the existing keychain entry (which would have been created with the wrong type). Keychain items should be more or less compatible with Safari - I'd certainly like to know of cases where they aren't working interchangeably in the two browsers. We should be able to get most of them ironed out though are are a few tricky compatibility issues.
>My guess is that your facebook and google logins were already in the keychain from Safari but you added the bugzilla one with the extension? No, unfortunately not. I haven't added any entries through the extension, all of the entries are from Safari. (And they all work in Safari). If there is any information I can provide from the keychain (that doesn't give anything away, obviously), let me know. Feel free to email me directly if that would be easier.
Hey guys, Talking about bugs in an add-on is going to make this bug harder to fix when a developer comes around to actually implement it because he/she will have to read all the comments that are not actually relevant to the bug. Please take the discussion to a different place.
Agreed. As I said, please don't comment here; either leave a comment on the add-on page or send me an email. I was planning on setting up a Google Code page at some point eventually anyway so I just went and did that: http://code.google.com/p/mozilla-keychain Feel free to post bugs there.
> Platform: PowerPC Mac OS X Can we change the platform of this bug to include Intel? Thanks. Also: the URL is outdated. Apple's more recent summary guide to Keychain Services in Mac OS X is at the redirect from <http://tinyurl.com/keychain-services>.
Although marking this as blocking-, I think this would be a super great enhancement for Firefox. Anyone interested in working on it (or continuing the existing work) should co-ordinate with Mossop and josh in #developers or #fx-team
I wanted to note that I looked into using the Keychain as a replacement. At the time it didn't seem like a good option because of the limited fields that could be stored in the Keychain. We could store additional information in Secure Notes (I think), but it seems like a less than optimal solution. That means at least one additional sqlite call per entry vs the current 1 (since the keychain is just a sqlite db). I think there's also an inherent problem with chrome:// passwords (usually stored by extensions, Weave for example). I didn't get too look into too much detail, but you have to associate a protocol with each entry and chrome isn't one of them. I'd be more than willing to look at this again though & lead an integration project (if deemed a good idea). jfitzell, would you be willing to put the source & relevant build instructions up on the Google Code project? As a side note, I filed bug 496660 as a possible alternative to using Keychain for storing logins. We don't get the shared data with Safari, but it might serve as a OK alternative.
Sorry to get all naive uppity non-implementing demanding user on you, but "it didn't seem like a good option because of the limited fields that could be stored in the Keychain" seems irrelevant to end users' interests. What I (and I suspect others) want is to have Firefox (and Thunderbird) store and retrieve username/password pairs in the same way that other Mac programs do, in particular Safari. I think that a technically superior solution that doesn't do that is missing the point from a value to the application user perspective, and that a partial solution that just uses the Keychain to store one master password and keeping all the FF data independent is probably a waste of the implementer's time. I'm of course not actually volunteering to do any work. Talk is cheap. But I encourage those who actually do productive coding to not let the perfect be the enemy of the adequately good. Laptop-wide, *application-independent* (host,username,password) or (url,username,password) strored data are what I want, and on the Mac platform that of necessity means that doing whatever it takes to play nicely with the MacOS Keychain and with whatever Safari does with the Keychain, even if it isn't a perfect match with The Mozilla Way or something. And yes, I am trying to be constructive.
Agreed with Richard Mlynarik. Safari/Camino/etc. interoperability is the whole point of this bug. We don't want to use the keychain because we enjoy using the keychain, we want to use the keychain because it keeps our passwords across applications. Keychain is the system-wide password store, and using it provides real benefits to end-users.
I will definitely post code for my extension, just haven't got around to it yet. I agree with several other comments that the whole point is to play nicely with the way other apps work on Mac OS (or Gnome or whatever). Having a "better" system that doesn't integrate nicely really is of limited value to users of these platforms. Obviously this is tricky but surely not trickier than any other platform compatibility issue. There may be value to having an option to store the master password in the Keychain (something I'll add to the extension if I can figure out how) but that is really a different feature. The nsILoginStorage interface, although pluggable, is still pretty specific to the existing implementations (not surprising since there aren't real alternates yet). There are ways it could be improved to make things more flexible. For one, it would be very useful to have a separate operation to request the password (Keychain Services only requires authentication to get the password and since I currently need to fill the password into every nsILoginInfo, you end up getting an authentication prompt when searching instead of when you actually start filling in the username and password). I ran into a problem similar to the chrome:// URLs with the ScribeFire plugin which stores passwords for URIs (not valid URLs) like performancing:http://foo.com/bar. At the moment, I'm just passing those through to the mozStorage implementation but they could also possibly be stored as Generic Password items in the Keychain. Chrome URLs could probably be treated similarly (ie. they are application-specific passwords, not internet passwords) since they would be of no use to other browsers anyway. I haven't implemented the generic password interfaces yet but it would be easy to do so.
(In reply to comment #73) > co-ordinate with Mossop and josh in #developers or #fx-team I joined irc://irc.mozilla.org/#developers and irc://irc.mozilla.org/#fx-team manually (my IRC client didn't find the rooms indexed). Topics make no reference to logs. Please, does anyone know, is either one logged anywhere?
Please: assume multiple keychains. (In reply to comment #75) > play nicely with the MacOS Keychain Passwords may be spread across *multiple* keychains. (Echoing and building upon comment #21) > Benefits to proper keychain integration on Mac OS X include: > * It's possible to store some items in non-login keychains that have their > own passwords. … not merely possible; it's sometimes *necessary* to keep items separate from the login keychain. Consider a job share in which a keychain for a role, or for a function, is passed from one person to another; and each person may have multiple roles. My own use case currently involves nine keychains -- some personal (two of three identities relate to troubleshooting Microsoft Exchange services), some functional. Other people's use cases will differ. > * Using keychains at a fine-grained level enables overall better integration > with the Mac OS X platform and other keychain aware applications and tools > in a way that just storing the master password cannot. Wishing support for multiple keychains should not block this enhancement bug 106400, but it should be a long-term consideration. --- > irc://irc.mozilla.org/#developers and irc://irc.mozilla.org/#fx-team > … is either one logged anywhere? In #developers I'm advised that there's no logging, but that Mossop and josh both are online frequently. --- A personal perspective: http://www.brighton.ac.uk/centrim/Members/gjp4/2009/08/06
(In reply to comment #76) > … Safari/Camino/etc. interoperability is the whole point of this bug. +1 to that and if it helps, http://www.diigo.com/06vy3 highlights a point from Apple's guide: >> Keychain services and other Mac OS X security APIs are built on the open source >> Common Data Security Architecture (CDSA) and its programming interface, >> Common Security Services Manager (CSSM). Apple refer to http://www.opengroup.org/security/cdsa.htm
Ugh, sorry, I meant: Dolske: who knows the password manager code in Firefox Josh: who knows about OSX integration work in Firefox, and might be able to hook you up with the best contact/reviewer there Apologies for the error.
I noticed the Chrome guys have looked into this, and have an interesting design document hilighting a number of issues with supporting Keychain... http://dev.chromium.org/developers/design-documents/os-x-password-manager-keychain-integration
Very interesting, thanks. For what it's worth, my analysis for the keychain services extension gave pretty much the same results and issues so I think this document is on track and very clearly written.
Another possibility not mentioned already is dual mode - Firefox will shadow copy between the two systems based on what it finds. Examples: 1. http://example.com (username) in exists only in Keychain. Firefox pulls the password and puts it in the form on the web page and then when the user submits it Firefox then adds it to the password manager as well. 2. http://foo.bar (myuser) exists only in FF password manager. The form is autofilled and on submit the password is copied into Keychain. 3. http://fairies.wand has no stored password. On submit the user is asked if they wish to store it. Upon choosing yes, the password is written to the Firefox password manager and then to keychain. Having a dual-system option will allow a user to keep their profile synchronized with the Firefox style for cross-platform portability and with Keychain for system interoperability. An additional field should be added to the FF password to indicate if it has been synced with keychain. A field should exist for each native platform password management system so that a FF profile need not step on the toes of another password manager. I think the dual mode would allow for fairly portable code as I am sure a generic "native" password API could be written to do all the heavy lifting. Some issues to solve: 1. What password is prioritized if it is different in both? (I vote the newer or inform the user of the conflict and let them choose). 2. If I had way better Objective-C skills I'd try my hand at this. :'( Other comments: I find that Firefox has the best password feild detector of all the browsers, but I don't use it as my primary Mac browser because in part the passwords are not portable to most of the other browsers for Mac OS X. That's all I got to say for now.
No progress at this issue? No progress on http://code.google.com/p/mozilla-keychain/ either (compatibility issue with FF 3.6.x)? Why not simply take Caminos code to use MacOSX' native keychain? Or why not simply take Google Chrome's code? Both browsers do have and use native MacOSX keychain integration. Be remembered to your own goals on https://wiki.mozilla.org/Firefox/Namoroka, Firefox.next Platform Requirements: System Integration * OSX Dictionary integration * OSX Services & AppleScript integration * OSX Keychain integration Also: https://wiki.mozilla.org/Firefox:Password_Manager No real progress on this bug since years and months, just vague declarations of intent...
Well... as far as the extension goes, I admit I haven't had much time of late to work on it, but I'm using it daily in 3.6.3 as are nearly 1000 other users so I think it's working ok. Honestly the major thing preventing me from doing the occasional bug fix is that I couldn't get the bloody thing to compile after upgrading to Snow Leopard. Last I tried, I couldn't find documentation of the required compile flags, spent hours on it, and then gave up. If anyone can give me the magic incantation to get a universal binary extension (or even a number of binaries) that works on intel/ppc, 10.6, 10.5 (10.4?), and in Firefox 3.6.x (and 3.5.x ?), I might well be inclined to close a few of the minor issues. :)
Another, simpler approach would be to generate a new password in cases where the user doesn't have a master password set for a given profile. Store that in Keychains and use it as the master password. This has two downsides obviously: a) you don't get login integration with other apps (do the extend that would actually work anyway) b) risk of orphaning all their saved password data if the user moves their profile or nukes the keychain entry.
Downside b) is a known and accepted risk of anyone using the OS X keychain. If storing the master password in the keychain is easier to implement, I'd certainly welcome it while we wait for full integration.
(In reply to comment #88) > Another, simpler approach would be to generate a new password in cases where > the user doesn't have a master password set for a given profile. Store that in > Keychains and use it as the master password. I filed bug 496660 on that approach a while back.
This bug was opened on 23-10-2001 — over 12 years ago. It has become blindingly obvious that not only has nothing has been done in this regard other than hand-wringing and -waving, but also that nothing is likely to ever be done. As a result, people CC'd on this should just bite the bullet and install the Keychain Services Integration add-on: https://addons.mozilla.org/en-us/firefox/addon/keychain-services-integration/ Shame on the Mozilla developers for not using the OS X Keychain after all these years, or at the very least optionally allowing its use.
They removed Growl support, which was platform specific and would have added support for Notification Center if they had updated the framework. I do not see them adding this in if they are getting away from platform specific items. Both items are unfortunate because they would make Firefox a better browser to have some native support for things on specific platforms. But it entirely depends on the goals that Mozilla has for Firefox going forward as to what they decide to do with this one. I'd just like to see it either get some progress or get closed with an explanation at this point (an explanation which is not "cleaning up tickets because this is really old ideally :) That said, I do not see any patches on this bug which are recent. I believe if a patch were made then perhaps this would have a better chance of being added in. No need to be negative about this though, that doesn't get things done. So, does anyone subscribed to this bug have the ability to get a patch written for this? If so let's get the ball rolling.
Emphasis on "lowest common denominator": http://www.apple.com/hotnews/thoughts-on-flash/ He was even more right than he knew at the time. This (pwmgr) is one reason I no longer use (or recommend) Firefox as my default browser. (As an aside: Big fan of your [plural] work, Chris. Keep it up.)
3 years ago
11 months ago
As I understand it, replacing the built-in login storage will no longer be possible under WebExtensions, so how about reviving this bug and bumping up the priority?