Martin Paljak wrote:
On 11.10.2006, at 3:43, Antti S. Lankila wrote:
The anatomy of the problem is this. If you go to
https://vrk.fineid.fi/ and log on, the system asks for the pins for
both of your keys (what does it ask the pin for the nonrepudiation
key for?), and provides my certificate to the remote host, where the
server analyses it, etc. Now, if I try to test the signature, the
browser freezes.
These days the lock_login should be false in opensc.conf ? Make sure
you have the configuration in place and do turn *off* the lock_login
option.
And only now you tell' me that!!!
The distirbuted configuration file I got was incorrect. It claims that
the lock_login default is false, and has a commented out line that says
lock_login = true. However, the default is actually true! But with
uncommenting the line and specifying lock_login = false, I'm now able to
perform digital signatures using the nonrepudiation key, and all the
patches required for this to happen are contained in just the signer
component, without the terrible cache hack in libopensc2.
I've now notified the Debian maintainer of mozilla-opensc about the
following issues:
* the default pinentry points to /usr/local/bin/gpinentry instead of
/usr/bin/pinentry
* the package's control file does not recommend installation of either
pinentry-gtk2 or pinentry-qt.
This is Debian bug #392241.
Many and humble thanks! Finally---after 5 years or so---I can make
digital signatures purely on Linux in real-world situations, without
having to use the soul-sucking Microsoft software or untrustworthy
closed-source components which may sign legally binding messages
concerning me that have actually originated from local mafia, for all I
know. This is the beginning of progress, mark my words...
--
Antti
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel