https://bugs.kde.org/show_bug.cgi?id=522615
--- Comment #15 from Branislav Klocok <[email protected]> --- Confirming comment #14 from the other openSUSE side, and correcting something of my own while I am at it. The negative result Brian reports is the part I can back up. My episode in July was the same shape as his second one - the loop driven by kded6 writePassword against the PSK of the connection I had just joined, killing kwalletd6 not helping, and systemctl --user restart plasma-kded6.service stopping it instantly. Checking my notes from that night, I never recorded a single GTask "finalized without ever returning" or "unexpected result type" line from my own journal either. I should be straightforward about what that means for my earlier comment: when I wrote that my observations matched that backtrace and the ao versus o signature mismatch, I was taking the explanation from this report and applying it to my case, not reporting something I had measured. The journal from that night has since rotated, so I cannot go back and check. Two openSUSE machines showing this loop with none of those messages present seems worth stating plainly. There is one detail from my setup that neither of the other reports has, and it may help separate the two failure modes. On my machine org.freedesktop.secrets is owned by neither ksecretd nor gnome-keyring, but by KeePassXC, because kwalletrc here carries apiEnabled=false under [org.freedesktop.secrets] and ksecretd therefore never claims the public name. Brian has ksecretd owning it; the original reporters had gnome-keyring. All three configurations produce the same kded6 retry loop, which suggests the loop does not care who holds that name at all. I also checked ksecretd against the three operations libsecret types a prompt for, as described in my previous comment, and it answers correctly in every one of them. Taken together with the absent log messages, my reading is that this report may be covering two different problems: the Secret Service prompt leak in the original description, which produces those GTask messages and appears to need a provider that mishandles prompts, and the kded6 writePassword retry loop, which produces no such messages and happens with a perfectly well-behaved provider. If that is right, then my objection in an earlier comment about the loop not requiring a broken provider was closer to the mark than my own follow-up gave it credit for - but it applies to the retry loop, not to the leak this bug was opened about. One small thing to add to Brian's observation about two passwords alternating. In my case the password was asked for twice during the join - an inline prompt in the panel and then a separate dialog - and the connection succeeded. Under his reading that would mean two save requests were in flight from a single join flow, which fits, though I have no capture left to confirm it. -- You are receiving this mail because: You are watching all bug changes.
