On 10/11/2011 12:50 PM, Michael StJohns wrote:
Two things -
1) Why not just extend this to support "unsigned" long rather than just the 32
bit value - not saying it will be needed, but seems like you might as well do this once.
Well, InputStream::read only supports 32-bit int, and array length is
also 32-bit int. Trying to read so many bytes will be quite complicated.
2) How about cleaning up this section of code and moving it to an iterative
model:
Yes, your codes look more correct. However, this is a regression bug and
we need to fix it fast and with zero risk. Therefore, I choose this
stupid and lazy code change.
Thanks
Max
long length = 0;
if (n< 0x80)
length = n;
else if (n == 0x80) {
// indefinite encoding
} else {
int bytecount = (n&0x7f);
int lencount = bytecount; // needed to do a write to bout
int tempbyte;
is.mark(8);
if (bytecount> 8)
error; // can't fit this in a long
do {
tempbyte = is.read();
if (tempbyte == -1)
error - encoding EOL;
if ((length& 0x7f) != 0& bytecount == 8)
error; // can't do an unsigned long
length = (length<< 8) | tempbyte;
bytecount--;
} while (bytecount> 0);
is.reset();
for (int i = 0; i< lencount; i++) {
bout.write(is.read());
}
}
At 09:05 PM 10/10/2011, Weijun Wang wrote:
Webrev at http://cr.openjdk.java.net/~weijun/7099399/webrev.00/
Basically, we're now accepting X.509 block of 4-octets length. For simplicity, the
highest byte must be<= 127, so that the length can be expressed with a 32-bit
int.
Thanks
Max
-------- Original Message --------
*Change Request ID*: 7099399
*Synopsis*: cannot deal with CRL file larger than 16MB
Product: java
Category: java
Subcategory: classes_security
Type: Defect
=== *Description* ============================================================
The X.509 impl of CertificateFactory only parses X.509 blocks smaller than
16MB, i.e. when the length can be encoded in 3 octets. Now we have a customer
whose CRL file is as big as 30MB.
