https://bugs.kde.org/show_bug.cgi?id=522615
--- Comment #11 from Branislav Klocok <[email protected]> --- Correcting myself on the last part of my previous comment: the claim about KeePassXC does not hold, and I would rather retract it here than have anyone build on it. I concluded there that KeePassXC never exposes /org/freedesktop/secrets/prompt or a session node, and inferred the same failure mode described for gnome-keyring in comment #8. The introspection output I quoted is real, but my reading of it was wrong, because the measurement was: busctl opens a fresh D-Bus connection per invocation, and a Secret Service session is bound to the client connection, so it was already gone by the time I looked for it. Those nodes are created on demand rather than kept around, so their absence on an idle system means nothing. Repeating the test inside a single connection with dbus-python gives the opposite result: OpenSession returned /org/freedesktop/secrets/session/0b937bc4... /org/freedesktop/secrets/session -> exists the returned session path -> exists, org.freedesktop.Secret.Session Session.Close() -> succeeds So KeePassXC 2.7.12 registers the object properly, and its binary implements the Prompt, Session and Collection interfaces. Please disregard my "same gap as gnome-keyring, only more pronounced" sentence and the prediction that followed it - neither is supported. To be precise about what remains open: I did not test the prompt path itself, which would need the database locked so a client actually receives a prompt object path back, and I have not done that. So this is not evidence that KeePassXC handles prompts correctly either - it simply is not evidence of the opposite, which is what I wrongly suggested. The rest of my previous comment stands: no gnome-keyring on this system, no contest over org.freedesktop.secrets at the time of the episode, and kwalletd6 observed talking to ksecretd over the internal name. -- You are receiving this mail because: You are watching all bug changes.
