*** This bug is a duplicate of bug 41179 ***
https://bugs.launchpad.net/bugs/41179
Seahorse is a front-end for GNOME Keyring, so that is what Firefox would
integrate with. Setting this as a duplicate of an older bug that asks
for the same thing.
** This bug has been marked a duplicate of bug
** Changed in: firefox
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/217300
Title:
Seahorse integration
Status in Mozilla Firefox:
Won't Fix
(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
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?
--
You
** Bug watch added: Mozilla Bugzilla #106400
https://bugzilla.mozilla.org/show_bug.cgi?id=106400
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/217300
Title:
Seahorse integration
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
(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.
--
You received this bug notification because you are a member of
(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
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
(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
(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
(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
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
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
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.
--
You received this bug notification because you are a
(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.
--
You
(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
(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 :)
--
You received this bug notification
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
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
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
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
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
(In reply to jhorak from comment #104)
do the libsecret supports KDE right now?
https://wiki.gnome.org/Libsecret says it does.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/217300
(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
(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
(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
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
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 Brian Smith (:briansmith), was bsm...@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
(In reply to Brian Smith (:briansmith), was bsm...@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
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.
--
You received this bug notification because you are a
Created attachment 785385
Refreshed patch
This is a refreshed version of attachment 713868; 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
(In reply to Brian Smith (:briansmith), was bsm...@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
(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
(In reply to Brian Smith (:briansmith), was bsm...@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
(In reply to Brian Smith (:briansmith), was bsm...@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,
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
Created attachment 780879
Modified patch to be applied to mozilla-central, but it won't compile
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/217300
Title:
Seahorse integration
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 :
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
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 ?
--
You received this bug
(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.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
You have been subscribed to a public bug:
Binary package hint: firefox
The Seahorse SSH integration totally rocks!
Would it be possible to integrate Firefox with Seahorse to manage web site
passwords or the Firefox master password?
** Affects: firefox
Importance: Wishlist
** Package changed: firefox-3.0 (Ubuntu) = firefox (Ubuntu)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/217300
Title:
Seahorse integration
Status in The Mozilla Firefox Browser:
45 matches
Mail list logo
