Hi Andreas, indeed my fault, the attempt was to check if the slotid is not 0, there is a conversion missing.
Problem was that the slot id was not parsed from the string but the whole string. e.g. "slot_5" resulted in a slot ID equals to the string instead of "5". This caused problems with one of our HSM's where if no slot ID is passed on it defaults to 0. Ending up in situation if a lot greater 0 is used as keystore, the engine wont be able to access it. should have been changed to somehing better, but ended up in a bogus that worked. Currently checking the new build... kind regards Andreas Kroehnert Telephone: +44-1276-608046 - Mobile: +44-7852-925958 > -----Original Message----- > From: Andreas Jellinghaus [mailto:a...@dungeon.inka.de] > Sent: 02 June 2009 11:38 > To: opensc-devel@lists.opensc-project.org; Kroehnert, Andreas > Cc: Ubi - opensc > Subject: Re: [opensc-devel] Problems (bug?) in engine_pkcs11 ver 0.1.5 > > yes, the code in engine_pkcs11.c to parse the slot string > is horrible, we tried to allow far too many formats old and new, > and the result is a big mess. > > if anyone could clean it up (and properly test it), that would > be very welcome. > > hmm the safenet changes look bogus. > the line 339 says: > if (slot_id[i + 5] >= 0) { > > > that test was meant to be "does the string end with "slot_DIGITS" > or does it continue with something (e.g. "-id_HEXDIGITS")? > > every u8 char is >= 0, so the condition now is aways true... > > hmm, ok slot_id is const char, but we are not concerned with > chars 0..127 opposed to 128..255 (or -127 .. -1 in char notation). > > the next tests are for "-" and "id_" which should follow any > "slot_" plus DIGITS. and then of course the rest of the string > should be HEXDIGITS and a zero char to terminate the string. > > the old code looks good to me: if "slot_" followed by a 0 > char, we put the number we scanf()ed from the DIGITS into slot, > and set id_len to 0, since there was no ID information and > we return 1 (parsed ok). > > the code for slot_ seems to be ok to me too, it puts the > number n into slot as well, and uses hex_to_bin for putting > the slot into into the id and id_len. > > what seems to be missing is the label_ branch, which doesn't > store n into slot as far as I can see, maybe that was the > reason for the old "bugfix" change? > > akroehnert, your email is in the comment, so I put you on CC: > maybe you can re-read your changes and the previous posters > email and help us out? > > is there some regular expression library that is available on > all unix'es and mac OS X and mingw windows environment (in > standards environments, so we don't need another new dependency)? > writing pattern matching yourself is sooo ugly. > > Regards, Andreas > p.s. not sure if akroehnert is on opensc-devel. thus I keep the > whole original email included here. > Am Montag 01 Juni 2009 10:13:17 schrieb Ubi - opensc: > > Dear all, I'm a happy user of OpenSC stuff since some time. > > Recently, by testing my SW with the latest release of smart card > > software, I stumbled on a problem that I never had. > > > > Using a common smart card (InCrypto 34v2) I had this *CUSTOMized* log > in > > my application: > > > > Ubi: id string too long (slot_NN-id_NN slot_00-id_65725359524e796c) > > > > this, after I changed line 364 of engine_pkcs11.c that simply stated > "id > > string too long" (I wanted to tell it apart from similar messages). > > > > As you see, it seems that the identifier "slot_00- > id_65725359524e796c" > > is rejected by the parser. > > > > In my humble opinion the problem is in line 340 where I read > > > > *id_len = 0; > > > > That will trigger the condition in line 363 > > > > (strlen(slot_id) - i - 3 + 1) / 2 > *id_len) > > > > I had to comment line 340 to make things work again. > > Can anybody confirm this? > > Which is the most logical fix? > > > > I don't dare to go beyond because > > 1) I'm really busy > > 2) I don't know the project sufficiently > > > > > > Some more info: > > > > SW compiled on a Slackware 12.2 for IA 32 bit > > engine_pkcs11-0.1.5 > > opensc-0.11.8 > > nothing special in compilation options ______________________________________________________________ The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. ______________________________________________________________ SafeNet UK Ltd. Registered Office: Rivercourt, 3 Meadows Business Park, Station Approach, Blackwater, Camberley, Surrey, GU17 9AB. Registered in England Number 02258824
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
