GH-49614: [C++] Fix silent truncation in base64_decode on invalid input

[Reranko05]

Rationale for this change

arrow::util::base64_decode silently truncates output when encountering invalid base64 characters, returning partial results without signaling an error. This can lead to unintended data corruption.

What changes are included in this PR?

• Add upfront validation of input characters in base64_decode
• Return an empty string if invalid base64 characters are detected
• Prevent silent truncation of decoded output

Are these changes tested?

Yes. A unit test has been added to verify that invalid input returns an empty string.

Are there any user-facing changes?

Yes. Previously, invalid base64 input could result in partial decoded output. Now, such inputs return an empty string.

This PR contains a "Critical Fix".

This change fixes a correctness issue where invalid base64 input could result in silently truncated output, leading to incorrect data being produced. The fix ensures such inputs are detected and handled safely.

• GitHub Issue: [C++] arrow::util::base64_decode silently truncates on invalid characters instead of reporting an error #49614

[github-actions]

⚠️ GitHub issue #49614 has been automatically assigned in GitHub to PR creator.

[dmitry-chirkov-dremio]

I’m not comfortable with "" as the error path here. It’s indistinguishable from a valid decode of empty input, so malformed input still fails silently. I’d prefer this API to fail explicitly (Result<std::string> / checked variant) and have Gandiva propagate that as an error.

Returning null would be slightly better than returning "", because at least it doesn’t collide with a valid decoded empty string. But I still don’t think it’s the right default behavior here as null still turns malformed input into a regular value rather than an explicit failure.

[dmitry-chirkov-dremio]

This is absolutely insufficient and will not trip on input like abcd=AAA. Please do some research on best practices for sufficient and efficient base64 input validation.

[dmitry-chirkov-dremio]

More tests! In our day and age with tools that we have this is not even bare minimum. Null input? Valid input? Non-ascii input?

Did you locate other tests? I'm not seeing any other tests for base64_decode in this file so where are they?

[Reranko05]

Thanks for the feedback. I’ve updated the implementation and tests.

• Added stricter validation (length, padding placement/count, allowed characters)
• Removed early termination in the decode loop to avoid silent truncation
• Expanded test coverage to include invalid inputs and edge cases

All tests pass locally. Please let me know if any further adjustments are needed.

[kou]

Could you use arrow::Result<std::string> return type instead of using ARROW_LOG()?

[kou]

FYI: You can run CI on your fork by enabling GitHub Actions on your fork.

[Reranko05]

Could you use arrow::Result<std::string> return type instead of using ARROW_LOG()?

Thanks for the suggestion @kou !

Just to clarify, would you prefer changing the existing base64_decode API to return arrow::Resultstd::string, or introducing a separate checked variant while keeping the current API unchanged?

I want to make sure the approach aligns with existing usage and expectations.

[kou]

"changing the existing base64_decode API to return arrow::Resultstd::string".
But I want to know how many changes are required for existing code that use base64_decode().

[Reranko05]

@kou I checked the current usages of base64_decode(), and it appears to be used in a very limited number of places (primarily in tests and one internal call site in flight_test.cc).

Updating to arrow::Result<std::string> would require adjusting those call sites to use ARROW_ASSIGN_OR_RAISE, but the impact seems quite localized and manageable.

I can proceed with the API change and update the affected call sites accordingly.