Hi Martin, Martin Paljak wrote: > On Apr 22, 2010, at 00:25 , Jan Just Keijser wrote: > >> Hi Andreas, >> >> Andreas Jellinghaus wrote: >> >>> hmm. if we had only one engine doing both rsa and gost, the >>> problem would be gone, without this "hack" required in opensc? >>> >>> my point of view: >>> if so: I think that is the solution! please drop the stuff >>> from opensc, and work in that direction. >>> >>> engine_pkcs11.c is bsd3 / openssl license, and libp11 >>> is lgpl (but only 2k lines of code, and not very great code >>> anyway), so long term a unified engine is the way to go. >>> >>> or send patches for libp11/engine_pkcs11 to handle gost. >>> (no idea how much work that would be - I'm quite clueless >>> over there. also gost engine might be much better than the >>> simple and hacky engine_pkcs11). >>> >>> but maybe I missed something in the discussion or got some >>> parts wrong? please don't let me stay stupid :-) >>> >>> >>> >> the problem is quite subtle: >> - some applications load engine_pkcs11 and/or opensc-pkcs11 but they >> themselves do not use openssl >> - to use the gost algorithms inside of engine_pkcs11 the openssl gost >> engine (an external .so file) needs to be loaded. >> > Isn't it engine-pkcs11 where the engine is loaded (or at least the > configuration trick done) ? > > > >> - the current 'trick' is to simply call OPENSSL_config() and hope/make >> sure that the gost engine is loaded based on what is found in the system >> default openssl.cnf file >> > Relying on config files can lead to trouble some time.. > > > >> - the problem occurs when you're calling OPENSSL_config() again, e.g. >> such as the 'openssl engine' command does; this causes all openssl >> engines to be loaded *again*, including the gost engine and the >> engine_pkcs11 file. at that point openssl barfs with the error as reported. >> A quick and dirty hack is to only load the 'gost' section (provided >> there is one): >> OPENSSL_config( "gost" ) >> but that can also fail if the application loading engine_pkcs11 itself calls >> OPENSSL_config() >> again the engine would be loaded twice. >> >> I have not yet come up with a totally clean solution to this problem; >> perhaps there needs to be a test to see if the 'gost' engine is already >> loaded or not. The real problem is openssl's inability to load an engine >> twice (e.g. ignore the second attempt). >> > > > So, eventually this needs to be fixed in OpenSSL to fix/add support for > double loading or provide some signaling to deal with it (unless there is a > proper workaround that can be implemented right now, which does not seem to > exist.). > > As it only affects OpenSH+OpenSSL 1.0 line (which is not yet widespread and > was not available before) and only (skimming through code) GOST 3411 > verification done in the software and does not affect the ability to access > the hardware features of Rutokens via OpenSC (on-card actions, what OpenSC > should be designed to do), I think it would be a good idea to disable it in > OpenSC until something can be figured out with OpenSSL folks. > > > some "modern" linux distro's are already using a version of openssl 1.0: - fedora 12 - fedora 13 (beta) Debian Lenny and OpenSuse are still at 0.9.8 ; Ubuntu seems to follow Lenny.
I agree that for the time being this code be disabled (or perhaps use a #define to enable it). cheers, JJK _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
