Fix output length of Base64 decoded keys#55
Open
cvuosalo wants to merge 2 commits into
Open
Conversation
DrDaveD
requested changes
Jun 16, 2026
DrDaveD
approved these changes
Jun 16, 2026
luissimas
approved these changes
Jun 17, 2026
This file contains hidden or 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 join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The Base64Coder was added to frontier-tomcat in 2007. It was modified shortly thereafter, and a small bug was introduced. This bug added a byte to the output of the decoder when the encoded key had two padding characters. This bug had no effect until now, when more modern libraries rejected decoded keys with a trailing random byte for the case of encoded keys had two padding characters. The bug was only noticed on machines that happened to have host keys with two padding characters.
To prevent any future confusion about this code, not only has the bug been fixed, but a comment has been added to the code to help explain how the fix is correct. Also, the corrected calculation is written more explicitly and does not rely on the implicit truncation of integer arithmetic.The calculation could be written more concisely, but that would invoke the implicit truncation that caused confusion in the past and that can be difficult for the reader to easily check for correctness.
This fix was tested on cmsfrontier7 with two different sized keys. During testing,
printlnstatements were added to show the input and output lengths to confirm that the calculation was correct.