Hi,
On 19.11.2006, at 12:49, Andreas Jellinghaus wrote:
solved: I need to set lock_login to true,
otherwise the engine doesn't work.
This is a bug.
thanks to nils for pointing out the cache or lock_login as
the usual suspect.
No, this could be a bug of either cache_pins or lock_login. To be
precise - the combination of these options.
* lock_login false, cache pins false:
your scenario. As pin is not cached, security status is lost in
between transactions (now if you would play with different pcsc reset
options available...), results in the error you described.
TODO: This is the default when we have pinpads and still would want
to have lock_login feature in 'false' state. This must not result in
error but GUI callback indicating 'please enter your pin on the
pinpad' (or in the simple case 'Please enter your pin')
* lock_login false, cache pins true:
you get an error about security status not satisfied, this error
triggers pin revalidation that does the job, request gets signed.
TODO: we should handle the security status not satisfied error and
only show this if the result of 'pin validation' still indicates
'wrong' (think: pinpads). Currently after the error you would hear
'beep' and know that you should again type your pin (which one?) but
there is no visual feedback about the 're-validation' phase.. (Still
has to be tested...)
* lock_login true, cache pins true:
Everything works as expected (no session unlock during operation to
change the security environment, but even if it would, pin is cached
and revalidation would work)
* lock_login true, cache pins false:
PIN revalidation is not needed, reader transaction is keeping the SE.
This is getting real frustrating for us and our users:
sometimes we need lock_login = true (like here),
sometimes we need it to be false (like firefix+thunderbird).
any way to end this problem would be fantastic.
I guess this has to do with the 'proper pin handling' in both opensc
as well as other applications.
We just need to lay down right rules, implement as needed and
document as needed. Currently it seems like a bug because there is no
clean documentation about the expected or wished functionality and
thus the implementation can not be 100% correct - who caches the pin?
where and how and why ? What indicates pinpad ? Who overwrites the
'pin or pinpad' functionality, where and how?
--
Martin Paljak / [EMAIL PROTECTED]
martin.paljak.pri.ee / ideelabor.ee
+372 515 64 95
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
