Re: Emacs Secret Service integration and KeePassXC issues

[Liam Hupfer]

Hi Michael,

Glad to see you were able to reproduce the issues!

Michael Albinus <michael.albinus@gmx.de> writes:

> The ephemeral “session” collection is created by the Secret Service
> provider (GNOME keyring daemon in my tests). KeePassXC doesn’t seem to
> create it. I’ve scanned the docs whether this temporary collection is
> requested (as I assume), but I couldn’t find it. So maybe we shouldn’t
> trust its existence. I’ve added a respective note to the auth info
> pages, where the Secret Service API is described.

Makes sense, thanks. This is the conclusion I came to as well (that the
session collection is not part of the spec, but rather a
GNOME Keyring-specific feature).

>> Soon, I noticed another
>> thing: in KeePassXC’s app-wide secret service settings, there is an
>> “Authorization” tab that lists currently connected applications. For
>> some reason, Emacs was listed dozens of times when I opened this. I
>> watched the scroll-bar for the pane and it did shrink and grow when I
>> closed and reopened a session from Emacs, and I noticed that repeatedly
>> opening does in fact return the same session path, so I wasn’t sure how
>> that happened. But then I figured out how to try running the code in the
>> aforementioned `defconst’, and I realized that it indeed opens a session
>> and attempts to create a dummy item to dynamically get the content-type.
>> However, because the “session” collection it uses doesn’t exist, it ends
>> up simply opening a session and then failing to create the item with
>> `dbus-call-method: D-Bus error: “No such object path
>> ‘/org/freedesktop/secrets/collection/session’”’. The removal call fails
>> because the result from the creation is nil. All of this is wrapped in
>> `ignore-errors’, so it doesn’t get printed. But I think the result is
>> this somehow gets called repeatedly which creates the many open
>> sessions? Because once I got this far I just tried evaluating the
>> `defconst’ repeatedly and it indeed opened many sessions, and the result
>> remained nil.
>
> All of this shouldn’t happen anymore with my recent change.

I tried your change by downloading the updated `secrets.el' and
executing `(load "/path/to/new/secrets.el")' followed by `(require
'secrets)' in my config. This seems to use the new version, because
creating items works and `secrets-struct-secret-content-type' is set.
However, over a few hours running Emacs and KeePassXC with my
`auth-sources' set appropriately, it appears that many extra sessions
are still opened when I view the aforementioned `Tools > Settings >
Secret Service Integration > Authorization' in KeePassXC. I believe it
is specific to Emacs, because the Nextcloud client and the GNOME Online
Accounts daemon also show up and do not seem to ever create extra
sessions. I’m not really sure how to debug this. I think this would mean
something is calling `secrets-open-session' somewhere, but it only seems
to be called when `secrets.el' is loaded, so I have no idea how it’s
happening. If how I load your updated version has something to do with
it, is there a better way for me to override the `defconst' and `defun'
with your changes than what I’ve described?

> After my change, pushed to Emacs master, your example with
> `secrets-create-item’ in Emacs works as expected. And the item is
> visible in KeePassXC. Wow!

Indeed, excellent! Despite the remaining issue I have with extraneous
sessions, it seems to reliably work regardless of how many of those are
open. Deleting items also works as expected. This has significantly
improved dealing with secrets in Emacs for me. Thanks for taking the
time to go through my report!

—Liam