The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-07-22T16:25:47Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13381tor man page says you can use nicknames for node selection2021-07-22T16:25:47ZRoger Dingledinetor man page says you can use nicknames for node selectionE.g.
```
[[ExitNodes]] **ExitNodes** __node__,__node__,__...__::
A list of identity fingerprints, nicknames, country codes and address
patterns of nodes to use as exit node
```
do nicknames still work here, now that we've gotten...E.g.
```
[[ExitNodes]] **ExitNodes** __node__,__node__,__...__::
A list of identity fingerprints, nicknames, country codes and address
patterns of nodes to use as exit node
```
do nicknames still work here, now that we've gotten rid of the Named flag in practice?Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13158Did we ever document +/ semantics for config files?2021-07-22T16:25:47ZSebastian HahnDid we ever document +/ semantics for config files?I can't find any kind of documentation in the manpage or anywhere else besides a couple of comments in the source code. Is it anywhere? What are the exact semantics we're going for?
I'm tentatively marking this for 0.2.5.x, because it's...I can't find any kind of documentation in the manpage or anywhere else besides a couple of comments in the source code. Is it anywhere? What are the exact semantics we're going for?
I'm tentatively marking this for 0.2.5.x, because it's a documentation fixTor: 0.2.8.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12748INTERNALS document2021-07-22T16:26:02Zrl1987INTERNALS documentWrite a document that describes implementation details and inner workings of Tor, like http://gcc.gnu.org/onlinedocs/gccint/ or http://www.phpinternalsbook.com/ .Write a document that describes implementation details and inner workings of Tor, like http://gcc.gnu.org/onlinedocs/gccint/ or http://www.phpinternalsbook.com/ .Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12670HiddenServicePort TARGET IPv6 address2021-07-22T16:26:02ZgrarpampHiddenServicePort TARGET IPv6 addressThe man page HiddenServicePort does not say anything about TARGET being an IPv6 address. Since Tor is becoming IPv6 enabled it probably should (ie: ::1, and precedence). There are some combinations to consider supporting if not already d...The man page HiddenServicePort does not say anything about TARGET being an IPv6 address. Since Tor is becoming IPv6 enabled it probably should (ie: ::1, and precedence). There are some combinations to consider supporting if not already done (latter dependant on host if tor is not bound to both)...
4 -> TARGET 4
6 -> TARGET 6
4 -> TARGET 6
6 -> TARGET 4Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11634fix warnings from "make check-docs"2021-07-22T16:26:02ZNick Mathewsonfix warnings from "make check-docs"It looks like tor.1.txt has gotten out of sync with tor again; better fix that.It looks like tor.1.txt has gotten out of sync with tor again; better fix that.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11321We stopped being able to build torify.1, and stopped trying to build it.2021-07-22T16:26:02ZNick MathewsonWe stopped being able to build torify.1, and stopped trying to build it.When we merged f8c45339f72525c6826d6db6a5e2acc4d7475952 to stop preprocessing the torify script, we broke the ability to preprocess the torify manpage... or indeed to build it at all.
We also stopped trying to build it unless building ...When we merged f8c45339f72525c6826d6db6a5e2acc4d7475952 to stop preprocessing the torify script, we broke the ability to preprocess the torify manpage... or indeed to build it at all.
We also stopped trying to build it unless building tor-fw-helper.
Silly us.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11108SocksPolicy and DirPolicy ignore port specifications, contrary to documentation2021-07-22T16:26:02ZcypherpunksSocksPolicy and DirPolicy ignore port specifications, contrary to documentationThe documentation for SocksPolicy and DirPolicy both say "policies have the same form as exit policies", but looking at the code at https://gitweb.torproject.org/tor.git/blob/4348c52a353a5242ddefc5c866ffb58e98443c7e:/src/or/policies.c#l3...The documentation for SocksPolicy and DirPolicy both say "policies have the same form as exit policies", but looking at the code at https://gitweb.torproject.org/tor.git/blob/4348c52a353a5242ddefc5c866ffb58e98443c7e:/src/or/policies.c#l344 it appears both only consider the address, not the port number. The documentation should be updated to reflect this.
(It seems unlikely to me that limiting the source ports allowed to connect to these listeners is actually a feature anyone wants, but maybe it is?)Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11060socks-extensions.txt says username/password are ignored2021-07-22T16:26:02ZRoger Dingledinesocks-extensions.txt says username/password are ignoredIn torspec's socks-extensions.txt, we say
```
and as of Tor 0.2.3.2-alpha, the "USERNAME/PASSWORD" (SOCKS5)
authentication method [02] is supported too. Any credentials passed to
the latter are ignored.
```
But don't we use ...In torspec's socks-extensions.txt, we say
```
and as of Tor 0.2.3.2-alpha, the "USERNAME/PASSWORD" (SOCKS5)
authentication method [02] is supported too. Any credentials passed to
the latter are ignored.
```
But don't we use them for stream isolation now?
Also (hit-and-run two-bugs-in-one-ticket faux pas, sorry), the Tor man page says:
```
IsolateSOCKSAuth
Don’t share circuits with streams for which different SOCKS
authentication was provided. (On by default; you can disable it
with NoIsolateSOCKSAuth.)
```
which makes it sound like we look at SOCKS4 username too -- maybe we should change SOCKS to SOCKS5 in this man page stanza?Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11007Add more documentation about EntryGuardAddedBy in the state file2021-07-22T16:26:02ZcypherpunksAdd more documentation about EntryGuardAddedBy in the state fileDocument better how EntryGuardAddedBy date is calculated and written in the state file (well, more documentation about all the state file would be also good).
Should we also change the way the date is calculated?
The EntryGuardAddedBy ...Document better how EntryGuardAddedBy date is calculated and written in the state file (well, more documentation about all the state file would be also good).
Should we also change the way the date is calculated?
The EntryGuardAddedBy dates in the state file are not sequential because the date is calculated as the real date minus a random date between the real and 30 days before [1].
The reason for this is to avoid revealing the real date the user was online at that date to that entry guard.
The only existent documentation is in doc/state-contents.txt
[1] e->chosen_on_date = time(NULL) - crypto_rand_int(3600*24*30);Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10881Drop AlternativeHSAuthority and friends2021-07-22T16:26:02ZNick MathewsonDrop AlternativeHSAuthority and friendsWe haven't had a notion of an HSAuthority since we dropped the v0 hidden service descriptor design completely back in 0.2.2. (See legacy/trac#10841 for more.) Specifically, in 0.2.2 or later, neither clients nor relays publish anything...We haven't had a notion of an HSAuthority since we dropped the v0 hidden service descriptor design completely back in 0.2.2. (See legacy/trac#10841 for more.) Specifically, in 0.2.2 or later, neither clients nor relays publish anything resembling a v0 hidden service descriptor, and "HS authorities" have nothing to do.
That said, we should drop the vestigial AlternativeHSAuthority option, since it has apparently has misled some folks into thinking that we do have HS authorities. (See legacy/trac#10722.)Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/10124Documentation and log entries still refer to DirServer2021-07-22T16:26:02ZTracDocumentation and log entries still refer to DirServerDocumentation and log warnings still refer to the DirServer configuration option, but the documentation itself only defines DirAuthority, leaving the user guessing what could be meant.
(I have a patch.)
**Trac**:
**Username**: sqrt2Documentation and log warnings still refer to the DirServer configuration option, but the documentation itself only defines DirAuthority, leaving the user guessing what could be meant.
(I have a patch.)
**Trac**:
**Username**: sqrt2Tor: 0.2.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9866add anchors to the manpage2021-07-22T16:26:02Zweasel (Peter Palfrader)add anchors to the manpageIt would be nice if https://www.torproject.org/docs/tor-manual.html.en had anchors so we could link to specific config options.
I suspect adding the relevant anchors to our asciidoc tor manpage might make that happen.It would be nice if https://www.torproject.org/docs/tor-manual.html.en had anchors so we could link to specific config options.
I suspect adding the relevant anchors to our asciidoc tor manpage might make that happen.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9655Tor manual's config default options could be clearer2021-07-22T16:26:02ZTracTor manual's config default options could be clearerCurrently the default value for an option is suffixed on the description body, e.g.
**UseMicrodescriptors** **0**|**1**|**auto**:: Microdescriptors are a smaller version of the information that Tor needs in order to build its circuits....Currently the default value for an option is suffixed on the description body, e.g.
**UseMicrodescriptors** **0**|**1**|**auto**:: Microdescriptors are a smaller version of the information that Tor needs in order to build its circuits. Using microdescriptors makes Tor clients download less directory information, thus saving bandwidth. Directory caches need to fetch regular descriptors and microdescriptors, so this option doesn’t save any bandwidth for them. If this option is set to "auto" (recommended) then it is on for all clients that do not set FetchUselessDescriptors. (Default: auto)
If you read this example it reads as if FetchUselessDescriptiors is defaulted to auto (It's actually defaulted to zero) when it actually means to show that UseMicrodescriptors defaults to auto.
I think it would be clearer if the default was clearly seperated from the description body, maybe as a subheader for each option.
**Trac**:
**Username**: RyTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9627Document ExtORPort in tor manual page2021-07-22T16:26:02ZDavid Fifielddcf@torproject.orgDocument ExtORPort in tor manual pageI did `man doc/tor.1` to see if my current checkout had support for ExtORPort and what the syntax was; it did have support but the option was not in the manual page.I did `man doc/tor.1` to see if my current checkout had support for ExtORPort and what the syntax was; it did have support but the option was not in the manual page.Tor: 0.2.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8964doc/HACKING is out of date2021-07-22T16:26:02ZRobert Ransomdoc/HACKING is out of date(as of commit e7134c2375f3c577ab7dcc20c74c5773d1a5f37d)
Line 43 states that the maint-0.2.1 branch is currently ‘actively developed’. It should not.
Line 54 uses “bug 9999” as a dummy bug number. That ticket will be opened this year....(as of commit e7134c2375f3c577ab7dcc20c74c5773d1a5f37d)
Line 43 states that the maint-0.2.1 branch is currently ‘actively developed’. It should not.
Line 54 uses “bug 9999” as a dummy bug number. That ticket will be opened this year.
Line 96 refers to “https://buildbot.vidalia-project.net/one_line_per_build”. I don't believe that that URL is still valid.
The Doxygen formatting details (starting after line 329) are frequently ignored in practice. That's probably a good thing, because fewer developers use Doxygen than jump around in the source using TAGS files and grep and read the comments directly. If you don't agree that abandoning Doxygen is a good idea, `make check-spaces` should detect and complain about at least gross problems (e.g. characters that should be escaped left unescaped).
The HACKING file does not mention using a TAGS file. (I put “`find src/ -name '*.[hc]' |etags -`” in my Git post-checkout hook.)Tor: 0.2.6.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/8948Write a "code review guidelines" page2021-07-22T16:26:02ZNick MathewsonWrite a "code review guidelines" pageCheck out this awesome page that Twisted has:
https://twistedmatrix.com/trac/wiki/ReviewProcess
We should totally get one like it to give people a checklist of what to do when they're coding.Check out this awesome page that Twisted has:
https://twistedmatrix.com/trac/wiki/ReviewProcess
We should totally get one like it to give people a checklist of what to do when they're coding.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7876Tor DNS capabilities should be documented somewhere2021-07-22T16:26:02ZMoritz BartlTor DNS capabilities should be documented somewhereWhat questions can Tor's DNSPort answer? We should put that somewhere. If the answer is not overly complex, I suggest it should be in the Tor manual under "DNSPort".
nickm, arma wants me to ask you first about the current state of Tor D...What questions can Tor's DNSPort answer? We should put that somewhere. If the answer is not overly complex, I suggest it should be in the Tor manual under "DNSPort".
nickm, arma wants me to ask you first about the current state of Tor DNS answers.Tor: 0.2.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7826Specs contain undocumented "ipv6-policy" lines2021-07-22T16:26:01ZDamian JohnsonSpecs contain undocumented "ipv6-policy" linesOh how I love stem's descriptor tests. They're so wonderfully nit-picky.
The server descriptor for toorvoid (an IPv6 exit using Tor 0.2.4.7-alpha) contains an "ipv6-policy" line. This is mentioned in proposal 208 (IPv6 Exits Redux) but ...Oh how I love stem's descriptor tests. They're so wonderfully nit-picky.
The server descriptor for toorvoid (an IPv6 exit using Tor 0.2.4.7-alpha) contains an "ipv6-policy" line. This is mentioned in proposal 208 (IPv6 Exits Redux) but is not yet in the specs.
The spec has frequently been missing new tor additions. Is there anything that we can do to fix that? I flag spec changes in my email to make the corresponding changes in stem, so if the spec doesn't change then I'm unaware of it.
Here's the full descriptor...
```
@downloaded-at 2012-12-30 07:24:36
@source "188.138.104.154"
router toorvoid 83.212.96.201 443 0 993
or-address [2001:648:2ffc:1112:a80c:eaff:feda:b0db]:443
platform Tor 0.2.4.7-alpha on Linux
protocols Link 1 2 Circuit 1
published 2012-12-29 16:14:48
fingerprint 0B37 3232 98FF 98CD 86ED 4048 95BB 27B7 426E 8AE1
uptime 233569
bandwidth 8704000 9216000 4171880
extra-info-digest 005AA0068E524A900D09FD949D1DB14C745B34E0
onion-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAO0kckCtEvVIBVi+du47U/C7u1Ybal/Zl6XGTKh2C0yu1Iey32iwj/o9
pIHq3T7GdU9ZzwYSAsXSuDUN2g2D9B2kDHqO1k8DIfXDV/M8E+vpnuQ7dHNjJOBL
kLmxftOrf2eFr41lQyRQQ31IxojPPHSAIKhiEYrBSlOK0/fAvU2jAgMBAAE=
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAMTezvB8ykqV7SpS4Lzv55UJnLy6PjSTirsYiUAFoAbMwr1vrQNPvDcd
8AAjgYZqUheCfrPffry/aAswS2QKSeYToFaCr1OGQ36xCWjXQLNS39RnnkXgVqqW
UefHaELcQ8FVUnr9vyIPCRJCFhpXrvK9G/ayZ0dass2vPrlLw3uFAgMBAAE=
-----END RSA PUBLIC KEY-----
family $7C312668970B5AA53DF89BD6B5394ED9019124D2
hidden-service-dir
contact 1024D/E4F4FFE6
reject 0.0.0.0/8:*
reject 169.254.0.0/16:*
reject 127.0.0.0/8:*
reject 192.168.0.0/16:*
reject 10.0.0.0/8:*
reject 172.16.0.0/12:*
reject 83.212.96.201:*
accept *:22
accept *:23
accept *:53
accept *:80
accept *:110
accept *:143
accept *:443
accept *:993
accept *:995
accept *:6667
accept *:6668
accept *:6669
accept *:6666
accept *:7000
accept *:8080
accept *:8443
accept *:554
accept *:1755
reject *:*
ipv6-policy accept 22-23,53,80,110,143,443,554,993,995,1755,6666-6669,7000,8080,8443
router-signature
-----BEGIN SIGNATURE-----
ejUGInU/ZbOOAACyC/coUJMg7r9obKLRRLef7aj6XjSUv6uKnvIyKEcXQVagjj0v
jc3os/aEbVHprOcjcTs0JIwOyII3c8s/7Zm5dtXgDnGrmKNiwktKmjAQ2swCKntA
vyWMrp2iqiKPsLTTMk0lZRZe105Dh9X/bhv23FAu/qs=
-----END SIGNATURE-----
```Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7483Update default torrc with new entries2021-07-22T16:26:01ZNick MathewsonUpdate default torrc with new entriesWe want to update our default torrc only infrequently, since it hassle for users of some operating systems, but it may be time eventually. Let's list the places we might want to update here on this ticket, so that when we *do* update, w...We want to update our default torrc only infrequently, since it hassle for users of some operating systems, but it may be time eventually. Let's list the places we might want to update here on this ticket, so that when we *do* update, we'll know what we want to add.
* The *4 and *6 syntax for exit policies.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6892improve torify manpage to say different connections may be over the same circ...2021-07-22T16:26:01Zweasel (Peter Palfrader)improve torify manpage to say different connections may be over the same circuit.Linus Lüssing would like the torify manpage to spell out that it does not do anything to make different torify calls unlinkable.
Probably not an unreasonable request.
For details of his request see
http://bugs.debian.org/681123
Cheers...Linus Lüssing would like the torify manpage to spell out that it does not do anything to make different torify calls unlinkable.
Probably not an unreasonable request.
For details of his request see
http://bugs.debian.org/681123
Cheers,
weaselTor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org