Planning to upgrade to Leap 15.5 I have been keeping up to date with patches. But now on booting into the desktop a box pops up saying KWalletManager wants me to make a new wallet. If I click to continue the process a message pops up saying I should install at least one key, so I exported the only key I was using in Leap 15.3 (where I was using Kleopatra) using the gpg export command and then gpg import in my current Leap 15.4.
On booting into KDE plasma desktop a box showing no keys appears on clicking the continue button, with a note that only ultimately trusted keys are listed. According to the web page
[url]SDB:System upgrade - openSUSE Wiki
“older” versions of openSUSE should install two keys manually, so I thought to install a new trusted key but the rpm command didn’t work for me so I copied the text of the key from the web page and pasted it into a text file with the name gpg-pubkey-25db7ae0-645bae34.asc and imported it and edited it to ultimately trusted status with
Should work (I think). But I can’t be sure, because I did a clean install rather than an upgrade. For the clean install, I unchecked “pam_kwallet” so that it would not be installed. I locked it later.
Where I ran into minor problems, was with a 15.5 system that I had installed during alpha testing, before “pam_kwallet” became part of a default install. And that all worked. But on a later update (with “zypper dup”), I noticed that “pam_kwallet” was pulled in. Everything still worked, but “pam_kwallet” attempted to open “kwallet” during login (or a short time after login). That’s when I decided to uninstall and lock.
If you are upgrading 15.4, then you might be able to lock “pam_kwallet” in 15.4 before the upgrade. But that might depend on how you upgrade.
I spoke too soon; looking at the packages in YAST (in 15.4) I don’t see a pam_kwallet. But I plan to uninstall all the packages kwallet* and libkwalletbacknd5-5 and signon-kwallet-extension then click the box to get - “Do Not Install” (or maybe taboo before the upgrade)? That should stop pam_kwallet getting installed. I see that kleopatra is already installed.
To unlock KDE Wallet automatically on login, install kwallet-pam for the PAM compatible module. The chosen KWallet password must be the same as the current user password.
Note: kwallet-pam is not compatible with GnuPG keys, the KDE Wallet must use the standard blowfish encryption.
Please be aware that, if you’re worried that Blowfish “ain’t good enough” then, you should only be using the Blowfish encrypted default Wallet named “kdewallet” with a password which is the same as your login password for things which need to be unlocked at login time:
DrKonqi access to the KDE Bugzilla.
E-Mail account information for Akonadi and KDE PIM.
The rest of your sensitive information can be installed in additional wallets which use GnuPG for encryption.
You are advised to, make a dump of your existing Wallet and, MOVE that dump to at least one secure external storage medium which is not accessible via any form of a network and, is physically stored in secure place → such as a strongroom –
You are advised to NOT store the KWallet dump in a Cloud service …
Okay, that’s good. But I’ve not been using kwallet and the wallet appears empty (I probably should use it, I have passwords on my clipboard and I could avoid that).
I jumped to the conclusion that I would ned KDE wallet to manage the new keys mentioned here [url} https://en.opensuse.org/SDB:System_upgrade[/url] because the box prompted me to make a new wallet appeared, even though I wasn’t using it. I left key management of openSUSE packages to YAST and for the one source of non-hardware related software I use that does not come from openSUSE I used gpg to manually verify the code before I installed it.
Sorry if I mislead the thread but now I am set up to use KDE walet when I do upgrade to 15.5!
The KDE KWallet, only manages the keys used by the user who logged into the KDE Plasma Desktop.
The package certificates needed by YaST are managed at the system level and, are not those keys a logged-in user uses.
And, just to confuse you, there are also the system’s UEFI security certificates located in ‘/etc/uefi/certs/’ …
That is a useful one-liner. I see now that I had not imported the new signing key after all; if I had just cut and pasted the code on the web site (and as quoted in my last post) and run it as root all would have been well.
I never “looked under the hood” to see how openSUSE was handling the public keys for verifying its packages. While I realized that all the packages were rpm based I thought that the rpm commands as used here were, as it were, offered as a sort of add-on to zypper…