https://bugs.kde.org/show_bug.cgi?id=522615
--- Comment #13 from Branislav Klocok <[email protected]> --- I went through the remaining paths systematically, and the result argues against the objection I raised earlier, so it seems only fair to say so plainly. In libsecret 0.21.7 the prompt is asked for a specific type in three places only: secret-paths.c:1080 wants "ao" for lock and unlock, while :1684 and :1948 want "o" for CreateCollection and CreateItem respectively. The "expected o, received ao" message can therefore only come from the latter two - Unlock is ruled out by construction, and the spec agrees, since Unlock and Lock both take and return arrays of object paths. Measuring each of those against ksecretd over org.kde.secretservicecompat, on kwalletd6 6.28.0: Lock / Unlock prompt completes with "ao" - matches what libsecret asks for CreateItem unlocked collection -> prompt "/", no prompt at all locked collection -> org.freedesktop.Secret.Error.IsLocked CreateCollection prompt /org/freedesktop/secrets/prompt/p2 Completed carries "o" - matches So ksecretd does not produce the mismatch on any path that libsecret types. That undercuts what I wrote in my earlier comment, where I argued the loop on my machine must have arisen on the internal kwalletd6 to ksecretd path with no foreign provider involved. If ksecretd cannot generate that signature at all, then something else did, and the name-conflict finding in comment #8 carries more weight than I gave it. Three caveats, so this is not read as more than it is. I measured 6.28.0-1.2 while the episode I reported happened on 6.28.0-1.1. I only exercised the three operations libsecret types, not every path through the service. And my recollection about the looping traffic going to the internal name cannot be re-checked, since that capture is gone - as I noted when I first mentioned it. Two small things that may be useful anyway. ksecretd numbers its prompts p1, p2 and registers them, so the empty prompt node reported for gnome-keyring in comment #8 does look like the odd one out. And CreateItem against a locked collection failing with IsLocked rather than handing back an unlock prompt means that particular combination cannot be where the mismatch enters, which I had assumed it might be. -- You are receiving this mail because: You are watching all bug changes.
