Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 72.14.220.156 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:content-transfer-encoding:content-disposition
         :references;
        b=dHuUgCH1nbKdiSn0qK0Fl1ozK2an5W08MUq/etxdZYfg07vQOCdZ/Pcnk8N/Q2VvQJ
         FfTwm9QfKyZ4CUHDI6lEp+3jFoalfGF+H9MD23ePRP7sTP6opZfA8SI7pJaKyXe/+NJ6
         As6mU0s7xpjEpXWksOAj8et4iDBuEHB8evdVk=
Message-ID: <25aac9fc0807141529i77104751hc0f7e2daa7c86a86@mail.gmail.com>
Date: Mon, 14 Jul 2008 23:29:05 +0100
From: sebb <sebbaz@gmail.com>
To: "Commons Developers List" <dev@commons.apache.org>
Subject: Re: [CODEC] Base64 decode() handling of invalid encoded data
In-Reply-To: <e75283b10807141055n3859e022w1ea917469f6c8cd5@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <25aac9fc0806210519p21dbeefco3dd002d4d8d95bcb@mail.gmail.com>
	 <e75283b10806251039o2d7db556n76c7719c2526630f@mail.gmail.com>
	 <598ad5b50806251202v73bd95efj44e0dec5997c6125@mail.gmail.com>
	 <25aac9fc0807140524n7de7a58av2db1e6b92dc07a77@mail.gmail.com>
	 <e75283b10807140536w562d5006tb4aa3263a96975fc@mail.gmail.com>
	 <25aac9fc0807140637ob066fffhb57d7e2ca5567bd1@mail.gmail.com>
	 <e75283b10807140704w57544681l12c548243fd19e23@mail.gmail.com>
	 <25aac9fc0807140821y236edf48t79966142afc55173@mail.gmail.com>
	 <e75283b10807141055n3859e022w1ea917469f6c8cd5@mail.gmail.com>

On 14/07/2008, Jochen Wiedmann <jochen.wiedmann@gmail.com> wrote:
> On Mon, Jul 14, 2008 at 5:21 PM, sebb <sebbaz@gmail.com> wrote:
>
>  > Just noticed https://issues.apache.org/jira/browse/CODEC-68 which
>  > implies that at least one person is expecting to be able to include
>  > invalid base64 characters without a problem - in that case, after the
>  > PAD characters.
>  >
>  > So maybe there is a need to preserve compatibility after all.
>
>
> Questionable. I understand the problem in CODEC-68 to be the
>  ArrayIndexOutOfBoundsException, which is indeed not what one would
>  expect.

Indeed, and the OOB has been fixed.

But the example showed:

 'n', 'A', '=', '=', 0x9c

So clearly the poster is expecting this to succeed.

However, that is not a valid message, and would trigger the invalid
character checking - assuming that the code checks that PAD characters
only occur at the end of the message.

I was testing the code to check for this - a test failed, and that led
me to CODEC-68.

>  Jochen
>
>
>
>  --
>  Look, that's why there's rules, understand? So that you think before
>  you break 'em.
>
>   -- (Terry Pratchett, Thief of Time)
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

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