#17868: base64_decode_nopad() destination buffer length problem -----------------------------+------------------------------------ Reporter: dgoulet | Owner: nikkolasg Type: defect | Status: needs_revision Priority: Medium | Milestone: Tor: 0.3.1.x-final Component: Core Tor/Tor | Version: Severity: Normal | Resolution: Keywords: review-group-12 | Actual Points: Parent ID: #19531 | Points: 2 Reviewer: dgoulet | Sponsor: SponsorR-can -----------------------------+------------------------------------
Comment (by nickm): Replying to [comment:38 catalyst]: > I think part of the difficulty is that the contract of `base64_decode_nopad()` is a bit ambiguous. Must padding be absent? Must spaces (or newlines) be absent? i.e., must the unpadded input encoding be of minimum length (which also means that the output length is a function solely of the input length)? If the input to `base64_decode_nopad()` doesn't meet these constraints, should that be an error? Suggestion: The nopad() variant should allow either padding or no padding. > > Also, in `base64_decode()`, the length check at the beginning is overly conservative. Maybe it should just start decoding and return an error if it runs out of space? Or maybe make a first pass over the input to count the actual number of output bytes required before the actual decoding? I think the first option is better? Two-pass approaches can be risky if there is the tiniest mismatch in the passes' behavior. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17868#comment:39> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs