Am Freitag, 27. Juni 2008 schrieb Franz Brandl: > as far as i remember, the PKCS#11 driver has to use > CKF_PROTECTED_AUTHENTICATION_PATH to indicate to the application that it > shall not prompt for the PIN itself. Seems that this is not the case for > your reader. The question is how OpenSC decides on whether to use the > flag, i am pretty sure it does with other readers. Do you know whether > your KOBIL is accessed via PC/SC or CT-API ? >
I suppose PC/SC. I use Debian Lenny with pcscd Version: 1.4.101-2 libccid Version: 1.3.7-1 opensc Version: 0.11.4-3 libpam-pkcs11 Version: 0.6.0-3 libengine-pkcs11-openssl Version: 0.1.4-1 A colleague just now found that while using openssl with libengine-pkcs11-openssl the pinpad responds immediately. So my guess is, that you have to blame pam-pkcs11 and firefox for waiting for a keyboard return. My pam configuration might be wrong. Is there a working example around? Below I enclose my answer to Ludovic Rousseau. I forgot to send it to the list as well. -- Grüße Johannes ----------------------------------------------------------------- Am Freitag, 27. Juni 2008 schrieb Ludovic Rousseau: > > Which PAM are you using with OpenSC? libpam-pkcs11 Version: 0.6.0-3 on Debian Lenny > > Firefox 2 acts similar. If you use the Kobil pksc11 modules instead of > > opensc, the behaviour is as you wish (both on Linux and Windows). > > Do you use the same PAM module or does Kobil provides one? Kobil provides libkpkcs11hash.so / kpkcs11hash.dll for firefox. (Equivalent to opensc-pkcs11.so / opensc-pkcs11.dll) I have no pam modules from Kobil. > > Can you start firefox in debug mode to try to identify the source of > the crash (firefox or opensc)? > This is the protocol from the moment I clicked on the web page requiring the certificate: [New Thread 0xb01ffb90 (LWP 10019)] pure virtual method called terminate called without an active exception Program received signal SIGABRT, Aborted. [Switching to Thread 0xb01ffb90 (LWP 10019)] 0xffffe410 in __kernel_vsyscall () (gdb) (gdb) (gdb) (gdb) (gdb) (gdb) backtrace #0 0xffffe410 in __kernel_vsyscall () #1 0xb68acef5 in raise () from /lib/i686/cmov/libc.so.6 #2 0xb68ae871 in abort () from /lib/i686/cmov/libc.so.6 #3 0xb6a98838 in __gnu_cxx::__verbose_terminate_handler () from /usr/lib/libstdc++.so.6 #4 0xb6a966f5 in ?? () from /usr/lib/libstdc++.so.6 #5 0xb6a96732 in std::terminate () from /usr/lib/libstdc++.so.6 #6 0xb6a973d5 in __cxa_pure_virtual () from /usr/lib/libstdc++.so.6 #7 0xb7baebed in ?? () from firefox/libxul.so #8 0xb0289ec0 in ?? () #9 0x00000003 in ?? () #10 0xb4fb2268 in ?? () #11 0xb01ff250 in ?? () #12 0x00000001 in ?? () #13 0xb7ea95a8 in ?? () from firefox/libxul.so #14 0xb01ff258 in ?? () #15 0xb02b5470 in ?? () #16 0x00000003 in ?? () #17 0xb01ff250 in ?? () #18 0x9103f278 in ?? () #19 0xb7edabb7 in free () from firefox/libjemalloc.so #20 0xb79d9b5d in ?? () from firefox/libxul.so #21 0xb02b5470 in ?? () #22 0x00000000 in ?? () (gdb) -- Grüße Johannes _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
