From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Philipp Uhl" Newsgroups: gmane.emacs.bugs Subject: bug#62952: 28.2.50; secrets.el unlocking items Date: Tue, 02 May 2023 12:05:03 +0200 Message-ID: <0a74e18e-d972-43b6-b661-cee36b08ddb4@app.fastmail.com> References: <87fs8u6bm1.fsf@gmx.de> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=93c579becba24d34b286ed6a1eb3d3d6 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35174"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Cyrus-JMAP/3.9.0-alpha0-374-g72c94f7a42-fm-20230417.001-g72c94f7a Cc: 62952@debbugs.gnu.org To: "Michael Albinus" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 02 12:06:30 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ptmtu-0008oy-BH for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 May 2023 12:06:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ptmtZ-0000QK-LH; Tue, 02 May 2023 06:06:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ptmtX-0000QC-HS for bug-gnu-emacs@gnu.org; Tue, 02 May 2023 06:06:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ptmtX-0004Ze-96 for bug-gnu-emacs@gnu.org; Tue, 02 May 2023 06:06:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ptmtV-0003bY-TP for bug-gnu-emacs@gnu.org; Tue, 02 May 2023 06:06:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Philipp Uhl" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 May 2023 10:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62952 X-GNU-PR-Package: emacs Original-Received: via spool by 62952-submit@debbugs.gnu.org id=B62952.168302193713823 (code B ref 62952); Tue, 02 May 2023 10:06:01 +0000 Original-Received: (at 62952) by debbugs.gnu.org; 2 May 2023 10:05:37 +0000 Original-Received: from localhost ([127.0.0.1]:41784 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ptmt6-0003as-Qu for submit@debbugs.gnu.org; Tue, 02 May 2023 06:05:37 -0400 Original-Received: from wout5-smtp.messagingengine.com ([64.147.123.21]:37431) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ptmt1-0003aX-91 for 62952@debbugs.gnu.org; Tue, 02 May 2023 06:05:35 -0400 Original-Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 7028632009E6; Tue, 2 May 2023 06:05:25 -0400 (EDT) Original-Received: from imap48 ([10.202.2.98]) by compute3.internal (MEProxy); Tue, 02 May 2023 06:05:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ph-uhl.com; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1683021925; x=1683108325; bh=NI u7BqfTJGWjEFNzxOvKFCGDQH2RKo7VFuGmbewpscg=; b=iRKvUuo7QZ6MwzwG88 yUpwddkSTHHgHr8EzQvSXciAjv5iP6474heV8aTCtIvlr4wg+7AirQkFZYlypaSZ l7X2MJnSLX0ZByQ4fNxdfQifZkc5Nz8MlFF4pYuVGHLKrJuzvvqciHO0oRHsoOO2 oWZyMx2Gh5+9JEoIlxxAduD8OVk8dwhG6nfMGWbgAYntCbDYCK82YILEfG47d4mF LiQTnDggns10CZH1cpe0UwOTCBwI+ZF7SxOTPVcBfpYJ/OpZLFu8Wg69iiK44BpK YEgAI8AsA6JAFlbS+aiTk6pOaM3En93+q1uBPWpcKflFm0l4vkIsdJtimk84IdJb dl9Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1683021925; x=1683108325; bh=NIu7BqfTJGWjE FNzxOvKFCGDQH2RKo7VFuGmbewpscg=; b=Ntc/9hNjU139cPnRZOU0Oo/tf5zk3 OoeCNkI9goga8FuiBUH7rPboHz1lKTR5oDgcHuSmp95T6Pxf5nlYYDge1DN0PHfH 0eACweLogYoJ3TlKKemwaUJS+pd7OU+9XJrwJR2QpN7sSCEs0yeD0GjeJ9tAb14j kNeDq3GDBlxdoORGCfrBj9j+8/vskipRycR0IXSJbCer9M1N6zjsxl2toWScr4mo kzBn3HYse5/nEIv8akd1EZIyRIETiiZduo0lQ0QR1k8IzZrtjL6/C9wMRBHAh+R9 9vh2UdQG+eN3MOklpDrizfp9rtbyQys/8bCVResG6j2f/rZLyjXhFiuvA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedviedgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsegrtderreerredtnecuhfhrohhmpedfrfhh ihhlihhpphcufghhlhdfuceoghhithesphhhqdhuhhhlrdgtohhmqeenucggtffrrghtth gvrhhnpedvvddtteekvdejleekvdeutdduteehfffgleetffdvgeelfeejtdduvdettdev tdenucffohhmrghinhepghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehgihhtsehphhdquhhhlhdrtghomh X-ME-Proxy: Feedback-ID: i17694467:Fastmail Original-Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6DFD731A0064; Tue, 2 May 2023 06:05:24 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <87fs8u6bm1.fsf@gmx.de> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:260908 Archived-At: --93c579becba24d34b286ed6a1eb3d3d6 Content-Type: text/plain Hi Michael, thanks for your response. Here is the secrets-lock-item function: (defun secrets-lock-item (collection item) "Lock collection item labeled ITEM in COLLECTION. If successful, return the object path of the item. Does not lock the collection." (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 "Lock" `(:array :object-path ,item-path))))) item-path)) > 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. > Well, I don't know how relevant it is to wait for the IsLocked > event. If you have use cases where it is needed, we shall do. I don't. For my purposes the code as shown before suffices. > All these changes exceed the limit for tiny changes in Emacs, which > could be submitted w/o legal work. Would you like to sign FSF copyright > papers in order to contribute to Emacs? See > > which explains the reasons. Yes. Would digitally suffice? What exactly do I have to sign? Cheers, Philipp ----------------------------- Philipp Uhl git@ph-uhl.com Am Do, 20. Apr 2023, um 13:23, schrieb Michael Albinus: > "Philipp Uhl" writes: > > Hi Philipp, > >> 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. > > Thanks for the report. > >> 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. > > LGTM. Well, I don't know how relevant it is to wait for the IsLocked > event. If you have use cases where it is needed, we shall do. > > When we add secrets-unlock-item, we should also add secrets-lock-item as > counterpart. Like we have done it with secrets-(un)?lock-collection. > Would you like to add this function? Bonus points for respective tests > in secrets-tests.el. > > All these changes exceed the limit for tiny changes in Emacs, which > could be submitted w/o legal work. Would you like to sign FSF copyright > papers in order to contribute to Emacs? See > > which explains the reasons. > >> Cheers, >> Philipp Uhl > > Best regards, Michael. --93c579becba24d34b286ed6a1eb3d3d6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Michael= ,

thanks for your response. Here is the sec= rets-lock-item function:

(defun = secrets-lock-item (collection item)
    "Lock collection item labeled ITEM in C= OLLECTION.
If successf= ul, return the object path of the item. Does not lock
the collection."
    (let ((item-path (secrets-it= em-path collection item)))
      (unless (secrets-empty-path item-pat= h)
   &= nbsp;    (secrets-prompt
         (cadr=
   &nb= sp;      (dbus-call-method
       =     :session secrets-service secrets-path secrets-interfa= ce-service
  = ;         "Lock" `(:array :objec= t-path ,item-path)))))
      item-path))

> Bonus points for respective tests
> in sec= rets-tests.el.

I didn't find any secrets-te= sts.el in the Emacs repository. Also I am not really familiar with writi= ng test code in Elisp. But I did manually test the code and it works.

> Well, I don't know how relevant it is to= wait for the IsLocked
> event. If you have use cases w= here it is needed, we shall do.

I don't. Fo= r my purposes the code as shown before suffices.

> All these changes exceed the limit for tiny changes in Emacs,= which
> could be submitted w/o legal work. Would you l= ike to sign FSF copyright
> papers in order to contribu= te to Emacs? See
  Philipp Uhl

Am Do, 20. Apr 2023, um 13:23, schrieb Mich= ael Albinus:
> "Philipp Uhl" <git@ph-uhl.com> writes:
>
<= div>> Hi Philipp,
>
>> The secre= ts.el implementation lacks support for unlocking specific
= >> items. It only unlocks collections. This does not work well wit= h certain
>> password managers (e.g. in my case Keep= assXC, accessed through secret
>> service). When rec= eiving a secret through
>>
>> (s= ecrets-get-secret  "MyPws" "MyEntry")
>>
>> with the setting "Confirm when passwords are retrieved = by clients"
>> turned on in KeepassXC, secrets-get-s= ecret will just say IsLocked.
>
> Than= ks for the report.
>
>> Instead, se= crets-get-secret should try to unlock the entry itself before
<= div>>> retrieving.
>>
>> H= ere 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 c= ollection labeled COLLECTION.
>> +  If successf= ul, return the object path of the item."
>> + &= nbsp;  (let ((item-path (secrets-item-path collection item)))
>> +      (unless (secrets-empty= -path item-path)
>> +     &= nbsp;  (secrets-prompt
>> +   &n= bsp;     (cadr
>> +  &= nbsp;       (dbus-call-method
>> +          = :session secrets-service secrets-path secrets-interface-service
>> +         &= nbsp; "Unlock" `(:array :object-path ,item-path)))))
>&= gt; +      item-path))
>>
>>   (defun secrets-get-secret (collection = item)
>>     "Return the secret = of item labeled ITEM in COLLECTION.
>>   I= f there are several items labeled ITEM, it is undefined which
<= div>>>   one is returned.  If there is no such item= , return nil.
>>
>>   = ITEM can also be an object path, which is used if contained in COLLECTIO= N."
>> -    (let ((item-path (secrets= -item-path collection item)))
>> +   = (let ((item-path (secrets-unlock-item collection item)))
= >>       (unless (secrets-empty-path= item-path)
>>      &n= bsp;  (dbus-byte-array-to-string
>>  =         (nth 2
>>=             =    (dbus-call-method
>>   &= nbsp;            = :session secrets-service item-path secrets-interface-item
= >>          &nbs= p;     "GetSecret" :object-path secrets-session-path= ))))))
>>
>> To make this functi= on 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 b= e braking.
>
> LGTM. Well, I don't kno= w how relevant it is to wait for the IsLocked
> event. = If you have use cases where it is needed, we shall do.
>= ;
> When we add secrets-unlock-item, we should also add= secrets-lock-item as
> counterpart. Like we have done = it with secrets-(un)?lock-collection.
> Would you like = to add this function? Bonus points for respective tests
&g= t; in secrets-tests.el.
>
> All these = changes exceed the limit for tiny changes in Emacs, which
= > could be submitted w/o legal work. Would you like to sign FSF copyr= ight
> papers in order to contribute to Emacs? See
<= /div>
&= gt; which explains the reasons.
>
>>= ; Cheers,
>>   Philipp Uhl
&= gt;
> Best regards, Michael.
--93c579becba24d34b286ed6a1eb3d3d6--