Andreas Jellinghaus wrote:
Am Sonntag, 22. April 2007 11:38 schrieb Nils Larsch:
does setting "lock_login = true" or "cache_pins = true" in the opensc
config help ?

cache_pins solves the problem. enable that by default?

or include a separate copy of the opensc.conf in the tests/regression
directory and use it in the test scripts (by setting the OPENSC_CONF
env. variable). On the other hand has the options caused quite a lot
of problems ...


if we change code/config before release anyway, what should
we do with the max_send_size issue / related code?

currently I edit opensc.conf to set max_send_size to 255 for cryptoflex.
haven't tested if that breaks other cards. what would be a code equivalent?

currently I prefer something like this:

Index: src/libopensc/ctx.c
===================================================================
--- src/libopensc/ctx.c (Revision 3148)
+++ src/libopensc/ctx.c (Arbeitskopie)
@@ -263,7 +264,7 @@
                        break;
        }

-       driver->max_send_size = SC_APDU_CHOP_SIZE;
+       driver->max_send_size = SC_APDU_CHOP_SIZE-1;
        driver->max_recv_size = SC_APDU_CHOP_SIZE;
        if (conf_block != NULL) {
                driver->max_send_size = scconf_get_int(conf_block,



/* Beware: the following needs to be a multiple of 4
 * or else sc_update_binary will not work on GPK */
/* increased to 256 on 2007-03-12 by aj so we have max size by default */

I will test my gpk card

#define SC_APDU_CHOP_SIZE               256

and that size is used for both recv and send size. recv size needs to be at
least 256 AFAIK, so we can get a full 2048 byte signature in one apdu?

it also needs to be less for some readers, otherwise cryptoflex won't work in some readers. (ludovic mentioned the SCM readers can be fixed with a new firmware or the restriction can be ignored, but I need to search my old mails, what other readers had limitations too).

yep, we really need a way to specify the max send / recv size based on the
currently used reader (the best solution would be to ask the reader [driver]

Nils
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Reply via email to