same behaviour by upgrading to 4.14.4 (from the Version, openSuse 13.1 uses. Must be s.th. like 4.11.xx)

I have seen similar on a gentoo installation.

The default wallet used by all applications was working well all the time, why it took some time to notice this serious behaviour.

I am using my other wallets manually and less frequently. These could not be opened. After downgrading to kwallet and kwalletmanager to 4.14.3, I could only access backups of my secondary wallets. The primary files were inaccessible, so likely corrupted, as no version could open them.

Because I am using my secondary wallets less frequently I cannot say, if the change came after upgrading to kde applications 14.12 or to 14.12.1.

I had the same problem on Arch Linux. The workaround I found was to downgrade kwalletmanager to 4.14.3-1, at which time I could open my main default wallet used by applications and my main other wallet I stash stuff in myself.

However, I later discovered my other 3 wallets were unopenable still and so:
1. I downgraded kdebase-runtime (which contains kwalletd that I was targeting) from 14.12.1-1 => 4.14.3-1.
2. I killed kwalletd.
3. I opened my 3 previously unopenable wallets and made a change to each to force a new write. At this time one of my main wallets was unusable with an error code 42.
4. After upgrading kdebase-runtime back to 14.12.1-1, I killed kwalletd and had success with some of my 3 wallets but still got error -9 for one.
5. I killed kwalletd again after some time making no other changes and now all my wallets are working fine. What's more, I then upgraded kwalletmanager to 14.12.1-1 and my wallets are all still working fine.

It appears somewhere around kdebase-runtime 4.14.3-1 a data format migration is introduced that only happens on write and 14.12.1-1 is unable to use the old format for some reason.

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

Hrvoje, any idea if it could simply be caused by a missing dependency for the kwallet packages? It looks related to an update of KDE packages.

Albert, this is a really critical bug, and I am not sure if Valentin right now has the time to investigate it. Do you know of someone else who could understand kwallet internals?

hm, kwallet daemon is in the kdebase4-runtime package, so nothing should be missing. we had downstream report about this/similar issue with 14.12.0, and user reported back it got 'magically' resolved for him with 14.12.1

Odd, because both reports we have (excluding the comments here) mention updating 14.12.0 -> 14.12.1 broke it.

downstream report, http://bugzilla.opensuse.org/show_bug.cgi?id=913943

The downstream report seems closed & fixed. How about you? Still in trouble?

1. downgraded kdebase-runtime to 4.14.3-4.9-x86_64 (openSuse repo)
2. killed kwalletd (as root) and then startet kwalletmanager (as user)
3. upgrading kdebase-runtime back to 14.12.1-1, 
4. killed kwalletd (as root) and then startet kwalletmanager (as user)
5. killed kwalletd again after some time making no other changes to kwallet and then startet kwalletmanager (as user). 

This worked for me too. After step 2 (and before step 3) I was able to open the formerly unreachable 2 wallets (kdewallet and localwallt) and exported them as XML. Between step 4 and 5, I created a new wallet, imported the formerly exported XML of kdewallet and closed kwalletmanager. Then I go to $HOME/.kde4/share/apps/kwallet/ and I renamed the (unopenable) kdewallet.kwl and kdewallet.salt (only this one for testing) and the correspondending *.kwl/*.salt files, of the newly created wallet, as kdewallet.*. Restarting kwalletmanager and this works too.
So if you have a XML-backup of your wallets, they might be restoreable without down- and upgrading, but with the penalty of low-level file-handling.

PS. I used the easier blowfish crypt for the new crated wallets, where I imported my xml-backups.

The workaround described above only worked for me on *.kwl-files, I did not try to open before and for which I already got either an error "42" or "-9". These files remained unreadable by kwalletmanager, no matter what version of kdebase4-runtime I used.

Using the workaround I was able to open old *.kwl-files from a backup (opensuse 13.1), export them as XML and import them in my newly created, empty kwallets.

(In reply to Andy from comment #10)
> 1. downgraded kdebase-runtime to 4.14.3-4.9-x86_64 (openSuse repo)
> .......
This works for me as well... Doesnt explain why te update causes this issue, did the support for Blowfish end?

The upstream bug in openSUSE mentions an other code (-42 not -9), although the net result is identical...

We have a downstream bugreport in Mageia
https://bugs.mageia.org/show_bug.cgi?id=15246
after updating kdebase4-runtime in Mageia 4 with the patch from the KDE/4.12 branch
http://quickgit.kde.org/?p=kde-runtime.git&a=commit&h=afc98f06117aa720aeb608ea1ec6155a9c9d8398

> The standard "kdewallet" wallet can be opened after updating
> kdebase4-runtime-4.12.5-1.3.mga4, but the others (e.g. "passwords" wallet in
> my case) can't: there is a "Error code -9: wrong password" error.

*** This bug has been confirmed by popular vote. ***

Have those people rebooted their computers after the update?

Yes I did reboot my computers (3 in total).

Please notice that the kwallet-dump python utility managed to open the "passwords" wallet but not the "kdewallet", thus suggesting that the "passwords" wallet has not been converted to the new format.


Personnaly my workaround was to get all my passwords decrypted using the kwallet-dump utility on my "passwords.kwl" file, and then convert it in the XML backup format of kwallet (using a simple python script of my own). Then importing this XML file into a new "passwords" wallet. Of course not everyone can do that, and probably the downgrading workaround should be simpler. But maybe also a standalone command line script can do the job of encrypting/decrypting between preivous and new formats: the kwallet-dump developer seems to have reverse engineered the .kwl format...

(In reply to Andy from comment #10)
> 1. downgraded kdebase-runtime to 4.14.3-4.9-x86_64 (openSuse repo)
> 2. killed kwalletd (as root) and then startet kwalletmanager (as user)
> 3. upgrading kdebase-runtime back to 14.12.1-1, 
> 4. killed kwalletd (as root) and then startet kwalletmanager (as user)
> 5. killed kwalletd again after some time making no other changes to kwallet
> and then startet kwalletmanager (as user). 
> 
> This worked for me too. After step 2 (and before step 3) I was able to open
> the formerly unreachable 2 wallets (kdewallet and localwallt) and exported
> them as XML. Between step 4 and 5, I created a new wallet, imported the
> formerly exported XML of kdewallet and closed kwalletmanager. Then I go to
> $HOME/.kde4/share/apps/kwallet/ and I renamed the (unopenable) kdewallet.kwl
> and kdewallet.salt (only this one for testing) and the correspondending
> *.kwl/*.salt files, of the newly created wallet, as kdewallet.*. Restarting
> kwalletmanager and this works too.
> So if you have a XML-backup of your wallets, they might be restoreable
> without down- and upgrading, but with the penalty of low-level file-handling.
> 
> PS. I used the easier blowfish crypt for the new crated wallets, where I
> imported my xml-backups.

Well, seeing all these steps needed to get you wallets working after the security update, I'd really like to understand what's happening. But we're talking here about wallets, containing sensitive data. I cannot ask you to send me these files, so could you please use a hexdump tool and show me what are the first 16 bytes of the unrecognized wallets?

(In reply to Albert Astals Cid from comment #15)
> Have those people rebooted their computers after the update?

And along writing this, I realise : the update was done on a live system. The kwalletd was already running. It uses libkwalletbackend.so and that got updated. Are there any chances that the new libkwalletbackend.so got updated in memory also?

Grappling with very similar symptoms that began a few days ago.

I am presently running kwalletmanager-4.14.3-1.fc20.x86_64 rpm.  

I keep two wallets:
- "kdewallet" as default wallet for normal passwords.  I allow programs access to this wallet directly.
- "mywallet" for passwords that I allow programs minimal direct access to.

My kdewallet continues to function but when I open "mywallet" a dialog complains "Error opening the wallet 'mywallet'.  Please try again.  (Error code -9: Read error - possibly incorrect password)."

I *know* that I am entering my password correctly.  I access mywallet less often than kdewallet and so I can't pinpoint the time when things went bad.

I have daily snapshots of all files for the last 45 days and have been unable to use kwalletmanager to reload from old files.

My yum logs show that I updated to kwalletmanager-4.14.3-1.fc20.x86_64 Nov 26 last year.

I've tried accessing the wallet files from an old version of kwalletmanager (4.11) but it says something like "wrong revision".

I am taking steps similar to those of other posters to see if they help.

I'm having the same problem. (openSUSE 13.2 after upgrading from 4.14.3 -> 4.14.4).
Two wallets, one is considered the main one and was converted? during the update.

Downgrading to 4.14.3 I could access the second one but no longer the main one Error Code 42.

So I simply exported the content of the second one to xml and created a new one after upgrading to 4.14.4 again. 
(The upgrade didn't touch the second one this time either so it was not accessible after the upgrade again whilst the main one was no error 42 any longer.)

Can I trigger the conversion progress manually for the ones, not being accessible under 4.14.4?
That would definitely help those, not able to downgrade any longer.

More detailed description:
https://forums.opensuse.org/showthread.php/505025-kdewallet-broken-after-yesterdays-backup?p=2694469#post2694469

4.14.4 of what package? There's no released 4.14.4 package of anything that should be causing this, the change to kwalletd code was released as part of kde-runtime 14.12.1

Created attachment 91037 [details]
The KDE-Platform-Version prior to upgrade

(In reply to Albert Astals Cid from comment #21)
> 4.14.4 of what package? There's no released 4.14.4 package of anything that
> should be causing this, the change to kwalletd code was released as part of
> kde-runtime 14.12.1

This is the version number displayed in kinfocenter. Honestly, I do have trouble to understand the versioning schema. But if kde-runtime is the culprit, than the exact version of this package is
kdebase4-runtime-14.12.1-8.24.x86_64

The package installed applying the recommended update ( openSUSE-RU-2015:0183-1 - 
http://lists.opensuse.org/opensuse-updates/2015-02/msg00000.html )
is most probably this one:
http://download.opensuse.org/update/13.2/x86_64/kdebase4-runtime-4.14.3_14.12.1-4.9_8.24.x86_64.drpm

I'm still interested on how to convert the corrupt wallets manually.

HTH

Valentin is the one in the know, please read his comments about getting the first 16 bytes of the file.

(In reply to Valentin Rusu from comment #17)
> send me these files, so could you please use a hexdump tool and show me what
> are the first 16 bytes of the unrecognized wallets?

Broken wallet
0000:0000 4b 57 41 4c 4c 45 54 0a 0d 00 0d 0a 00 01 00 02 KWALLET.........

Working wallet
0000:0000 4b 57 41 4c 4c 45 54 0a 0d 00 0d 0a 00 01 03 02 KWALLET.........

> > Have those people rebooted their computers after the update?
Yes, both my machines were rebooted

> talking here about wallets, containing sensitive data. I cannot ask you to send ...
I just created a new blowfish encrypted wallet on another openSUSE 13.1 machine with
rpm -qa | grep walletmanager
kwalletmanager-4.14.3-2.4.i586

Transfering this to the current machine
rpm -qa | grep walletma
kwalletmanager-14.12.1-8.1.x86_64
rpm -qa | grep kdebase4-runtime
kdebase4-runtime-14.12.1-8.24.x86_64
I'm no longer able to open it.

If it was of any help I could send this to you as I just added foobar entries and used a simple and no sensitive password to secure it
I'd still rather mail it to you directly rather than attaching it here.
@Valentin: are you interessted?


(In reply to Hrvoje Senjan from comment #8)
> downstream report, http://bugzilla.opensuse.org/show_bug.cgi?id=913943
I do not think that is the same issue here.
The repoterd clamed to have upgraded to openSUSE 13.2 and seen the error 42.
After I upgraded from openSUSE 13.1 to 13.2, I had an older KDE version since it took a while until more recent KDE packages were provided for 13.2.
So his wallet might have been already updated/converted then updating the KDE version whilst running an older openSUSE-version.
I've seen Error 42 myself after downgrading to an older KDE version and trying to open the main wallet. This error disappeard after going back to the last KDE version again.

(In reply to Meinhard Ritscher from comment #25)

OK, thanks for the headers. If you look closely, you'll see that the working one has an 03 juste before the 02 KWALLET:
> Broken wallet
> 0000:0000 4b 57 41 4c 4c 45 54 0a 0d 00 0d 0a 00 01 00 02 KWALLET.........
> Working wallet
> 0000:0000 4b 57 41 4c 4c 45 54 0a 0d 00 0d 0a 00 01 03 02 KWALLET.........

That 03 corresponds to the new schema and I'd like to ask you: can you change that 00 in 03 in the broken wallet, save it, then retry to open it. Does this solve your issue?

> @Valentin: are you interessted?
Not yet, waiting for your test.

> 
> 
> (In reply to Hrvoje Senjan from comment #8)
> > downstream report, http://bugzilla.opensuse.org/show_bug.cgi?id=913943
> I do not think that is the same issue here.
> The repoterd clamed to have upgraded to openSUSE 13.2 and seen the error 42.
> After I upgraded from openSUSE 13.1 to 13.2, I had an older KDE version
> since it took a while until more recent KDE packages were provided for 13.2.
> So his wallet might have been already updated/converted then updating the
> KDE version whilst running an older openSUSE-version.
> I've seen Error 42 myself after downgrading to an older KDE version and
> trying to open the main wallet. This error disappeard after going back to
> the last KDE version again.

That's consistent behavior, as the old version should not be able to read the new schema, the one having the 03 byte I already pointed you to.

(In reply to Valentin Rusu from comment #26)
> That 03 corresponds to the new schema and I'd like to ask you: can you
> change that 00 in 03 in the broken wallet, save it, then retry to open it.
> Does this solve your issue?
I'm sorry to have to disappoint you but still seeing the -9 error after doing so. (Just logged out and in again just to make sure)

Tried this with two broken wallets

I notice some similarities between the state of my files and those of M. Ritscher.  I have two wallets, one broken (mywallet) and one working (default kdewallet).  Their headers are like so:

Broken wallet (mywallet):
00000000  4b 57 41 4c 4c 45 54 0a  0d 00 0d 0a 00 01 00 02  |KWALLET.........|

Working wallet (kdewallet):
00000000  4b 57 41 4c 4c 45 54 0a  0d 00 0d 0a 00 01 03 02  |KWALLET.........|

Changing byte 15 (offset 14) of the broken wallet from 00 to 03 has not allowed me to open the wallet.

I've found it hard to duplicate the downgrade/upgrade process used by some of the other posters so I can't yet tell if it works for me.

(In reply to Meinhard Ritscher from comment #27)
> (In reply to Valentin Rusu from comment #26)
> > That 03 corresponds to the new schema and I'd like to ask you: can you
> > change that 00 in 03 in the broken wallet, save it, then retry to open it.
> > Does this solve your issue?
> I'm sorry to have to disappoint you but still seeing the -9 error after
> doing so. (Just logged out and in again just to make sure)
> 
> Tried this with two broken wallets

OK, can you please attach the test wallets please?

(In reply to Hans de Raad from comment #12)
> (In reply to Andy from comment #10)
> > 1. downgraded kdebase-runtime to 4.14.3-4.9-x86_64 (openSuse repo)
> > .......
> This works for me as well... Doesnt explain why te update causes this issue,
> did the support for Blowfish end?

The support for blowfish will not end. It only received a security update, as the previous implementation had a security problem.

Created attachment 91088 [details]
A Wallet no longer openable with the current KDE version

Password is the same as the wallet's name (lower case)

(In reply to Meinhard Ritscher from comment #31)
> Created attachment 91088 [details]
> A Wallet no longer openable with the current KDE version
> 
> Password is the same as the wallet's name (lower case)

bunzip2 says the file is not a bzip2 file. Perhaps it got corrupted on its way. Could you please re-attach it.

Created attachment 91092 [details]
A Wallet no longer openable with the current KDE version

I downloaded it and could open it without any trouble. Uploading it again.
Added a MD5 sum for verification

Password: same as the wallet name (lower case)

~>tar -tvf testcase2.tgz 
-rw------- joe/users       260 2015-02-12 21:21 testcase.kwl
-rw-r--r-- joe/users        56 2015-02-12 21:18 testcase.salt
~>md5sum testcase2.tgz 
91d1724756aa7a0574d32ffd9a0d4762  testcase2.tar.bz2
~> file testcase2.tgz 
testcase2.tgz: gzip compressed data,

(In reply to Meinhard Ritscher from comment #33)
> Created attachment 91092 [details]
> A Wallet no longer openable with the current KDE version
> 
> I downloaded it and could open it without any trouble. Uploading it again.
> Added a MD5 sum for verification
> 
> Password: same as the wallet name (lower case)
> 
> ~>tar -tvf testcase2.tgz 
> -rw------- joe/users       260 2015-02-12 21:21 testcase.kwl
> -rw-r--r-- joe/users        56 2015-02-12 21:18 testcase.salt
> ~>md5sum testcase2.tgz 
> 91d1724756aa7a0574d32ffd9a0d4762  testcase2.tar.bz2
> ~> file testcase2.tgz 
> testcase2.tgz: gzip compressed data,

OK, this time it decompressed without problems. And I even could open it on my system - see the attached screenshot. That becomes bizarre.

Created attachment 91094 [details]
The "testcase" wallet successfully open on my system

Do you confirm that's the test wallet you created, please?

OK, I managed to reproduce your issue on my system. And I think I know where the problem is. Now working to fix that.

The problem is that I backported the CBC security fix to 4.12 not knowing that some older change made by the team has not also been backported. That leaved the 4.12 kwalletd backend code into an inconsistent state.

Meanwhile, do not hesitate to upgrade to KDE/4.14 if you can, as the screenshot showing the opened wallet was obtained with that version, on my system.

Git commit d67da2bc99d1ca78c10d056df666e9d1da663e62 by Valentin Rusu, on behalf of Àlex Fiestas.
Committed on 13/02/2014 at 14:26.
Pushed by vrusu into branch 'KDE/4.12'.

Replace SHA with PBKDF2-SHA512+Salt

Uses the MINOR_VERSION (which until now it was 0) to upgrade the hash
from SHA to PBKDF2-SHA512+salt.
I would have loved to completely replace it once the wallet is ported
to the new hashing but because of kwalletd code that is not possible
without a bigger rewrite.

There are 2 reasons for this patch:
1-We avoid using our own implementation of SHA
2-We use a modern hashing technique

I'm cooking more patches to use the system user password to open the
wallet, we want that password to be hashed using PBKDF2_SHA512
for security reasons.

REVIEW: 115497

NOTE by valir: this was not backported to 4.12 branch and because of
that my CBC patch let the sources into an incosistent state in respect
with the 4.14 branch. I cherry-picked this commit here, on the 4.12
branch an now the problem is gone, confirmed using the "testcase"
wallet provided with the bug report.

M  +6    -0    CMakeLists.txt
A  +61   -0    cmake/modules/FindLibGcrypt.cmake
M  +1    -1    kwalletd/backend/CMakeLists.txt
M  +8    -2    kwalletd/backend/backendpersisthandler.cpp
M  +119  -14   kwalletd/backend/kwalletbackend.cc
M  +4    -0    kwalletd/backend/kwalletbackend.h

http://commits.kde.org/kde-runtime/d67da2bc99d1ca78c10d056df666e9d1da663e62

Reopening.

Above commit cannot possibly fix this, because it would only affect the old KDE/4.12 branch.

Testing using system packages on ArchLinux  - the testcase wallet opens OK

 $ pacman -Q | grep kdebase-runtime
kdebase-runtime 14.12.2-2

Testing using the sources from download.kde.org (kde-runtime-14.12.2.tar.xz) - the testcase wallet opens OK

So, should we file this BUG downstream?

Opened downstream BUG with openSuse :
https://bugzilla.opensuse.org/show_bug.cgi?id=917988

Please feel free to update that bug report as needed.

regarding last two comments: we have people here from mageia and gentoo(?) also, so i'm not sure 'downstreaming' the report is correct...

(In reply to Meinhard Ritscher from comment #33)
> Created attachment 91092 [details]
> A Wallet no longer openable with the current KDE version
> 
> I downloaded it and could open it without any trouble. Uploading it again.
> Added a MD5 sum for verification
> 
> Password: same as the wallet name (lower case)
> 
> ~>tar -tvf testcase2.tgz 
> -rw------- joe/users       260 2015-02-12 21:21 testcase.kwl
> -rw-r--r-- joe/users        56 2015-02-12 21:18 testcase.salt
> ~>md5sum testcase2.tgz 
> 91d1724756aa7a0574d32ffd9a0d4762  testcase2.tar.bz2
> ~> file testcase2.tgz 
> testcase2.tgz: gzip compressed data,

Could you please test as instructed here:
https://bugzilla.opensuse.org/show_bug.cgi?id=917988#c3

Reopening - tests done by openSuSE show the problem is in our sources.

Created attachment 91117 [details]
Fix attempt for kwalletd/backend

I think I found the problem and this patch is a fix attempt, for those who can build from sources. OpenSuSE users, please follow the bug I opened there, as I already attached this patch there, and asked for a test on their side.

Please apply the patch from the kde-runtime/kwalletd directory, to get the backend patched, then build & install & test. Does it fixes the problem?

i've applied the patch, and the issue is resoved for me.
also tried to adjust it for the kwallet-framework (experienced the bug there also), and it is working with kwalletd5 correctly now with your patch =)

Git commit 345e36a8b35e2c6f8fcda50d0776d77102d6648a by Valentin Rusu.
Committed on 16/02/2015 at 21:44.
Pushed by vrusu into branch 'Applications/14.12'.

Fix for the random wallet open failure when updating

The problem seems to be caused by the use of BackendPersistHandler
singleton when the user has several wallets on his system and not
all of them have been updated to the new schema.

M  +7    -23   kwalletd/backend/backendpersisthandler.cpp
M  +11   -8    kwalletd/backend/kwalletbackend.cc

http://commits.kde.org/kde-runtime/345e36a8b35e2c6f8fcda50d0776d77102d6648a

Git commit 33a17ba0104cd94f2e33a3ac007b300553cdb417 by Valentin Rusu.
Committed on 16/02/2015 at 21:44.
Pushed by vrusu into branch 'KDE/4.14'.

Fix for the random wallet open failure when updating

The problem seems to be caused by the use of BackendPersistHandler
singleton when the user has several wallets on his system and not
all of them have been updated to the new schema.

M  +7    -23   kwalletd/backend/backendpersisthandler.cpp
M  +11   -8    kwalletd/backend/kwalletbackend.cc

http://commits.kde.org/kde-runtime/33a17ba0104cd94f2e33a3ac007b300553cdb417

Git commit 3495ca773d925b7536f1dcafe6ed4c6302c3cdf9 by Valentin Rusu.
Committed on 16/02/2015 at 21:44.
Pushed by vrusu into branch 'KDE/4.13'.

Fix for the random wallet open failure when updating

The problem seems to be caused by the use of BackendPersistHandler
singleton when the user has several wallets on his system and not
all of them have been updated to the new schema.

M  +7    -23   kwalletd/backend/backendpersisthandler.cpp
M  +11   -8    kwalletd/backend/kwalletbackend.cc

http://commits.kde.org/kde-runtime/3495ca773d925b7536f1dcafe6ed4c6302c3cdf9

Git commit d14b2da6fe4d4ed415c6a8f2361ce4e5fc685d2d by Valentin Rusu.
Committed on 17/02/2015 at 21:45.
Pushed by vrusu into branch 'master'.

Retrofitting the fix for a bug found in Applications/14.12

Commit 345e36a8b35 from Applications/14.12
Fix for the random wallet open failure when updating

The problem seems to be caused by the use of BackendPersistHandler
singleton when the user has several wallets on his system and not
all of them have been updated to the new schema.

M  +7    -24   src/runtime/kwalletd/backend/backendpersisthandler.cpp
M  +4    -1    src/runtime/kwalletd/backend/kwalletbackend.cc

http://commits.kde.org/kwallet-framework/d14b2da6fe4d4ed415c6a8f2361ce4e5fc685d2d

(In reply to Valentin Rusu from comment #49)
> Git commit d14b2da6fe4d4ed415c6a8f2361ce4e5fc685d2d by Valentin Rusu.
> Committed on 17/02/2015 at 21:45.
> Pushed by vrusu into branch 'master'.
> 
> Retrofitting the fix for a bug found in Applications/14.12
> 
> Commit 345e36a8b35 from Applications/14.12
> Fix for the random wallet open failure when updating
> 
> The problem seems to be caused by the use of BackendPersistHandler
> singleton when the user has several wallets on his system and not
> all of them have been updated to the new schema.
> 
> M  +7    -24   src/runtime/kwalletd/backend/backendpersisthandler.cpp
> M  +4    -1    src/runtime/kwalletd/backend/kwalletbackend.cc
> 
> http://commits.kde.org/kwallet-framework/
> d14b2da6fe4d4ed415c6a8f2361ce4e5fc685d2d

From your description of the problem I was able to recover my wallet data.

1.  I backed up all wallets.
2.  I deleted all wallets except for my one problem wallet.
3.  Restart kwallet.
4.  Problem wallet opens like a charm.

Git commit ac812e35ec27d061472b191654a7c48976e11f0c by Hrvoje Senjan.
Committed on 09/03/2015 at 19:53.
Pushed by hrvojes into branch 'Applications/15.04'.

Merge remote-tracking branch 'origin/Applications/14.12' into Applications/15.04

M  +0    -2    kcontrol/emoticons/emoticons.desktop
M  +0    -3    kcontrol/locale/language.desktop
M  +0    -35   knotify/kde.notifyrc
M  +2    -0    kurifilter-plugins/ikws/searchproviders/qwant.desktop
M  +2    -0    kurifilter-plugins/ikws/searchproviders/qwant_news.desktop
M  +2    -0    kurifilter-plugins/ikws/searchproviders/qwant_shopping.desktop
M  +2    -0    kurifilter-plugins/ikws/searchproviders/qwant_social.desktop
M  +2    -0    kurifilter-plugins/ikws/searchproviders/qwant_videos.desktop
M  +0    -3    nepomuk/kcm/kcm_nepomuk.desktop
M  +0    -3    phonon/kcm/kcm_phonon.desktop
M  +0    -2    pics/hicolor/index.theme

http://commits.kde.org/kde-runtime/ac812e35ec27d061472b191654a7c48976e11f0c

Git commit 0c861f17b801052b8aa798210ad5c6f1af39ed03 by Hrvoje Senjan.
Committed on 09/03/2015 at 19:54.
Pushed by hrvojes into branch 'master'.

Merge remote-tracking branch 'origin/Applications/15.04'


http://commits.kde.org/kde-runtime/0c861f17b801052b8aa798210ad5c6f1af39ed03

Valentin, i've merged 14.12 to 15.04 to master - the fix wasn't present in 15.04 beta...

Dear all,

I have read this bug report and your comments thoroughly, However, I'm not able to open my wallets.
I'm using Gentoo stable and updated release. KDE/KWallet version is 4.14.3. I can see that the patch is applied on my Gentoo system and I don't remember having troubles opening the wallets on my system. However, my computer is in service shop. I have full backup of my system, and I can't open my wallets and access my passwords. I'm having a nightmare.
I tried: Kubuntu-14.04.4, Kubuntu-15.10, Mint-17.3, Sabayon-15.02.1, Slackel-16.02.
Neither one of these distribution can open my wallets. Is it possible that neither one has applied the patch?!
Gentoo has this patch since August 2015 and I'm pretty sure that my wallets are updated.
Hex dump of both my wallets has "01 03 02 KWALLET" sequence. Does this mean that the wallets have been updated?
Does anyone knows any distribution that I can boot and open my wallets?

Kind regards!

Finally made it with openSuSE 13.2 with updated kwalletmanager and kdebase4-runtime...