Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2021-12-13T20:37:24Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/23126HSDirs should publish some count about new-style onion addresses (v3 metrics)2021-12-13T20:37:24ZRoger DingledineHSDirs should publish some count about new-style onion addresses (v3 metrics)Right now we have an ongoing estimate of the total number of onion addresses published to the HSDirs:
https://metrics.torproject.org/hidserv-dir-onions-seen.html
How many of those are 224-style onion addresses, and how many of them are ...Right now we have an ongoing estimate of the total number of onion addresses published to the HSDirs:
https://metrics.torproject.org/hidserv-dir-onions-seen.html
How many of those are 224-style onion addresses, and how many of them are legacy-style onion addresses?
I see a `rep_hist_stored_maybe_new_hs()` for the v2-style descriptors, and I think I see a
```
/* XXX: Update HS statistics. We should have specific stats for v3. */
```
for the v3-style descriptors.
So I think that means that the graph is only showing v2-style onions, and we have no infrastructure for noticing trends with v3 style onions.
I also suspect that noticing trends is harder with v3-style onions, since each descriptor the hsdir sees is standalone, and it's not possible (without knowing the onion address) to link two descriptors to the same address.
So our only chance at estimating total number of v3 onion addresses is to know the publishing habits of v3 style onion services (how many descriptors per how much time period), and then publish the total number of descriptors we see, and folks can do some math afterwards to estimate number of running services? In any case we can see if the number goes up or down over time.
Or maybe there is some even better design? :)
The reason I bring it up now is (a) if we want to get any code into relays, we need to do it sufficiently before we need it, so it can get rolled out, and (b) I see discussions about bugs with v3-style onion services publishing every 2 minutes, and while we're fixing those we should keep in mind how handy it would be to be able to predict how many descriptors a new onion service will publish per time period on average.Tor: 0.4.5.x-stableGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/33389Disable routerkeys.c and part of connection_or.c when building without relay ...2020-06-27T13:48:10ZNick MathewsonDisable routerkeys.c and part of connection_or.c when building without relay mode.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33370Don't build selftest.c when relay mode is disabled2020-06-27T13:48:11ZNick MathewsonDon't build selftest.c when relay mode is disabledTor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33368Don't compile ext_orport.c when relay mode is disabled.2020-06-27T13:48:11ZNick MathewsonDon't compile ext_orport.c when relay mode is disabled.Tor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33366Disable dns.c when relay mode is disabled2020-06-27T13:48:12ZNick MathewsonDisable dns.c when relay mode is disabledTor: 0.4.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18346Separate the various roles that directory authorities play, from a configurat...2022-10-11T23:40:17ZNick MathewsonSeparate the various roles that directory authorities play, from a configuration POVIt would be handy if the following roles were split up:
1) The list of IP:Orport:Identity to which every relay should upload every descriptor.
2) The list of IP:Orport:Identity from which caches should expect to find canonical conse...It would be handy if the following roles were split up:
1) The list of IP:Orport:Identity to which every relay should upload every descriptor.
2) The list of IP:Orport:Identity from which caches should expect to find canonical consensuses and descriptors.
3) The list of IP:Orport:Identity from which non-caches should expect to bootstrap consensuses and descriptors. (See 'fallbackdir')
4) The list of keys that must sign a vote or a consensus.
5) The list of IP:Orport:Identity that authorities use when sending and receiving votes.
Splitting roles up in this way would better prepare us for an implementation of prop#257 down the road.Tor: 0.4.7.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/4700Tor should provide a mechanism for hidden services to differentiate authorize...2020-06-27T14:07:09ZTracTor should provide a mechanism for hidden services to differentiate authorized clients and circuitsTor allows a hidden service to require that clients provide a secret key prior to connecting. Even though hidden services support the use of multiple keys, information mapping the key specified to the specific connection is never exporte...Tor allows a hidden service to require that clients provide a secret key prior to connecting. Even though hidden services support the use of multiple keys, information mapping the key specified to the specific connection is never exported.
**Trac**:
**Username**: katmagicTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33844Do next iteration of HS-DoS proposal by folding in comments from dgoulet/mike2022-10-11T23:39:35ZGeorge KadianakisDo next iteration of HS-DoS proposal by folding in comments from dgoulet/mikeThis is just a ticket to track progress: making the next iteration of the proposal based on dgoulet/mike comments is the next step here.This is just a ticket to track progress: making the next iteration of the proposal based on dgoulet/mike comments is the next step here.https://gitlab.torproject.org/tpo/core/tor/-/issues/33843Write detailed priority queue scheduler design on the proposal2022-10-11T23:39:34ZGeorge KadianakisWrite detailed priority queue scheduler design on the proposalTor: unspecifiedDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33712Design a PoW scheme for HS DoS defence2022-10-11T23:39:34ZGeorge KadianakisDesign a PoW scheme for HS DoS defenceSome initial research has been done on comment:13:ticket:31223 to sketch out a PoW/credential scheme that works for HS DoS defence.
This ticket is to continue scheming and working on this design.
See https://lists.torproject.org/piperm...Some initial research has been done on comment:13:ticket:31223 to sketch out a PoW/credential scheme that works for HS DoS defence.
This ticket is to continue scheming and working on this design.
See https://lists.torproject.org/pipermail/tor-dev/2020-April/014215.html for initial proposal.https://gitlab.torproject.org/tpo/core/tor/-/issues/33650Verify that intro2 cell extensions actually work2022-10-11T23:39:34ZRoger DingledineVerify that intro2 cell extensions actually workIn the future we're going to want to transport end-to-end tokens, proofs of work, or other blobs from client to onion service. We should make sure that we can actually add these into the cells without anything going wrong, like surprisin...In the future we're going to want to transport end-to-end tokens, proofs of work, or other blobs from client to onion service. We should make sure that we can actually add these into the cells without anything going wrong, like surprising asserts or surprising length enforcement.
(Now is the time to notice if things will go wrong, so we can fix them and deploy that fix, and then people will have upgraded by the time we're ready to actually use them.)
So: let's make a branch that adds "hi mom" on the client side, and reads it out again on the service side.
In spelunking through the code and the spec, I found that modern intro2 cells have an "extensions" field inside their encrypted component, which seems perfectly suited for transporting arbitrary blobs from client to service. Here's how we set it currently on the client side:
```
/* Set extension data. None are used. */
ext = trn_cell_extension_new();
tor_assert(ext);
trn_cell_extension_set_num(ext, 0);
trn_cell_introduce_encrypted_set_extensions(enc_cell, ext);
```
So that 0 needs to become a 1, and then we need something new that makes and sets a new extension in ext (modeled maybe on `build_establish_intro_dos_extension()`, and something on the receiving end that invokes trn_cell_extension_parse() and reads it out to us.
I am optimistic, because this thing is encrypted, so the intro point in the middle can't be looking at it very carefully. But if we have bugs on the client side or the service side, or surprise length enforcement in the middle, now is a great time to notice and fix them.Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33414Split router.c, and disable it (mostly) when building without relay support.2022-06-24T14:52:17ZNick MathewsonSplit router.c, and disable it (mostly) when building without relay support.The last _big_ piece of code in feature/relay that we want to turn off when --disable-module-relay is set is `router.c`.The last _big_ piece of code in feature/relay that we want to turn off when --disable-module-relay is set is `router.c`.https://gitlab.torproject.org/tpo/core/tor/-/issues/33102Do an updated version of "top changes since 2004 paper"?2020-07-29T14:30:20ZRoger DingledineDo an updated version of "top changes since 2004 paper"?Periodically I find myself pointing professors to the three blog posts, "top changes since the 2004 design paper", when they are wanting to put the original Tor paper on their seminar class's reading syllabus:
https://blog.torproject.org...Periodically I find myself pointing professors to the three blog posts, "top changes since the 2004 design paper", when they are wanting to put the original Tor paper on their seminar class's reading syllabus:
https://blog.torproject.org/top-changes-tor-2004-design-paper-part-1
https://blog.torproject.org/top-changes-tor-2004-design-paper-part-2
https://blog.torproject.org/top-changes-tor-2004-design-paper-part-3
Those were posted in 2012, so 8 years after the original paper. Now here we are 8 years later.
It would be keen to do another round of those posts, or an update to all of them, or something.https://gitlab.torproject.org/tpo/core/tor/-/issues/32813Move V3BandwidthsFile into feature/dirauth module2020-07-29T14:21:26ZNick MathewsonMove V3BandwidthsFile into feature/dirauth moduleThis change will take some code movement, because the option is also used in dircache.c.This change will take some code movement, because the option is also used in dircache.c.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32807Mark TestingEstimatedDescriptorPropagationTime as OBSOLETE.2020-06-27T13:48:36ZNick MathewsonMark TestingEstimatedDescriptorPropagationTime as OBSOLETE.This option doesn't actually do anything, and hasn't done anything since 0.3.0.This option doesn't actually do anything, and hasn't done anything since 0.3.0.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32806Move "easy" dirauth-only options to dirauth module2020-06-27T13:48:36ZNick MathewsonMove "easy" dirauth-only options to dirauth moduleFor this ticket, I'll be moving all of the easy, simple dirauth configuration options to the appropriate module.
I'm defining options as "easy" if they aren't currently used anywhere outside the dirauth module, the config module, and th...For this ticket, I'll be moving all of the easy, simple dirauth configuration options to the appropriate module.
I'm defining options as "easy" if they aren't currently used anywhere outside the dirauth module, the config module, and the tests.
For other dirauth-only options, I'll want to do some refactoring first.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32490Phase 1: Stop compiling "Listening for OR and Dir connections " in --disable-...2021-11-06T13:23:28ZteorPhase 1: Stop compiling "Listening for OR and Dir connections " in --disable-module-relayWe want to stop compiling the code that makes tor listen for OR and Dir connections, when the relay module is disabled.
(We already disable ORPort and DirPort, so the functionality is not available.)
At each stage, we should work to mi...We want to stop compiling the code that makes tor listen for OR and Dir connections, when the relay module is disabled.
(We already disable ORPort and DirPort, so the functionality is not available.)
At each stage, we should work to minimize layer-violations: there should generally not be calls from src/core/ into relay-specific code, and we should plan to refactor as needed to minimize them. We can reduce layer violations in parallel with the above.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32489Phase 1: Stop compiling "Responding to BEGIN cells" in --disable-module-relay2021-11-06T13:23:25ZteorPhase 1: Stop compiling "Responding to BEGIN cells" in --disable-module-relayWe want to stop compiling the code that makes tor respond to BEGIN cells, when the relay module is disabled.
(We already disable ORPort, so the functionality is not available.)
At each stage, we should work to minimize layer-violations...We want to stop compiling the code that makes tor respond to BEGIN cells, when the relay module is disabled.
(We already disable ORPort, so the functionality is not available.)
At each stage, we should work to minimize layer-violations: there should generally not be calls from src/core/ into relay-specific code, and we should plan to refactor as needed to minimize them. We can reduce layer violations in parallel with the above.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32488Phase 1: Stop compiling "Responding to CREATE and EXTEND cells" in --disable-...2021-11-06T13:23:21ZteorPhase 1: Stop compiling "Responding to CREATE and EXTEND cells" in --disable-module-relayWe want to stop compiling the code that makes tor respond to CREATE and EXTEND cells, when the relay module is disabled.
(We already disable ORPort, so the functionality is not available.)
At each stage, we should work to minimize laye...We want to stop compiling the code that makes tor respond to CREATE and EXTEND cells, when the relay module is disabled.
(We already disable ORPort, so the functionality is not available.)
At each stage, we should work to minimize layer-violations: there should generally not be calls from src/core/ into relay-specific code, and we should plan to refactor as needed to minimize them. We can reduce layer violations in parallel with the above.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/32487Phase 1: Stop compiling "acting as a directory cache" in --disable-module-relay2020-06-27T13:48:50ZteorPhase 1: Stop compiling "acting as a directory cache" in --disable-module-relayWe want to stop compiling the code that makes tor act as a directory cache, when the relay module is disabled.
(We already disable DirPort and DirCache, so the functionality is not available.)
At each stage, we should work to minimize ...We want to stop compiling the code that makes tor act as a directory cache, when the relay module is disabled.
(We already disable DirPort and DirCache, so the functionality is not available.)
At each stage, we should work to minimize layer-violations: there should generally not be calls from src/core/ into relay-specific code, and we should plan to refactor as needed to minimize them. We can reduce layer violations in parallel with the above.Tor: 0.4.3.x-finalNick MathewsonNick Mathewson