Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T17:18:29Zhttps://gitlab.torproject.org/legacy/trac/-/issues/1765Project: Spanish translations2020-06-13T17:18:29ZNick MathewsonProject: Spanish translationsFor our September 30 deliverable, we've promised Spanish translations. Right now we believe that this mainly involves a better Spanish version of the website, but somebody should confirm that we don't need other things too.For our September 30 deliverable, we've promised Spanish translations. Right now we believe that this mainly involves a better Spanish version of the website, but somebody should confirm that we don't need other things too.Deliverable-Sep2010Andrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/1764Project: Launch the improved website2020-06-13T17:18:29ZNick MathewsonProject: Launch the improved websiteAt the end of our [milestone:"Tor Website Overhaul" website overhaul efforts], we should finally launch the new website on torproject.org.
Tickets labeled for "Tor Website Overhaul":
[[TicketQuery(milestone=Tor Website Overhaul)]]
Chil...At the end of our [milestone:"Tor Website Overhaul" website overhaul efforts], we should finally launch the new website on torproject.org.
Tickets labeled for "Tor Website Overhaul":
[[TicketQuery(milestone=Tor Website Overhaul)]]
Child tickets:
[[TicketQuery(parent=#1764)]]Deliverable-Sep2010Andrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/1763Project: publish "10 things to think about circumvention systems" whitepaper2010-09-28T17:50:19ZNick MathewsonProject: publish "10 things to think about circumvention systems" whitepaperRoger wrote a draft whitepaper here. We should get it into publishable format so that it can get more attention.Roger wrote a draft whitepaper here. We should get it into publishable format so that it can get more attention.Deliverable-Sep2010Andrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/1762Project: Automated translation seeding2020-06-13T17:32:28ZNick MathewsonProject: Automated translation seedingFor our 30 September deliverable date, we need to make some progress on "automated translation seeding."
Runa asked "Are you talking about Google translator toolkit and Worldwide Lexicon?" And perhaps that is what Phobos was talking ab...For our 30 September deliverable date, we need to make some progress on "automated translation seeding."
Runa asked "Are you talking about Google translator toolkit and Worldwide Lexicon?" And perhaps that is what Phobos was talking about, but perhaps not.
The first step here is to describe what the long-term requirement is, and what the September 30 requirement is, and edit this description to contain them.
Child tickets:
[[TicketQuery(parent=#1762)]]Deliverable-Sep2010Andrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/1761Add support for bufferevent-based transports2020-06-13T14:05:29ZNick MathewsonAdd support for bufferevent-based transportsWe've been planning for a while to move Tor's transport mechanism from using our own buf_t implementation to Libevent's bufferevents, which in Libevent 2.0 allow us to use IOCP on windows, full scatter/gather IO, and other useful things....We've been planning for a while to move Tor's transport mechanism from using our own buf_t implementation to Libevent's bufferevents, which in Libevent 2.0 allow us to use IOCP on windows, full scatter/gather IO, and other useful things.
The latest version of the code is in the highest-numbered "bufferevent*" branch in my public repository, currently bufferevent3.Deliverable-Sep2010Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1759Microdescriptors: clean out the microdescriptor cache when it gets too big2020-06-13T14:05:28ZNick MathewsonMicrodescriptors: clean out the microdescriptor cache when it gets too bigThe current microdescriptor fetching/cacheing code has no idea of how to forget about microdescriptors once they're too old. Doing this for router descriptors has been a major pain since, like, forever. We should design this more caref...The current microdescriptor fetching/cacheing code has no idea of how to forget about microdescriptors once they're too old. Doing this for router descriptors has been a major pain since, like, forever. We should design this more carefully so that we don't replace one maintenance headache with two.Deliverable-Sep2010https://gitlab.torproject.org/legacy/trac/-/issues/1757Microdescriptors: abstract the notion of "Tor node" in the code2020-06-13T14:05:27ZNick MathewsonMicrodescriptors: abstract the notion of "Tor node" in the codeRight now we have at least 5 things that we use to indicate a Tor node:
* A `const char *` pointing to an ID key digest
* A `routerinfo_t`
* A `routerstatus_t`
* An `extend_info_t`
* An entry in `rephist.c`, though those are mostly...Right now we have at least 5 things that we use to indicate a Tor node:
* A `const char *` pointing to an ID key digest
* A `routerinfo_t`
* A `routerstatus_t`
* An `extend_info_t`
* An entry in `rephist.c`, though those are mostly isolated.
For microdescriptors, we're about to add another thing:
* A `microdescriptor_t`
Making our code work properly with all of these variant things is already a bit hairy. It sure would be nice if we had some kind of abstract node_t that could make it so our code worked well with all of the above.
First, we'll need a basic design here. At the minimum we should make routerstatus_t and routerinfo_t (basically) immutable, and add a node_t that abstracts routerstatus_t and routerinfo_t. Then, we can make it so that its interface can be satisfied by microdescriptor_t as well.Deliverable-Sep2010Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1755Microdescriptors: caches fetch and serve microdescriptors2020-06-13T14:05:26ZNick MathewsonMicrodescriptors: caches fetch and serve microdescriptorsFor microdescriptors to work, clients need to be able to fetch them from the caches. Thus, caches need to fetch microdescriptors and serve them. This is mostly implemented in my "microdesc_dl" branch, but depends on [#1754].
The "cach...For microdescriptors to work, clients need to be able to fetch them from the caches. Thus, caches need to fetch microdescriptors and serve them. This is mostly implemented in my "microdesc_dl" branch, but depends on [#1754].
The "caches fetch and store microdescriptors" code will be reusable for clients.Deliverable-Sep2010Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1754Microdescriptors: caches fetch and server all flavors of consensus2020-06-13T14:05:25ZNick MathewsonMicrodescriptors: caches fetch and server all flavors of consensusRight now, caches only know how to download and use one single consensus flavor. We need them to be able to fetch, parse, store, and serve every flavor. Right now, that means "normal" and "microdesc".
Storing and serving are already i...Right now, caches only know how to download and use one single consensus flavor. We need them to be able to fetch, parse, store, and serve every flavor. Right now, that means "normal" and "microdesc".
Storing and serving are already implemented (I believe) since authorities do them. Parsing and fetching remain are partially implemented in my "microdesc_dl" branch.
See proposals 158 and 162 for more information.Deliverable-Sep2010Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1751Project: Make it harder to use exits as one-hop proxies2020-06-13T14:05:24ZNick MathewsonProject: Make it harder to use exits as one-hop proxies[Proposal 163](https://gitweb.torproject.org/tor.git/blob_plain/HEAD:/doc/spec/proposals/163-detecting-clients.txt) outlined some ways to detect clients, and [later emails](http://archives.seul.org/or/dev/Jun-2009/msg00018.html) elaborat...[Proposal 163](https://gitweb.torproject.org/tor.git/blob_plain/HEAD:/doc/spec/proposals/163-detecting-clients.txt) outlined some ways to detect clients, and [later emails](http://archives.seul.org/or/dev/Jun-2009/msg00018.html) elaborated on the issue, clarifying some parts and exposing hopeless muddiness in others.
There's an initial implementation of a variant of the concept in Tor now, under the RefuseUnknownExits configuration option. Unfortunately, turning it on seems to give many positives. We haven't investigated whether they're false positives or just jerks using Tor as a one-hop proxy.
Child Tickets:
[[TicketQuery(parent=#1751)]]Deliverable-Sep2010https://gitlab.torproject.org/legacy/trac/-/issues/1750Project: See if we can improve performance by throttling busy streams at guar...2020-06-13T14:05:23ZNick MathewsonProject: See if we can improve performance by throttling busy streams at guard nodesIn particular see http://archives.seul.org/or/dev/Dec-2009/msg00002.html and discussion stemming from Proposal 163. Basically, we want to keep individual clients from hammering the network too hard when we need the banwidth to relay tr...In particular see http://archives.seul.org/or/dev/Dec-2009/msg00002.html and discussion stemming from Proposal 163. Basically, we want to keep individual clients from hammering the network too hard when we need the banwidth to relay traffic. We have a partial implementation, and Roger says that current next steps are performance measurements of some kind:
Look at bwconnrate and bwconnburst in the consensus. Next step is to do more rigorous performance comparisons (turn it on, off, on, off, compare torperf results).
Child Tickets:
[[TicketQuery(parent=#1750)]]Deliverable-Sep2010https://gitlab.torproject.org/legacy/trac/-/issues/1721Analyze increase in Microsoft Windows relay availability?2020-06-13T17:49:31ZAndrew LewmanAnalyze increase in Microsoft Windows relay availability?In the past two years, have relays claiming to be microsoft windows had increased uptime? I'm trying to determine if bug #98 is effectively resolved, because the empirical evidence shows that the average uptime of relays has increased o...In the past two years, have relays claiming to be microsoft windows had increased uptime? I'm trying to determine if bug #98 is effectively resolved, because the empirical evidence shows that the average uptime of relays has increased over the past 2 years.Deliverable-Sep2010Karsten LoesingKarsten Loesing