help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Secret Service integration and KeePassXC issues


From: Michael Albinus
Subject: Re: Emacs Secret Service integration and KeePassXC issues
Date: Mon, 27 Dec 2021 19:55:09 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Liam Hupfer <liam@hpfr.net> writes:

Hi Liam,

>> 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.

I'm on Fedora 35 and KeePassXC 2.6.6-3.fc35 now.

> 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:”.

Yep. This works for me, and I see the collection "Passwords", exposed
from KeePassXC. This maps to my database file name Passwords.kdbx.

> 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.

Yes.

> 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?

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.

> 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.²

As the comment above the `secrets-struct-secret-content-type' definition
says, it was just a backward compatibility hack. 10 years have passed,
so we don't need it anymore. I've removed that hack.

> 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 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
> └────

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!

> —Liam

Best regards, Michael.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]