GNU bug report logs - #62952
28.2.50; secrets.el unlocking items

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: "Philipp Uhl" <git <at> ph-uhl.com>
Subject: bug#62952: closed (Re: bug#62952: 28.2.50; secrets.el unlocking
 items)
Date: Mon, 08 May 2023 11:43:02 +0000

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

Your bug report

#62952: 28.2.50; secrets.el unlocking items

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 62952 <at> debbugs.gnu.org.

-- 
62952: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62952
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: "Philipp Uhl" <git <at> ph-uhl.com>
Cc: 62952-done <at> debbugs.gnu.org
Subject: Re: bug#62952: 28.2.50; secrets.el unlocking items
Date: Mon, 08 May 2023 13:42:44 +0200

Version: 30.1

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

Hi Philipp,

>> thanks for your response. Here is the secrets-lock-item function:
>
> Thanks. I'll check it next days.

I've played this morning with your changes. Everything looks fine (in my
environment), so I have pushed them to the Emacs master branch.

>>> Bonus points for respective tests in secrets-tests.el.
>>
>> I didn't find any secrets-tests.el in the Emacs repository. Also I am
>> not really familiar with writing test code in Elisp. But I did
>> manually test the code and it works.
>
> See test/lisp/net/secrets-tests.el in the git repository. Tests are
> performed using ERT, see (info "(ert) Top") for the manual.

I've tried to see how it works with this, but it looks like the
temporary "session" session of Gnome keyring, which I use, doesn't care
about locking/unlocking of single items. So likely it isn't worth to
extend secrets-tests.el.

I'm closing the bug.

>> Cheers, Philipp

Best regards, Michael.

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

From: "Philipp Uhl" <git <at> ph-uhl.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.2.50; secrets.el unlocking items
Date: Wed, 19 Apr 2023 14:23:17 +0200

The secrets.el implementation lacks support for unlocking specific
items. It only unlocks collections. This does not work well with certain
password managers (e.g. in my case KeepassXC, accessed through secret
service). When receiving a secret through

(secrets-get-secret  "MyPws" "MyEntry")

with the setting "Confirm when passwords are retrieved by clients"
turned on in KeepassXC, secrets-get-secret will just say IsLocked.

Instead, secrets-get-secret should try to unlock the entry itself before
retrieving.

Here is a proof of concept:

+  ;; New function, analogously to secrets-unlock-collection, that
+  ;; specifically unlocks the item
+  (defun secrets-unlock-item (collection item)
+    "Unlock item labeled ITEM from collection labeled COLLECTION.
+  If successful, return the object path of the item."
+    (let ((item-path (secrets-item-path collection item)))
+      (unless (secrets-empty-path item-path)
+        (secrets-prompt
+         (cadr
+          (dbus-call-method
+           :session secrets-service secrets-path secrets-interface-service
+           "Unlock" `(:array :object-path ,item-path)))))
+      item-path))

  (defun secrets-get-secret (collection item)
    "Return the secret of item labeled ITEM in COLLECTION.
  If there are several items labeled ITEM, it is undefined which
  one is returned.  If there is no such item, return nil.

  ITEM can also be an object path, which is used if contained in COLLECTION."
-    (let ((item-path (secrets-item-path collection item)))
+    (let ((item-path (secrets-unlock-item collection item)))
      (unless (secrets-empty-path item-path)
        (dbus-byte-array-to-string
         (nth 2
              (dbus-call-method
               :session secrets-service item-path secrets-interface-item
               "GetSecret" :object-path secrets-session-path))))))

To make this function a bit more similar to how it was before, one could
concider to explicitly wait for the IsLocked event before unlocking the
item. That way, if the password manager does not support unlocking of
items, this would not be braking.

Cheers,
-----------------------------
  Philipp Uhl
  git <at> ph-uhl.com

Previous Next

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