After updating to >=net-misc/nextcloud-client-3.8.0 I had to login via the website auth method on every app start. My keychain was unlocked, I checked via seahorse. I have not found any bug entries upstream (neither in nextcloud/deskop nor in qtkeychain), so this might just be my system. However, I could fix it by upgrading dev-libs/qtkeychain to 0.14.0, and manual rebuild of nextcloud-client followed by an additional web auth login. After closing the client, following app starts worked correctly. Reproducible: Always Steps to Reproduce: 1. start nextcloud-client 2. web auth starts to request a login 3. close the client 4. start the nextcloud-client Actual Results: web auth is requied every time Expected Results: authentification is reused via libsecret I do not have the logs anymore, but the relevant parts are that after: [ info nextcloud.sync.account /tmp/portage/net-misc/nextcloud-client-3.8.0/work/desktop-3.8.0/src/libsync/account.cpp:761 ]: appPassword stored in keychain followed by: [ warning nextcloud.sync.credentials.keychainchunk /tmp/portage/net-misc/nextcloud-client-3.8.0/work/desktop-3.8.0/src/libsync/creds/keychainchunk.cpp:360 ]:Unable to read "<user>_clientCertificatePEM:https://<domain>/:0" chunk "0" "Entry not found" [ warning nextcloud.sync.credentials.keychainchunk /tmp/portage/net-misc/nextcloud-client-3.8.0/work/desktop-3.8.0/src/libsync/creds/keychainchunk.cpp:360 ]: Unable to read "<user>_clientKeyPEM:https://<domain>/:0" chunk "0" "Entry not found" [ warning nextcloud.sync.credentials.webflow /tmp/portage/net-misc/nextcloud-client-3.8.0/work/desktop-3.8.0/src/gui/creds/webflowcredentials.cpp:484 ]: Unable to read client key "Entry not found" and on app close, the appPassword could NOT be stored.
Please correct me if I'm wrong with my $summary changes. Assuming you just assumed gnome-base/gnome-keyring when really what qtkeychain[keyring] does is pull in app-crypt/libsecret.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d67443f3670672c937dccfbf9bfe43a9fa74c09b commit d67443f3670672c937dccfbf9bfe43a9fa74c09b Author: Florian Schmaus <flow@gentoo.org> AuthorDate: 2023-05-26 09:25:22 +0000 Commit: Florian Schmaus <flow@gentoo.org> CommitDate: 2023-05-26 09:31:46 +0000 net-misc/nextcloud-client: add 3.8.2 This also adds the USE=keyring requirement to the qtkeychain dependency (bug #907201). Thanks to asturm for wrangling the bug and pointing out the fix, and to Alexander Petermann for reporting the issue. Closes: https://bugs.gentoo.org/907201 Signed-off-by: Florian Schmaus <flow@gentoo.org> net-misc/nextcloud-client/Manifest | 1 + .../nextcloud-client/nextcloud-client-3.8.2.ebuild | 113 +++++++++++++++++++++ 2 files changed, 114 insertions(+)
(In reply to Andreas Sturmlechner from comment #1) > Please correct me if I'm wrong with my $summary changes. > > Assuming you just assumed gnome-base/gnome-keyring when really what > qtkeychain[keyring] does is pull in app-crypt/libsecret. No, I had libsecret already installed. I missed libsecret a few months (or about a year ago) because I had the wrong use flag set: >=dev-libs/qtkeychain-0.6.2 qt5 gnome-keyring instead of: >=dev-libs/qtkeychain-0.6.2 qt5 keyring I removed the select on libsecret after finding this a few days ago, but that did not fix the issue for me. Maybe it was another rebuild/ restart/ login whatever required. However, like I can't pinpoint the issue and the ebuild change for 3.8.2 might have been enough for me, and I'm glad you helped so quickly.
Please revert the dependency on qtkeychain[keyring]. The bug was caused by local USE flag issue, see previous comment. qtkeychain can use kwallet as a backend directly. See also bug 765220, this has happened before.
(In reply to Andrei Slavoiu from comment #4) > Please revert the dependency on qtkeychain[keyring]. The bug was caused by > local USE flag issue, see previous comment. qtkeychain can use kwallet as a > backend directly. See also bug 765220, this has happened before. 1. Like I have sad before, the useflag change was NOT the root course for my issue. After fixing my useflag I even added 'keyring' to my make.conf, but the bug persisted. 2. It might make sense to be able to add a 'keyring' use flag to nextcloud-client so that the dependency chain is valid whenever one does want to use gnome-keyring and not kwallet
(In reply to Alexander Petermann from comment #5) > (In reply to Andrei Slavoiu from comment #4) > > Please revert the dependency on qtkeychain[keyring]. The bug was caused by > > local USE flag issue, see previous comment. qtkeychain can use kwallet as a > > backend directly. See also bug 765220, this has happened before. > > 1. Like I have sad before, the useflag change was NOT the root course for my > issue. After fixing my useflag I even added 'keyring' to my make.conf, but > the bug persisted. > 2. It might make sense to be able to add a 'keyring' use flag to > nextcloud-client so that the dependency chain is valid whenever one does > want to use gnome-keyring and not kwallet BTW, qtkeychain can also use gnome-keyring as a native backend, if installed. This is from the code for selecting the backend on non-kde environments: if (LibSecretKeyring::isAvailable()) { return Backend_LibSecretKeyring; } if (GnomeKeyring::isAvailable()) { return Backend_GnomeKeyring; } if (isKwallet5Available()) { return Backend_Kwallet5; } As you can see, libsecret has priority if available, so if it didn't work for you it must have that you had a somehow broken instance of libsecret that it was trying to use. Probably if you uninstalled that it would have worked fine as well.
In the logs, which I can not reproduce anymore, I saw that the nextcloud client tried to fetch credentials 3 times. But without succeedes. The think is, I did nothing to libsecret (except rebuilding it 2x) to get it working, but only the changes to nextcloud-client and qtkeychain helped. However, I can't reproduce this anymore and debug further.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e9011b6c2389a31f703ad6def5843f01137a50ff commit e9011b6c2389a31f703ad6def5843f01137a50ff Author: Florian Schmaus <flow@gentoo.org> AuthorDate: 2023-05-26 18:45:54 +0000 Commit: Florian Schmaus <flow@gentoo.org> CommitDate: 2023-05-26 18:47:35 +0000 net-misc/nextcloud-client: revert qtkeychain[keyring] dependency Turns out that qtkeychain supports multiple backends and it the root cause of bug #907201 was probably something else. Thanks to Andrei Slavoiu for pointing this out. Bug: https://bugs.gentoo.org/907201 Signed-off-by: Florian Schmaus <flow@gentoo.org> .../{nextcloud-client-3.8.2.ebuild => nextcloud-client-3.8.2-r1.ebuild} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
