GNU bug report logs - #78490
Feature Request: secrets.el should handle org.freedesktop.Secret.Prompt for KeePassXC approval

Previous Next

To reply to this bug, email your comments to 78490 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: André Colomb <src <at> andre.colomb.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Feature Request: secrets.el should handle
 org.freedesktop.Secret.Prompt for KeePassXC approval
Date: Sun, 18 May 2025 23:09:03 +0200

Hi Emacs developers,

I hope this is the right channel to pose such a feature request, 
especially concerning the secrets.el component.  If not, please direct 
me to the right venue.

I've been trying to switch my Secret-Service integration within Emacs 
(used by magit via ghub via auth-source via secrets.el) from accessing 
the GNOME Keying Daemon to KeePassXC as the backend.

It works in principle, but as soon as the option in KeePassXC "Confirm 
when passwords are retrieved by clients" is activated, the credential 
lookup fails silently.  Normally, a graphical prompt should pop up from 
KeePassXC to either allow or deny the request.  That part works 
perfectly using other methods such as secret-tool from the command line.

Some further investigation and a helpful ChatGPT interrogation pointed 
toward the culprit here: Emacs' secrets.el simply doesn't implement the 
unlocking workflow of that API.  AFAIUI, the DBus call returns an error 
code org.freedesktop.Secret.Error.IsLocked, and a Prompt object whose 
"Prompt" method needs to be invoked via DBus to show the confirmation 
popup.  The same behavior can be reproduced using the "M-x 
secrets-show-secrets" command.

Is there a chance this could be properly added to secrets.el?  I 
wouldn't even mind if the whole lisp execution got blocked while waiting 
for a response to the popup.

Unfortunately, I have no experience at all in Emacs lisp development, so 
I doubt I'd be able to provide a patch myself.  Would be happy to test a 
patch though, as long as it only needs a new version of secrets.el, not 
a whole rebuild of Emacs.

I am running: GNU Emacs 29.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.24.41, cairo version 1.18.0) of 2024-04-01, modified by Debian; 
installed from the Ubuntu 24.04 packages.

Thanks in advance and kind regards
André

Message #8 received at 78490 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: André Colomb <src <at> andre.colomb.de>
Cc: 78490 <at> debbugs.gnu.org
Subject: Re: bug#78490: Feature Request: secrets.el should handle
 org.freedesktop.Secret.Prompt for KeePassXC approval
Date: Mon, 19 May 2025 09:03:31 +0200

André Colomb <src <at> andre.colomb.de> writes:

> Hi Emacs developers,

Hi André

> Some further investigation and a helpful ChatGPT interrogation pointed
> toward the culprit here: Emacs' secrets.el simply doesn't implement
> the unlocking workflow of that API.  AFAIUI, the DBus call returns an
> error code org.freedesktop.Secret.Error.IsLocked, and a Prompt object
> whose "Prompt" method needs to be invoked via DBus to show the
> confirmation popup.  The same behavior can be reproduced using the
> "M-x secrets-show-secrets" command.

Thanks for the report! Yes, an Emacs bug report is the right place.

> Is there a chance this could be properly added to secrets.el?  I
> wouldn't even mind if the whole lisp execution got blocked while
> waiting for a response to the popup.

I will investigate in a couple of days, when there is some spare time.

> I am running: GNU Emacs 29.3 (build 1, x86_64-pc-linux-gnu, GTK+
> Version 3.24.41, cairo version 1.18.0) of 2024-04-01, modified by
> Debian; installed from the Ubuntu 24.04 packages.

There is bug#62952. It sounds very similar to your problem, and it is
fixed in Emacs 30.1. Do you have a chance to check, whether Emacs 30.1
solves your problem?

> Thanks in advance and kind regards
> André

Best regards, Michael.

Message #11 received at 78490 <at> debbugs.gnu.org (full text, mbox):

From: André Colomb <src <at> andre.colomb.de>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 78490 <at> debbugs.gnu.org
Subject: Re: bug#78490: Feature Request: secrets.el should handle
 org.freedesktop.Secret.Prompt for KeePassXC approval
Date: Mon, 19 May 2025 22:36:35 +0200

Hi Michael,

On 19.05.25 09:03, Michael Albinus wrote:
>> I am running: GNU Emacs 29.3 (build 1, x86_64-pc-linux-gnu, GTK+
>> Version 3.24.41, cairo version 1.18.0) of 2024-04-01, modified by
>> Debian; installed from the Ubuntu 24.04 packages.
> 
> There is bug#62952. It sounds very similar to your problem, and it is
> fixed in Emacs 30.1. Do you have a chance to check, whether Emacs 30.1
> solves your problem?

Sorry I did not find that previous bug report before.  It sounds like 
exactly the same problem.

I've tested with the Flatpak version 30.1 and gave it D-Bus access. 
Looks like the feature is already implemented in that newer version. 
KeePassXC did ask me for confirmation when accessing the secret.  It was 
a little weird because KeePassXC warned that it cannot find / identify 
the emacs executable, probably because of the flatpak sandboxing.  But 
at least there was an unlock prompt for the individual entry.

I guess it's fine then and I just need to wait for an updated emacs 
package for my Ubuntu installation.  Going with the flatpak version is 
not really an option for me.  But I haven't found a trustworthy and 
recent Ubuntu PPA with builds of 30.1 which I could use.  Might try 
installing the packages from Ubuntu Plucky Puffin (25.04), but I fear 
it's a high risk for my day-to-day editor / IDE.  So might just be 
patient as well and look forward to seeing this bug fixed when I do 
switch to a newer official Ubuntu release.

Thank you very much for your time and investigation.

Kind regards
André

Message #16 received at 78490-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: André Colomb <src <at> andre.colomb.de>
Cc: 78490-done <at> debbugs.gnu.org
Subject: Re: bug#78490: Feature Request: secrets.el should handle
 org.freedesktop.Secret.Prompt for KeePassXC approval
Date: Tue, 20 May 2025 09:46:07 +0200

Version: 30.1

André Colomb <src <at> andre.colomb.de> writes:

> Hi Michael,

Hi André,

> Sorry I did not find that previous bug report before.  It sounds like
> exactly the same problem.
>
> I've tested with the Flatpak version 30.1 and gave it D-Bus
> access. Looks like the feature is already implemented in that newer
> version. KeePassXC did ask me for confirmation when accessing the
> secret.  It was a little weird because KeePassXC warned that it cannot
> find / identify the emacs executable, probably because of the flatpak
> sandboxing.  But at least there was an unlock prompt for the
> individual entry.

Thanks for the feedback. I'm closing this bug, therefore.

> I guess it's fine then and I just need to wait for an updated emacs
> package for my Ubuntu installation.  Going with the flatpak version is
> not really an option for me.  But I haven't found a trustworthy and
> recent Ubuntu PPA with builds of 30.1 which I could use.  Might try
> installing the packages from Ubuntu Plucky Puffin (25.04), but I fear
> it's a high risk for my day-to-day editor / IDE.  So might just be
> patient as well and look forward to seeing this bug fixed when I do
> switch to a newer official Ubuntu release.

Well, you could extract secrets.el from Emacs 30.1 flatpak, and use it
with your Emacs 29. I didn't test, but the diff between the two versions
is rather small, I expect that it works.

> Thank you very much for your time and investigation.
>
> Kind regards
> André

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.