[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #28634 [Core Tor/Tor]: Design a first useful padding machine (hiding client-side intro/rend circuits)
#28634: Design a first useful padding machine (hiding client-side intro/rend
circuits)
-------------------------------------------------+-------------------------
Reporter: asn | Owner: (none)
Type: defect | Status:
| needs_revision
Priority: Very High | Milestone: Tor:
| unspecified
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: wtf-pad, tor-relay, tor-cell, | Actual Points:
padding, 041-proposed |
Parent ID: #28632 | Points: 8
Reviewer: mikeperry | Sponsor:
| Sponsor2
-------------------------------------------------+-------------------------
Changes (by mikeperry):
* status: needs_review => needs_revision
Comment:
Some minor comments on the PR for the code and the spec.
High level questions+comments:
1. Should we #define CIRCPAD_STATE_SPOOF_GENERAL CIRCPAD_STATE_BURST, and
use a different terminology (and variables) for that first state? I think
using the wtf-pad names can be confusing, since we're not using the
histograms in the same way it did.
2. It's hard to follow force-pushed PRs like this. I personally would
prefer a fresh PR squashed down rather than worrying about which version
of the force-push I click on for a commit when doing the review.
3. Should we flag these machines as reduced padding using #29203?
I can do the renaming of the burst state in the code and spec if we agree
on a name for the first state of the intro and rend machines.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28634#comment:19>
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