#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

Reply via email to