This repository has been archived by the owner on Nov 18, 2024. It is now read-only.
Pin commons-codec to 1.12, due to Base64 handling changes #74
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We recently upgraded the reactivemongo dependency in this project, to fix a bug with signalling channel initialisation. Whilst that got fixed, it surfaced another 'issue', by bringing in the apache commons-codec 1.13.
Commons-codec 1.13 subtly changed the way that Base64 got decoded, when the string being decoded was invalid. If it was completely invalid, it would error. However, there are certain strings that are not valid Base64, but can be decoded as if they were. I won't try and explain the detail here (more detail is on the first JIRA ticket linked below), but it seems to involve the last few characters of a string - in that Base64 decoders can discard/pad them. However, if you randomly change the last few characters of a Base64 string, chances are that you just made it invalid.
Anyway, commons-codec 1.12 was lenient to this. 1.13 is not, and neither is 1.14. 1.15 will be, but it is not currently released.
See these relevant JIRAS:
https://issues.apache.org/jira/browse/CODEC-263
https://issues.apache.org/jira/browse/CODEC-270
https://issues.apache.org/jira/browse/CODEC-280
This change in behaviour has surfaced various encoding/decoding scenarios where we relied on an invalid Base64 string, but it was being used leniently. Whilst it is a good thing that spot, and fix, these invalid Base64 occurrences, it has been causing lots of noise. Therefore, this PR reverts the upgrade to 1.13 and forces the use of 1.12. It is intended that we release a new version of this library when apache commons-codec 1.15 is released, provided that changes for CODEC-280 are contained within in.
Phew.