encoding/base64: The current decode implementation is the mixture of RFC2045 and RFC4648 #25702
Labels
FrozenDueToAge
NeedsInvestigation
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
WaitingForInfo
Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Comments
agnivade
added
the
NeedsInvestigation
|
Any news? |
|
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 |
ianlancetaylor
added
the
WaitingForInfo
|
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.) |
|
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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/base64is used inmimemodule, 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'sjava.util.Base64.The text was updated successfully, but these errors were encountered: