Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-21T18:04:51Zhttps://gitlab.torproject.org/legacy/trac/-/issues/3893Verifying-signatures needs some work2020-06-21T18:04:51ZMike PerryVerifying-signatures needs some workhttps://www.torproject.org/docs/verifying-signatures.html.en is ridiculously complicated and stuffed with tons of irrelevant information.
We should break it into 2 pages. The list of keys that signs sub-components and/or email should be...https://www.torproject.org/docs/verifying-signatures.html.en is ridiculously complicated and stuffed with tons of irrelevant information.
We should break it into 2 pages. The list of keys that signs sub-components and/or email should be on a completely separate page. The only keys on this page should be those that actually sign user-facing packages: TBB and (maybe) the vidalia expert bundles.
The page should walk the user through verifying a signature of a specific package for each platform. The page should focus on only one key and only one package. This package should probably be TBB.
Also, much of the material on this page is out of date. For example, the Mac utilities are completely different now, are hosted at a new URL, and now have a GUI that handles the key import process (but sadly not package signature verification). They do at least put the gpg binary into the system path, so you no longer have to grovel through /Applications in order to find it.website redesignRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/242"closing wedged cpuworker"2020-06-13T18:01:08ZTrac"closing wedged cpuworker"Jan 16 17:35:42.229 [notice] cull_wedged_cpuworkers(): Bug: closing wedged cpuworker. Can somebody find the bug?
Using libevent-1.1a on a Linux i586 system, the above message appears in my log. Tor server does not seem to crash; servic...Jan 16 17:35:42.229 [notice] cull_wedged_cpuworkers(): Bug: closing wedged cpuworker. Can somebody find the bug?
Using libevent-1.1a on a Linux i586 system, the above message appears in my log. Tor server does not seem to crash; service remains viable.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: jtestaRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/5569ides has relocated and become turtles2020-06-13T17:50:02ZMike Perryides has relocated and become turtlesI think we're all set. Should we update the source right away, or should we just specify custom it in our torrcs for now?
Apr 04 18:45:23.000 [notice] Now checking whether ORPort 76.73.17.194:9090 and DirPort 76.73.17.194:9030 are reac...I think we're all set. Should we update the source right away, or should we just specify custom it in our torrcs for now?
Apr 04 18:45:23.000 [notice] Now checking whether ORPort 76.73.17.194:9090 and DirPort 76.73.17.194:9030 are reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Apr 04 18:45:30.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
Apr 04 18:47:22.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.Tor: 0.2.2.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/2535Research task summaries and bibliography recommendations for Dan's class2020-06-13T17:49:42ZRoger DingledineResearch task summaries and bibliography recommendations for Dan's class[Not sure what component to put this in. I picked metrics, but maybe there should be a separate 'research' component.]
Dan Boneh is teaching a class next quarter on circumvention and anonymity. The students will break up into groups and...[Not sure what component to put this in. I picked metrics, but maybe there should be a separate 'research' component.]
Dan Boneh is teaching a class next quarter on circumvention and anonymity. The students will break up into groups and do research projects on various topics. We're writing up more detailed examples of some of the research topics (#2530, #2531), but we should put the whole list somewhere for posterity.
Also, he wanted to pick 15 to 20 papers to cover, and wanted some tips.Deliverable-Mar2011Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/6470distinguishing between (non-) hidden service hosters, too few/much open circuits2020-06-13T17:47:41Zproperdistinguishing between (non-) hidden service hosters, too few/much open circuitsFor Internet Service Providers it's too easy to find who hosts a hidden service and who doesn't.
For people connecting to the public Tor network:
* Tor users have X open circuits after Tor started.
* Hosters of hidden services have mu...For Internet Service Providers it's too easy to find who hosts a hidden service and who doesn't.
For people connecting to the public Tor network:
* Tor users have X open circuits after Tor started.
* Hosters of hidden services have much more open circuits after Tor started. In my tests it were mostly X*3 open circuits.
* It's trivial for ISPs to distinguish between non-hidden-services and regular Tor users.
* That analysis combined with another attack, such as Murdoch's clock skew attack can de-anonymize Tor hidden service hosters.
For people connecting to (obfuscated) bridges:
* Same as above but depends on the ability of the ISP to detect connections to the Tor network.
Suggested solution:
* Open the same amount of circuits. Do not let that depend on if the user hosts a hidden service or not.Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/4682Deal with 'double door' effects because our read and write rate limiting are ...2020-06-13T17:47:19ZKarsten LoesingDeal with 'double door' effects because our read and write rate limiting are independentIn [sponsor F deliverable 2](uploads/org/sponsors/SponsorF/Year2) we promised to "build and execute a plan for proposal 182" and to "figure out how it does or does not relate to the N23 congestion control design, to Ian's ideas about Def...In [sponsor F deliverable 2](uploads/org/sponsors/SponsorF/Year2) we promised to "build and execute a plan for proposal 182" and to "figure out how it does or does not relate to the N23 congestion control design, to Ian's ideas about Defenestrator, etc."
There are a couple of subtasks to work on here:
* Review proposal 182 and reword any unclear parts.
* Review any existing patches for proposal 182 and update them for merging them into master.
* Run simulations of proposal 182 using ExperimenTor and Shadow.
* Make a list of designs that are related to proposal 182.
* Compare proposal 182 to related designs.Tor: unspecifiedRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/4506Simulate the N23 design to see how it performs for typical and for really slo...2020-06-13T17:47:13ZKarsten LoesingSimulate the N23 design to see how it performs for typical and for really slow client connectionsThis project ticket has the sole purpose of combining the N23 simulation tickets that are due March 15, 2012. The actual work should take place in the child tickets.This project ticket has the sole purpose of combining the N23 simulation tickets that are due March 15, 2012. The actual work should take place in the child tickets.Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/4490Sensitivity analysis of different ways to sample relay capacity for simulations2020-06-13T17:47:10ZRoger DingledineSensitivity analysis of different ways to sample relay capacity for simulationsSince current Tor simulators can't handle the whole 2500 relays, they end up running simulations on a subset of relays that they hope is representative. Early papers chose their sample by choosing n relays weighted by capacity. Rob and K...Since current Tor simulators can't handle the whole 2500 relays, they end up running simulations on a subset of relays that they hope is representative. Early papers chose their sample by choosing n relays weighted by capacity. Rob and Kevin both found that they could achieve more consistent results by breaking the relays into deciles, and choosing n/10 relays from the "0-10%" bucket, n/10 from the "10-20%" bucket, and so on.
But I suspect that it is not optimal to base these parameter choices on the number of fingers that primates have. In particular, Mike's graphs show that the "0-5%" bucket is quite different from the "5-10%" bucket. So I worry that different runs could see quite different outcomes.
Rob pointed out that if we want to match reality, we'll need to know what load to place on the network -- and even messier, how to scale down that load in a way that matches the scaling down of the relay population.
But I think there's still some good insight to be had here, by looking at how much variation we get for a variety of sampling algorithms for a given set of loads. If the results are consistent for a given set of loads while varying sampling algorithms, that would be a surprising and interesting result. And if the results for a given load change by sampling algorithm, we should get some better intuition about how much they change, and what parameters seem to influence the changes the most.
Alas, the part of this question that makes the number of simulation runs blow up is that we ought to do the tests for a variety of research questions, since maybe some research questions are quite sensitive to changes in capacity distribution and others not so much.
I bet we could get quite a bit of mileage here by just looking at the resulting capacity (and thus probability) distributions of various sampling algorithms, and leaving the "Tor simulation" component out entirely -- since using a full-blown Tor simulator to measure similarity of distribution is a mighty indirect approach.Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/4486Research: should N23 actually help in practice?2020-06-13T17:47:08ZRoger DingledineResearch: should N23 actually help in practice?The N23 design (see http://freehaven.net/anonbib/#pets2011-defenestrator) looked promising based on the ExperimenTor simulations.
What do the Shadow simulations think about it?
What knobs should we expose to be able to tune it in pract...The N23 design (see http://freehaven.net/anonbib/#pets2011-defenestrator) looked promising based on the ExperimenTor simulations.
What do the Shadow simulations think about it?
What knobs should we expose to be able to tune it in practice? What are the recommended initial guesses for those knobs, and how sensitive are our expected performance results to changes in the values, or changes in network load?Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/3276Analyze onion key lifetimes2020-06-13T17:46:55ZKarsten LoesingAnalyze onion key lifetimesOnion keys are supposed to be rotated after 7 days. This ticket is for analyzing the relay descriptor archives whether this is really the case.Onion keys are supposed to be rotated after 7 days. This ticket is for analyzing the relay descriptor archives whether this is really the case.Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/2764analyze security tradeoffs from using a socks proxy vs a bridge to reach the ...2020-06-13T17:46:48ZRoger Dingledineanalyze security tradeoffs from using a socks proxy vs a bridge to reach the Tor networkAt the beginning of the bridge design, we decided to use a building block we'd already written (a "relay") for the proxy step. This strategy gave us several practical advantages:
- The code was already written, so we didn't have to write...At the beginning of the bridge design, we decided to use a building block we'd already written (a "relay") for the proxy step. This strategy gave us several practical advantages:
- The code was already written, so we didn't have to write new proxy programs.
- The packages already exist so we don't have any new portability worries.
- People already have an incentive to install the Tor program, so we'd get more bridges.
- It's easier to extend our code to collect and publish statistics like load, number of users, geoip lookups on the users, etc
- We could reuse the directory authority design to run a bridge authority that does reachability checking, collects bridge descriptors, annotates which ones are Running/Stable/etc, exports them to bridgedb, and so on.
But from a *security* perspective (for a broad definition of security), is there really any difference between a socks proxy and a bridge relay?
One difference is that the socks handshake is in the clear, so if you're asking to connect to a public Tor relay, an observer can see its IP address and realize that you're using socks to reach the Tor network. We could imagine workarounds here where the socks proxy chooses its destination independent of the address you ask for, either by hard-coding a bridge address, hard-coding a public relay address, or round-robining you among several. Depending on which we choose, the Tor client would have to learn to not freak out when it gets the wrong guy on the other end.
Another difference is that the traffic coming into the bridge is crypted differently than the traffic coming out of it (both via link encryption on each side and at a layer underneath that). Are there any adversaries that this traffic rewriting step stymies in any way?
What other considerations am I missing?
(I don't mean to throw away the bridge notion. But -- if it's safe -- I want to supplement it with an alternative, for people who don't want to run a whole Tor bridge, either due to resource constraints (Tor router) or complexity constraints (imagine a flash plugin that proxies incoming traffic to a "real" Tor relay).)Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/1854Investigate raising the minimum bandwidth for getting the Fast flag2020-06-13T17:46:33ZRoger DingledineInvestigate raising the minimum bandwidth for getting the Fast flagMike's performance work has shown that the smaller relays -- for example, the ones that set bandwidthrate and bandwidthburst to 20k -- are never good news to have in your circuit.
Damon McCoy's hotpets 2010 paper showed more details of ...Mike's performance work has shown that the smaller relays -- for example, the ones that set bandwidthrate and bandwidthburst to 20k -- are never good news to have in your circuit.
Damon McCoy's hotpets 2010 paper showed more details of how you could improve performance by dumping the bottom X% of the relays.
Of course, there's a network effect issue here: clearly you get better performance if you're the only one ignoring the slower relays.
But I think there's something to this even when everybody is doing it. Our load balancing makes a 500KB relay 10x more likely to be used than a 50KB relay, but given a whole lot of users building paths, the 50KB relay will get overloaded more often and show worse characteristics when overloaded than the 500KB relay -- in large part because we're load balancing by circuit rather than by byte.
So I'd like to do a series of performance experiments where the directory authorities take away the Fast flag from everybody whose consensus bandwidth is under X.
Ideally we'd do it while the network is under a variety of load conditions (removing capacity from the network when there's a lot of load seems like it would hurt us more, but then, using overloaded relays when there's a lot of load could hurt us a lot too).
This could even be a research task that we try to give to a research group that wants to work on simulated Tor network performance. But I think that's a separate project.
Along with the performance simulations we need to consider the anonymity implications of reducing the diversity of relays. How much anonymity do we lose if we treat anonymity as entropy? How much do we lose if we consider the location-based anonymity metrics of Feamster or Edman? Ideally we'd figure out some way to compare performance and anonymity so we can decide if we like various points in the tradeoff space. Really, we should be working on this piece already to analyze whether Mike's bwauth algorithm is worth it.
Finally, should we consider keeping them in the network if they have nice exit policies?
Relays that are too slow should be encouraged to become bridges. Even better, we should help people recognize when they ought to start out as a bridge rather than trying to be a relay.Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/25751Add Rose Foundation to our Sponsors page2020-06-13T17:26:25ZTommy CollisonAdd Rose Foundation to our Sponsors pageLet's add the Rose Foundation for Communities and the Environment (2017-2018) to https://www.torproject.org/about/sponsors.html.en. They just gave us a general support grant.Let's add the Rose Foundation for Communities and the Environment (2017-2018) to https://www.torproject.org/about/sponsors.html.en. They just gave us a general support grant.Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/5192All awesome projects we love get web pages2020-06-13T17:21:57ZJacob AppelbaumAll awesome projects we love get web pagesThe goal is to show the world what we're actually working on - a lot of projects live in git, some never have a tar.gz release, etc
Atagar knows where the template is for a simple project page.
Off the top of my head:
ooni-probe
getto...The goal is to show the world what we're actually working on - a lot of projects live in git, some never have a tar.gz release, etc
Atagar knows where the template is for a simple project page.
Off the top of my head:
ooni-probe
gettor
thandy
shadowRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/7716Add txtorcon to volunteer (+projects) page2020-06-13T17:20:45ZmeejahAdd txtorcon to volunteer (+projects) pageAs per advice on #tor-dev, I'm filing this to get txtorcon added to the volunteer page (and the projects page, if that's appropriate).
If it's easier, I can do a patch to the Web stuff (it's still in subversion, right?) just comment her...As per advice on #tor-dev, I'm filing this to get txtorcon added to the volunteer page (and the projects page, if that's appropriate).
If it's easier, I can do a patch to the Web stuff (it's still in subversion, right?) just comment here to that effect and I'll attach a patch.
_For the projects page:_
75x75 pixel logo is here: https://raw.github.com/meejah/txtorcon/master/logo/txtorcon-logo-75px.png
## [txtorcon](https://github.com/meejah/txtorcon)
Twisted-based asynchronous Tor control protocol implementation. Includes unit-tests, examples, state-tracking code, slave Tor launching code and configuration abstraction. Useful for anyone writing event-based utilities or applications based around Tor.
_For the volunteer page:_
| name | category | language | activity | contributors |
|------|----------|----------|----------|--------------|
| txtorcon | library | Python, Twisted | moderate | meejah |
## txtorcon ([code](https://github.com/meejah/txtorcon), [docs](https://txtorcon.readthedocs.org))
Twisted-based asynchronous Tor control protocol implementation. Includes unit-tests, examples, state-tracking code and configuration abstraction. Used by OONI and APAF.
Thanks!Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/2111some faq entries duplicated on faq.wml and wikifaq2020-06-13T17:18:41ZRoger Dingledinesome faq entries duplicated on faq.wml and wikifaqLooks like phobos copied some of the text from the faq.wml back onto the wikifaq. Now this text is in two places. When we change one place, we're unlikely to change the other place. Not a stable solution.
My main motivations for moving ...Looks like phobos copied some of the text from the faq.wml back onto the wikifaq. Now this text is in two places. When we change one place, we're unlikely to change the other place. Not a stable solution.
My main motivations for moving things over to faq.wml were a) it can be translated, and b) it can't be scribbled on by wrong people like what happened with https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#I2P
I'm guessing phobos's main motivation for putting the text back is that I don't seem likely to actually finish the transition anytime soon, and he wants a less confusing faq. Is there more to it?Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/2110download page has confusing source code link and no link to TBB instructions2020-06-13T17:18:41ZRoger Dingledinedownload page has confusing source code link and no link to TBB instructionsBug 1: the first "source code" link on the download page is the tarball for TBB, not for Tor. Everybody was reporting that it's a 404 because they were all thinking they were clicking on "get the Tor tarball".
Bug 2: we have some useful...Bug 1: the first "source code" link on the download page is the tarball for TBB, not for Tor. Everybody was reporting that it's a 404 because they were all thinking they were clicking on "get the Tor tarball".
Bug 2: we have some useful videos and screenshots for how to install TBB at https://www.torproject.org/projects/torbrowser but we don't link to them from the download page.
Bug 3: there are translated TBB's out there, but our download page doesn't give you any hint that they exist.
How about we solve all of these at once by changing the 'source code' column to something like "Details / other languages"? Downloading the scripts that build tbb is cool to provide but doesn't need to be on our main download page.Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/33628Add charly to many internal aliases2020-06-13T17:01:18ZRoger DingledineAdd charly to many internal aliasesNow that we have our executive assistant in place (#33611), we should add her to many aliases. Isa identified these:
```
Grants
Comms
Travel
Roger-delegates
Tor-board
tor-exec
speaking
accounting
```Now that we have our executive assistant in place (#33611), we should add her to many aliases. Isa identified these:
```
Grants
Comms
Travel
Roger-delegates
Tor-board
tor-exec
speaking
accounting
```Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/25480Add Tommy to the giving@ email alias2020-06-13T16:54:34ZTommy CollisonAdd Tommy to the giving@ email aliasWe're giving out this email address as part of the current DuckDuckGo fundraising challenge [1]. Tommy can help Jon triage the emails we get as part of the campaign. Jon thinks it's a good idea.
[1] https://www.crowdrise.com/o/en/campai...We're giving out this email address as part of the current DuckDuckGo fundraising challenge [1]. Tommy can help Jon triage the emails we get as part of the campaign. Jon thinks it's a good idea.
[1] https://www.crowdrise.com/o/en/campaign/tor-projectRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/6403Make a Stegotorus trac component?2020-06-13T16:45:52ZRoger DingledineMake a Stegotorus trac component?Zack (and others),
Is now a good time to make a Stegotorus component in Tor's trac? Or do you still prefer keeping your tickets elsewhere?Zack (and others),
Is now a good time to make a Stegotorus component in Tor's trac? Or do you still prefer keeping your tickets elsewhere?Roger DingledineRoger Dingledine