Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2023-09-15T11:40:49Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33371Build only with required libevent2 libraries2023-09-15T11:40:49ZNick MathewsonBuild only with required libevent2 librariesWe should only need libevent_core and libevent_extra.We should only need libevent_core and libevent_extra.https://gitlab.torproject.org/tpo/core/tor/-/issues/1938UpdateBridgesFromAuthority dangerous2023-05-23T20:45:59ZRoger DingledineUpdateBridgesFromAuthority dangerousNow that we've fixed legacy/trac#1138, it might be tempting to start distributing identity fingerprints along with our bridge addresses again, so clients can try the bridge authority for the descriptor.
In retrospect, though, the plan o...Now that we've fixed legacy/trac#1138, it might be tempting to start distributing identity fingerprints along with our bridge addresses again, so clients can try the bridge authority for the descriptor.
In retrospect, though, the plan of "first go to the centralized place that is easily associated with being a Tor bridge user, then if it's unreachable go directly to the bridge for its descriptor" is unwise.
In practice we should go to our bridges directly for their descriptor, and if we learn no descriptors, fail closed. Then, for the bridges that we've configured but didn't get a descriptor for, we can ask the bridge authority *via Tor* if it happens to know a newer descriptor for them.
We'll have an opportunity to make things more robust once we get going on legacy/trac#1852.
In the mean time, we should continue to avoid putting fingerprints on bridge addresses. (I believe Vidalia still sets UpdateBridgesFromAuthority for you when you configure a bridge.)Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30477Tor should self-test reachability of TCP listeners exposed by PT's2023-05-10T17:27:06ZAlexander Færøyahf@torproject.orgTor should self-test reachability of TCP listeners exposed by PT'sIt would be useful if Tor would do self-test of TCP port reachability for bridge listeners and not just the ORPort itself.
Currently when a bridge operator starts their Bridge Relay, Tor will test whether their ORPort is available from ...It would be useful if Tor would do self-test of TCP port reachability for bridge listeners and not just the ORPort itself.
Currently when a bridge operator starts their Bridge Relay, Tor will test whether their ORPort is available from the internet, but we do not test the reachability of, for example, the obfs4 TCP port.
We believe that *just* testing for whether the port is available to the internet is better than to actually test if the port, for example, is able to speak the obfs4 protocol.
We should probably have a way to disable the warning that is emitted if a port is not reachable if, for example, the bridge is actually lying to Tor about its port, does not have a port, or the port is exposed via UDP instead of TCP.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/6676Nuke ‘MyFamily’2023-01-19T15:33:20ZRobert RansomNuke ‘MyFamily’For reasons discussed in legacy/trac#5565, the ‘MyFamily’ option should go away:
* It is probably harmful for clients to refuse to use two relays operated by the same honest entity, and malicious relay operators will not use MyFamily h...For reasons discussed in legacy/trac#5565, the ‘MyFamily’ option should go away:
* It is probably harmful for clients to refuse to use two relays operated by the same honest entity, and malicious relay operators will not use MyFamily honestly.
* Honest relay operators have a hard time setting MyFamily correctly on all of their relays.
* Relay family information bloats up microdescriptors, likely for no benefit.
* Groups of relays operated by the same entity can be recognized tolerably well (e.g. for metrics purposes) using their ContactInfo string instead (modulo the possible need for fuzzy matching of some sort).
This change requires (assuming I didn't forget anything):
* a proposal, spec change, and consensus method to remove relay family information from microdescriptors;
* a corresponding code change for Tor dirauths;
* a code change to clients to make them ignore relay family information (if they receive it, e.g. by turning off UseMicrodescriptors) by default, and warn if the user tries to re-enable use of relay family information without disabling UseMicrodescriptors.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/15251Make tor support starting with 10.000 Tor Hidden Service2022-10-11T23:40:45ZnaifMake tor support starting with 10.000 Tor Hidden ServiceThis ticket is to make Tor support loading and managing 10.000 Tor Hidden services .
Today when you pre-create 10.000 Tor Hidden Service and start Tor, very weird things happen and, basically, it does not work.
This ticket is to analyz...This ticket is to make Tor support loading and managing 10.000 Tor Hidden services .
Today when you pre-create 10.000 Tor Hidden Service and start Tor, very weird things happen and, basically, it does not work.
This ticket is to analyze and address all the issues related in supporting a Tor instance that load, expose and publish 10.000 Tor Hidden Service descriptors.
This ticket, for testing/experimentation, could make use of functionality described at legacy/trac#6411 .
This ticket is required for implementation of OnionFlare service within Tor2web project https://github.com/globaleaks/Tor2web/issues/228 .Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19377Consider retry/backoff behavior when building new circuits2022-10-11T23:40:19ZAndrea ShepardConsider retry/backoff behavior when building new circuitsRetrying connections is the wrong level of abstraction at which to think about circuit failure behavior IMO (see comment on legacy/trac#15942); we should consider whether, as a client or an HS, we're ever doing anything like repeatedly r...Retrying connections is the wrong level of abstraction at which to think about circuit failure behavior IMO (see comment on legacy/trac#15942); we should consider whether, as a client or an HS, we're ever doing anything like repeatedly retrying to build a circuit without smart backoff behavior for the sake of DoS resistance though.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19306Write a proposal for removing liveness-testing from dirauths.2022-10-11T23:40:19ZNick MathewsonWrite a proposal for removing liveness-testing from dirauths.https://gitlab.torproject.org/tpo/core/tor/-/issues/19305Write a proposal for separating "upload descriptors here" from the rest of wh...2022-10-11T23:40:18ZNick MathewsonWrite a proposal for separating "upload descriptors here" from the rest of what dirauths do.https://gitlab.torproject.org/tpo/core/tor/-/issues/19304Write a proposal for having dirauths push to fallbacks, rather than pull.2022-10-11T23:40:18ZNick MathewsonWrite a proposal for having dirauths push to fallbacks, rather than pull.This will require some kind of chatter mechanism for fallbacks to circulate documents.This will require some kind of chatter mechanism for fallbacks to circulate documents.https://gitlab.torproject.org/tpo/core/tor/-/issues/18645Replace our http parser with something machine-generated2022-10-11T23:40:18ZNick MathewsonReplace our http parser with something machine-generatedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18644Replace our routerparse.c core with something machine-generated2022-10-11T23:40:18ZNick MathewsonReplace our routerparse.c core with something machine-generatedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18638Write a proposal for PK handshake that uses more client resources than server.2022-10-11T23:40:18ZNick MathewsonWrite a proposal for PK handshake that uses more client resources than server.Our current handshakes (TLS, TAP, ntor, and ) all have resource asymmetries: a client can send junk with very little effort, and thereby cause a server to spend more CPU. We could instead look for ways to make sure that a client cannot ...Our current handshakes (TLS, TAP, ntor, and ) all have resource asymmetries: a client can send junk with very little effort, and thereby cause a server to spend more CPU. We could instead look for ways to make sure that a client cannot force servers to spend X resources without themselves spending something in vicinity of X resources.https://gitlab.torproject.org/tpo/core/tor/-/issues/25095Update dir-spec.txt with recent consensus param additions2022-10-11T23:40:03ZRoger DingledineUpdate dir-spec.txt with recent consensus param additionsWe have a section in dir-spec.txt that tries to describe the possible consensus parameters, and their ranges, and their meanings.
We just added a bunch of new ones in legacy/trac#24902. And maybe we missed a few recently, like hs_servic...We have a section in dir-spec.txt that tries to describe the possible consensus parameters, and their ranges, and their meanings.
We just added a bunch of new ones in legacy/trac#24902. And maybe we missed a few recently, like hs_service_max_rdv_failures.
We should patch dir-spec.txt to specify all of them.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33894make (retroactive) proposal for DoS subsystem2022-10-11T23:39:35ZRoger Dingledinemake (retroactive) proposal for DoS subsystemIn legacy/trac#24902, dgoulet speaks of a ddos-design.txt document.
But there is no actual proposal for the overall DoS subsystem.
If we have the document around, and we just never published it, this is a great chance to notice, clean ...In legacy/trac#24902, dgoulet speaks of a ddos-design.txt document.
But there is no actual proposal for the overall DoS subsystem.
If we have the document around, and we just never published it, this is a great chance to notice, clean it up a bit, and call it proposal three-hundred-and-something. (And then maybe turn some of it into one of the spec files if that makes sense, but, one step at a time here. :)
Motivated by this month's tor-dev thread where all we have to show for the DoS subsystem design is a trac ticket number and a changelog entry.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/21814Reduce binary size for client-only tor2022-07-26T15:16:35ZArthur EdelsteinReduce binary size for client-only torUncompressed, the Tor executable and associated libs as bundled in Tor Browser is 7.7 MB. If we want other browsers to adopt Tor, it would be good to make it a lot smaller if possible. What is responsible for the bulk? Can we cut out unu...Uncompressed, the Tor executable and associated libs as bundled in Tor Browser is 7.7 MB. If we want other browsers to adopt Tor, it would be good to make it a lot smaller if possible. What is responsible for the bulk? Can we cut out unused code from libcrypto and other libraries? Or can we reuse some shared libraries from the browser? Would it help to chop out unused code that implements relays, hidden services, etc.?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17275Package directory authority scripts for debian in compliant packages2022-06-24T14:36:55ZNick MathewsonPackage directory authority scripts for debian in compliant packagesIn order to reduce the difficulty of being an authority, we should make (compliant) packages for the scripts that we hope authorities will run. This will (ideally) improve the code quality and usability of these scripts.
The scripts in...In order to reduce the difficulty of being an authority, we should make (compliant) packages for the scripts that we hope authorities will run. This will (ideally) improve the code quality and usability of these scripts.
The scripts include:
* guard fraction
* bandwidth authority
* bad exit finder
* probably more!https://gitlab.torproject.org/tpo/core/tor/-/issues/24468Measure HSDir usage to guide parameter choices2022-06-17T18:35:31ZteorMeasure HSDir usage to guide parameter choicesSplit off legacy/trac#24425:
Replying to [ticket:24425#comment:5 asn]:
> Replying to [ticket:24425#comment:4 teor]:
> > If you write down a list of exactly what you want to know, we can probably collect some stats on ~18 HSDirs using Pr...Split off legacy/trac#24425:
Replying to [ticket:24425#comment:5 asn]:
> Replying to [ticket:24425#comment:4 teor]:
> > If you write down a list of exactly what you want to know, we can probably collect some stats on ~18 HSDirs using PrivCount.
> ...
> here are some basic ideas:
>
> - How many v2/v3/both descs per HSDir?
How is this different to "rate of incoming"?
If you mean "cached right now", then I'd need a timeframe so I could design an event. I could do this in December or January.
> - How much total RAM do all v2/v3/both descs occupy on your hsdirs? (max,min,avg,mean over your 18 hsdirs)
I think we have some of the data, but I'd need a list of the objects that contribute to RAM usage. Do you just want descriptors, or is there a replay cache? I could do this in December or January.
> - Size variance of v2/v3 descs? (max,min,avg,mean)
Already implemented as a histogram, needs defined bin sizes.
> - What's the rate of incoming v2/v3/both descs?
Already implemented, needs a time period.
> - How many failed requests for HS descriptors over time? (percentage over total requests?)
I'm going to implement this in December.
> These are just the obvious stats that I came up with. We can come up with more stuff as we see some results and understand the space better.
>
> Let me know if you need help in turning the above sentences into methodologies.
>
> > We will also need an estimate of how much 1 client / service would contribute to each statistic in 10 minutes.
> >
>
> Is that to figure out the noise for differential privacy? Let's try to come up with the final stats list and then we can figure this out.
Yes, that's fine. They only need to be rough estimates.https://gitlab.torproject.org/tpo/core/tor/-/issues/25519move away from asciidoc2022-06-17T18:27:18Zdkgmove away from asciidocasciidoc is the only part of the tor build process that requires python 2. python 2 is deprecated upstream and is approaching end-of-life.
Over in https://bugs.debian.org/892830 , i asked about upgrading asciidoc to move to python3, bu...asciidoc is the only part of the tor build process that requires python 2. python 2 is deprecated upstream and is approaching end-of-life.
Over in https://bugs.debian.org/892830 , i asked about upgrading asciidoc to move to python3, but apparently asciidoc itself is on life support, and upstream is encouraging everyone to move to asciidoctor instead (which introduces a ruby dependency) or to use something else like pandoc.
in any case, presumably we want the documentation to stay buildable, so i encourage switching away from asciidoc.https://gitlab.torproject.org/tpo/core/tor/-/issues/30801Investigate running CI with hardened dependencies vs running CI with valgrind2022-06-17T18:06:43ZNick MathewsonInvestigate running CI with hardened dependencies vs running CI with valgrindIn legacy/trac#30674, we investigated why running with --enable-fragile-hardening had missed a memory leak that valgrind could successfully catch. The answer turned out to be that we had not compiled our dependencies with sanitizers ena...In legacy/trac#30674, we investigated why running with --enable-fragile-hardening had missed a memory leak that valgrind could successfully catch. The answer turned out to be that we had not compiled our dependencies with sanitizers enabled -- so they didn't catch memory leaks that happened inside our dependencies.
Assuming we want CI to catch this kind of bug (and we do!) the alternatives seem to be: build our dependencies with sanitizers, or run with valgrind.
Teor made the following notes about deployment and evaluations:
> Hardened dependencies:
> 1. We know we can harden dependencies
> 2. Hardened dependencies may cause CI failures due to bugs in dependencies
> 3. Hardened dependencies may be slower
> 4. We probably won't rebuild libc and other large libraries in hardened mode
> 5. We don't know if valgrind or hardened builds provide better coverage of the kinds of coding errors we typically make
> 6. It might be complicated to configure builds for all our dependencies
> 7. We can't harden our chutney, stem, and sbws CIs, because they use pre-built binaries
>
> Valgrind:
> 1. We don't know if valgrind runs well in Travis CI
> 2. Valgrind may cause CI failures due to bugs in dependencies
> 3. Valgrind may be slower
> 4. Valgrind instruments all the code, no matter which library it's in
> 5. We don't know if valgrind or hardened builds provide better coverage of the kinds of coding errors we typically make
> 6. Valgrind is simple to configure
> 7. We can run valgrind on the pre-built binaries in our chutney, stem, and sbws CIs
We should come to a decision here and take action.