** Changed in: gnome-keyring
Importance: Unknown = Medium
--
the login password is stored in the user's keyring
https://bugs.launchpad.net/bugs/566046
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing list
** Changed in: gnome-keyring
Status: New = Fix Released
--
the login password is stored in the user's keyring
https://bugs.launchpad.net/bugs/566046
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing list
This bug was fixed in the package gnome-keyring -
2.92.92.is.2.30.0-0ubuntu3
---
gnome-keyring (2.92.92.is.2.30.0-0ubuntu3) lucid; urgency=low
* Drop 04_clean_session_keyring.patch: This was a cleanup for users who
installed Lucid Alpha versions and persisted until after Beta-2
** Branch linked: lp:ubuntu/gnome-keyring
--
the login password is stored in the user's keyring
https://bugs.launchpad.net/bugs/566046
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing list
Upstream ack'ed the patch and committed it with a slight refinement,
confirmed that the password shouldnt' be there at all (it's not a (bad)
design choice to make those extra keyrings work), and I tested the hell
out of it now.
Discussed with Steve and we agreed to push this into final, I
Notes:
* Create a new user, log in the first time (no autologin) - creates
login keyring and User Keys password entry
After every action below, log out and back into GNOME:
* Remove User Keys password entry - no change, User Keys is not
regenerated
* Remove entire Passwords: login keyring -
This is an easier reproducer for developers, which mimics what the PAM
module and autostart .desktop files do, but without the requirement to
log out/in:
killall gnome-keyring-daemon
rm -v .gnome2/keyrings/*
export `echo s3kr1t | gnome-keyring-daemon --daemonize --login`
export
** Branch linked: lp:~ubuntu-desktop/gnome-keyring/ubuntu
--
the login password is stored in the user's keyring
https://bugs.launchpad.net/bugs/566046
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing list
I have a patch to stop the password from being added to the keyring, and
also to remove it on upgrades. I sent it to upstream, but it's probably
not an approach which upstream likes. Also, this most probably breaks
this ominous user.keystore. I don't see how to use it in the first
place, I
@security team: This is not _such_ a big deal IMHO, since the password
is encrypted on disk, and can only be retrieved if the user is already
logged in (at which point all the wifi passphrases, empathy accounts,
and everything else stored in the keyring is also accessible). Thus it
seems prudent
Package uploaded to ppa:ubuntu-desktop/ppa for testing.
--
the login password is stored in the user's keyring
https://bugs.launchpad.net/bugs/566046
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing list
@pitti: I think you can get info here on how to store things in the
pkcs11 keyring: http://live.gnome.org/GnomeKeyring/ApplicationSetup.
Instead of using the users password to encrypt the user.keystore file,
it would probably be more appropriate to generate a random password and
use it, unless
Obviously we can do an SRU/security update after the fact, but this
does, as Marc pointed out, leave a root escalation path for malware or
applications with a security hole. Perhaps worse is that it allows the
malware call home with the password so that it can be used later to
potentially login to
Marc Deslauriers [2010-04-21 12:07 -]:
as long as we write a tool/script to automatically remove the user's
password upon upgrade
That's already contained in the patch, BTW. g-keyring-daemon removes
it on startup.
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu
Just to keep you up to date, I got a reply from upstream, and it seems
the patch goes into the right direction. He committed a patch upstream
now, but apparently forgot to push. I contacted him again.
--
the login password is stored in the user's keyring
https://bugs.launchpad.net/bugs/566046
Jamie Strandboge [2010-04-21 12:38 -]:
Obviously we can do an SRU/security update after the fact, but this
does, as Marc pointed out, leave a root escalation path for malware or
applications with a security hole.
That's a good point. Now that upstream has replied and confirmed that
having
** Changed in: gnome-keyring
Status: Unknown = New
--
the login password is stored in the user's keyring
https://bugs.launchpad.net/bugs/566046
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing list
I am not absolutely sure the problem is in gnome-keyring, it could be
the installer. I chose gnome keyring because a bug has to be filed
against one package ... So is it still a good idea to tell upstream now
there's a problem with Gnome Keyring?
--
the login password is stored in the user's
the issue is not an installer one, it happens on upgraded systems too
--
the login password is stored in the user's keyring
https://bugs.launchpad.net/bugs/566046
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing
I had the entry in my keyring on an upgraded system as well, so I can
confirm it isn't an installer issue.
I removed the item via Applications/Accessories/Passwords and Encryption
Keys, then restarted my session and things still seem to be working fine
(evolution, ssh), though I don't know why it
20 matches
Mail list logo
