#26846: prop289: Leave unused random bytes in relay cell payload
-------------------------------------------------+-------------------------
Reporter: dgoulet | Owner: nickm
Type: enhancement | Status:
| accepted
Priority: Medium | Milestone: Tor:
| 0.4.1.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: prop289, 035-roadmap-subtask, | Actual Points: .1
prop289-assigned-sponsor-v, 041-proposed-on- |
roadmap, 0411-alpha, security, 041-should, |
postfreeze-ok |
Parent ID: #26288 | Points:
Reviewer: | Sponsor:
| SponsorV
-------------------------------------------------+-------------------------
Comment (by arma):
Looks reasonable! Sad to use so much more code and per-circuit state but,
everything seems to involve adding more and more code and state these
days. :)
Cleaning up with attention to detail seems smart, e.g. in the commit
message it says 28646, which is a different ticket.
One little nit: connection_edge_get_inbuf_bytes_to_package() in this
branch returns 0 if !package_partial and n_available < RELAY_PAYLOAD_SIZE,
even if we were planning to send a shorter payload and n_available is
enough to send it. Not the end of the world I guess, but kind of weird,
and avoided in my earlier branch. Could be fixed with a bit of gymnastics
(like "reduce length at the top of the function but don't actually commit
to changing state until later in the function").
I also spent a while trying to convince myself that there aren't
situations where connection_edge_get_inbuf_bytes_to_package() can return 0
in this branch yet we changed the state. Would probably be smart to
clearly delineate, in that function, the point at which we've committed to
send a cell. (I think it is right after the final opportunity to "return
0;".)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26846#comment:25>
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
