[Haskell-cafe] [ANN] base64-bytestring-1.2.0.0

[Emily Pillmore]

Hi everyone!

I’m pleased to announce base64-bytestring-1.2.0.0. In this release, we cleared out the backlog of outstanding feature requests, correctness, and security fixes to present a new stable release. This constituted a major version bump due to the fact that the fixes changed the semantics of the decode function for some inputs, making the decoding process more correct than it was previously.

To illustrate one of the changes to correctness, here’s a quick quiz:

```

What are the correct results of Base64-decoding the strings "ZK==“, "Zm9vYE==“, or "Zm9vYmD=" ?

```

The answer is: the decoding should fail. Why? Even though the above strings may look like externally valid Base64 strings, they are technically impossible to construct such string via Base64-encoding from any binary data in the first place.

Previously (and historically in every version up until this release), they would pass decoding, but fail to roundtrip:

```

П> decode "ZK=="

Right "d"

П> encode "d"

"ZA=="

П> decode "Zm9vYE=="

Right "foo`"

П> encode "foo`"

"Zm9vYA=="

П> decode "Zm9vYmD="

Right "foob`"

П> encode "foob`"

"Zm9vYmA="

```

This was the result of leaking bits when decoding the final quanta of the bytestring. I caught this, and provided a fix. Now here’s an interesting point: there are very few libraries out there that actually address this problem! In fact, there was only one other library out there that I was able to find that was fully correct-per-RFC-spec, which was the Java Amazon SDK. So I guess we can be proud of Haskell in that sense now? I’ve implemented the same in my `base64` library on hackage using the same bitmasking verification techniques, so that one is up to date as well.

Anyway, cheers and happy hacking,

Emily
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20200814/bb776b08/attachment.html>