RFR 8163251 : Hard coded loop limit prevents reading of smart card data greater than 8k

[Mike StJohns]

To test this you’d have to have an applet and card and card reader or an applet and simulator.    It’s possible you could build something using the java card simulator in the JCDK, but I don’t know if that would actually exercise the code.   

Mike

Sent from my iPad

> On Feb 11, 2020, at 09:47, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> 
> Hi Ivan,
> 
> Raising it to work up to the spec'd limit is a good approach.
> 
> Do we have a way to test this?  Aka: There should be a test.
> 
> Roger
> 
> 
>> On 2/10/20 8:07 PM, Ivan Gerasimov wrote:
>> Thank you Michael!
>> 
>> It's a good point about maximum length.
>> 
>> Here's the updated webrev with the new System property dropped and the increased number of iterations:
>> 
>> http://cr.openjdk.java.net/~igerasim/8163251/01/webrev/
>> 
>> With kind regards,
>> Ivan
>> 
>> 
>>> On 2/10/20 4:18 PM, Michael StJohns wrote:
>>> On 2/10/2020 6:49 PM, Ivan Gerasimov wrote:
>>>> Hello!
>>>> 
>>>> Current implementation of the method javax.smartcardio.CardChannel.transmit() has an internal limitation on the maximum allowed amount of the transmitted data.
>>>> 
>>>> This limitation is dictated by the maximum number of iterations to transmit data from a card:  Each iteration can transmit up to 256 bytes of data, and we have a hardcoded limit of 32 iterations.
>>>> 
>>>> Over time, we've received requests to increase this limit, as there are occasions when the effective limit of 8k is not enough.
>>>> 
>>>> Would you please help review a proposal:  First, it is proposed to increase the default limit of iteration to 128 (so that up to 32k of data can be transmitted);  Second, the limit of iterations is made configurable via a System property. This limit can be increased up to 4096 (so that the total amount of transmitted data can be made up to 1m).
>>>> 
>>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8163251
>>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8163251/00/webrev/
>>>> 
>>>> If there is an agreement on the proposal, I'll file a CSR to document a new System property.
>>>> 
>>>> Thanks in advance!
>>>> 
>>> Given that the maximum length for an extended APDU is 64K (65536) (hmm +7 for the header and +2 for LE), and for its return is 64K + 2 bytes,  I'm not quite sure why you'd up the number to 4096/1M - I'd set the default and fixed value to 257 (64K) and leave it at that.
>>> 
>>> Mike
>>> 
>>> 
>>> 
>>> 
>>> 
>