code review request: 7099399: cannot deal with CRL file larger than 16MB

[Michael StJohns]

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.