New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support decoding of Base64 with intermediary padding. #3

Open
wants to merge 1 commit into
base: trunk
from

Conversation

Projects
None yet
2 participants
@ghost

ghost commented Aug 20, 2015

Some base64 encoders in the wild incorrectly pad data before the end of
data. For instance, the string "testtesttest" might be encoded as
"dGVzdA==dGVzdA==dGVzdA==" instead of "dGVzdHRlc3R0ZXN0". This is,
technically speaking, a bug.

This patch makes the decoder tolerant to this kind of nonsense.
Intermediary padding is processed and then decoding carries on as
though a new string were provided.

Bram
Support decoding of Base64 with intermediary padding.
Some base64 encoders in the wild incorrectly pad data before the end of
data. For instance, the string "testtesttest" might be encoded as
"dGVzdA==dGVzdA==dGVzdA==" instead of "dGVzdHRlc3R0ZXN0". This is,
technically speaking, a bug.

This patch makes the decoder tolerant to this kind of nonsense.
Intermediary padding is processed and then decoding carries on as
though a new string were provided.
@garydgregory

This comment has been minimized.

Show comment
Hide comment
@garydgregory

garydgregory Aug 20, 2015

Contributor

Thank you for providing a patch.

I would be OK with a workaround like this if it had to be turned with a strict=false or lenient=true option.

Contributor

garydgregory commented Aug 20, 2015

Thank you for providing a patch.

I would be OK with a workaround like this if it had to be turned with a strict=false or lenient=true option.

@kinow

This comment has been minimized.

Show comment
Hide comment
@kinow

kinow Sep 1, 2017

Member

+1 to what @garydgregory suggested. I'd prefer to keep it strict by default, and have an option to make it accept this other format. Or maybe a different Base64 decoder (we currently support only RFC2045's Base64 format). And there are conflicts in the PR, so would be nice if it could be updated to fix/merge the conflicts too :-)

Member

kinow commented Sep 1, 2017

+1 to what @garydgregory suggested. I'd prefer to keep it strict by default, and have an option to make it accept this other format. Or maybe a different Base64 decoder (we currently support only RFC2045's Base64 format). And there are conflicts in the PR, so would be nice if it could be updated to fix/merge the conflicts too :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment