Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
T
Tor
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Package registry
Container Registry
Model registry
Operate
Environments
Terraform modules
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Benjamin J. Thompson
Tor
Commits
f72c6f91
Commit
f72c6f91
authored
14 years ago
by
Nick Mathewson
Browse files
Options
Downloads
Patches
Plain Diff
Remove TODO items that are either done or moved to the tracker
parent
a9edb0b4
No related branches found
No related tags found
No related merge requests found
Changes
2
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
doc/TODO.022
+4
-21
4 additions, 21 deletions
doc/TODO.022
doc/TODO.future
+0
-7
0 additions, 7 deletions
doc/TODO.future
with
4 additions
and
28 deletions
doc/TODO.022
+
4
−
21
View file @
f72c6f91
...
...
@@ -8,29 +8,16 @@ NOTE 2: It's easy to list stuff like this with no time estimates and
0.2.2, figure out how long the stuff we want will take, and
triage accordingly, or vice versa.
- Design only
- Begin design work for UDP transition; identify areas where we need to
make changes or instrument stuff early.
[multiple weeks, ongoing. Need to do a draft early.]
- Performance, mostly protocol-neutral.
- Work with Libevent 2.0's bufferevent interface
- Identify any performance stuff we need to push back into
libevent to make it as fast as we want.
- Get a decent rate-limiting feature into Libevent
- Get openssl support into Libevent.
-
Revise how we do bandwidth limiting and round-robining between
o
Revise how we do bandwidth limiting and round-robining between
circuits on a connection.
-
Revise how we do bandwidth limiting and round-robining between
.
Revise how we do bandwidth limiting and round-robining between
connections.
- Better flow-control to avoid filling buffers on routers.
- Split AES across cores if possible.
- Split SSL across cores (reach; may require Libevent 2.1).
- Figure out good ways to instrument Tor internals so we can tell
how well our bandwidth and flow-control stuff is actually working.
- What ports eat the bandwidth?
...
...
@@ -58,10 +45,6 @@ NOTE 2: It's easy to list stuff like this with no time estimates and
- 158: microdescriptors
o Revise proposal
- Implement
o 160: list bandwidth in consensus
o Finish proposal
o and actually set it reasonably
o and actually use it.
- Proposals to improve and implement if not broken
D IPv6 support. (Parts of 117, but figure out how to handle DNS
...
...
@@ -104,6 +87,6 @@ M? - Write proposal
- Switch to MSI on win32
- Use Thandy, perhaps?
-
Deprecations
-
Make .exit safe, or make it off-by-default.
o
Deprecations
o
Make .exit safe, or make it off-by-default.
This diff is collapsed.
Click to expand it.
doc/TODO.future
+
0
−
7
View file @
f72c6f91
...
...
@@ -22,7 +22,6 @@ K - Karsten claims
=======================================================================
Later, unless people want to implement them now:
- tor as a socks proxy should accept (and ignore) password auth
- Actually use SSL_shutdown to close our TLS connections.
- Include "v" line in networkstatus getinfo values.
[Nick: bridge authorities output a networkstatus that is missing
...
...
@@ -30,10 +29,6 @@ Later, unless people want to implement them now:
bridgedb gives out bridges with certain characteristics. -RD]
[Okay. Is this a separate item, or is it the same issue as the lack of
a "v" line in response to the controller GETINFO command? -NM]
- Let tor dir mirrors proxy connections to the tor download site, so
if you know a bridge you can fetch the tor software.
- when somebody uses the controlport as an http proxy, give them
a "tor isn't an http proxy" error too like we do for the socks port.
- MAYBE kill stalled circuits rather than stalled connections. This is
possible thanks to cell queues, but we need to consider the anonymity
implications.
...
...
@@ -45,8 +40,6 @@ Later, unless people want to implement them now:
online config documentation from a single source.
- It would be potentially helpful to respond to https requests on
the OR port by acting like an HTTPS server.
- Make the timestamp granularity on logs configurable, with default
of "1 second". This might make some kinds of after-the-fact attack harder.
- We should get smarter about handling address resolve failures, or
addresses that resolve to local IPs. It would be neat to retry
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment