Re: scdaemon lockup with Yubikey NEO

[the2nd]

On 2015-12-03 03:54, NIIBE Yutaka wrote:

On 12/02/2015 11:35 PM, the...@otpme.org wrote:
No problem. I'm glad to help out and probably get a fix for this 
annoying issue. :)


Thanks for your patience.


Anyway, when Scdaemon detects card/token removal, it could finish
existing connection(s).  I'll consider fixing this.


Sounds good. Should i open a bug report for this?


Not needed.  It's fixed in master.  I'm going to backport this to 2.0.

The commit is: f42c50dbf00c2e6298ca6830cbe6d36805fa54a3


Is there any workaround we can apply to fix this issue? Currently i
am using a self compiled ssh client binary of openssh 6.7p1 as
workaround.


Well, I found another bug with PC/SC.  Because of this bug, it is
sometimes (not always) possible for gpg not to raise the error of
"Conflicting usage".  So, it would be a workaround to disable internal
ccid driver of GnuPG and to use PC/SC.  (I don't recommend, though.)

Here is a backport patch which I'm considering to apply to 2.0.

Thank you again for your cooperation fixing this long standing bug.


Thank your for fixing it. :)

Currently i will use the udev rule workaround from Lance.

Is there any automatism that informs e.g. debian/ubuntu folks about such 
a backported fix?
Does it make sense to open a debian/ubuntu bug report for this with 
reference to this thread?




=
diff --git a/scd/apdu.c b/scd/apdu.c
index f9a1a2d..acca799 100644
--- a/scd/apdu.c
+++ b/scd/apdu.c
@@ -3136,7 +3136,13 @@ apdu_close_reader (int slot)
 return SW_HOST_NO_DRIVER;
   sw = apdu_disconnect (slot);
   if (sw)
-return sw;
+{
+  /*
+   * When the reader/token was removed it might come here.
+   * It should go through to call CLOSE_READER even if we got an 
error.

+   */
+  log_debug ("apdu_close_reader => 0x%x (apdu_disconnect)\n", sw);
+}
   if (reader_table[slot].close_reader)
 return reader_table[slot].close_reader (slot);
   return SW_HOST_NOT_SUPPORTED;
diff --git a/scd/app-common.h b/scd/app-common.h
index e48db3c..ac2c2e9 100644
--- a/scd/app-common.h
+++ b/scd/app-common.h
@@ -44,11 +44,6 @@ struct app_ctx_s {
  operations the particular function pointer is set to NULL */
   unsigned int ref_count;

-  /* Flag indicating that a reset has been done for that application
- and that this context is merely lingering and just should not be
- reused.  */
-  int no_reuse;
-
   /* Used reader slot. */
   int slot;

diff --git a/scd/app.c b/scd/app.c
index 742f937..380a347 100644
--- a/scd/app.c
+++ b/scd/app.c
@@ -190,9 +190,12 @@ application_notify_card_reset (int slot)
   /* FIXME: We are ignoring any error value here.  */
   lock_reader (slot, NULL);

-  /* Mark application as non-reusable.  */
+  /* Release the APP, as it's not reusable any more.  */
   if (lock_table[slot].app)
-lock_table[slot].app->no_reuse = 1;
+{
+  deallocate_app (lock_table[slot].app);
+  lock_table[slot].app = NULL;
+}

   /* Deallocate a saved application for that slot, so that we won't
  try to reuse it.  If there is no saved application, set a flag so
@@ -265,16 +268,6 @@ select_application (ctrl_t ctrl, int slot, const
char *name, app_t *r_app)
 return gpg_error (GPG_ERR_CONFLICT);
   }

-  /* Don't use a non-reusable marked application.  */
-  if (app && app->no_reuse)
-{
-  unlock_reader (slot);
-  log_info ("lingering application `%s' in use by reader %d"
-" - can't switch\n",
-app->apptype? app->apptype:"?", slot);
-  return gpg_error (GPG_ERR_CONFLICT);
-}
-
   /* If we don't have an app, check whether we have a saved
  application for that slot.  This is useful so that a card does
  not get reset even if only one session is using the card - this
@@ -506,15 +499,7 @@ release_application (app_t app)

   if (lock_table[slot].last_app)
 deallocate_app (lock_table[slot].last_app);
-  if (app->no_reuse)
-{
-  /* If we shall not re-use the application we can't save it for
- later use. */
-  deallocate_app (app);
-  lock_table[slot].last_app = NULL;
-}
-  else
-lock_table[slot].last_app = lock_table[slot].app;
+  lock_table[slot].last_app = lock_table[slot].app;
   lock_table[slot].app = NULL;
   unlock_reader (slot);
 }


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Why gpg 2.1.9 cannot export secret key without passphrase?

[Peter Lebbing]

On 03/12/15 05:25, Andrey Utkin wrote:
> Is the approach of using "s2kmode = 0" and "protection sha1" together
> correct? Shouldn't "protection none" be used?

Why is all this hackery necessary? Why don't you just install GnuPG 1.4
next to your 2.1, instead of compiling a special hacked 2.1?

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at 

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users