Fwd: card_status - change-request to update allways

Myonium myonium at gmail.com
Wed May 31 21:18:00 CEST 2017


Hi Werner

Any chance to get this change pushed into the next build?
----------------------snip-------------------------
diff --git a/g10/card-util.c b/g10/card-util.c
index 78cd52b..950b76f 100644
--- a/g10/card-util.c
+++ b/g10/card-util.c
@@ -376,7 +376,7 @@ current_card_status (ctrl_t ctrl, estream_t fp,
   if (serialno && serialnobuflen)
     *serialno = 0;
 
-  rc = agent_scd_learn (&info, 0);
+  rc = agent_scd_learn (&info, 1);
   if (rc)
     {
       if (opt.with_colons)
----------------------snip————————————

Best,
Ben

> Begin forwarded message:
> 
> From: Myonium <myonium at gmail.com>
> Subject: card_status - change-request to update allways
> Date: May 14, 2017 at 11:29:32 GMT+2
> To: gnupg-devel at gnupg.org
> 
> Hi all
> 
> I would love to change the „card_status“ behavior to always update the "key stubs“. (It's only a 1 character change ;-) 
> 
> Is there anything which would speak against making the following change:
> 
> diff --git a/g10/card-util.c b/g10/card-util.c
> index 78cd52b..950b76f 100644
> --- a/g10/card-util.c
> +++ b/g10/card-util.c
> @@ -376,7 +376,7 @@ current_card_status (ctrl_t ctrl, estream_t fp,
>  if (serialno && serialnobuflen)
>    *serialno = 0;
> 
> -  rc = agent_scd_learn (&info, 0);
> +  rc = agent_scd_learn (&info, 1);
> 
> With „force=true“ agent_scd_learn will always update the „key stub“. I.e. if a new card is attached containing the „private key“ of an already known keygrip it will update the stub so that the newly attached token can be used for crypto-operations.
> I cannot think of any scenario where somebody does not want such a behavior or where this could brake anything. In case the user would shuffle back the old token the system would be reverted back to the old key stub. 
> 
> Please advise. Many thanks,
> Ben

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20170531/6b52a677/attachment.html>


More information about the Gnupg-devel mailing list