https://bugs.kde.org/show_bug.cgi?id=495748
Alexey "Kitsune" Rusakov <kitsune....@pm.me> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kitsune....@pm.me
--- Comment #8 from Alexey "Kitsune" Rusakov <kitsune....@pm.me> ---
As I wrote in the libQuotient issue tracker, the situation is a bit
unconventional here. What is not written in the bug description is that NeoChat
is running outside of KDE; moreover, outside of a full desktop environment. One
of the terminal outputs has the crucial piece:
Could not save access token to the keychain: The name org.freedesktop.secrets
was not provided by any .service files
which leads me to believe that Qt Keychain couldn't find anything to work with
for a keychain, and the library disables E2EE in that situation, to protect the
user against data loss. Calling any E2EE-related method like
Connection::isKnownE2eeCapableDevice() would then lead to a crash because of
the missing E2EE backend. I would strongly recommend checking
Connection::encryptionEnabled() on the client side after
Connection::connected() or Connection::ready() are emitted; if it does not
return true, displaying a message to the user to the effect of "Oh noes, I
cannot encrypt anything!!!" and possibly disabling access to the account
altogether.
It could be argued that checking for Qt Keychain configuration sanity could be
done much earlier, even before logging in, then the message could be displayed
at the moment of saving/reading the access token. I'm open to discuss possible
extension to the library code in this regard - the current access token
saving/reading code doesn't handle keychain errors. NeoChat code will still
have to be changed in that case, too.
--
You are receiving this mail because:
You are watching all bug changes.
