[tor-commits] [tor/master] Remove TODO file.

[nickm at torproject.org]

commit b269ab5aaeee65a3a0b1e5e0923d9dc7898c232e
Author: George Kadianakis <desnacked at riseup.net>
Date:   Mon Jan 14 15:07:19 2019 +0200

    Remove TODO file.
    
    All remaining tasks are now part of #28632.
---
 PADDING_TODO.txt | 58 --------------------------------------------------------
 1 file changed, 58 deletions(-)

diff --git a/PADDING_TODO.txt b/PADDING_TODO.txt
deleted file mode 100644
index a2e97f7ca..000000000
--- a/PADDING_TODO.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-TODO sketch for this branch, in rough priority order:
-
-- Clean up/fix XXX's and FIXMEs
-  - Test event entry points into circuitpad?
-    - Most of our events come from completely untested code :/
-
-- Compat-breaking changes to be decided/done ASAP
-  - Option to keep circuits open if machine present
-  - Specify an ordered preference list of padding machines
-  - Specify exit policy for machine conditions?
-    - short_policy_t looks good, except for its flexible array member :/
-      - Can we make our own struct with a small, fixed number of policy
-        entries? Say 3-4? Or is that a bad idea to lose this flexibility?
-    - Check conditions based on attached streams on the circuit
-      - Accept should mean "only apply if matched"
-      - Reject should mean "don't apply if matched"
-      - If a policy is specified, Reject *:* is implicit default (so reject
-        policies need an Accept entry).
-      - With no policy, Accept *:* is implicit default.
-
-
-- Misc fixes:
-  - Remove circuitsetup machine (but place it in unittests -- they depend on it)
-  - Circuit RTT measurement will break on var_cell/EXTEND2 cells
-    - Are there any heuristics we can use here?
-      - If RELAY_EARLY is only for the first cell of an EXTEND2 series,
-        we can use that. But the proposal currently says MAY, but not MUST
-        for this behavior.
-
-======== 0.3.6 ========
-
-- Come up with some good histograms for eg circuit setup fingerprinting,
-  website fingerprinting, and vanguards usage.
-
-- Vanguards compatibility for MiddleNodes (via changes to vanguards addon)
-
-- circpad_machine_validate() function to sanity-check histograms loaded from
-  consensus/torrc (can also be used to help guide a GA).
-  - Check bin construction
-  - no type overflow (start_usec + range_sec, etc)
-  - no conflicting state transitions (or overlap with cancel events)
-  - no use of both histograms and iat_dist
-  - at least two histogram bins
-  - min_hop vs target_hop
-
-- Support torrc load+serialization of state machines
-  - ??
-
-- Support consensus load+serialization of state machines
-  - ??
-
-- Prop #265 load balancing
-
-- Rephist timer stats
-  - Is this a privacy risk? The adversary could create lots of circuits
-    to find a layer2 vanguard.. Otherwise they will be spread across middles.
-
-