Re: Emacs Secret Service integration and KeePassXC issues

[Liam Hupfer]

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

> Hi Liam,

Hello again Michael. Thank you very much for the prompt response; I must
apologize for the gargantuan delay. Hey, I got back to you before your
response’s first birthday, right?

Part of the reason for the wait was that I figured I’d have to create a
Fedora VM and reproduction instructions with vanilla Emacs (I use the
Doom distribution and have pretty much no idea how to navigate or
configure vanilla 😅) and KeePassXC.

I didn’t do that, but I did come back to this and actually read the
secrets.el and auth-sources.el source code as well as some of the
KeePassXC implementation comments.

> Well, I’ve tried it. I’m running Fedora 33, and I’ve installed KeePassXC
> 2.6.3 via dnf.
>
> Stopped the GNOME keyring daemon, started keepassxc. I’ve created a new
> database, and two entries. Then I’ve enabled the Secret Service
> Integration via Setings. And now I’m lost. I don’t see any collection,
> and so I don’t know how to access.

If you’re on Fedora 34, you should be able to get KeePassXC 2.6.6 now¹;
it’s what I’m using, so that’s probably our best bet for
reproducibility.

Firstly, I suspect the reason you don’t see a collection is because even
after enabling the Secret Service Integration in KeePassXC’s app-wide
settings, KeePassXC exposes no entries from the database to the service
by default. To expose some, you need to select `Database > Database
Settings > Secret Service Integration > Expose entries under this
group:', and then choose a group (likely only Root will exist for your
test database) to expose. Then in the app-wide secret service settings,
the group should show up under “Exposed database groups:”.

You might have to restart KeePassXC or Emacs at this point; I’m not 100%
sure how those interactions work, so I did it just to be safe. At this
point, invoking `(secrets-list-collections)' should return a list with
one string corresponding to your database name, and `M-x
secrets-show-secrets' should let you browse the entries and attributes.

Now for the main issue. Assuming my instructions are still working, you
have probably noticed that the “session” collection does not seem to be
present. I browsed the Emacs source and can’t find any
`CreateCollection' or `secrets-create-collection' references, but the
docs say the collection is “created automatically when Emacs uses the
Secret Service interface”. This does not seem to be happening. In any
case, KeePassXC maps collections to database files, so evaluating
`(secrets-create-collection)' results in KeePassXC prompting me for a
new database name and password and a place to save it. Since this
collection is intended to be ephemeral, it’s probably not great to go
through the whole database creation process every time you launch Emacs.
But that’s a KeePassXC issue to handle, and I’m fine with doing it for
the time being if it gets this working. Unfortunately, the session
collection does not seem to be created at all at the moment, despite
`(secrets-create-collection)' working fine. That part seems to be an
Emacs thing?

My only guess was that the `secrets-struct-secret-content-type'
`defconst' which creates a dummy item in the “session” collection
somehow creates the collection in the process.² 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.

I supposed this is why `(secrets-create-item)' failed, but I noticed you
said the nil content type was backwards compatible so I gave it a try
and it gives /another/ error. I ran `(secrets-create-item "default"
"test emacs item" "test pw")' ³, and received:
┌────
│ No such method 'CreateItem' in interface 'org.freedesktop.Secret.Collection' 
at object path '/org/freedesktop/secrets/collection/main' (signature 
'a{sv}(oayay)b')
└────

Interestingly, KeePassXC’s logs said:
┌────
│ Message signature does not match, expected "a{sv}(oayays)b" 3 got 
"a{sv}(oayay)b" 3
└────

In summary:
• Where is the “session” collection actually initialized?
• Do you have any idea what the issue is with the message signature
  issue for `CreateItem'?
• Can we get the “session” collection initialized (even if it involves
  waiting for me to interact with KeePassXC’s database creation UI)
  before the `defconst' evaluation in order to correctly grab the
  content-type?

Sorry this got long; writing about GUI navigation over email gets a
little verbose, I guess, and then I ended up doing a bunch more
debugging as I tried to write the email which resulted in me effectively
documenting my debugging process. I realize I’m asking a little much to
have the secrets.el maintainer debug interactions with an application he
doesn’t use, so let me be clear I’m not obliging you to try all this. If
you have suggestions or hunches I’m happy to try them myself. Also happy
to explore other debugging methods if you prefer!

Thanks for reading if you made it this far 😄.

—Liam

¹ <https://src.fedoraproject.org/rpms/keepassxc>
² 
<https://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/net/secrets.el?id=194556425f140b8599467959b73d5954a59128e3#n317>
³ In KeePassXC’s implementation, the default alias refers to the currently 
focused open database, which is probably the only one you have.