DO NOT REPLY [Bug 19860] New: - base64 codec doesnt ignore all illegal chars

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19860>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19860

base64 codec doesnt ignore all illegal chars

           Summary: base64 codec doesnt ignore all illegal chars
           Product: Commons
           Version: Nightly Builds
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Minor
          Priority: Other
         Component: Codec
        AssignedTo: commons-dev@jakarta.apache.org
        ReportedBy: Brian.Ewins@btinternet.com


Reading the base64 code after the release I noticed that it isn't actually
RFC2045 compliant. Top of page 25, http://www.ietf.org/rfc/rfc2045.txt -

"Any characters outside of the base64 alphabet are to be ignored in
base64-encoded data."

Instead, the base64 decoder just throws away (some) whitespace. The lookups in
decodeBase64 will return -1 for illegal characters, which isn't checked for and
will be mistakenly incorporated into the data.

I guess the bug seems a little far-fetched, but XML 1.1 already had to expand
their definition of end-of-line to take account of text processing on
mainframes, which would trigger exactly this problem:
http://www.w3.org/TR/xml11/#sec2.11

I've been bitten by this one in the past, bizarrely enough, and was checking the
code to see if I could start using the apache codec instead of one I'd written.

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org