The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-07-22T16:22:39Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22491DownloadExtraInfo doesn't download bridge extra infos2021-07-22T16:22:39ZteorDownloadExtraInfo doesn't download bridge extra infosThere's some confusion about what these options do for bridge extra infos:
```
DownloadExtraInfo 1
FetchUselessDescriptors 1
```
We should clarify that they don't affect Tor's usual behaviour, which is to (eventually) download bridge de...There's some confusion about what these options do for bridge extra infos:
```
DownloadExtraInfo 1
FetchUselessDescriptors 1
```
We should clarify that they don't affect Tor's usual behaviour, which is to (eventually) download bridge descriptors, and never download bridge extra-infos.
Or we should make them download bridge extra-infos, and document that.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22469tor should probably reject "0x00" in port range specifications2021-10-04T19:22:56Ztoralftor should probably reject "0x00" in port range specificationssomething like
```
ExitPolicy reject6 [2a00:1450:4001:0815:0000:0000:0000:200e]:0x00
```
should spew an error message.something like
```
ExitPolicy reject6 [2a00:1450:4001:0815:0000:0000:0000:200e]:0x00
```
should spew an error message.https://gitlab.torproject.org/tpo/core/tor/-/issues/22463Reduce REACHABLE_TIMEOUT in test networks2022-06-17T17:42:19ZteorReduce REACHABLE_TIMEOUT in test networksWhen we test relay failure in chutney networks, relays aren't removed from the consensus for 45 minutes. That's way too long.When we test relay failure in chutney networks, relays aren't removed from the consensus for 45 minutes. That's way too long.https://gitlab.torproject.org/tpo/core/tor/-/issues/22449Remove timestamp_dirty kludge from mark_circuit_unusable_for_new_conns()2021-09-16T14:18:43ZNick MathewsonRemove timestamp_dirty kludge from mark_circuit_unusable_for_new_conns()In mark_circuit_unsusable_for_new_conns(), we set the unusable_for_new_conns flag... but we also carry around some old code that messes around with timestamp_dirty.
The root problem here is that the old code makes timestamp_dirty into...In mark_circuit_unsusable_for_new_conns(), we set the unusable_for_new_conns flag... but we also carry around some old code that messes around with timestamp_dirty.
The root problem here is that the old code makes timestamp_dirty into a lie; "unusable" and "dirty" are not the same concept.
We should carefully audit timestamp_dirty and its users to make sure that it's safe to remove this old kludge, and then remove it or replace it with something more accurate.https://gitlab.torproject.org/tpo/core/tor/-/issues/22448Move circuit_t.timestamp_dirty into origin_circuit_t2021-09-16T14:32:30ZNick MathewsonMove circuit_t.timestamp_dirty into origin_circuit_tIt's not meaningful for an or_circuit_t to be dirty; we shouldn't expire them in the same way.
Of course, we shouldn't do this recklessly: instead, when we make this change, we should make sure that it's actually safe.It's not meaningful for an or_circuit_t to be dirty; we shouldn't expire them in the same way.
Of course, we shouldn't do this recklessly: instead, when we make this change, we should make sure that it's actually safe.https://gitlab.torproject.org/tpo/core/tor/-/issues/22382Fix fd leak-on-close from tor-fw-helper pipe2020-07-28T03:26:56ZNick MathewsonFix fd leak-on-close from tor-fw-helper pipeSee discussion on legacy/trac#4296, in particular asn's comments. It seems that we can sometimes leak a file descriptor on exit when we're using tor-fw-helper.
Marking as very low priority since almost nobody uses that feature afaict.See discussion on legacy/trac#4296, in particular asn's comments. It seems that we can sometimes leak a file descriptor on exit when we're using tor-fw-helper.
Marking as very low priority since almost nobody uses that feature afaict.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22380Make windows log_from_handle() handle partial lines2022-06-21T14:55:40ZNick MathewsonMake windows log_from_handle() handle partial linesSee legacy/trac#2045 for a full description of the problem. With legacy/trac#21654, we fixed the unix case, but the windows case may remain.See legacy/trac#2045 for a full description of the problem. With legacy/trac#21654, we fixed the unix case, but the windows case may remain.https://gitlab.torproject.org/tpo/core/tor/-/issues/22322Typo in timercmp comment2020-06-27T13:56:36ZteorTypo in timercmp comment```
#ifndef timercmp
/** Replacement for timersub on platforms that do not have it: returns true
* iff the relational operator "op" makes the expression tv1 op tv2 true.
``````
#ifndef timercmp
/** Replacement for timersub on platforms that do not have it: returns true
* iff the relational operator "op" makes the expression tv1 op tv2 true.
```Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22311authdir_mode_any_nonhidserv() is an obsolete concept2020-06-27T13:56:36ZRoger Dingledineauthdir_mode_any_nonhidserv() is an obsolete concept```
/** Return true if we believe ourselves to be any kind of
* authoritative directory beyond just a hidserv authority. */
int
authdir_mode_any_nonhidserv(const or_options_t *options)
```
This phrase "hidserv authority" is from back i...```
/** Return true if we believe ourselves to be any kind of
* authoritative directory beyond just a hidserv authority. */
int
authdir_mode_any_nonhidserv(const or_options_t *options)
```
This phrase "hidserv authority" is from back in the days of v1 directory authorities, where there were 3 central authorities that collected and served all the hidden service descriptors.
Those days are gone, so references to a hidserv authority no longer make sense.
In particular, I think there are now only two types of directory authorities -- bridge authorities and main authorities. So this function could be replaced with just authdir_mode(). I'm marking it as 'easy' since it's a good one for a newbie to grab.Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22304Support generating HS private key / onion address without publishing2020-08-17T14:06:05ZsegfaultSupport generating HS private key / onion address without publishingWhile developing Tails Server, we encountered the need to know the onion address of a service before making it available via Tor. It would be awesome if this could be achieved via the control port, e.g. with a `DontPublish` flag to `ADD_...While developing Tails Server, we encountered the need to know the onion address of a service before making it available via Tor. It would be awesome if this could be achieved via the control port, e.g. with a `DontPublish` flag to `ADD_ONION`.https://gitlab.torproject.org/tpo/core/tor/-/issues/22223MyFamily manual page update2021-07-22T16:22:39ZcypherpunksMyFamily manual page updatehttps://lists.torproject.org/pipermail/tor-dev/2017-May/012249.html
I wanted to help improve the man page section for MyFamily in the light
of today's MyFamily change [1].
I sometimes contact relay operators about their MyFamily config...https://lists.torproject.org/pipermail/tor-dev/2017-May/012249.html
I wanted to help improve the man page section for MyFamily in the light
of today's MyFamily change [1].
I sometimes contact relay operators about their MyFamily configuration
and a common request is: "Please send me an example"
So I added an example to the man page (including the new multiline
support in 031)
- replaced "node" with "fingerprint"
(no one is using nicknames anymore, or onionoo does not display
fingerprints?) Are nicknames still supported? (Roger started to remove
remaining bits of the past Named "world" so this might be another place?)
- made clear that you can still have multiple fingerprints in a single
line (if this will be deprecated at some point I can add a deprecation info)
- added info that the fingerprint can be prefixed with $
- changed "This option can be repeated many times, for multiple families"
to
"This option can be repeated many times, for multiple fingerprints"
(from one relay's view there is only one family)
nusenu
inline patch below (I can paste it to trac if you like)
[1]
https://gitweb.torproject.org/tor.git/commit/?id=d76cffda601eed40d6a81eadb1240d98ee1e70a2
https://trac.torproject.org/projects/tor/ticket/4998#comment:11
```
1735c1735
< [[MyFamily]] **MyFamily** __node__::
---
> [[MyFamily]] **MyFamily** __fingerprint__,__fingerprint__,__...__::
1738,1739c1738,1741
< their identity fingerprints. This option can be repeated many
times, for
< multiple families. When two servers both declare that they are in the
---
> their (possibly $-prefixed) identity fingerprints.
> This option can be repeated many times, for
> multiple fingerprints, all fingerprints in all MyFamily lines will
be merged.
> When two servers both declare that they are in the
1745,1746c1747,1753
< When listing a node, it's better to list it by fingerprint than by
< nickname: fingerprints are more reliable.
---
> Example: +
> MyFamily
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA,BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
+
> MyFamily CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC +
> +
> is identical to: +
> +
> MyFamily
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA,BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
```Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22214When authority certificates expire, give a better error message2022-06-17T14:15:04ZteorWhen authority certificates expire, give a better error messageOn master, I have a test directory authority on i386 macOS 10.12 which can't download certificates. The directory authority had been down (asleep) for a while, and on update to the new master, it said:
```
May 10 19:02:28.645 [notice] T...On master, I have a test directory authority on i386 macOS 10.12 which can't download certificates. The directory authority had been down (asleep) for a while, and on update to the new master, it said:
```
May 10 19:02:28.645 [notice] Tor 0.3.1.0-alpha-dev (git-0266c4ac819d9c83) running on Darwin with Libevent 2.1.8-stable, OpenSSL 1.0.2k, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
...
May 10 19:03:15.000 [warn] Got a certificate for lemonpeasy, but we already have it. Maybe they haven't updated it. Waiting for a while.
May 10 19:03:15.000 [warn] Got a certificate for triplepeak, but we already have it. Maybe they haven't updated it. Waiting for a while.
May 10 19:03:15.000 [warn] Got a certificate for Betty, but we already have it. Maybe they haven't updated it. Waiting for a while.
May 10 19:03:15.000 [warn] Got a certificate for Evelyn, but we already have it. Maybe they haven't updated it. Waiting for a while.
May 10 19:03:15.000 [warn] Got a certificate for albert, but we already have it. Maybe they haven't updated it. Waiting for a while.
May 10 19:03:15.000 [warn] Got a certificate for missionary, but we already have it. Maybe they haven't updated it. Waiting for a while.
...
May 10 19:04:16.000 [warn] Looks like we need to download a new certificate from authority 'triplepeak' at ...
May 10 19:04:16.000 [warn] Looks like we need to download a new certificate from authority 'Betty' at ...
```
I suspect this bug might have been introduced in 0.3.1. Or, it might be due to the fact our test network consensus is broken. Or it could be because we're on mixed versions (which should work).https://gitlab.torproject.org/tpo/core/tor/-/issues/22207Add bridge authority fingerprint to sanitized bridge network statuses2020-06-27T13:56:42ZKarsten LoesingAdd bridge authority fingerprint to sanitized bridge network statusesWhen I looked through existing code that uses methods from `DescriptorFile` other than `DescriptorFile#getDescriptors()` for legacy/trac#22141, I spotted [this code in metrics-web](https://gitweb.torproject.org/metrics-web.git/tree/modul...When I looked through existing code that uses methods from `DescriptorFile` other than `DescriptorFile#getDescriptors()` for legacy/trac#22141, I spotted [this code in metrics-web](https://gitweb.torproject.org/metrics-web.git/tree/modules/legacy/src/main/java/org/torproject/ernie/cron/network/ConsensusStatsFileHandler.java#n205):
```
if (descriptorFile.getFileName().contains(
"4A0CCD2DDC7995083D73F5D667100C8A5831F16D")) {
authority = "Tonga";
} else if (descriptorFile.getFileName().contains(
"1D8F3A91C37C5D1C4C19B1AD1D0CFBE8BF72D8E1")) {
authority = "Bifroest";
}
```
Not beautiful, I know, but that's not the point. The point is that we need to parse the bridge authority fingerprint from the file name, because it's not contained in the descriptor itself. That seems bad, and relatively easy to fix.
Right now, the header of a sanitized bridge network status looks like this:
```
@type bridge-network-status 1.1
published 2017-05-09 07:57:32
flag-thresholds stable-uptime=1075980 stable-mtbf=2384868 fast-speed=21000 guard-wfu=98.000% guard-tk=691200 guard-bw-inc-exits=318000 guard-bw-exc-exits=318000 enough-mtbf=1 ignoring-advertised-bws=0
```
We could easily include a "fingerprint" line there, like this:
```
@type bridge-network-status 1.2
published 2017-05-09 07:57:32
flag-thresholds stable-uptime=1075980 stable-mtbf=2384868 fast-speed=21000 guard-wfu=98.000% guard-tk=691200 guard-bw-inc-exits=318000 guard-bw-exc-exits=318000 enough-mtbf=1 ignoring-advertised-bws=0
fingerprint 1D8F3A91C37C5D1C4C19B1AD1D0CFBE8BF72D8E1
```
Ideally, we'd modify the bridge authority code to include this line, too, and then go through archived bridge network statuses and retroactively put it in.
This is somewhat related to legacy/trac#12951 when we added a `"published"` line to bridge network statuses in a similar way.
I'm copying isis to hear what they think about putting in a `"fingerprint"` line.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22203Should a hup reload the geoip files?2023-09-15T11:45:58ZRoger DingledineShould a hup reload the geoip files?In config.c in config_maybe_load_geoip_files_() we have this line:
```
/* XXXX Reload GeoIPFile on SIGHUP. -NM */
```
and sure enough, it looks like there's nothing in main.c's do_hup() that would make us reload the geoip files.
It w...In config.c in config_maybe_load_geoip_files_() we have this line:
```
/* XXXX Reload GeoIPFile on SIGHUP. -NM */
```
and sure enough, it looks like there's nothing in main.c's do_hup() that would make us reload the geoip files.
It would be relatively easy to do I think:
* In do_hup(), right around the call to routerlist_reset_warnings(), we call something in geoip.c that tells it to no longer consider itself initialized. Maybe that call is something like clear_geoip_db().
* Then in config_maybe_load_geoip_files_(), since geoip_is_loaded() returns 0, it loads them.
Things get tricky though: catalyst asked if reloading the geoip files messes up the statistics gathering.
If reloading the geoip files *does* mess up statistics gathering, we have ourselves a minor bug, since config_maybe_load_geoip_files_() does reload them if the GeoIPFile location changes.
But it turns out to be more complicated than that, since geoip_load_file() only clears selective things: it clears geoip_ipv4_entries and geoip_ipv6_entries, but it leaves geoip_countries alone! And I see elsewhere, at the bottom of geoip_note_client_seen(), that we are keeping statistics directly in the geoip_countries smartlist:
```
geoip_country_t *country = smartlist_get(geoip_countries, country_idx);
++country->n_v3_ns_requests;
```
So we would not want to call clear_geoip_db() on hup, or we'd lose some stats.
I guess that means if we want to make do_hup reload the geoip stats file, the better (non-invasive) plan is to have a boolean want_to_reload_geoip{4,6} in geoip.c that we turn on in do_hup, and then we check the right boolean in geoip_is_loaded().
I think there's a big argument for growing some good unit tests here, around "what happens when we reload this, collect those stats, reload that, examine those other stats, etc", since things are either subtly broken right now, or awfully fragile.https://gitlab.torproject.org/tpo/core/tor/-/issues/22145Document which interface is used for DNS requests in the context of OutboundB...2021-07-22T16:22:39ZcypherpunksDocument which interface is used for DNS requests in the context of OutboundBindAddressOR/ExitIn legacy/trac#17975 two new options have been added:
* OutboundBindAddressOR
* OutboundBindAddressExit
The manual page makes no clear statement which interface is used for DNS traffic.
https://trac.torproject.org/projects/tor/ticket...In legacy/trac#17975 two new options have been added:
* OutboundBindAddressOR
* OutboundBindAddressExit
The manual page makes no clear statement which interface is used for DNS traffic.
https://trac.torproject.org/projects/tor/ticket/17975#comment:13
hints towards OutboundBindAddressOR, but users should not be required to search the bugtracker find out about that.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22110Defining TOR_BUILD_TAG and tor_git_revision violates the version spec2020-06-27T13:56:46ZteorDefining TOR_BUILD_TAG and tor_git_revision violates the version specWhen we removed the git revision in legacy/trac#2988, we allowed vendors to specify TOR_BUILD_TAG instead. But if we specify both TOR_BUILD_TAG and tor_git_revision, get_version() returns a string like this:
```
Tor 0.2.9.9 (TOR_BUILD_TA...When we removed the git revision in legacy/trac#2988, we allowed vendors to specify TOR_BUILD_TAG instead. But if we specify both TOR_BUILD_TAG and tor_git_revision, get_version() returns a string like this:
```
Tor 0.2.9.9 (TOR_BUILD_TAG) (git-tor_git_revision)
```
This violates the version spec, which only allows one set of brackets for EXTRA_INFO.
https://gitweb.torproject.org/torspec.git/tree/version-spec.txt#n22
So instead, we should use:
```
Tor 0.2.9.9 (TOR_BUILD_TAG,git-tor_git_revision)
```
(We can't use spaces in the EXTRA_INFO.)
We should also write a unit test that checks that our own version passes the directory authority checks.
This isn't serious, because the only programmatic interface that uses this is GETINFO version.Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22090Rename channel client functions for clarity2021-09-16T14:32:29ZteorRename channel client functions for clarityIn legacy/trac#21406, nickm said:
> I would like to rename "channel_mark_client" to "channel_mark_as_client" and "channel_is_client" to "channel_comes_from_client" or something, but that's another ticket.In legacy/trac#21406, nickm said:
> I would like to rename "channel_mark_client" to "channel_mark_as_client" and "channel_is_client" to "channel_comes_from_client" or something, but that's another ticket.https://gitlab.torproject.org/tpo/core/tor/-/issues/22049The various proxy options should support an AF_LOCAL socket.2021-06-18T18:09:39ZYawning AngelThe various proxy options should support an AF_LOCAL socket.It would be nice if `Socks4Proxy`, `Socks5Proxy`, `HTTPProxy`, and `HTTPSProxy` all supported `AF_LOCAL` sockets. Of all the options listed, `HTTPProxy` is probably the lowest priority, since it's scope is fairly limited (Is it still ev...It would be nice if `Socks4Proxy`, `Socks5Proxy`, `HTTPProxy`, and `HTTPSProxy` all supported `AF_LOCAL` sockets. Of all the options listed, `HTTPProxy` is probably the lowest priority, since it's scope is fairly limited (Is it still even useful?).
This along with PTs eventually getting support for `AF_LOCAL` sockets would let clients run the daemon in a container with no ability to create `AF_INET`/`AF_INET6` sockets.https://gitlab.torproject.org/tpo/core/tor/-/issues/22028The approved-routers file isn't documented anywhere2021-07-22T16:22:39ZteorThe approved-routers file isn't documented anywhereTor directory authorities load an approved-routers file, but it isn't documented in the man page.Tor directory authorities load an approved-routers file, but it isn't documented in the man page.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21864Support Bridges setting MyFamily to include Relays2020-06-27T20:32:04ZIsis LovecruftSupport Bridges setting MyFamily to include Relays
In src/or/config.c:
```
if (options->MyFamily && options->BridgeRelay) {
log_warn(LD_CONFIG, "Listing a family for a bridge relay is not "
"supported: it can reveal bridge fingerprints to censors. "
"You ...
In src/or/config.c:
```
if (options->MyFamily && options->BridgeRelay) {
log_warn(LD_CONFIG, "Listing a family for a bridge relay is not "
"supported: it can reveal bridge fingerprints to censors. "
"You should also make sure you aren't listing this bridge's "
"fingerprint in any other MyFamily.");
}
```
In src/or/router.c, function `router_build_fresh_descriptor`:
```
if (options->MyFamily && ! options->BridgeRelay) {
smartlist_t *family;
[…]
```
I propose instead that we:
1) Warn bridge operators not to include _other_ bridges in MyFamily, but let them know that including relays is fine. We should continue to warn them not to list any bridge in the MyFamily of a public relay.
2) Allow bridges to specify MyFamily.
The reasoning for this is that NoiseTor would like to run high-capacity default bridges for Tor Browser, but they are nervous about simultaneously running exits without being able to direct people not to use both.Tor: unspecified