Skip to content
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

encoding/base64: The current decode implementation is the mixture of RFC2045 and RFC4648 #25702

spacewander opened this issue Jun 2, 2018 · 4 comments
NeedsInvestigation WaitingForInfo


Copy link

@spacewander spacewander commented Jun 2, 2018

What version of Go are you using (go version)?

go version go1.10 linux/amd64

Does this issue reproduce with the latest release?

Yes. The issue could be confirmed with the latest source code.

What operating system and processor architecture are you using (go env)?


What did you do?

Decode base64 with string contained CR/LF.

What did you expect to see?

RFC 4648 doesn't allow to use CR/LF as line separators, so the decode is expected to fail.
Please correct me if I am wrong.

What did you see instead?

CR/LF is ignored.

It looks like the change is introduced by #2541.
RFC 2045 requires to ignore characters not in decodeMap, so this change is OK for RFC 2045.
But RFC 2045 is different from RFC 4648 and the documentation mentions that it implements RFC 4648.

The differences between RFC 2045 and RFC 4648 could be found here:

Since the encoding/base64 is used in mime module, it is reasonable to implement part of RFC 2045 here. But is it better to implement separate MIME base64 methods with full RFC 2045 support (ignore all characters not in decodeMap)? Just like Java's java.util.Base64.

@agnivade agnivade added the NeedsInvestigation label Jun 2, 2018
@agnivade agnivade added this to the Unplanned milestone Jun 2, 2018
Copy link

@agnivade agnivade commented Jun 2, 2018

/cc @rsc , @bradfitz

Copy link

@plo- plo- commented May 2, 2022

Any news?

Copy link

@ianlancetaylor ianlancetaylor commented May 2, 2022

There is no news.

I'm not sure what action we should take here. If the concern is that the input can contain characters that should be ignored, then it seems straightforward to use an io.Reader that strips such characters. Perhaps we should not have started ignoring \r and \n, but we can't change that now.

@ianlancetaylor ianlancetaylor added the WaitingForInfo label May 2, 2022
Copy link

@gopherbot gopherbot commented Jun 2, 2022

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

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

No branches or pull requests

5 participants