SUMMARY When configuring the sync function (nextcloud sync), the sync just works until kasts gets closed. When reopen the software, sync is disabled. When trying to login again, the password field is empty and even if it gets set again, sync stays disabled. Running the flatpak as root (sudo -i) works as expected. STEPS TO REPRODUCE 1. Install Kasts Flatpak and open it 2. Configure Synchronization for nextcloud-gpodder sync. 3. Sync your podcasts 4. Close Kasts 5. Reopen Kasts OBSERVED RESULT Synchronizsation is disabled and sync is not working anymore, even if you try to re-enter your credentials and url. EXPECTED RESULT Sync should work, even after closing and reopening Kasts. SOFTWARE/OS VERSIONS Linux: Debian Bookworm Kasts Version: 22.02 (Flatpak)
*** Bug 451306 has been marked as a duplicate of this bug. ***
Thanks for reporting. This is a bit puzzling though, as this works for me under all the scenarios that I'll list below. Kasts will try to save passwords first to the current keyring through the "secret service". In that case you should see a popup from the keyring when you have entered the password the first time (e.g. kde wallet, gnome keyring or keepassxc). Did you see such a popup? If not, kasts will try to fall back to saving the password to a local file. This should be in `~/.var/app/org.kde.kasts/data/KDE/kasts`. The filename should be equal to the username and should contain the password. Is this indeed the case? (You mentioned that it does work as root. Running as root will change the config and data directory for the flatpak. So that might indicate that there is an issue with the configuration under `./var` of your regular user account.) If not, you could enable debug for the sync routine to try and find out what's going on. You can do this by e.g. running the following from the command line: `QT_LOGGING_RULES=org.kde.kasts.sync=true flatpak run org.kde.kasts`. Then look for lines on the stdout that mention keychain and/or password files.
(In reply to bart from comment #2) > Thanks for reporting. This is a bit puzzling though, as this works for me > under all the scenarios that I'll list below. > > Kasts will try to save passwords first to the current keyring through the > "secret service". In that case you should see a popup from the keyring when > you have entered the password the first time (e.g. kde wallet, gnome keyring > or keepassxc). Did you see such a popup? > > If not, kasts will try to fall back to saving the password to a local file. > This should be in `~/.var/app/org.kde.kasts/data/KDE/kasts`. The filename > should be equal to the username and should contain the password. Is this > indeed the case? > > (You mentioned that it does work as root. Running as root will change the > config and data directory for the flatpak. So that might indicate that > there is an issue with the configuration under `./var` of your regular user > account.) > > If not, you could enable debug for the sync routine to try and find out > what's going on. You can do this by e.g. running the following from the > command line: > `QT_LOGGING_RULES=org.kde.kasts.sync=true flatpak run org.kde.kasts`. > Then look for lines on the stdout that mention keychain and/or password > files. Hey there, I knew about the config files in .var - so I tried to delete the configuration (folder) and start over again. The folder and the configuration gets recreated as expected. But the result is the same. I even tried to copy the folder from the root user to my actual user (and chown folder and files), since I know, sync works on the root user. Unfortunately, that did not work either. After your reply, I once again deleted the folder and started kasts with logging enabled as you mentioned. The first time, I configure sync, this was the relevant part: org.kde.kasts.sync: Save the password to the keychain for "my_nextcloud_username" org.kde.kasts.sync: Password saved to keychain org.kde.kasts.sync: Finished device update request (It syncs a first time) After closing casts and reopening it, the password field is empty again and stdout says: org.kde.kasts.sync: Save the password to the keychain for "my_nextcloud_username" But sync keeps being disabled. Also, I got no prompt for the keychain (never happened in Kasts). Also, there is no file in '~/.var/app/org.kde.kasts/data/KDE/kasts' containing the password. Is it correct, that "my_nextcloud_username" is used in the keyring and not my linux username?
Yes, that's correct: "my_nextcloud_username" is used to store the password in the keychain. Anyway, the debug output clearly shows that you have a keychain service running in the background. I have the impression that that service is not returning the stored password. That would also explain why clearing .var or copying working .var directories doesn't work. Do you know which keychain that is? What would happen if you disable or remove that service?
I am using the gnome-keyring and also keepass2 as my normal password storage, which shouldnt be involved in this (hopefully). By "using gnome-keyring" I mean, its installed and it manages my ssh-keys etc. I think, its a bit to elementary baked into my system to uninstall it...
Ok, no problem. I had KDE wallet interfere on my machine in the past, so I just uninstalled it since I wasn't using it at all. (Now using keepassxc without any issues.) I'm not suggesting removing stuff you actually use and/or require. :-) At least it's clear now that it might be related to gnome-keyring. Maybe a wild idea, but could you perhaps check the gnome-keyring settings to make sure that apps can connect to it to store/retrieve secrets. Just thinking about potential permission settings...
I found the entry for Kasts in the keyring earlier and deleted it. After deleting the Kasts folder in var and reopening Kasts, I entered my credentials again. The entry got created again in the keyring. Without any description. Its just the password and the app_id is org.kde.kasts. Not sure, if it is maybe an xorg/wayland thing, although normally wayland is the problematic one. This time, the entry in the keyring exclusively gets created in wayland. Neverless, the sync still doesnt work after restarting. I am installing debian testing in a VM (Gnome-boxes) now, and try to reproduce the bug.
It's correct that only the password is stored in the keychain along with the app name, and not the username. That's intended behaviour (and I think also a limitation of the secret service protocol). It's very curious that it's stored correctly, but can't be retrieved... BTW all the secret service stuff in kasts goes through the qtkeychain library, which is a dependency. It's really starting to look like an upstream issue in that library. Or at least the combination of qtkeychain and gnome-keyring (and potentially flatpak as well).
So, I was able to reproduce the behaviour in a fresh debian testing vm. Maybe thats the way, you can try to recreate it yourself?
I can confirm the same bug. Using KDE Neon and Kasts 22.02. I no longer can sync any podcast via gpodder, even introducing credentials. It used to work before last update.
> I can confirm the same bug. > Using KDE Neon and Kasts 22.02. > > I no longer can sync any podcast via gpodder, even introducing credentials. > It used to work before last update. This is also with the flatpak version? It seems like this issue is very much related: https://discourse.flathub.org/t/loading-of-passwords-via-libsecret-sometimes-not-working/2036 That could also explain why it stopped working, because libsecret was added (by another KDE maintainer) to the flatpak build about a month ago. I guess that before that point in time, passwords were just stored as plaintext within the flatpaks.
(In reply to bart from comment #11) > > I can confirm the same bug. > > Using KDE Neon and Kasts 22.02. > > > > I no longer can sync any podcast via gpodder, even introducing credentials. > > It used to work before last update. > > This is also with the flatpak version? Yes, I can confirm that I'm using the flatpak version and I am experiencing that error.
Created attachment 148031 [details] Screenshot: syncronisation is still disabled After updating Kasts to 22.02 via flatpak, the problem still persists: the syncronisation is still disabled.
(In reply to ccamara from comment #13) > Created attachment 148031 [details] > Screenshot: syncronisation is still disabled > > After updating Kasts to 22.02 via flatpak, the problem still persists: the > syncronisation is still disabled. I assume that you already tried again after removing the local settings in ~/.var/app/org.kde.kasts? Do you have a keychain program running? I tested this with keepassxc myself, and that works. I didn't try (yet) without keychain app or with e.g. kde wallet. I will try to do that next. Could you perhaps try the commands mentioned above to get some debug info printed to stdout related to the sync procedure?
Created attachment 148055 [details] publickey - ccamara@pm.me - 0xD439405D.asc Thank you, it works now! 1. I removed ~/.var/app/org.kde.kasts 2. Ran kasts 3. Sync with gpodder is working! Carlos Cámara-Menoyo https://carloscamara.es/en https://carloscamara.es ------- Original Message ------- El dijous, 7 de abril 2022 a les 21:08, <bugzilla_noreply@kde.org> va escriure: > https://bugs.kde.org/show_bug.cgi?id=451836 > > --- Comment #14 from bart@mogwai.be --- > (In reply to ccamara from comment #13) > > > Created attachment 148031 [details] > > Screenshot: syncronisation is still disabled > > > > After updating Kasts to 22.02 via flatpak, the problem still persists: the > > syncronisation is still disabled. > > > I assume that you already tried again after removing the local settings in > ~/.var/app/org.kde.kasts? > > Do you have a keychain program running? I tested this with keepassxc myself, > and that works. I didn't try (yet) without keychain app or with e.g. kde > wallet. I will try to do that next. > > Could you perhaps try the commands mentioned above to get some debug info > printed to stdout related to the sync procedure? > > -- > You are receiving this mail because: > You are on the CC list for the bug.
Created attachment 148056 [details] signature.asc
Hello again, I'm afraid that I was too hasty. After starting Kasts again, the sync stopped working. I'm not sure of having understood what you were mentioning about keychain and how to debug it further, but happy to do it.
(In reply to ccamara from comment #17) > I'm not sure of having understood what you were mentioning about keychain > and how to debug it further, but happy to do it. You can enable debug by starting kasts through the following command from the CLI: QT_LOGGING_RULES=org.kde.kasts.sync=true flatpak run org.kde.kasts This will start the flatpak version of kasts and print debug info related to the sync procedure to stdout. If you could paste the output of a sync that has succeeded (probably after deleting .var/app/org.kde.kasts and removing the entry from the keychain), and of a sync that has failed, that would hopefully help me find the root cause. PS It could be that you have to censor sensitive info before pasting it here.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Sorry it took me so long to answer. I have updated kasts to latest version and the problem persists. Please find the logs you requested (sorry, I didn't find a way to attach them here): 1. Working sync (I have redacted the urls): https://cloud.montera34.org/index.php/s/ayKQtjxZs398GKL 2. Failing sync: https://cloud.montera34.org/index.php/s/tHgY92ScCJ2awtr
Created attachment 148641 [details] Log of successful sync (first setup)
Created attachment 148642 [details] Log of failing sync
I think I've finally found the cause and a workaround. I've submitted a PR to flathub to implement the workaround. Once it's merged, the issue should be solved. :fingers_crossed: https://github.com/flathub/org.kde.kasts/pull/7
Created attachment 149338 [details] publickey - ccamara@pm.me - 0xD439405D.asc Great news, Bart! Thanks for dealing with it (and for developing kasts, which is great!) Carlos Cámara-Menoyo https://carloscamara.es/en https://carloscamara.es ------- Original Message ------- El dilluns, 30 de maig 2022 a les 18:57, <bugzilla_noreply@kde.org> va escriure: > https://bugs.kde.org/show_bug.cgi?id=451836 > > --- Comment #23 from bart@mogwai.be --- > I think I've finally found the cause and a workaround. > > I've submitted a PR to flathub to implement the workaround. Once it's merged, > the issue should be solved. :fingers_crossed: > https://github.com/flathub/org.kde.kasts/pull/7 > > -- > You are receiving this mail because: > You are on the CC list for the bug.
Created attachment 149339 [details] signature.asc
The issue should now be solved with the latest flathub package update. (At least, it solved it for me.) Can anyone please check and report back?
It is working now! Thanks Bart!
Thanks for the feedback!