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
The Reader returned by base32.NewReader sometimes fails to signal an error when its input is improperly padded (length not a multiple of 4 bytes). Whether an error is signaled depends on how the underlying Reader segments its output. If its final read is aligned to a 4-byte boundary and contains only the final unpadded block, then the package does the (IMO) right thing and returns io.UnexpectedEOF. But otherwise, then the package silently ignores the extraneous characters and returns io.EOF (i.e., successful completion of decoding).
The example program demonstrates this with the 18-byte input "NBSWY3DPO5XXE3DEZZ". When the final read is of "ZZ", it returns io.UnexpectedEOF. But when the final read is "EZZ", "DEZZ", or anything else, it returns io.EOF. I would expect it to return io.UnexpectedEOF in all cases. (A case could be made for returning base32.CorruptInputError, like base32.DecodeString does, but at any rate the error should be something other than io.EOF.)
This bug was originally reported on golang-nuts, in 2014 for go1.3.2. There was some discussion but it never got fixed. The thread mentions that base64 may be similarly affected, but I didn't check.
What version of Go are you using (go version)?
go version go1.10.1 linux/amd64
Does this issue reproduce with the latest release?
Yes, with go1.10.2 on play.golang.org.
What operating system and processor architecture are you using (go env)?
josharian
changed the title
base32 decoder silently ignores unpadded trailing characters, depending on the chunking of the underlying Reader
encoding/base32: decoder silently ignores unpadded trailing characters, depending on the chunking of the underlying Reader
May 8, 2018
This changes decoder.Read to always return io.ErrUnexpectedEOF if the input
contains surplus padding or unexpected content. Previously the error could
be io.EOF or io.ErrUnexpectedEOF depending on how the input was chunked.
Fixesgolang#25296
Changing the behavior of decoder.Read is a bit risky, as some inputs will now cause ioutil.ReadAll to return a non-nil error where it previously returned nil. I definitely think that the CL should be merged anyway, as the current behavior is very surprising.
The
Reader
returned bybase32.NewReader
sometimes fails to signal an error when its input is improperly padded (length not a multiple of 4 bytes). Whether an error is signaled depends on how the underlyingReader
segments its output. If its final read is aligned to a 4-byte boundary and contains only the final unpadded block, then the package does the (IMO) right thing and returnsio.UnexpectedEOF
. But otherwise, then the package silently ignores the extraneous characters and returnsio.EOF
(i.e., successful completion of decoding).The example program demonstrates this with the 18-byte input
"NBSWY3DPO5XXE3DEZZ"
. When the final read is of"ZZ"
, it returnsio.UnexpectedEOF
. But when the final read is"EZZ"
,"DEZZ"
, or anything else, it returnsio.EOF
. I would expect it to returnio.UnexpectedEOF
in all cases. (A case could be made for returningbase32.CorruptInputError
, likebase32.DecodeString
does, but at any rate the error should be something other thanio.EOF
.)This bug was originally reported on golang-nuts, in 2014 for go1.3.2. There was some discussion but it never got fixed. The thread mentions that base64 may be similarly affected, but I didn't check.
What version of Go are you using (
go version
)?go version go1.10.1 linux/amd64
Does this issue reproduce with the latest release?
Yes, with go1.10.2 on play.golang.org.
What operating system and processor architecture are you using (
go env
)?What did you do?
https://play.golang.org/p/Bya6YSpMJrB
What did you expect to see?
What did you see instead?
The text was updated successfully, but these errors were encountered: