Bug 566286

The problem is known since quite a while obviously, see bug 555610 and bug 553272 and bug 522361.

What's even worse is that if one re-enters all passwords and chooses to store them in gnome-keyring, pidgin will still prompt for the passwords on next start up. Apparently gnome-keyring integration only works with one account or when activating one account at a time.

Ludwig: the rationale is that if the keyring is running, then it should always use it (I'm not sure the use case "users do not use gnome-keyring will it's running" is really something we want to handle). That's why it doesn't fallback to the xml file.

Now, if gnome-keyring is not running, there's indeed a bug, and the pidgin package in home:vuntz:11.2-testing should fix it. Can you try it?

I'll try but I'm not sure it will fix the issue. gnome-keyring sometimes just seems to be running for some reason. Maybe some random other program causes it to start. IMHO pidgin really should remember where it got the password from and store it there again.

That would mean no migration, and also, it wouldn't help if the first time pidgin is run, you have, by accident, a keyring running too... To be honest, I don't see a perfect solution there.

Is a migration really needed? If so pidgin could just ask once whether to migrate all passwords then.
If on first start gnome-keyring is running pidgin could of course try to use it but if the user presses cancel in the setup dialog of gnome-keyring it could fall back to the xml file (IIRC KDE programs behave that way if one rejects setting up kwallet). Is there a way to check whether gnome-keyring is already set up (without starting the setup procedure at the same time)? If gnome-keyring is not set up pidgin could just silently continue using the xml method.

Guessing from product = openSUSE 11.0, Ludwig complains to introduction of gnome-keyring support in old products. And I agree, it should not happen.

I propose to keep gnome-keyring support in products where it was enabled before the update.

I'll prepare update that should return pre-upgrade behavior to all products.

I just checked all pre-update versions.

All 11.0, 11.1, 11.2, SLE10 and SLE11 were using SUSE-specific gnome-keyring patch even before the update.

But wait, the patch in SLE10 seems to be broken:

AC_DEFINE(VINO_ENABLE_KEYRING,
          ^^^^^^^^^^^^^^^^^^^

#ifdef PURPLE_ENABLE_KEYRING
       ^^^^^^^^^^^^^^^^^^^^^

So it seems that we had a patch that did nothing for years. But then somebody fixed it, and the stuff started to be active...

From SLE11 and 11.2 pidgin.changes:
Tue Jan  6 12:11:13 EST 2009 - jpr@novell.com
- Fix keyring patch so the keyring paths actually get used
  (bnc #327391)


Summary for SLE10 and 11.0, 11.1:

Disable it there, it was never enabled there.

Summary for SLE11, 11.2 and Factory:

Let somebody else decide, whether it is wanted there.

There is my opinion:

Let's either upstream or drop our long-time-off patches.

(In reply to comment #7)
> Summary for SLE10 and 11.0, 11.1:
> 
> Disable it there, it was never enabled there.

Makes sense.

> Summary for SLE11, 11.2 and Factory:
> 
> Let somebody else decide, whether it is wanted there.
> 
> There is my opinion:
> 
> Let's either upstream or drop our long-time-off patches.

Well, I guess that the patch was made for SLE, so it'd probably make sense to keep for SLE11. But it's not my decision.

Here's the upstream bug about using the keyring: http://developer.pidgin.im/ticket/673. It looks like they want to integrate something like this in 3.0.0 (no idea when it'll be released), but it's unlikely they'll go with our patch.

So, yeah, for openSUSE, I'm fine removing the patch, I guess. On a general note, I'm not sure why we have so many patches for pidgin that are not upstream, so I'm all for upstreaming them, or removing them.

I created new bug 569271 to review downstream pidgin patches.

pidgin from home:vuntz:11.2-testing certainly works better if gnome-keyring is not running. the passwords are not wiped from the config anymore.

Well, I see a problem:

I am not be able to enable it for SLED11 and disable for openSUSE 11.1. I am searching for a way to differentiate between openSUSE 11.1 and SLE11 and I cannot find any.

In older SLES version, there was a %sles_version variable. In SLE11 it is not.

I guess I have to install and parse distribution-release.

well, if the patch is not good enough for openSUSE why should it be for SLED (and vice versa)? The patch didn't work on SLED before either, didn't it? So the new feature was 'inadvertently' introduced there as well.

I guess that there are different requrements. But please correct me if anybody has a different opinion.


SLED:

- Customers use GNOME+pidgin or KDE+kopete. In both cases, opening the
appropriate keyring happens automatically during login.

- Customers want to store IM passwords really safe.


openSUSE:

- Users use arbitrary combinations of pidgin and desktop environment. In some
of these combinations, pidgin requires extra password to unlock the keyring and it is not possible to skip this dialog.

- Encrypted local storage of passwords is not a top priority.


Related discussion: bug 186189

It is marked as fixed, but I think that it is not. The current solution -
KDE/GNOME unlocks its own keyring on login, other environments don't unlock
anything, is far from an optimal solution.

The same problems affects other users of keyrings:

- evolution outside GNOME (but how many people do it?)

- FATE outside KDE

for comment#11/#12: well finding out sles vs opensuse at install time
(e.g. %post) would be the right solution.
Installing $foo-release at build-time would just circumvent that we killed
the sles-version macro on purpose: a package should not differenciate at
build time between these two ...

Use of distribution-release does not work as well:

have choice for distribution-release: dummy-release sles-release sled-release


Summary: Our build system makes impossible to keep this patch for SLE11 and not apply for openSUSE.


So there remains several bad solutions:

1. Implement an incredibly ugly hack to discriminate between openSUSE 11.1 and SLED11 during compile time.

2. Drop the patch breaking a small piece of privacy on SLED.

3. Keep this patch in openSUSE and consider this report as INVALID, at least for openSUSE versions that perform code base for SLED.

4. Keep things as they are for now and start working on another solution and provide it with the next security issue.

If there are no objections, I'll go for 3, as it means least effort. It will fix openSUSE complains for 11.0 and 11.2, but not for 11.1.

Going to 2 would be even better, but requires approval from the SLED managers.

Yet another ugly solution:

5. pidgin.spec files will be equal in all products with exception of a single line: %define building_for_sle 0/1. Then hope, that maintainer will never forget to edit the spec file before the submit.

*** Bug 574419 has been marked as a duplicate of this bug. ***

An ugly fix 5 from comment 18 was applied to the security fix bnc#567799:

gnome-keyring is not used in openSUSE.

gnome-keyring is used in SLED11.

gnome-keyring is not used in SLED10 (the support was always broken there).

gnome-keyring is used in NLD9.

Just got the 11.2 update and suddenly all my accounts are not working anymore.
This cannot be a solution! I like that openSUSE takes updates a bit more relaxed than before but this type of change really must be avoided and if really not possible be documented in the patch description. I cannot even find anything about it in the rpm changelog.
That's nothing I expect from an official security online update. Not amused.