Re: your mail

["Life is hard, and then you die." <ro...@innovation.ch>]

One day, Bill Stoddard wrote:
> 
> ab_base64decode_binary(decoded, encoded) NULL terminates the decoded buffer
> passed to it. Seems the _binary  modifier should indicate the output should
> be treated as an opaque type and not a character string.  As it is written,
> the following code snippet would cause a one byte buffer overflow:
> 
> time_t t = time();
> char encoded[1024];
> ap_base64encode(encoded, t, sizeof(encoded));
> ap_base64decode_binary((char*) &t, encoded);
> 
> Is the function broken or should the caller make sure the output buffer size
> is adjusted for the NULL termination character? IMO, the function is broken.

Aack! You just solved PR#4957... :-)  Good catch.

Yes, decode_binary should not Nul-terminate:

--- ap_base64.c.orig    Sat Aug 14 01:35:45 1999
+++ ap_base64.c Thu Sep  9 21:57:26 1999
@@ -139,6 +139,7 @@
     for (i = 0; i < len; i++)
        bufplain[i] = os_toebcdic[bufplain[i]];
 #endif                         /* CHARSET_EBCDIC */
+    bufplain[len] = '\0';
     return len;
 }
 
@@ -186,7 +187,6 @@
            (unsigned char) (pr2six[bufin[2]] << 6 | pr2six[bufin[3]]);
     }
 
-    *(bufout++) = '\0';
     nbytesdecoded -= (4 - nprbytes) & 3;
     return nbytesdecoded;
 }

I think when Dirk-Willem and I were adding this stuff I thought that
the decode_binary should Nul-terminate too, but I've now seen the
error of my ways.


  Cheers,

  Ronald