https://bugs.kde.org/show_bug.cgi?id=313216
--- Comment #34 from Thaodan <m...@thaodan.de> --- (In reply to Alexander Schlarb from comment #33) > (In reply to Thaodan from comment #32) > > (In reply to Alexander Schlarb from comment #29) > > > > > Finally, how would you feel about replacing the existing KWallet daemon > > > with > > > a proxy implementation that forwards all calls on the KWallet D-Bus API to > > > org.freedesktop.Secrets/KeePassXC? At this point we're back to “+1”s of > > > course, but if done properly, KWalletManager and all existing KWallet > > > clients should continue to work and, as a future endeavour, KeePassXC > > > could > > > be stripped of its GUI and simply run as a daemon in the background while > > > supporting the well-established KDBX2 database format with native sync > > > support, as well as having browser integration and of course the > > > org.freedesktop.Secrets API. > > This could break usescases that use GPG to encrypt the password database. > > I see, didn't know KWallet could do that. Is this a blocker though? When do > people actually use this option over master passwords (and especially the > auto-unlock with login password option)? When they want to secure the wallet by more then a password, especially when the authentication method is separate from the computer e.g. on smartcard. This also allows to cache the authentication to limit the time the wallet can be opened without opening the authentication method again. This is also a part of a central authentication with a key instead of a password and allows physical separation from the device that requests the authentication and they one that stores the secret that is unlocked. This then allows to remove the physical token when the user leaves the computer. -- You are receiving this mail because: You are watching all bug changes.
