[tor-bugs] #17868 [Core Tor/Tor]: base64_decode_nopad() destination buffer length problem

[Tor Bug Tracker & Wiki]

#17868: base64_decode_nopad() destination buffer length problem
--------------------------------------------+------------------------------
 Reporter:  dgoulet                         |          Owner:  nikkolasg
     Type:  defect                          |         Status:
 Priority:  Medium                          |  needs_revision
Component:  Core Tor/Tor                    |      Milestone:  Tor:
 Severity:  Normal                          |  0.2.9.x-final
 Keywords:  review-group-4, review-group-6  |        Version:
Parent ID:                                  |     Resolution:
 Reviewer:  dgoulet                         |  Actual Points:
                                            |         Points:  0.1
                                            |        Sponsor:  SponsorR-can
--------------------------------------------+------------------------------
Changes (by dgoulet):

 * status:  needs_review => needs_revision


Comment:

 Replying to [comment:21 nikkolasg]:
 [snip]
 > With these two remarks in mind, it seems to me that using
 `base64_encode_size` for encoding *without* padding is wrong API wise and
 logic wise. My suggestion would be to introduce a new function
 `base64_encode_size_nopad` which returns the encoded buffer size without
 padding. That way, both base64 APIs are being consistent:
 > * Padding:
 >     * Get the base64 buffer length with `m = base64_encode_size(n)`
 >     * Encode with `base64_encode(encoded,m,plain,n)`
 >     * Decode with `base64_decode(decoded,n,encoded,m)`
 > * No padding:
 >     * Get the base64 buffer length with `m =
 base64_encode_size_nopad(n)`
 >     * Encode with `base64_encode_nopad(encoded,m,plain,n)`
 >     * Decode with `base64_decode_nopad(decoded,n,encoded,m)`
 >
 > Does it make sense or am I over my head ?
 > If it does make sense, I'm happy to provide that method once you approve
 it.

 It does! It makes a consistent API which makes sense to me. It's symmetric
 also, so please go ahead! :)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17868#comment:24>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online