*** 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
** 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
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 receive
(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 (...)
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 s
(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 De
(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. jscty
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).
(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 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
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
> 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
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
(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
(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 perso
(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 be
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 addi
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
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.
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 pass
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.
(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 include
(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
T
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.
-
> 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
p
(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 n
(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 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 impo
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 m
(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
y
(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 d
(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
(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,
(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 sh
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 b
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
"nsDirectoryServiceUti
Ok, I've tried to clone mozilla-central, apply patch and compile, but it
wasn't successful.
In fact, I wasn't able to apply the patch and so I've tried to apply
manually the changes, but it was a little bit as black magic for me.
That's why I've got this compilation error I think :
https://pbin.ad
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
Stat
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 revi
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 notif
(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.
https://bugs.l
** 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:
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
Status:
45 matches
Mail list logo