The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-07-22T16:22:39Zhttps://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/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/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/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/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-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21405Clarify "address" in man page: IPv4, IPv6, hostname?2021-07-22T16:22:56ZteorClarify "address" in man page: IPv4, IPv6, hostname?The DirAuthority line only takes an IPv4 address as an "address".
But other torrc options take IPv6 addresses or hostnames.
We should clarify what we mean when we say "address".
Reported by Andrew Smith:
https://lists.torproject.org/pi...The DirAuthority line only takes an IPv4 address as an "address".
But other torrc options take IPv6 addresses or hostnames.
We should clarify what we mean when we say "address".
Reported by Andrew Smith:
https://lists.torproject.org/pipermail/tor-relays/2017-February/011876.htmlTor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21355Warn when IPv6Exits have no ipv6-policy line in their descriptor2020-07-28T02:21:36ZteorWarn when IPv6Exits have no ipv6-policy line in their descriptorThere appears to be a bug in Tor's IPv6 Exit code, where exits that have IPv6Exit set do not have an ipv6-policy line in their descriptor.
To assist in diagnosing this bug, we should log a warning message (not a bug message) containing ...There appears to be a bug in Tor's IPv6 Exit code, where exits that have IPv6Exit set do not have an ipv6-policy line in their descriptor.
To assist in diagnosing this bug, we should log a warning message (not a bug message) containing the full exit policy, when the IPv6 exit policy summary is empty, but IPv6Exit is 1 and ExitRelay is 1 or auto.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21266test: Improve hs intropoints unit test with expected msg log.2020-06-27T13:57:20ZDavid Gouletdgoulet@torproject.orgtest: Improve hs intropoints unit test with expected msg log.Now that legacy/trac#20029 has been merged, during review there has been a request for improving the unit tests for the failure cases to expect a log message.Now that legacy/trac#20029 has been merged, during review there has been a request for improving the unit tests for the failure cases to expect a log message.Tor: 0.3.0.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/21151man page lists wrong default for DataDirectory2021-07-22T16:22:56ZRoger Dingledineman page lists wrong default for DataDirectoryIn my doc/tor.1 in my git checkout, I have
```
DataDirectory DIR
Store working data in DIR (Default: /usr/local/var/lib/tor)
```
Apparently the underlying code (in tor.1.txt) is
```
[[DataDirectory]] **DataDirectory** ...In my doc/tor.1 in my git checkout, I have
```
DataDirectory DIR
Store working data in DIR (Default: /usr/local/var/lib/tor)
```
Apparently the underlying code (in tor.1.txt) is
```
[[DataDirectory]] **DataDirectory** __DIR__::
Store working data in DIR (Default: @LOCALSTATEDIR@/lib/tor)
```
It looks like if DataDirectory remains unset (which is the default), on Windows you get
```
get_windows_conf_root()
```
whereas on other platforms, you get
```
d = "~/.tor";
```
and then it's only if you're running as root that you get
```
fn = tor_strdup(LOCALSTATEDIR PATH_SEPARATOR "tor");
```
But I admit that all of this is confusing, because we have functions like `find_torrc_filename()` and `get_default_conf_file()` and `get_torrc_fname()` so it's hard to say for sure.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21124ChangeLog: reference to 18625 actually corresponds to 186262021-07-22T16:22:54ZteorChangeLog: reference to 18625 actually corresponds to 18626The ChangeLog lines:
```
- Avoid spurious failures from configure files related to calling
exit(0) in TOR_SEARCH_LIBRARY. Fixes bug 18625; bugfix on
0.2.0.1-alpha. Patch from "cypherpunks".
```
actually correspond to lega...The ChangeLog lines:
```
- Avoid spurious failures from configure files related to calling
exit(0) in TOR_SEARCH_LIBRARY. Fixes bug 18625; bugfix on
0.2.0.1-alpha. Patch from "cypherpunks".
```
actually correspond to legacy/trac#18626.
This issue was added in commit db13527.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21122Document all options that can't be changed while tor is running2021-07-22T16:22:54ZteorDocument all options that can't be changed while tor is runningTurns out we've been pretty bad at keeping the man page up to date with options_transition_allowed().Turns out we've been pretty bad at keeping the man page up to date with options_transition_allowed().Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21115Building Tor With Static SNI2020-06-27T13:57:26ZTracBuilding Tor With Static SNII want to have a static value of SNI in TOR in Https Connection. TOR currently uses Random SNI but Firewall is blocking it by checking random SNI.
I have changed crypto_random_hostname to a Static char* in /src/common/tortls.c to a fixed...I want to have a static value of SNI in TOR in Https Connection. TOR currently uses Random SNI but Firewall is blocking it by checking random SNI.
I have changed crypto_random_hostname to a Static char* in /src/common/tortls.c to a fixed string but after that it is not working.
**Trac**:
**Username**: mintu.juit@gmail.comTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21109apparent inconsistency in prop2642021-07-22T16:22:54Zcypherpunksapparent inconsistency in prop264In A.1, "the protocol list for all current Tor versions" says HSDir=1, there is no version 2. But in A.2, both clients and relays are required to support HSDir=2, which A.1 just said does not exist.
https://gitweb.torproject.org/torspec...In A.1, "the protocol list for all current Tor versions" says HSDir=1, there is no version 2. But in A.2, both clients and relays are required to support HSDir=2, which A.1 just said does not exist.
https://gitweb.torproject.org/torspec.git/tree/proposals/264-subprotocol-versions.txt#n304Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21003extend_info_describe should list IPv6 address (if present)2020-06-27T13:57:33Zteorextend_info_describe should list IPv6 address (if present)When running an IPv6-only client using:
```
src/or/tor ClientUseIPv4 0 DataDirectory `mktemp -d` UseMicrodescriptors 0
```
I get log messages like
`[info] add_an_entry_guard(): Chose $906933A309F15D7CF379127078A6791DF9B0C763~Unnamed at ...When running an IPv6-only client using:
```
src/or/tor ClientUseIPv4 0 DataDirectory `mktemp -d` UseMicrodescriptors 0
```
I get log messages like
`[info] add_an_entry_guard(): Chose $906933A309F15D7CF379127078A6791DF9B0C763~Unnamed at 91.121.82.25 as new entry guard`
But I'm really contacting them on their IPv6 address. So we should list it along with the IPv4 address.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20887DIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d instead2021-09-16T14:33:04ZteorDIRCACHE_MIN_MEM_MB does not stringify on FreeBSD, we should use %d insteadA FreeBSD relay operator reports the message:
```
[WARN] Being a directory cache (default) with less than DIRCACHE_MIN_MB_BANDWIDTH MB of memory is not recommended and may consume most of the available resources, consider disabling this ...A FreeBSD relay operator reports the message:
```
[WARN] Being a directory cache (default) with less than DIRCACHE_MIN_MB_BANDWIDTH MB of memory is not recommended and may consume most of the available resources, consider disabling this functionality by setting the DirCache option to 0
```
So we should print the macro value the same way we do every other value, using "%d" in the string, and passing it as an argument.
(This macro changed name in legacy/trac#20684.)Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20853rend_config_services should use service_is_ephemeral rather than old/new->dir...2021-09-16T14:33:04Zteorrend_config_services should use service_is_ephemeral rather than old/new->directoryWe missed this in the earlier refactor.
(Does that make it a bug? I think so.)We missed this in the earlier refactor.
(Does that make it a bug? I think so.)Tor: 0.3.0.x-final