Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix: Base64 encoding/decoding #2452

Merged
merged 5 commits into from
Jul 6, 2020
Merged

Fix: Base64 encoding/decoding #2452

merged 5 commits into from
Jul 6, 2020

Conversation

mookerji
Copy link
Contributor

@mookerji mookerji commented Jul 1, 2020

  • Moves base64 decoding into proper header file, adds unit test coverage.
  • Fix bug in base64 decoder that failed to remove padding bytes.
  • Updates test fixtures impacted by improper base64 decoding.

Split out from:

/cc @kevinkreiser

Comment on lines +747 to +748
size_t pad_chars = std::count(padded.begin(), padded.end(), PADDING_ENCODED);
std::replace(padded.begin(), padded.end(), PADDING_ENCODED, ZERO_ENCODED);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it seems strange that we would iterate over the whole of the input when we know we can have at max 2 pad chars on the end of the string only. should we not just check the last 2 chars of the string? if any other chars in the string are set to the padding char then we know the input is bogus anyway.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i suppose the other option is that someone sent multiple messages in the same string but i fail to see how we would handle that practically after decoding. in the end we just get back a bucket of bytes and lose an info about the message boundaries

// HACK(mookerji): kDecodedSpeedSize+1 is the expected size (as opposed to kDecodedSpeedSize)
// because we start reading from a 1-byte offset below at the little endian conversion. This is
// actually a broken test fixture because we start reading from 0 in the actual CLI decoding in
// src/mjolnir/valhalla_add_predicted_traffic.cc
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

to fix this should we do a full round trip? we could loop over the values in the block of data below converting them to big endian, pushing back 2 bytes at a time into a string, encode the whole string, and then run the test as is but start the index at 0 instead of 1. i cant understand why this is written this way otherwise?

kevinkreiser
kevinkreiser previously approved these changes Jul 6, 2020
Copy link
Member

@kevinkreiser kevinkreiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mostly philosophical questions. i think this is ok

@kevinkreiser
Copy link
Member

@mookerji you should add a changelog entry

Buro Mookerji added 3 commits July 6, 2020 09:49
- Moves base64 decoding into proper header file, adds unit test coverage.
- Fix bug in base64 decoder that failed to remove padding bytes.
- Updates test fixtures impacted by improper base64 decoding.

Split out from:
- #2424

/cc @kevinkreiser
@mookerji mookerji merged commit 4d1ccc6 into master Jul 6, 2020
@nilsnolde nilsnolde deleted the mookerji-fix-base64 branch February 24, 2024 14:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants