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. _______________________________________________ opensc-devel mailing list [email protected] http://www.opensc-project.org/mailman/listinfo/opensc-devel
