The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-07-22T16:20:51Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25857::/128 is not the IPv6 equivalent of 0.0.0.0/02021-07-22T16:20:51ZTrac::/128 is not the IPv6 equivalent of 0.0.0.0/0The [man page of tor](https://gitweb.torproject.org/tor.git/tree/doc/tor.1.txt#n1837) states that "::/128" is the IPv6 equivalent of IPv4's "0.0.0.0/0" and that is not correct.
The equivalent of "0.0.0.0/0" in IPv6 is "::/0"
The IPv4 e...The [man page of tor](https://gitweb.torproject.org/tor.git/tree/doc/tor.1.txt#n1837) states that "::/128" is the IPv6 equivalent of IPv4's "0.0.0.0/0" and that is not correct.
The equivalent of "0.0.0.0/0" in IPv6 is "::/0"
The IPv4 equivalent of "::/128" would be "0.0.0.0/32".
https://en.wikipedia.org/wiki/IPv6_address#Unicast_addresses
**Trac**:
**Username**: CTassisFTor: 0.3.3.x-finalDamian JohnsonDamian Johnsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25892Replace RejectPlaintextPorts with RejectPlaintextPortPolicy2020-07-28T19:07:26ZcypherpunksReplace RejectPlaintextPorts with RejectPlaintextPortPolicyhttp://expyuzz4wqqyqhjn.onion/docs/tor-manual.html.en
RejectPlaintextPorts port,port
I want my Tor to allow only port 443(HTTPS) and 9877(XMPP).
But current RejectPlaintextPorts is not easy to use because I have to
set "RPP 0,1,2,3,4.....http://expyuzz4wqqyqhjn.onion/docs/tor-manual.html.en
RejectPlaintextPorts port,port
I want my Tor to allow only port 443(HTTPS) and 9877(XMPP).
But current RejectPlaintextPorts is not easy to use because I have to
set "RPP 0,1,2,3,4...65535".
I want something like this:
AccessibleTorPorts 443,9877
AccessibleTorPorts reject *
format:
AccessibleTorPorts port[,port...]
AccessibleTorPorts reject [port|*]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25897manual: document that ControlSocket is disabled by default2021-07-22T16:20:51Zcypherpunksmanual: document that ControlSocket is disabled by defaulthttps://www.torproject.org/docs/tor-manual.html.en#ControlSocket
"
Like ControlPort, but listens on a Unix domain socket, rather than a TCP socket. 0 disables ControlSocket (Unix and Unix-like systems only.)
"
Please add:
"(Default: ...https://www.torproject.org/docs/tor-manual.html.en#ControlSocket
"
Like ControlPort, but listens on a Unix domain socket, rather than a TCP socket. 0 disables ControlSocket (Unix and Unix-like systems only.)
"
Please add:
"(Default: 0)" add the end (as you do with most other entries).Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/25914dirserv: Remove dead code2020-06-27T13:53:37ZDavid Gouletdgoulet@torproject.orgdirserv: Remove dead codeWhile working on legacy/trac#25610, I've noticed dead code that uses `dirserv_get_consensus()`.
In `networkstatus.c`, function `networkstatus_set_current_consensus()`:
We parse the flavor and if it is unknown, we bail early with:
```
...While working on legacy/trac#25610, I've noticed dead code that uses `dirserv_get_consensus()`.
In `networkstatus.c`, function `networkstatus_set_current_consensus()`:
We parse the flavor and if it is unknown, we bail early with:
```
if (flav < 0) {
/* XXXX we don't handle unrecognized flavors yet. */
log_warn(LD_BUG, "Unrecognized consensus flavor %s", flavor);
return -2;
}
```
But later in the function we have this if/else on the flavor name with a `else {}` statement that uses `dirserv_get_consensus()`. But we can't get into that else case since the first conditions are the only two flavors we can handle.
In between the first checks above and this if/else ^, the flavor can change as in we take the one from the given consensus but again, there is a check on if we can handle that flavor:
```
if (flav != usable_consensus_flavor() &&
!we_want_to_fetch_flavor(options, flav)) {
```
Bottom line, I think the `else {}` code is dead code. This simplifies the callgraph into the dirauth subsystem.Tor: 0.3.4.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/25978UseEntryGuards 0 disables EntryNodes2021-07-22T16:20:51ZTracUseEntryGuards 0 disables EntryNodesUseEntryNodes {se} should allow UseEntryGuards 0
But UseEntryGuards 0 breaks UseEntryNodes unless it can find a GuardNode which is against the purpose of UseEntryNodes in TORRC.
**Trac**:
**Username**: tortracUseEntryNodes {se} should allow UseEntryGuards 0
But UseEntryGuards 0 breaks UseEntryNodes unless it can find a GuardNode which is against the purpose of UseEntryNodes in TORRC.
**Trac**:
**Username**: tortracTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26011Alias GETINFO config-can-saveconf to config/can-saveconf2020-06-27T13:53:30ZteorAlias GETINFO config-can-saveconf to config/can-saveconfBecause we have a config/ hierarchy, so we should use it.
This will also need a control spec patch.Because we have a config/ hierarchy, so we should use it.
This will also need a control spec patch.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26113Control spec is ambiguous whether a GETCONF error message is specified2020-07-31T14:03:27ZdmrControl spec is ambiguous whether a GETCONF error message is specifiedThe [[spec for `GETCONF` response](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt?id=436d08b49fb84aa62d7bc96013002a0c27534bbb#n307|control)] says:
```
If some of the listed keywords can't be found, Tor replies with a
...The [[spec for `GETCONF` response](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt?id=436d08b49fb84aa62d7bc96013002a0c27534bbb#n307|control)] says:
```
If some of the listed keywords can't be found, Tor replies with a
"552 unknown configuration keyword" message.
```
The spec also has a [[about error messages](https://gitweb.torproject.org/torspec.git/tree/control-spec.txt?id=436d08b49fb84aa62d7bc96013002a0c27534bbb#n1809|clause)]:
```
Unless specified to have specific contents, the human-readable messages
in error replies should not be relied upon to match those in this document.
```
Unfortunately, it's unclear what //specified to have specific contents// means here. The message for `GETCONF` is quoted, which at least in cursory read made me think it was //specified//.
But I suppose it's ambiguous.
==== Expected change
In discussion over IRC, arma suggested it...
> might be even better to change the spec to be like "replies with a 552 message because of the unrecognized configuration key."
Overall, it was agreed upon amongst arma, meejah, sysrqb, and myself that the spec shouldn't be denoting a specific message here, and that controllers shouldn't rely on a specific message. Only the numeric code `552` should be relied upon.https://gitlab.torproject.org/tpo/core/tor/-/issues/26138DirPort /tor/server/all document contains spurrious blank line following serv...2020-07-28T19:13:56ZstarlightDirPort /tor/server/all document contains spurrious blank line following serving relay's descriptorissuing
```
curl -s http://x.x.x.x:x/tor/server/all.z | openssl zlib -d | less -SX
```
as expected retrieves a complete set of server descriptors; contains one blank line immediately after the descriptor of the serving relay which is n...issuing
```
curl -s http://x.x.x.x:x/tor/server/all.z | openssl zlib -d | less -SX
```
as expected retrieves a complete set of server descriptors; contains one blank line immediately after the descriptor of the serving relay which is not expected
trivial issue, but noticed it so reported it
glitch appears in 0.3.3 as wellTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26223Allow longer bandwidth lines in bandwidth files2020-06-27T13:53:20ZteorAllow longer bandwidth lines in bandwidth filesBandwidth files have a line limit of 510 characters (512 - newline and NUL).
We should make sure this limit is high enough for future bandwidth files.
We can do this by finding out the current length of sbws and torflow lines, multiply...Bandwidth files have a line limit of 510 characters (512 - newline and NUL).
We should make sure this limit is high enough for future bandwidth files.
We can do this by finding out the current length of sbws and torflow lines, multiplying it by 4x, then rounding up to the nearest power of two.
We can use the examples in the spec if we need to:
https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt
Maybe we should wait until sbws has added all the new fields?Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26327Add Vagrant configurations for multiple different systems to contrib2020-06-27T13:53:14Zrl1987Add Vagrant configurations for multiple different systems to contribVagrant can enable us to have pre-configured VM blueprints with Tor development environment that developers could easily instantiate on their local machines.
We should have Vagrantfiles for:
* Linux (at least Debian, maybe some more)....Vagrant can enable us to have pre-configured VM blueprints with Tor development environment that developers could easily instantiate on their local machines.
We should have Vagrantfiles for:
* Linux (at least Debian, maybe some more).
* FreeBSD
* OpenBSD
* NetBSD
* Windows 10 (stretch goal)
* Android-x86 (stretch goal)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26333Write trac templates for bug reports / other tickets, and link them from some...2021-07-22T16:20:51ZNick MathewsonWrite trac templates for bug reports / other tickets, and link them from somewhere usefulIt would be awesome if we could have templates for opening better trac tickets, in a way to actually help people include all the necessary info and not have a hard time figure out what they're supposed to say.
This might be an "internal...It would be awesome if we could have templates for opening better trac tickets, in a way to actually help people include all the necessary info and not have a hard time figure out what they're supposed to say.
This might be an "internal services" ticket, but before we can get it there, we need to figure out what we actually want.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26388Update tor copyright headers to year 20182020-06-27T13:53:11Zrl1987Update tor copyright headers to year 2018Now it says:
```
* Copyright (c) 2007-2017, The Tor Project, Inc. */
```
Should be updated to 2018. We have updateCopyright.pl for this.Now it says:
```
* Copyright (c) 2007-2017, The Tor Project, Inc. */
```
Should be updated to 2018. We have updateCopyright.pl for this.Tor: 0.3.4.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/26447Add check-includes to check-local?2020-06-27T13:53:08ZNick MathewsonAdd check-includes to check-local?We now have a handy tool that lets us check our includes for modularity violations. We could make it part of "make check", and have our CI enforce it for us!We now have a handy tool that lets us check our includes for modularity violations. We could make it part of "make check", and have our CI enforce it for us!Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/arti/-/issues/663Use humantime in tests2023-02-28T19:22:54ZNick MathewsonUse humantime in testsIn various places in our test codes, we write times like `time::SystemTime::UNIX_EPOCH + time::Duration::new(1668455932, 0)`. Instead we should just write the time we want in UTC, adding the dev-dependencies that we need to do that.
We...In various places in our test codes, we write times like `time::SystemTime::UNIX_EPOCH + time::Duration::new(1668455932, 0)`. Instead we should just write the time we want in UTC, adding the dev-dependencies that we need to do that.
We can identify places to make this change by grepping for `UNIX_EPOCH`.https://gitlab.torproject.org/tpo/core/tor/-/issues/26567Replace ArgumentCharValue with ValueChar in dir-spec and bandwidth-file-spec2020-07-31T14:03:32ZteorReplace ArgumentCharValue with ValueChar in dir-spec and bandwidth-file-specHaving ArgumentChar and ArgumentCharValue is confusing, see:
https://trac.torproject.org/projects/tor/ticket/26541#comment:15Having ArgumentChar and ArgumentCharValue is confusing, see:
https://trac.torproject.org/projects/tor/ticket/26541#comment:15https://gitlab.torproject.org/tpo/core/tor/-/issues/26587--verify-config accepts RelayBandwidthRate with no value?2021-06-18T18:05:27Zcypherpunks--verify-config accepts RelayBandwidthRate with no value?is this a valid config line?
```
RelayBandwidthRate
```
(no value)
--verify-config does not complain - something I expectedis this a valid config line?
```
RelayBandwidthRate
```
(no value)
--verify-config does not complain - something I expectedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26591doc/ missing in build directory for out-of-tree builds2023-09-15T11:42:09ZTracdoc/ missing in build directory for out-of-tree builds**autoconf** allows building tor outside the source directory using `--srcdir=DIR`.
In that case, _doc/_ is not copied or symlinked from source to build directory, causing pages to be unnesseccarily regenerated using **rst2man**.
Would ...**autoconf** allows building tor outside the source directory using `--srcdir=DIR`.
In that case, _doc/_ is not copied or symlinked from source to build directory, causing pages to be unnesseccarily regenerated using **rst2man**.
Would it be possible to adjust the _configure_ stage to account for this?
Specifically, this would allow complete out-of-tree builds at least on OpenBSD, where where the following quirk is required after _configure_ and before _build_ stage to enable separation without **py-docutils** as additional build dependency:
```
pre-build:
ln -sf ${WRKSRC}/doc/ ${WRKBUILD}/
```
**Trac**:
**Username**: knhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26647defect: Spec for net/listeners/* doesn't covers HTTPTunnelPort directive or E...2020-06-27T13:52:59ZTracdefect: Spec for net/listeners/* doesn't covers HTTPTunnelPort directive or ExtORPortThere are (rather) new type of listener, that's not covered by 'GETINFO net/listeners/*'.
**Trac**:
**Username**: pyhedgehogThere are (rather) new type of listener, that's not covered by 'GETINFO net/listeners/*'.
**Trac**:
**Username**: pyhedgehogTor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26663Make torrc "auto" values case insensitive?2020-06-27T13:52:59ZRoger DingledineMake torrc "auto" values case insensitive?We had a relay operator who tried to do
```
ORPort Auto
```
but it failed, because it doesn't know what the "Auto" argument means. Now, the "auto" argument works just fine.
It seems like an easy step to be flexible about the case here. ...We had a relay operator who tried to do
```
ORPort Auto
```
but it failed, because it doesn't know what the "Auto" argument means. Now, the "auto" argument works just fine.
It seems like an easy step to be flexible about the case here. Are there any reasons not to?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/26703Lower log level of "Scheduler type KIST has been enabled"2020-06-27T13:52:57ZpastlyLower log level of "Scheduler type KIST has been enabled"I like seeing it, but that doesn't mean everyone should have to see it. Tor doesn't log about EWMA vs RR.I like seeing it, but that doesn't mean everyone should have to see it. Tor doesn't log about EWMA vs RR.Tor: 0.3.5.x-final