https://bugs.kde.org/show_bug.cgi?id=522615
--- Comment #12 from Branislav Klocok <[email protected]> --- Created attachment 194986 --> https://bugs.kde.org/attachment.cgi?id=194986&action=edit Check whether a Secret Service provider registers the Prompt object it returns Following up on the open point from my correction: I have now checked the prompt path itself, and KeePassXC registers the object it hands back. Lock() on the collection returns /org/freedesktop/secrets/prompt/<id>, and introspecting that path on the same connection finds a real object carrying org.freedesktop.Secret.Prompt. Unlock() returned "/" here because the database was already unlocked, so the path I exercised was the one from Lock(). That is the opposite of what comment #8 reports for gnome-keyring, where the returned path has nothing behind it, and it supports reading that as a bug on their side rather than something inherent to being a non-KDE Secret Service provider. One limitation worth stating: I did not carry the prompt through to completion, so I have not observed the signature of KeePassXC's Completed signal - which is the part that actually misbehaves in this bug. Only the registration of the prompt object was verified. I am attaching the test script in case it is useful to anyone checking their own provider. It has to hold a single D-Bus connection throughout, because busctl and dbus-send open a fresh connection per call while these objects are bound to the client connection - which is exactly what led me to the wrong conclusion I retracted above. -- You are receiving this mail because: You are watching all bug changes.
