Pidgin should support OS keyrings

Thank you for your bug. Any comment from upstream on that patch? Scott, what interest do you find to use the keyring? It doesn't seem to bring any useful feature, will add extra Depends for people using gaim without GNOME and will force people to enter the keyring password when running gaim. I would say we don't have any interest to do that move for the moment

Pros: Gaim would no longer store plaintext passwords in $HOME/.gaim/accounts.xml

Cons: Exactly what Sebastien said, it adds extra dependencies and forces people to enter their keyring password when running Gaim.

It would definitely have to be an optional feature, since Gaim is not a Gnome application, and that complicates things some. I'm not very familiar with the Gnome keyring daemon... but what would happen if the keyring daemon isn't running? The patch would need to make sure that Gaim falls back to doing something sensible, and possibly even warning the user. I'm particularly concerned about the case where someone switches between Gnome and non-Gnome.

I'm not opposed to adding support for this, and it sounds like other Gaim developers would be ok with it if it were done REALLY well, but the discussion on the gaim-devel mailing list about it was too short to really draw a concensus.

To not strongly object, I would have to see that the patch author had considered the case of a user switching between gnome and not-gnome, and had handled it in a sane way. This would minimally have to be handled in the case of one such transition.

To gain my _support_, the patch would have to additionally be able to handle multiple such transitions, for example the user who has a .gaim directory on a usb key and moves between home and work, where one is gnome and the other not.

Luke, I like your formula...

(This is on top of Luke's comments, which I agree with 100%.)

For *me* to not strongly object, I'd have to know that the double-prompting I was seeing with NetworkManager using gnome-keyring was fixed, or a NetworkManager bug. Ethan has the same problem with gnome-keyring and NetworkManager.

For me to support this *in Ubuntu*, I'd like to see gnome-keyring integrated, using pam_keyring to unlock the keyring with your account password. I want to package pam_keyring for Debian & Ubuntu, but the latest version depends on pam >= 0.99. I have a bug filed about that against both Debian and Ubuntu, I think.

@ Mark Doliner
But Gaim is a dependance of ubuntu-desktop and Ubuntu is gnome-based. So what's the problem?
This is a bug for Ubuntu not for gaim in general.
I'm totaly wrong?

faithful: You're correct. There are two things to consider here, though:

1. Kubuntu, Xubuntu, etc. all use the same Gaim package.
2. Many users synchronize their .gaim directory across machines, which may be running different distros or OSes. (A popular combination is Linux & Windows.) This means they'd need to store the passwords in clear-text anyway.

If we can come up with a way that doesn't break #2, I think it'd be acceptable for upstream. Ubuntu has to deal with #1.

Kubuntu is KDE-based and the IM for KDE is Kopete. Kubuntu don't install GAIM by default, so we don't have problems for Kubuntu users.
We could notify gnome-keyring as a suggested dependecy of GAIM so if some KDE user wants to install GAIM then he/she would be aware of the problem.
Maybe for Xubuntu users there will be some problems because GAIM is part of Xubuntu-desktop. In this case we can modify that patch to look if in home dir there are the credentials saved for every account and use them. If credentials are missing then use gnome-keyring.
The patch it's not so complex, it could modify easily.
It's a suitable solution?

I wonder how hard this would be to implement as a plugin. Looking at their api documentation, it would seem that c plugins have full access to the entire api. So, maybe we should look into reimplementing the patch as a plugin?

Btw, initial patch link posted above doesn't work any longer. Here is what seems to work now.
http://cvs.opensolaris.org/source/xref/jds/spec-files/trunk/patches/gaim-06-gnome-keyring.diff

Everyone is fine with this being done in the core, as long as it's generic and works properly.

i posted this at Bug #41179 (firefox)... right here it is just the other way around, of course...

I'd be very delighted to see this functionality. And as I am a GNOME user this would fix things quite nicely. However some people use KDE and even cruder stuff... They'd like to have support for kwallet or some other keyring manager... I'd like to change this bug to a more generic description.

... and then there is bug #75850 that is just the same bug as this one only that it is filed against pidgin ...

And I begin to wonder if there is not any standard abstract infrastructure for managing passwords. I think there are quite some applications that could make use of a proper password manager...

So to be more precise:
a) do we have a desktop environment independent password management infrastructure?
b) should we have one?
c) should theses bugs be kept separate or should they be united?

I think it'd be nice if there was a standard interface supported by both GNOME Keyring and KWallet. Unless or until that happens, each cross-desktop app is going to have to support both, which is unfortunate. For Pidgin, this is being worked on as a Summer of Code project this summer.

Has there been any progress?

I still see it as a BIG security flaw.

If you follow the link to the upstream bug report it shows that the bug has been assigned to a person but there has been no movement for 8 months. Maybe you could register to the upstream application and make further progress inquiries.

The biggest issue here is the API changes. I had been hoping that we were going to cut a 3.0.0 release soonish, so we could merge this change in for that. However, 3.0.0 may take longer than I'd like, so my plan was to get back to this after I tackle another patch I'm in the middle of. It is a highly requested feature and the code is mostly done, so *hopefully*, it won't be too much work.

I've taken a look at that branch recently, it doesn't change the existing APIs but adds quite a few, so we can do it in a minor release. However, there are also quite a few problems (silly memory management, bloated api) so it's not something that can just be merged.

for starters, I am thinking about redoing the _set_* hooks to be more like how ssl is handled, kill the prefs and make the enablement of the plugins as the prefs, and also killing all those destroy callback on passwords.

Richard I know this really isn't the place that this should be discussed, but you are nowhere to be found!

There's a plugin available at http://code.google.com/p/pidgin-gnome-keyring/

There is a PPA for the above plugin at https://launchpad.net/~pidgin-gnome-keyring/+archive/ppa

(Note that as of this posting the build is failing for Saucy and others, but hopefully this will be sorted out soon.)

Also note that keyring-based password store is on the roadmap for Pidgin 3.0.0 (no planned release date yet). See https://blog.wasilczyk.pl/en/2013/password-safe-support/

Also, https://developer.pidgin.im/ticket/673 has been closed, marked as fixed.

Hello,

The third-party plugin for Pidgin 2.x mentioned earlier, pidgin-gnome-keyring by Ali Ebrahim[1], is now packaged and published in Debian (Sid and Stretch, maintained by me) [2] and Ubuntu (Wily, auto-imported from Sid) [3].

This version uses Freedesktop's Secret Service API via libsecret, so for now only Gnome Keyring supports it, as KDE Wallet has not yet been updated to use libsecret, although I believe it is on the roadmap.

Would this be enough to mark this bug as fixed, pending 15.10 release?

Kind regards,
Luca Boccassi

[1] https://github.com/aebrahim/pidgin-gnome-keyring
[2] https://packages.debian.org/stretch/pidgin-gnome-keyring
[3] https://launchpad.net/ubuntu/+source/pidgin-gnome-keyring

pidgin-gnome-keyring is available since xenial, shouldn't this bug report be fix released already?