Hi Johan, One important question here is how do you want the secrets to be unlocked. Is the user going to type in some master password every time the otpclient is started?
If that is the case, you can use QCA to encrypt and decrypt the data you need to store securely. If that is not the case - if you don't want to always ask the user for the password, then you can expect quite a complicated story of how to make something like kwallet safe. > 1. (On KDE) these libraries wind up calling dbus. We would like to > avoid plain text out-of-process communication of secrets, especially > communication through a 'shared' channel (for obvious reasons). > 2. In particular with KDE Wallet it was suggested that the wallet > itself may, in fact, not be encrypted. Another huge problem of kwallet is that it can not authenticate which application is asking for the password. I was told that this could be easier to do with flatpaks, but it will still need significant changes to how kwallet works. > Another possible contender is Plasma Vault, but we don't really know > how that would work in the context of an app, especially a flatpak > app. An approach like the one taken in Plasma Vault could work for applications, but it would (like the QCA option previously mentioned) require the user to type in the password every time. The problem with using Plasma Vault is that it works with fuse mounts - so the decrypted data si visible through the filesystem. (though, flatpaks could maybe have some solution there as well, not my area) Cheers, Ivan -- dr Ivan Čukić KDE, ivan.cu...@kde.org, https://cukic.co/ gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232 07AE 01C6 CE2B FF04 1C12
