<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFCC">
+1<br>
<br>
<div class="moz-cite-prefix">On 2/11/20 3:24 PM, Ivan Gerasimov
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c0866433-0d58-8fbd-de3b-c2635bf47d96@oracle.com">Thank
you Roger!
<br>
<br>
We do have a manual test that performs some sanity verification
that a transmit call works [1].
<br>
<br>
I have also received a confirmation from a submitter of the bug
that the patched JDK now allows to retrieve data larger than 32k,
which was not possible before the fix.
<br>
<br>
I'll add a noreg-hard label to the bug.
<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="http://hg.openjdk.java.net/jdk/jdk/file/73bcb3e4e596/test/jdk/sun/security/smartcardio/TestTransmit.java">http://hg.openjdk.java.net/jdk/jdk/file/73bcb3e4e596/test/jdk/sun/security/smartcardio/TestTransmit.java</a><br>
<br>
With kind regards,
<br>
<br>
Ivan
<br>
<br>
<br>
On 2/11/20 6:46 AM, Roger Riggs wrote:
<br>
<blockquote type="cite">Hi Ivan,
<br>
<br>
Raising it to work up to the spec'd limit is a good approach.
<br>
<br>
Do we have a way to test this? Aka: There should be a test.
<br>
<br>
Roger
<br>
<br>
<br>
On 2/10/20 8:07 PM, Ivan Gerasimov wrote:
<br>
<blockquote type="cite">Thank you Michael!
<br>
<br>
It's a good point about maximum length.
<br>
<br>
Here's the updated webrev with the new System property dropped
and the increased number of iterations:
<br>
<br>
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~igerasim/8163251/01/webrev/">http://cr.openjdk.java.net/~igerasim/8163251/01/webrev/</a>
<br>
<br>
With kind regards,
<br>
Ivan
<br>
<br>
<br>
On 2/10/20 4:18 PM, Michael StJohns wrote:
<br>
<blockquote type="cite">On 2/10/2020 6:49 PM, Ivan Gerasimov
wrote:
<br>
<blockquote type="cite">Hello!
<br>
<br>
Current implementation of the method
javax.smartcardio.CardChannel.transmit() has an internal
limitation on the maximum allowed amount of the
transmitted data.
<br>
<br>
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.
<br>
<br>
Over time, we've received requests to increase this limit,
as there are occasions when the effective limit of 8k is
not enough.
<br>
<br>
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).
<br>
<br>
BUGURL: <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8163251">https://bugs.openjdk.java.net/browse/JDK-8163251</a>
<br>
WEBREV:
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~igerasim/8163251/00/webrev/">http://cr.openjdk.java.net/~igerasim/8163251/00/webrev/</a>
<br>
<br>
If there is an agreement on the proposal, I'll file a CSR
to document a new System property.
<br>
<br>
Thanks in advance!
<br>
<br>
</blockquote>
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.
<br>
<br>
Mike
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
</blockquote>
<br>
</body>
</html>