On Thu, 2010-09-23 at 00:59 +0200, Andre Zepezauer wrote: > On Wed, 2010-09-15 at 19:33 +0200, Andre Zepezauer wrote: > > On Wed, 2010-09-15 at 11:43 -0500, Douglas E. Engert wrote: > > > > > > On 9/15/2010 6:30 AM, Martin Paljak wrote: > > > > Hello, > > > > On Sep 15, 2010, at 12:12 PM, Viktor TARASOV wrote: > > > >>> Not yet! I had to replace line 122 of iso7816.c > > > >>>> assert(count<= card->max_recv_size); > > > >>> by > > > >>>> assert(count<= card->max_recv_size>0 ? card->max_recv_size : 256); > > > >>> > > > >>> And then everything worked as expected. > > > >> > > > >> The same concerns 'max_send_size'. > > > > > > Some more concerns! The max_*_size code was working, but now > > > we are making change to equate 256 = 0. Its not clear to me what is the > > > problem. > > > > > > > > > I would suggest that max_recv_size and max_send_size are always > 0, and > > > if using extended APDUs, could be > 256. > > > > > > The only place where 0 implies 256 is in a short APDU, and that is > > > handled by apdu.c as it builds the APDU to be sent and it is not using > > > the max_*_size > > > parameters. > > > > > > So I would like to suggest that we go back to 0.11 and look closer at > > > the original problem, and solve it without having to treat 0 == 256. > > > > I have to agree, because the whole max_*_size magic is unnecessary > > altogether. For example max_recv_size is only limited by the size of the > > receive buffer. And this can vary. An excerpt from 7816-3: > > > > "Number Lr (length of response data) is the number of bytes present in > > the data field of the response APDU. [...] ***Number Lr shall be in the > > range zero to number Le.***" > > > > Therefore the only check required on sending APDUs is: Le <= sizeof(buf) > > If there is nobody, who is able to state a real requirement on > > max_recv_size, it could be removed from the code completely. > > > > On the other hand, the constraint max_send_size is actually required by > > some cards. But this could be handled in lower layers too. For example > > apdu.c could use chaining if Lc > max_send_size. > > The meaning of max_recv_size is still unknown to me. Could someone > explain it to me, please. Btw, one of these changes has broken 2048b > keys for CardOS. It may be caused by the fact, that 2048b keys (and > corresponding cryptograms) are exactly 256 byte in size.
With the current trunk 2048b keys on CardOS are working again. Therefore the max_*_size patches work for me. But I have two suggestions: [1] The intended overriding will not work, if the card has a default value of zero for max_*_size. If this is the case, then limitations imposed by the reader are not honoured. [2] Why not moving this to the corresponding card driver? I'm not sure but card-gpk.c should be the right place. [1] http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card.c#L221 [2] http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/pkcs15-gemsafeGPK.c?annotate=blame#L215 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
