[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #17868 [Core Tor/Tor]: base64_decode_nopad() destination buffer length problem
#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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs