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

[spacewander]

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)?

linux_amd64

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: https://en.wikipedia.org/wiki/Base64#Variants_summary_table.

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]

/cc @rsc , @bradfitz

[plo-]

Any news?

[ianlancetaylor]

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.

[gopherbot]

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.)

[phtdacosta]

I will open this issue again because none of the language maintainers care to take a look at it, so it seems that the community effort will likely try to solve by ourselves.