On Tue, 29 Oct 2013, Daniel Stenberg wrote:

> The getpart is easy, that's only for our own tests and they should
> certainly have properly formatted base64 strings or we should fix
> them. I think the other places mostly decode externally provided
> data so as far as I can think of right now, they *should* be passed
> in correctly as well so a stricter parser would be fine.

No problem - I've just been updating lib1302 unit test so I will probably
push a change in a little while or even in the morning when I'm a bit more
awake ;-)

My worry at this stage is that some code that uses the function doesn't
terminate the response from the server properly, and the data contains a
CRLF combination at the end of it. All being well the test harnesses should
pick that up and like you say we can fix it up.

> I would say that the most likely thing that could make this backfire
> is if there's some widely deployed software out there in the wild
> that produces broken base64 sequences and we want libcurl to
> work with it. But I also don't think we will find out if there's anything
> like that until we actually try...

This first fix only really performs length validation and checking for an
invalid number of / or position of padding characters. It doesn't aim to
check for invalid base64 characters contained within the string at this
stage but that could easily be added.

I've used CURLE_BAD_CONTENT_ENCODING as the result code so if anyone starts
seeing issues then we should know about it fairly quickly - if there is a
better error code then I'm all ears ;-)

Kind Regards

Steve
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-10-29