You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Buffer.from('base64') decodes some white space as data #11987
I am writing a native addon to decode a buffer containing base64 directly into another buffer, without requiring the allocation of an interim string (see #11866 for why Node cannot decode base64 buffers directly).
I wrote a fuzz test to test my own decoder, and then decided to try it out on Node's base64 decoder.
There are a few cases where Node's decoder treats whitespace as actual data, rather than ignoring it. This happens when the "=" is left out:
changed the title [-]Buffer.from('base64') decodes white space inconsistently[/-][+]Buffer.from('base64') decodes some white space as data[/+]on Mar 22, 2017
I'm assuming Node.js doesn't throw on invalid base64 input for performance reasons.
This is another issue, but there's technically no performance reason why Node's decoder could not throw on non-whitespace, non-alphabet characters. The current decoder can be upgraded without introducing any additional branching cost.
So it's basically "garbage in - garbage out".
You're saying the lack of "=" padding plus extra trailing space is illegal? Node's decoder is supposed to ignore white space. It's also supposed to handle the lack of "=" padding. None of that is illegal.
atob() is generally pretty good at throwing on garbage or illegal data, and it has no problem on the same set.
There's nothing too unusual about this kind of input either. Imagine a MIME message scenario where the sender never added base64 padding, and an intermediary mail transport added trailing white space.
Activity
[-]Buffer.from('base64') decodes white space inconsistently[/-][+]Buffer.from('base64') decodes some white space as data[/+]seishun commentedon Mar 22, 2017
I'm assuming Node.js doesn't throw on invalid base64 input for performance reasons. So it's basically "garbage in - garbage out".
jorangreef commentedon Mar 22, 2017
This is another issue, but there's technically no performance reason why Node's decoder could not throw on non-whitespace, non-alphabet characters. The current decoder can be upgraded without introducing any additional branching cost.
You're saying the lack of "=" padding plus extra trailing space is illegal? Node's decoder is supposed to ignore white space. It's also supposed to handle the lack of "=" padding. None of that is illegal.
atob()is generally pretty good at throwing on garbage or illegal data, and it has no problem on the same set.There's nothing too unusual about this kind of input either. Imagine a MIME message scenario where the sender never added base64 padding, and an intermediary mail transport added trailing white space.
src: fix base64 decoding
src: fix base64 decoding
src: fix base64 decoding
src: fix base64 decoding
src: fix base64 decoding