Subject: bug#78490: closed (Re: bug#78490: Feature Request: secrets.el should handle org.freedesktop.Secret.Prompt for KeePassXC approval)

From: [email-masked] (GNU bug Tracking System)
Date: Tue, 20 May 2025 07:47:02 +0000

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 [email-masked].

-- 
78490: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78490
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#78490: Feature Request: secrets.el should handle org.freedesktop.Secret.Prompt for KeePassXC approval
From: Michael Albinus <[email-masked]>
To: André Colomb <[email-masked]>
Cc: [email-masked]
Date: Tue, 20 May 2025 09:46:07 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

Version: 30.1

André Colomb <[email-masked]> 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.

Subject: Feature Request: secrets.el should handle org.freedesktop.Secret.Prompt for KeePassXC approval
From: André Colomb <[email-masked]>
To: [email-masked]
Date: Sun, 18 May 2025 23:09:03 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

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é