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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: André Colomb <src <at> andre.colomb.de>
Subject: bug#78490: closed (Re: bug#78490: Feature Request: secrets.el
 should handle org.freedesktop.Secret.Prompt for KeePassXC approval)
Date: Tue, 20 May 2025 07:47:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#78490: Feature Request: secrets.el should handle org.freedesktop.Secret.Prompt for KeePassXC approval

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 78490 <at> debbugs.gnu.org.

-- 
78490: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78490
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

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.

[Message part 3 (message/rfc822, inline)]

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é

Previous Next

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