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
