Hello, On Sep 27, 2010, at 9:59 PM, Andre Zepezauer wrote: > the patch I proposed is mostly complete. The total count of lines is > huge, but individual changes are trivial. An exception to this is the > pkcs15 emulation related to the Oberthur cards. It makes heavy use of > flags before writing the TokenInfo to the card. Since the two different > kinds of flags are now divided, this required more changes than on other > places. Therefore it would be helpful if someone could test the > initialisation of oberthur cards after applying the attached patch. Great, I think this is a good example of separating sometimes a little bit obscure OpenSC specific data structures and specification related data structures.
I have a few recommendations that could be fixed in the same change: - Fix abuse of pkcs15card->(tokeninfo->)version. PKCS#15 v1.1 tells that version == 0 means "this version of the PKCS#15 spec" which is v1.1. Which means the +1/-1 trickery in pkcs15.c for parsing/decoding tokeninfo->version should be removed, as should be removed emulation driver overloading for version info. Only 0 should be encoded and only 0 should be handled/displayed by internal code. - Change the flag names of PKCS#15 flags and pkcs15_card_t flags (as noted below). SC_TOKENINFO_RNG would be OK, there would be no other SC_TOKENINFO_* constants so the extra _FLAGS_ would just eat up bytes. Or maybe prepend the internal flags with _. Ideally, the verbosity of C should not exceed the verbosity of Java. - Maybe change the granularity of some memory allocations and required matching free()-s by card drivers. Or make set_string use common by more drivers and move it to some internal implementation file instead (currently copied from pkcs15-esteid.c to 5 other files). Maybe "DEVELOPER FIX CARD NAME" would be better for the default name for a PKCS#15 card, or an assert somewhere? > For now I would like to know, if there are any complains about the patch > and your opinion about renaming the TokenInfo related flags to something > like SC_TOKENINFO_FLAGS. Some more additional improvements will make this a great patch. Cleaning up the internals of OpenSC is a good thing. -- @MartinPaljak.net +3725156495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
