Bug 297615 - Akonadi asks for wallet password even though no kmail2 has not been started
Summary: Akonadi asks for wallet password even though no kmail2 has not been started
Status: RESOLVED UNMAINTAINED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 4.8
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-06 18:00 UTC by Paul Gover
Modified: 2017-01-09 10:08 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Gover 2012-04-06 18:00:54 UTC
I use korganizer, and in particular kmail2 to handle my email.  I have three accounts, all POP3, with different servers.  Some time after booting my machine a dialog box suddenly pops up, asking form my wallet password, for the first of my email accounts - but I have NOT started kmail2 and it is not running.  A little later, I get the prompt for the second account.  Then the third.  I still have not started kmail2 (and, for clarity, it's not been restarted after closing an earlier KDE session without closing kmail2).

My guess it's the automatic "interval mail checking", and the requests for password  follow the 3 different times I have set for the 3 accounts.  I do have "Enable interval mail checking" selected for each account.  I'd be happy if kmail2 were running, but it isn't, and it's annoying (and worrying) that I get an unexpected request for the wallet password.

It didn't do this before about KDE 4.7 - I can't say for sure when it started, but it's about then.  It's still there in 4.8, as I updated KDE yesterday.

It may be irrelevant, but something strange is also happening related to the chromium web browser.  I let it store its web passwords in the KDE wallet (it creates a binary store, called "Chrome form data").  If chromium is running before I start kmail2, and if chromium has already asked for the wallet password, then starting kmail2 does NOT ask for a wallet password, and kmail2 happily retrieves my email.  I presume chromium is doing something naughty here, and not scoping its use of the wallet properly.

I think this bug has already been reported as #292544, but I don't think the developer concerned understood what the issue was.  Certainly the bypasses there don't address the problem, which is Akonadi asking for the wallet password even though kmail2 has not been started and is not running.  That bug report was for IMAP accounts, whereas I'm hitting it with POP3 accounts.
Comment 1 Kim 2012-04-17 05:53:42 UTC
I have the same problem (with imap)
Comment 2 Paul Gover 2012-04-17 10:47:24 UTC
(In reply to comment #0)
I said:
> ...
> It may be irrelevant, but something strange is also happening related to the
> chromium web browser.  I let it store its web passwords in the KDE wallet
> (it creates a binary store, called "Chrome form data").  If chromium is
> running before I start kmail2, and if chromium has already asked for the
> wallet password, then starting kmail2 does NOT ask for a wallet password,
> and kmail2 happily retrieves my email.  I presume chromium is doing
> something naughty here, and not scoping its use of the wallet properly.
> ...
It's been pointed out to me that this behaviour can be changed by editing the [Auto Allow] stanza in  ~/.kde4/share/config/kwalletrc, and I'd probably caused kwallet to include "chromium" in that stanza some time ago.  So the paragraph above was indeed irrelevant.

The main bug described remains.
Comment 3 Joachim Wagner 2013-02-14 11:09:50 UTC
Now also have this problem. Ticking the option "Switch offline on KMail Shutdown" does not help. I always close kontact before logging out. Everything was running fine for 4 months. No idea what triggered the problem. I installed updates 2 days ago but rebooted and logged in yesterday without this problem.

When I hit "Deny", kontact/kmail popped up a error message in the lower right corner and coloured the IMAP tree view red. Will now re-login and hit "Always allow". Not a big deal.

JJ
Comment 4 Martin 2014-01-18 13:56:22 UTC
For me, akonadi checks my mails (without involving kmail) and therefore asks for a password.
Is this still valid for you?
Comment 5 Daniel Vrátil 2014-01-20 12:32:28 UTC
In Akonadi world, KMail, KOrganizer etc are just frontends for Akonadi. The actual handling of PIM data, including synchronization happens automatically, as it's controlled by Akonadi in the background

This is a combination of two factors: a known bug that Akonadi will trigger email synchronization when resource is started and that we forcibly start all Akonadi resources on Akonadi startup, even when they are not needed.

The only workaround I can think of right now is that you allow access to KWallet to all Akonadi resources that require it, so that you are not bothered by the password prompt.
Comment 6 Silver Salonen 2014-01-20 12:36:42 UTC
To me it seems the original report actually already is about KWallet prompting for password, eg. this is already a presumption.
Comment 7 Paul Gover 2014-01-22 18:29:57 UTC
The behaviour changed with the latest KDE PIM release I installed (4.8.5); up to and including the previous (4.8.3), it remained as described in the bug above.
It now appears to work as I'd expect.  (Whether that's correct is another question, but it suits me!)

Thus, if I start Kontact before doing anything else, Kwallet pops up and asks for my password, after which it successfully gets my new mail etc.

If I start Firefox first (I've changed to that in preference to Chromium), the first time I browse a web page allowing a login causes the Kwallet plugin to pop up and ask me for my password.  If I now start Kontact, it doesn't bother to ask for a password, it just goes off and get my mail.  I believe I can tailor this behaviour in the KDE System Settings, but it's what I want.

The one scenario I'm not sure about is if I start Firefox, and then close it, whether Kontact asks for a password.  I tried testing it, but think I need to wait longer for the password from Firefox to expire.

I suspect the change in behaviour is linked to the fact that I now get to see the "new mail" gizmo in the Task Manager.  I suspect that the KDE desktop was starting it silently in the background immediately after login, and now it gets kicked off when I start Kontact, which is the behaviour I expect.  (This may be because I explicitly closed both Kontact and the "new mail" gizmo once before logging out of KDE; maybe that cleared it from the list of tasks to restart at login.  But I'm guessing.)

In summary, I'm now a happier bunny.
(If I could work out what semantic desktop and akonadi and all that actually bought me, I'd be ecstatic.  How about updating KDE help and find files applications guys? )
Comment 8 Paul Gover 2014-01-22 18:31:45 UTC
Sorry, forgot to say, if I start KDE but use neither Kontact nor Firefox, now nothing pops up and asks for a password, which was, of course, the point of the bug.
Comment 9 Denis Kurz 2016-09-24 20:41:16 UTC
This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present?

If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.
Comment 10 Denis Kurz 2017-01-07 21:57:07 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.
Comment 11 Joachim Wagner 2017-01-09 10:08:32 UTC
The unexpected behaviour is still present in KMail5 (tested with version 16.08 of current OpenSUSE Leap 42.2). However, reading comment #5 and observing that "New Email Notify" boxes pop up even if kmail/kontact has not been started yet in the current KDE session, this seems to be a feature, not a bug.

Workaround: Store all e-mail passwords in a single KDE wallet. To avoid even the first password pop-up, set an empty password for the wallet. (Note, however, that the latter increases the risks to your passwords: malware stealing your files containing the wallet, you accidentally publishing your files, leaving the unlocked laptop unattended etc.)