--- Begin Message ---
|
Subject: |
28.2.50; secrets.el unlocking items |
|
Date: |
Wed, 19 Apr 2023 14:23:17 +0200 |
|
User-agent: |
Cyrus-JMAP/3.9.0-alpha0-372-g43825cb665-fm-20230411.003-g43825cb6 |
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@ph-uhl.com
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#62952: 28.2.50; secrets.el unlocking items |
|
Date: |
Mon, 08 May 2023 13:42:44 +0200 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Version: 30.1
Michael Albinus <michael.albinus@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.
--- End Message ---