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.
2) How about cleaning up this section of code and moving it to an iterative
model:
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.
