The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:50:06Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30743Write a coccinelle script to catch increment/decrement calls inside log_debug().2020-06-27T13:50:06ZNick MathewsonWrite a coccinelle script to catch increment/decrement calls inside log_debug().See legacy/trac#30628 for motivationSee legacy/trac#30628 for motivationTor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/30048Write a bwfile creation and validation test for chutney2020-07-23T20:48:43ZteorWrite a bwfile creation and validation test for chutneyChutney has a bwfile network, but the user has to create the actual file. And there are no tests.Chutney has a bwfile network, but the user has to create the actual file. And there are no tests.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/1606Write a BridgeDB spec2020-06-27T13:43:36ZAndrew LewmanWrite a BridgeDB specWrite a BridgeDB specWrite a BridgeDB specNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/community/relays/-/issues/10Write a blog post advocating for getting more relays2021-11-24T19:08:48ZcypherpunksWrite a blog post advocating for getting more relaysI'm monitoring numbers of Tor nodes and the numbers are going down.
We need more Tor relay to keep up anonimity.
Why not write a blog about this? More tor relay wanted!I'm monitoring numbers of Tor nodes and the numbers are going down.
We need more Tor relay to keep up anonimity.
Why not write a blog about this? More tor relay wanted!Colin ChildsColin Childshttps://gitlab.torproject.org/tpo/web/blog/-/issues/40070write a blog post about the static mirror system2024-03-14T15:12:02Zanarcatwrite a blog post about the static mirror systemI found [this post](https://alexcabal.com/posts/standard-ebooks-and-classic-web-tech) to be pretty interesting. I wish I could write about some fancy new high-tech system we've built in TPA that's the cutting edge of technology, but the ...I found [this post](https://alexcabal.com/posts/standard-ebooks-and-classic-web-tech) to be pretty interesting. I wish I could write about some fancy new high-tech system we've built in TPA that's the cutting edge of technology, but the reality is that we're a hodgepodge collection of legacy systems we're keeping alive by a wise combination of "if it ain't broken don't fix it" and "okay, this is too horrible, let's fix that tiny piece", migrating one system at a time toward modernity.
The static mirror system is an excellent example of this. When I arrived, it was mostly built from shell servers and... Jenkins, which was hard to use and generally disliked. We migrated to GitLab and built a shim to avoid having to replace the entire system. That handful of servers is pumping out gigabits per second, it's easy to deploy and scale out (although *that* could be made easier).
This is mostly summarizing and glorifying the docs I've already written in the [service docs](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/static-component/).
This would be, therefore, an interesting blog post on its own, but I think it could also serve as great advertisement for the job posting (tpo/tpa/team#41542).anarcatanarcathttps://gitlab.torproject.org/tpo/tpa/team/-/issues/41553write a blog post about the static mirror system2024-03-11T17:06:03Zanarcatwrite a blog post about the static mirror systemI found [this post](https://alexcabal.com/posts/standard-ebooks-and-classic-web-tech) to be pretty interesting. I wish I could write about some fancy new high-tech system we've built in TPA that's the cutting edge of technology, but the ...I found [this post](https://alexcabal.com/posts/standard-ebooks-and-classic-web-tech) to be pretty interesting. I wish I could write about some fancy new high-tech system we've built in TPA that's the cutting edge of technology, but the reality is that we're a hodgepodge collection of legacy systems we're keeping alive by a wise combination of "if it ain't broken don't fix it" and "okay, this is too horrible, let's fix that tiny piece", migrating one system at a time toward modernity.
The static mirror system is an excellent example of this. When I arrived, it was mostly built from shell servers and... Jenkins, which was hard to use and generally disliked. We migrated to GitLab and built a shim to avoid having to replace the entire system. That handful of servers is pumping out gigabits per second, it's easy to deploy and scale out (although *that* could be made easier).
This is mostly summarizing and glorifying the docs I've already written in the [service docs](https://gitlab.torproject.org/tpo/tpa/team/-/wikis/howto/static-component/).
This would be, therefore, an interesting blog post on its own, but I think it could also serve as great advertisement for the job posting (tpo/tpa/team#41542).anarcatanarcathttps://gitlab.torproject.org/tpo/network-health/team/-/issues/174Write a blog post about bad-relay work, where we came from/where we are/what ...2022-04-26T06:21:08ZGeorg KoppenWrite a blog post about bad-relay work, where we came from/where we are/what plans we haveWe should write a blog post about the state of our bad-relay work which could be a good context for touching the [big non-exit attacker we kicked out at the end of last year](https://lists.torproject.org/pipermail/tor-relays/2021-Novembe...We should write a blog post about the state of our bad-relay work which could be a good context for touching the [big non-exit attacker we kicked out at the end of last year](https://lists.torproject.org/pipermail/tor-relays/2021-November/019980.html).
I imagine talking about where we came from with our bad-relay work, where we currently are after the network health team got created and what blockers/plans are (we should point to our metrics tooling revamp, too, in particular to tpo/network-health/metrics/collector#40012).Network Health OKRs 2022 Q1-Q2 (Metrics excluded)Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8948Write a "code review guidelines" page2021-07-22T16:26:02ZNick MathewsonWrite a "code review guidelines" pageCheck out this awesome page that Twisted has:
https://twistedmatrix.com/trac/wiki/ReviewProcess
We should totally get one like it to give people a checklist of what to do when they're coding.Check out this awesome page that Twisted has:
https://twistedmatrix.com/trac/wiki/ReviewProcess
We should totally get one like it to give people a checklist of what to do when they're coding.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29219Write (more) guidelines for Tor coding best practices2021-07-22T16:19:43ZNick MathewsonWrite (more) guidelines for Tor coding best practicesWe should extend our best practices guidelines in doc/HACKING with all/most of the following:
* Avoiding layer violations
* Fewer levels of block nesting
* Small functions
* Small files
* Few includes per file
* Smaller state obje...We should extend our best practices guidelines in doc/HACKING with all/most of the following:
* Avoiding layer violations
* Fewer levels of block nesting
* Small functions
* Small files
* Few includes per file
* Smaller state objects
* Making new features compile-time optional modules
* incremental implementation and testing
* Fewer branches
* Fewer callers/callees per function
* "Leave it better than you find it"
* Well-bounded modules
* Fewer data dependencies
Some of these can be quantified; the ones that can be should have targets.
I'm putting an optimistically low time estimate on this one under the assumption that we will have only minimal debate. :)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19459Write (C++) patch for window resizing parts2020-06-27T14:39:00ZGeorg KoppenWrite (C++) patch for window resizing partsResizing the window to multiples of 200x100 on start-up is one of the features in Torbutton we should get out of it and into Firefox. Getting away from the constraints if extension JS code might give us the means to finally solve this pr...Resizing the window to multiples of 200x100 on start-up is one of the features in Torbutton we should get out of it and into Firefox. Getting away from the constraints if extension JS code might give us the means to finally solve this properly.Arthur EdelsteinArthur Edelsteinhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7106Write "how to be nice to the Tor network" spec2022-03-17T19:42:18ZRoger DingledineWrite "how to be nice to the Tor network" specIn talking to Jake, I realized that there are still some people who expect jtor to be a workable Tor client one day. In fact, we've even been writing some funding proposals that make this assumption.
One of the main issues we're going t...In talking to Jake, I realized that there are still some people who expect jtor to be a workable Tor client one day. In fact, we've even been writing some funding proposals that make this assumption.
One of the main issues we're going to have with an alternate Tor client is that while it may follow our network specs, it will have different observable behavior than the mainline Tor client.
First, this different behavior will make users partitionable. Fine, we can accept that. But we should finish writing path-spec.txt so authors of other clients can have at least a chance of doing things the way "real" Tor does.
Second, it's easy to make client-side decisions that harm the Tor network. For examples, you can hold your TLS connections open too long, or do too many TLS connections, or make circuits too often, or ask the directory authorities for everything. We need to write up a spec to clarify how well-behaving Tor clients should do things. Maybe that means we write up some principles along the way, or maybe we just identify every design point that matters and say what to do for each of them.https://gitlab.torproject.org/tpo/network-health/team/-/issues/12Write "expectations for relay operators" document2021-04-06T11:53:00ZRoger DingledineWrite "expectations for relay operators" documentMotivated by tpo/web/community#165, we could really use a document for relay operators which sets our expectations for what it means to run a relay properly.
This document would be the mirror image of #11, which as I understand it would...Motivated by tpo/web/community#165, we could really use a document for relay operators which sets our expectations for what it means to run a relay properly.
This document would be the mirror image of #11, which as I understand it would be the guidelines for the bad-relays team on when a relay should no longer be permitted in the network.
The goal is to make it clear what we expect of relay operators, rather than leaving it implicit.
And with that preface, here is my first draft of five sections of a relay expectations document:
1. Keep users safe:
* Don't look at, or modify, network traffic.
* Don't reveal user or destination IP addresses, or the timing or volume of connections.
* By default (e.g. unless you are debugging a specific thing), log at loglevel "notice", and leave SafeLogging on.
* If you run more than one relay, set the MyFamily option for each of them, to instruct clients to avoid using more than one in a circuit, and to help the network health team know which relays are really yours.
* Don't modify your Tor process to examine internal state. In particular, don't record v2 onion addresses.
* If you want to measure or study the Tor network, do it safely: write up your plan first and get feedback from the Tor Research Safety Board: https://research.torproject.org/safetyboard/
2. Maintain good system op-sec:
* Run a version of Tor that is supported. You can see supported versions on this table: https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorReleases
* Watch your Tor logs for warnings and try to address them.
* Make sure to keep the rest of your system software up to date too.
* Try not to let the cops get your relay keys, but if they do, make sure we learn about it so we can block those keys from the network.
3. Make sure your relay isn't broken:
* Tor relays need 10000+ file descriptors, so be sure your Tor package or startup script is raising your ulimit -n.
* Don't firewall outgoing connections. Tor relays need to be able to reach all other Tor relays, including new ones that are self-testing their reachability.
* Exit relays need a working DNS resolver. Also, don't use a DNS resolver that censors its answers.
* If there's a port or address block that your exit relay can't reach, be sure to reject it in your ExitPolicy, so clients can know to use a different exit.
4. Sustainability:
* Don't try to run an exit relay at a place where you plan to just discard it and move on if the ISP complains to you. Running an exit relay involves advocacy to your ISP, to help them understand how Tor works and why it's important.
* If somebody tries to get you to backdoor or tap your relay, don't do it. Find a lawyer and fight it, and if you can't fight it, shut the relay down instead.
5. Be a part of our community:
* Remember that running a relay is an act of transparency (even though being a Tor *user* is an act of privacy), because the way to strengthen trust in relays is by having a stronger community.
* Make an effort to meet other relay operators and developers in your area and at conferences and meetups.
* Be sure to set your ContactInfo to a working address in case we need to reach you.
* Running a relay is great because it helps to make Tor users safer. Please make sure you're not undermining Tor or Tor user safety in your other activities. For example, if your other hobby is developing DPI tools for Palantir, or making people fear or hate privacy tools, please do not also run a Tor relay.
* Read our social contract and the other community documents: https://gitweb.torproject.org/community/policies.git/tree/
If there is a question about whether you or your relay are following the expectations laid out here, these are the documents we will be using to guide our choices.GusGushttps://gitlab.torproject.org/tpo/onion-services/onionmine/-/issues/18Wrapper for all scripts2022-05-17T21:22:24ZSilvio RhattoWrapper for all scriptsCreate the `onionmine` command, a wrapper for all scripts as an alternative to using the `Makefile` for everything.Create the `onionmine` command, a wrapper for all scripts as an alternative to using the `Makefile` for everything.Silvio RhattoSilvio Rhattohttps://gitlab.torproject.org/tpo/core/tor/-/issues/25067Wrap types in protover.rs2020-06-27T13:54:17ZTracWrap types in protover.rsIntroduce new wrapper types:
- `SupportedProtocols`
- `Versions`
Introduce a type alias:
- `Version` (`u32`)
git branch: https://github.com/frewsxcv/tor/compare/master...frewsxcv-protover
Patch for https://trac.torproject.org/projec...Introduce new wrapper types:
- `SupportedProtocols`
- `Versions`
Introduce a type alias:
- `Version` (`u32`)
git branch: https://github.com/frewsxcv/tor/compare/master...frewsxcv-protover
Patch for https://trac.torproject.org/projects/tor/ticket/24030
**Trac**:
**Username**: frewsxcvTor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24030Wrap types in protover.rs2020-06-27T13:55:10ZNick MathewsonWrap types in protover.rsOur rust protover implementation throws around HashSet and HashMap with wild abandon. We should probably wrap those types in struct declarations, to make the intent more clear.Our rust protover implementation throws around HashSet and HashMap with wild abandon. We should probably wrap those types in struct declarations, to make the intent more clear.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/onionmasq/-/issues/17Wrap the protect(int) function via JNI2023-01-23T10:02:35ZAlexander Færøyahf@torproject.orgWrap the protect(int) function via JNIFrom Onionmasq, we need a way to call the Java function protect() on our guard connection to ensure it does not get tracked by the VPN state machine on Android.From Onionmasq, we need a way to call the Java function protect() on our guard connection to ensure it does not get tracked by the VPN state machine on Android.Onionmasq 1.0.0: Initial releaseankitgusai19ankitgusai19https://gitlab.torproject.org/tpo/core/tor/-/issues/31921Wrap our Travis commands with travis_retry, to mitigate network timeouts2021-02-05T21:03:36ZteorWrap our Travis commands with travis_retry, to mitigate network timeoutsIf we see a lot of timeouts, we should start putting travis_retry before all our network commands:
https://docs.travis-ci.com/user/common-build-problems/#travis_retryIf we see a lot of timeouts, we should start putting travis_retry before all our network commands:
https://docs.travis-ci.com/user/common-build-problems/#travis_retryTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24659Wrap our sha2 interface in Rust which implements the appropriate traits2020-06-27T13:54:39ZIsis LovecruftWrap our sha2 interface in Rust which implements the appropriate traitsWe should wrap our usage of hash digest functions (and XOFs) in Rust types which implement the appropriate traits, yet still exposes the same API functionality we currently have in C. To keep this task small, I think we should start off ...We should wrap our usage of hash digest functions (and XOFs) in Rust types which implement the appropriate traits, yet still exposes the same API functionality we currently have in C. To keep this task small, I think we should start off with just the sha2 code for now. (Later, it's probably some copy-paste and a bit of refactoring to provide the same interface for other digests, and similar for XOFs.)
This ticket is probably slightly blocked on legacy/trac#24658, and in turn is blocking legacy/trac#23886.Tor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/core/tor/-/issues/24660Wrap our PRNG interface(s) in Rust with appropriate traits2020-06-27T13:54:39ZIsis LovecruftWrap our PRNG interface(s) in Rust with appropriate traitsSimilar to legacy/trac#24659, we should provide a way to wrap our C code for getting randomness in Rust, while implementing the appropriate traits (from `rand`) so that we're able to switch in Rust implementations if we want later.
This...Similar to legacy/trac#24659, we should provide a way to wrap our C code for getting randomness in Rust, while implementing the appropriate traits (from `rand`) so that we're able to switch in Rust implementations if we want later.
This is also blocking legacy/trac#23886.Tor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/22440wrap long lines not working in view source mode in TBB2020-06-27T14:37:33ZTracwrap long lines not working in view source mode in TBBWhen chosing CTRL-U / View Page Source in Tor Browser Bundle 6.5.2, and enableing Wrap Long Lines, the long lines do not wrap -- you have to scroll to the right.
Works OK with regular firefox
**Trac**:
**Username**: gapegas7uftpWhen chosing CTRL-U / View Page Source in Tor Browser Bundle 6.5.2, and enableing Wrap Long Lines, the long lines do not wrap -- you have to scroll to the right.
Works OK with regular firefox
**Trac**:
**Username**: gapegas7uftp