code review request: 7099399: cannot deal with CRL file larger than 16MB (original) (raw)

Michael StJohns mstjohns at comcast.net
Tue Oct 11 19:50:01 UTC 2011

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: classessecurity 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.

More information about the security-dev mailing list