The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-07-22T16:25:32Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17165new isolation flag inconsistent spelling2021-07-22T16:25:32Zcypherpunksnew isolation flag inconsistent spellingKeepAliveIsolateSOCKSAuth in doc/tor.1.txt
KeyAliveSOCKSAuth in ChangeLogKeepAliveIsolateSOCKSAuth in doc/tor.1.txt
KeyAliveSOCKSAuth in ChangeLogTor: 0.2.7.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17170documenation for BandwidthRate etc should mention TCP/IP overhead not included2021-07-22T16:25:32Zstarlightdocumenation for BandwidthRate etc should mention TCP/IP overhead not includedThe Tor manual page should mention that
`BandwidthRate`, `BandwidthBurst`, etc control
only application layer byte rates and that
TCP/IP overhead adds approximately 17%
to the total, or stated a different way
the payload data rate is abo...The Tor manual page should mention that
`BandwidthRate`, `BandwidthBurst`, etc control
only application layer byte rates and that
TCP/IP overhead adds approximately 17%
to the total, or stated a different way
the payload data rate is about 15% of
total traffic.
Is easy to overlook this important
detail and it matters greatly when one is
configuring maximums in order to stay
within ISP bandwidth allocations. ISPs
count total traffic and over-limit charges
can be extortionist. Is unpleasant
to exceed them by accident.
The overhead accounting also matters if one
is setting BandwidthRate for an unmetered
Internet connection with the idea of
minimizing TCP/IP congestion in preference
to Tor router flow control.
Generally ISPs do not charge for MAC layer
bytes which are not carried on WAN links
and so the above estimates omit it.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17292tor-guts documentation should cover all modules2021-07-22T16:25:32ZNick Mathewsontor-guts documentation should cover all modulesThis is a deliverable for November 2016This is a deliverable for November 2016Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17294Complete users manuals for low-level layers in tor-guts2021-07-22T16:25:32ZNick MathewsonComplete users manuals for low-level layers in tor-gutsOur tor-guts code (or our doxygen or whatever) should contain a complete users manual for src/common.
At the very least, we have deliverables for the crypto layer and the compat/util layer. But we should overdeliver here. This is a de...Our tor-guts code (or our doxygen or whatever) should contain a complete users manual for src/common.
At the very least, we have deliverables for the crypto layer and the compat/util layer. But we should overdeliver here. This is a deliverable for November 2016Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17602'HidServDirectoryV2 0' not disabling HSDir2021-07-22T16:25:32Zseeess'HidServDirectoryV2 0' not disabling HSDirtorrc:
DirPort 9
ORPort 443
#ControlPort 9051
#CookieAuthentication 1
Exitpolicy reject *:*
Nickname xxx
ContactInfo xxx
SocksPort 0
#BridgeRelay 1
#ServerTransportPlugin obfs3 exec /usr/local/bin/obfsproxy managed
#ExtORPort ...torrc:
DirPort 9
ORPort 443
#ControlPort 9051
#CookieAuthentication 1
Exitpolicy reject *:*
Nickname xxx
ContactInfo xxx
SocksPort 0
#BridgeRelay 1
#ServerTransportPlugin obfs3 exec /usr/local/bin/obfsproxy managed
#ExtORPort auto
User debian
DataDirectory /usr/local/etc/tor
BandwidthRate 6MBytes
BandwidthBurst 10MBytes
AvoidDiskWrites 1
#TunnelDirConns 1
#PreferTunneledDirConns 1
EntryStatistics 1
ConnDirectionStatistics 1
HidServDirectoryV2 0
HiddenServiceStatistics 1
#DisableDebuggerAttachment 0 #needed for arm stats
Log notice stdout
Log [rend,net,config,dir]info
Both atlas and globe show my relay having the "HSDir" flag, this torrc configuration was last changed on oct 25, and the tor process (and whole computer) was restarted since then.
I probably shouldn't be setting "HiddenServiceStatistics 1" anymore, but shouldn't HidServDirectoryV2 0 supersede HiddenServiceStatistics?
Is the relay being a v1 hidden service directory? I thought v1 was only for auth dirs?Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17793Inconsistent function comment cache_failure_intro_lookup2021-07-22T16:25:32ZcypherpunksInconsistent function comment cache_failure_intro_lookupThe `cache_failure_intro_lookup` function comment mentions that the `intro_entry` remains untouched when no entry is found in the rend failure cache. Yet the `intro_entry` variable is set to `NULL` right from the start.
We should find o...The `cache_failure_intro_lookup` function comment mentions that the `intro_entry` remains untouched when no entry is found in the rend failure cache. Yet the `intro_entry` variable is set to `NULL` right from the start.
We should find out if code depends on this behavior and make the behavior and comment consistent.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17837Move SOCKSPort open proxy warning to a more sensible location2021-07-22T16:25:32ZteorMove SOCKSPort open proxy warning to a more sensible locationThe SOCKSPort open proxy warning in the manual page is just below PreferIPv6.
It should probably be just under the first SOCKSPort paragraph. (Or, perhaps, right at the end of the flags.)
Here is what it says:
```
NOTE: Although this o...The SOCKSPort open proxy warning in the manual page is just below PreferIPv6.
It should probably be just under the first SOCKSPort paragraph. (Or, perhaps, right at the end of the flags.)
Here is what it says:
```
NOTE: Although this option allows you to specify an IP address
other than localhost, you should do so only with extreme
caution. The SOCKS protocol is unencrypted and (as we use it)
unauthenticated, so exposing it in this way could leak your
information to anybody watching your network, and allow anybody
to use your computer as an open proxy.
```Tor: 0.2.7.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17913TestingClient option missing from manual2021-07-22T16:25:32ZDamian JohnsonTestingClient option missing from manualHi Nick, in the [burst of new config options](https://gitweb.torproject.org/tor.git/commit/?id=35bbf2e4) being added to the tor manual one was missed...
**TestingClientBootstrapConsensusAuthorityOnlyMaxDownloadTries**Hi Nick, in the [burst of new config options](https://gitweb.torproject.org/tor.git/commit/?id=35bbf2e4) being added to the tor manual one was missed...
**TestingClientBootstrapConsensusAuthorityOnlyMaxDownloadTries**Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/17971Unrecognized relay in exit address '[scrubbed].exit'. Refusing.2021-07-22T16:25:32ZcypherpunksUnrecognized relay in exit address '[scrubbed].exit'. Refusing.This line appeared in my tor log the other day.
> Unrecognized relay in exit address '[scrubbed].exit'. Refusing.
I don't know what it means, and a quick search didn't return anything useful. I wasn't doing anything out of the ordinary...This line appeared in my tor log the other day.
> Unrecognized relay in exit address '[scrubbed].exit'. Refusing.
I don't know what it means, and a quick search didn't return anything useful. I wasn't doing anything out of the ordinary; just using Tor Browser. I use the system-installed Tor, so it could have come from anything on the system I guess. Safe logging was enabled, so I don't know what address was requested.
When I tried to reproduce it by making an explicit request to foo.nonexistant.exit, I got this.
> The ".exit" notation is disabled in Tor due to security risks. Set AllowDotExit in your torrc to enable it (at your own risk).
What does the first line mean, and why wasn't the request rejected by AllowDotExit=0? Is this something I should be worried about? Even if it's benign, hopefully users who get this warning will find this ticket in searches, since I've been unable to find the exact message anywhere.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18057Be more explicit about the certificate format in `tor-spec.txt`2021-07-22T16:25:32ZTracBe more explicit about the certificate format in `tor-spec.txt`Section 4.2. (“CERTS cells”) of`tor-spec.txt` contains the phrase:
```
The certificate format for the above certificate types is X509.
```
However, X.509 certificates can be uncoded in a number of different formats, DER being the one t...Section 4.2. (“CERTS cells”) of`tor-spec.txt` contains the phrase:
```
The certificate format for the above certificate types is X509.
```
However, X.509 certificates can be uncoded in a number of different formats, DER being the one that's used with Tor.
See the attached patch to improve the sentence like this:
```
The certificate format for the above certificate types is DER encoded X509.
```
**Trac**:
**Username**: herziTor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18140Update dir-spec for "reasonably live" consensuses2021-07-22T16:25:32ZteorUpdate dir-spec for "reasonably live" consensusesIn networkstatus_get_reasonably_live_consensus() and check_expired_networkstatus_callback(), tor has the concept of a "reasonably live" consensus. A consensus is reasonably live if it expired less than 24 hours ago.
This isn't in the di...In networkstatus_get_reasonably_live_consensus() and check_expired_networkstatus_callback(), tor has the concept of a "reasonably live" consensus. A consensus is reasonably live if it expired less than 24 hours ago.
This isn't in the directory spec, should it be?Tor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18145Avoid using "people" when we mean relays in tor's comments2021-07-22T16:25:33ZteorAvoid using "people" when we mean relays in tor's commentsThere are places in the tor codebase where relays and/or clients are referred to as "he" or "guy".
We could remove these unnecessary gender references, as it's more accurate to use "it" or "they".There are places in the tor codebase where relays and/or clients are referred to as "he" or "guy".
We could remove these unnecessary gender references, as it's more accurate to use "it" or "they".Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18146Tor's control protocol misspells "Dependent"2021-07-22T16:25:33ZteorTor's control protocol misspells "Dependent"In getinfo_helper_config(), tor misspells "Dependent" as "Dependant".
There's probably nothing we can do about this, because it's part of the controller interface.
But we should at least document it, preferably in the code and the cont...In getinfo_helper_config(), tor misspells "Dependent" as "Dependant".
There's probably nothing we can do about this, because it's part of the controller interface.
But we should at least document it, preferably in the code and the control spec.Tor: 0.3.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18224Tor control spec doesn't properly specify reply format2021-09-16T14:34:12ZcypherpunksTor control spec doesn't properly specify reply formatThe control spec does not sufficiently specify how to generically parse multi line replies from the controller. The intent seems to be that multi line response data is terminated by a '.' line.
However, this is not specified in the con...The control spec does not sufficiently specify how to generically parse multi line replies from the controller. The intent seems to be that multi line response data is terminated by a '.' line.
However, this is not specified in the control spec section 2.3 and the reply description there is insufficient to properly recognize multi-line reply packets leading to bugs like:
https://trac.torproject.org/projects/tor/ticket/16990https://gitlab.torproject.org/tpo/core/tor/-/issues/18312MapAddress should recommend fingerprints, not nicknames2021-07-22T16:23:43ZteorMapAddress should recommend fingerprints, not nicknamesSince we stopped voting on nicknames, they've become even less reliable as a way to identify a relay.
MapAddress (and similar man page entries) should be updated to recommend the use of fingerprints, not nicknames.Since we stopped voting on nicknames, they've become even less reliable as a way to identify a relay.
MapAddress (and similar man page entries) should be updated to recommend the use of fingerprints, not nicknames.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18345Fix all doxygen "X is not documented" warnings2021-07-22T16:23:43ZteorFix all doxygen "X is not documented" warningsQuoting arma:
It occurred to me while looking at the doxygen comment for
router_is_already_dir_fetching_ds() that if we had something go through
and complain about all cases where there's a function argument that is
not mentione...Quoting arma:
It occurred to me while looking at the doxygen comment for
router_is_already_dir_fetching_ds() that if we had something go through
and complain about all cases where there's a function argument that is
not mentioned by `<b>parameter</b>` (with the markup) in the doxygen
comment... we would end up with a lot of complaints.
We could fix this by placing `<b></b>` around documented parameters, and by documented undocumented parameters.
There might even be a way to semi-automatically do this using a script, and then clean up any mismatches.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18426Fedora has changed the default package manager from yum to dnf2021-07-22T16:23:43ZTracFedora has changed the default package manager from yum to dnfFrom Fedora 22, dnf is now the default package manager (https://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF). The attached patch reflects this.
I'm uncertain if its 100% necessary to do this yet, as using yum to install a package ...From Fedora 22, dnf is now the default package manager (https://fedoraproject.org/wiki/Changes/ReplaceYumWithDNF). The attached patch reflects this.
I'm uncertain if its 100% necessary to do this yet, as using yum to install a package will direct the user to the dnf command but Fedora 22 was released in May 15 so I imagine the majority of users will have upgraded.
**Trac**:
**Username**: icanhasaccountTor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18509Summarize our crypto migration plans in one place2021-07-22T16:23:43ZRoger DingledineSummarize our crypto migration plans in one placeTor has a bunch of crypto use throughout its design: link encryption (nist-style tls), relay identities (1024-bit rsa, soon to be ed25519), circuit handshakes (ntor, but we still support tap), cell crypto (aes), onion service identities ...Tor has a bunch of crypto use throughout its design: link encryption (nist-style tls), relay identities (1024-bit rsa, soon to be ed25519), circuit handshakes (ntor, but we still support tap), cell crypto (aes), onion service identities (1024-bit rsa, but soon to be this complicated thing), and probably a few more.
People keep misunderstanding where we are in the crypto migration plan ("omg tor still uses 1024-bit rsa"). It would be nice to have it all written out in one place that we can reference.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18720Improve comments on connection_t address2021-07-22T16:23:44ZteorImprove comments on connection_t addressIn legacy/trac#18460, we discovered that the comments on connection_t's address field were unhelpful.
Once I have the bug number, I'll post a patch to those comments.In legacy/trac#18460, we discovered that the comments on connection_t's address field were unhelpful.
Once I have the bug number, I'll post a patch to those comments.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18736[Manual] Add some information about sub-domain rules2021-07-22T16:23:44Zcypherpunks[Manual] Add some information about sub-domain ruleshttps://www.torproject.org/docs/tor-manual.html.en
> HIDDEN SERVICE OPTIONS
> The following options are used to configure a hidden service.
We need official statement about second-level domain(subdomain) of .onion.
Likely,
> this one(1...https://www.torproject.org/docs/tor-manual.html.en
> HIDDEN SERVICE OPTIONS
> The following options are used to configure a hidden service.
We need official statement about second-level domain(subdomain) of .onion.
Likely,
> this one(1) and,
> git.xxxxxxxxx.onion
are using second level domain.
I know only two URLs.
1: https://tor.stackexchange.com/questions/10068/sub-domain-of-onion-is-allowed-officialyTor: 0.3.2.x-finalNick MathewsonNick Mathewson