The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-09-16T14:32:30Zhttps://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: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21720Update Directory Server Options section for automatic DirCache2021-07-22T16:22:56ZteorUpdate Directory Server Options section for automatic DirCacheThis section header is wrong:
```
DIRECTORY SERVER OPTIONS
The following options are useful only for directory servers (that is,
if DirPort is non-zero):
```
It should read:
```
DIRECTORY SERVER OPTIONS
The followin...This section header is wrong:
```
DIRECTORY SERVER OPTIONS
The following options are useful only for directory servers (that is,
if DirPort is non-zero):
```
It should read:
```
DIRECTORY SERVER OPTIONS
The following options are useful only for directory servers:
(Relays with enough bandwidth automatically become directory
servers, see DirCache for details.)
```Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21716Avoid recursive call to routerlist_remove_old_routers via router_rebuild_store2022-02-28T19:41:05ZTracAvoid recursive call to routerlist_remove_old_routers via router_rebuild_storePeriodic functions have their log output duplicated when using adb logcat:
orbot/external/tor/src/or/periodic.c
static void
periodic_event_dispatch(evutil_socket_t fd, short what, void *data)
{
(void)fd;
(void)what;
periodic_even...Periodic functions have their log output duplicated when using adb logcat:
orbot/external/tor/src/or/periodic.c
static void
periodic_event_dispatch(evutil_socket_t fd, short what, void *data)
{
(void)fd;
(void)what;
periodic_event_item_t *event = data;
time_t now = time(NULL);
const or_options_t *options = get_options();
log_debug(LD_GENERAL, "Dispatching %s", event->name);
int r = event->fn(now, options);
I did uncomment the above log_debug which is then printed only once as expected.
The problem starts with r=events->fn(now, options);. Every function called this way seems to have its log output duplicated. I checked with builtin atomics that the function is actually called only once but the log output is duplicated, e.g.:
03-12 20:45:22.627 17948 17948 D Tor : periodic_event_dispatch(): Dispatching check_descriptor
03-12 20:45:22.637 17948 17948 I Tor : routerlist_remove_old_routers(): We have 0 live routers and 0 old router descriptors.
03-12 20:45:22.637 17948 17948 I Tor : routerlist_remove_old_routers(): We have 0 live routers and 0 old router descriptors.
This is somewhat irritating when tracing the flow of events.
**Trac**:
**Username**: ansteinhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21715Possible error in the Tor manual (section "NumEntryGuards NUM")2021-07-22T16:22:56ZTracPossible error in the Tor manual (section "NumEntryGuards NUM")In both, the Tor -stable Manual and the Tor -alpha Manual, there is a possible error in the section "NumEntryGuards NUM".
Literally, this is the description of the "NumEntryGuards NUM" option: "If UseEntryGuards is set to 1, we will tr...In both, the Tor -stable Manual and the Tor -alpha Manual, there is a possible error in the section "NumEntryGuards NUM".
Literally, this is the description of the "NumEntryGuards NUM" option: "If UseEntryGuards is set to 1, we will try to pick a total of NUM routers as long-term entries for our circuits. If NUM is 0, we try to learn the number from the NumEntryGuards consensus parameter, and default to 3 if the consensus parameter isn’t set. (Default: 0)".
But I think the correct description would be: "If UseEntryGuards is set to 1, we will try to pick a total of NUM routers as long-term entries for our circuits. If NUM is 0, we try to learn the number from the NumEntryGuards consensus parameter, and default to 1 if the consensus parameter isn’t set. (Default: 0)". Because Tor currently chooses a single entry guard, does not choose three.
**Trac**:
**Username**: moe-szyslak-0Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/21580circuit_build_needed_circs comment mentions router_have_min_dir_info, which d...2020-06-27T13:57:06Zteorcircuit_build_needed_circs comment mentions router_have_min_dir_info, which does not existThis was introduced somewhere in 0.3.0 with the new guard code.This was introduced somewhere in 0.3.0 with the new guard code.Tor: 0.3.1.x-final