Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:52:36Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33742Add information about design paper and anonbib inside README.1st2020-06-13T15:52:36ZGhost UserAdd information about design paper and anonbib inside README.1stAs mentioned under #33688 (comment 9) some old "TODO" items were removed from `doc/HACKING/README.1st.md` file.
Link and description should be added for:
- design paper,
- anonbib.As mentioned under #33688 (comment 9) some old "TODO" items were removed from `doc/HACKING/README.1st.md` file.
Link and description should be added for:
- design paper,
- anonbib.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33741Format code blocks inside markdown files (documentation)2020-06-13T15:52:36ZGhost UserFormat code blocks inside markdown files (documentation)There are issues with code blocks inside some *.md files (some files use code blocks syntax, some do not). First of all, it's not consistent but what's really bad is when *.md file is being displayed incorrectly. You can find an example ...There are issues with code blocks inside some *.md files (some files use code blocks syntax, some do not). First of all, it's not consistent but what's really bad is when *.md file is being displayed incorrectly. You can find an example of what I'm saying in CodingStandards.md under How we log changes section.
https://github.com/torproject/tor/blob/master/doc/HACKING/CodingStandards.md#how-we-log-changes
Part of the git log output is still displayed as a regular text rather than a formatted code block.
Goal of this ticket is to go through all *.md files under `doc` and `doc/HACKING` directories and format code snippets accordingly.
```
```c
// code snippet
// written in
// C language
```
```
```
```bash
// command to be run
// inside bash
```
```
This should fix the issues described above and enable syntax highlighting on supported websites and editors.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/33688README cleanups2020-06-13T15:52:30ZGhost UserREADME cleanupsHello everyone,
I just started playing around with Tor a few days back so as one could expect I started with `README.1st.md` file. I realized that different `*.md` files are not consistent style-wise so I decided to clean them up a bit.
...Hello everyone,
I just started playing around with Tor a few days back so as one could expect I started with `README.1st.md` file. I realized that different `*.md` files are not consistent style-wise so I decided to clean them up a bit.
Brief summary:
- no empty line at the very beginning of the file,
- single empty line between sections (sometimes there were two)
```
... end of the sentence.
New Section
----
```
rather than
```
... end of the sentence.
New Section
----
```
- external links use [name](url) format,
- there is no single space in front of the section name
```
Foo
===
```
is changed to
```
Foo
===
```
Which fixes syntax issues in editors like GNU Emacs with enabled markdown preview.
- I tried to check all links (local and external) and fix the ones which were broken.
For example **the Tor proposal process** inside `README.1st.md` or `doc/WritingTests.txt` were changed to `.../doc/HACKING/WritingTests.md` in few places).
----
At the very end of `README.1st.md` file there are some TODO (I think?) sections. I wrapped them around in "TODO" section.
```
TODO
-----------------------
XXXXX also describe
doc/HACKING/WritingTests.md
torguts.git
torspec.git
The design paper
freehaven.net/anonbib
XXXX describe these and add links.
```
However I am not sure if these are still needed there. Most of these topics are mentioned already in this file and linked to other files (WritingTests, torspec, etc.).Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/31478CodeStructure.md is not markdown compliant2020-06-13T15:44:26ZTracCodeStructure.md is not markdown compliantHello,
While going through the Tor project documentation, I saw a TODO in the file `doc/HACKING/CodeStructure.md` which is currently using a malformed markdown.
I will re-format the documentation in this file if that's fine for you.
*...Hello,
While going through the Tor project documentation, I saw a TODO in the file `doc/HACKING/CodeStructure.md` which is currently using a malformed markdown.
I will re-format the documentation in this file if that's fine for you.
**Trac**:
**Username**: aveuillerTor: 0.4.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30799Fix a small memory leak in nt_service_install() in ntmain.c2020-06-13T15:42:17ZTracFix a small memory leak in nt_service_install() in ntmain.cA string buffer `command` is allocated on L559, but it's not freed if `service_fns.LookupAccountNameA_fn` returns FALSE. The patch I attached adds `tor_free(command);` in this `else if` branch.
**Trac**:
**Username**: xiaoyinlA string buffer `command` is allocated on L559, but it's not freed if `service_fns.LookupAccountNameA_fn` returns FALSE. The patch I attached adds `tor_free(command);` in this `else if` branch.
**Trac**:
**Username**: xiaoyinlTor: 0.4.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30299Switch network interface2020-06-13T15:41:01ZTracSwitch network interfaceI have standalone Tor client listening on localhost port 53 for DNS UDP packets on a Ubuntu 18.04 VM environment. This is the equivalent to setting on /etc/tor/torrc:
DNSPort 127.0.0.1:53
I also have a DNS rule on network manager set t...I have standalone Tor client listening on localhost port 53 for DNS UDP packets on a Ubuntu 18.04 VM environment. This is the equivalent to setting on /etc/tor/torrc:
DNSPort 127.0.0.1:53
I also have a DNS rule on network manager set to redirect DNS packets to IP:
127.0.0.1
After following the standard OpenVPN configuration, I make a connection to the VPN server with:
openvpn --config /etc/openvpn/servers-conf/01.example.tcp.ovpn
The problem is Tor receives the DNS UDP packets, converts them to TCP packets and then attempts to send them through my main "naked" network interface to Tor relays, instead of using the secure tun0 interface. OpenVPN sees the TCP packet leaving the "naked" interface and thinks this is not safe and blocks them, which means I'm not able to resolve domain names as Tor's DNS TCP packets can't leave the system.
In order to fix this, I have to restart Tor using:
systemctl restart tor
This then updates Tor to connect to tun0 and everything works fine again however, it would make sense to have Tor update automatically or to have an option to specify a network interface order for Tor to connect to. Example:
InterfacePref: tun0, tun1, eth0
Similar to a bootloader selecting what to boot first, this means Tor would always try to connect to tun0 if available, if not it will try tun1 and else eth0. If at any time a better interface comes up Tor should switch to it automatically. A default value would still connect to the default interface as it does today.
**Trac**:
**Username**: enriquejr99Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30094MAPADDRESS exitnode by CountryCode2020-06-13T15:40:29ZcypherpunksMAPADDRESS exitnode by CountryCodeThe general idea is to have MAPADDRES match Country of exitnode addresses with one rule:
MAPADDRESS 1.2.3.4 1.2.3.4.<CC>.exit
Very useful for:
o geoblocking bypasses...
o censor testsThe general idea is to have MAPADDRES match Country of exitnode addresses with one rule:
MAPADDRESS 1.2.3.4 1.2.3.4.<CC>.exit
Very useful for:
o geoblocking bypasses...
o censor testsTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30085Bug: Unexpectedly high use successes counts (101.500000/100.000000) for guard2020-06-13T15:40:27ZcypherpunksBug: Unexpectedly high use successes counts (101.500000/100.000000) for guardI repeatly see counters above current? Log:
Bug: Unexpectedly high use successes counts (101.500000/100.000000) for guard $F6740DEABFD5F62612FA025A5079EA72846B1F67 ($F6740DEABFD5F62612FA025A5079EA72846B1F67) (on Tor 0.3.4.9 4ac3ccf2863b8...I repeatly see counters above current? Log:
Bug: Unexpectedly high use successes counts (101.500000/100.000000) for guard $F6740DEABFD5F62612FA025A5079EA72846B1F67 ($F6740DEABFD5F62612FA025A5079EA72846B1F67) (on Tor 0.3.4.9 4ac3ccf2863b86e7)Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/30084Relay: channel_tls_process_netinfo_cell private IP as public wrongly reported2020-06-13T15:40:27ZcypherpunksRelay: channel_tls_process_netinfo_cell private IP as public wrongly reportedLog output:
Nov 06 17:11:10.000 [info] {OR} channel_tls_process_netinfo_cell(): We made a connection to a relay at 92.167.89.160:9001 (fp=427E5C8ADC43B09582DDDA80EA8EDFBD05DF5003) but we think they will not consider this connection canon...Log output:
Nov 06 17:11:10.000 [info] {OR} channel_tls_process_netinfo_cell(): We made a connection to a relay at 92.167.89.160:9001 (fp=427E5C8ADC43B09582DDDA80EA8EDFBD05DF5003) but we think they will not consider this connection canonical. They think we are at 10.42.194.61, but we think its
92.222.41.125.
Nov 06 17:30:35.000 [info] {OR} channel_tls_process_netinfo_cell(): Got good NETINFO cell from 92.167.89.160:9001; OR connection is now open, using protocol version 5. Its ID digest is 033DC13D5639A530C098388D8F53A693D76AD59B. Our address is apparently
10.42.194.61.
10.42.194.61 does not exist in Intranet. It's reported wrongly by remote relay.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/29499permission error: nyx requires executable permission bit for `/var/lib/tor`2020-06-13T15:38:11Zcypherpunkspermission error: nyx requires executable permission bit for `/var/lib/tor`Offending logs from strace:
```
stat("/var/lib/tor/control_auth_cookie", 0x7ffca7ba61f0) = -1 EACCES (Permission denied)
stat("/var/lib/tor/control_auth_cookie", 0x7ffca7ba61f0) = -1 EACCES (Permission denied)
write(1, "We were unable to...Offending logs from strace:
```
stat("/var/lib/tor/control_auth_cookie", 0x7ffca7ba61f0) = -1 EACCES (Permission denied)
stat("/var/lib/tor/control_auth_cookie", 0x7ffca7ba61f0) = -1 EACCES (Permission denied)
write(1, "We were unable to read tor's aut"..., 176We were unable to read tor's authentication cookie...
Path: /var/lib/tor/control_auth_cookie
Issue: Authentication failed: '/var/lib/tor/control_auth_cookie' doesn't exist) = 176
```
Permissions on /var/lib/tor:
` drwx------ 3 tor tor 4.0K Feb 14 17:04 tor `
Permissions for cookie file:
` -rw-r----- 1 tor tor 32 Feb 13 06:36 control_auth_cookie `
A quick fix on the user part is to add the executable bit for group, but in general the cookie file should be accessible without the executable bit set so as long as the cookie file is configured to be readable by group (i.e. 'CookieAuthFileGroupReadable 1' written in /etc/tor/torrc).Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26703Lower log level of "Scheduler type KIST has been enabled"2020-06-13T15:27:46ZpastlyLower 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-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/26567Replace ArgumentCharValue with ValueChar in dir-spec and bandwidth-file-spec2020-06-13T15:27:23ZteorReplace 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:15Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/26492code style improvements for src/rust/protover/ffi.rs2020-06-13T15:27:08ZTraccode style improvements for src/rust/protover/ffi.rsWas reading through `src/rust/protover/ffi.rs` and made a few changes along the way. Here's my git branch:
https://github.com/frewsxcv/tor/compare/frewsxcv-stringlist-refactor
Each change is isolated to its own commit.
**Trac**:
**U...Was reading through `src/rust/protover/ffi.rs` and made a few changes along the way. Here's my git branch:
https://github.com/frewsxcv/tor/compare/frewsxcv-stringlist-refactor
Each change is isolated to its own commit.
**Trac**:
**Username**: frewsxcvTor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/26138DirPort /tor/server/all document contains spurrious blank line following serv...2020-06-13T15:25:47ZstarlightDirPort /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/legacy/trac/-/issues/26076test_keygen.sh and test_key_expiration.sh fail on Windows2020-06-13T15:28:13ZTractest_keygen.sh and test_key_expiration.sh fail on Windows```
FAIL: src/test/test_keygen.sh
=============================
May 11 01:50:30.175 [warn] Path for GeoIPFile (<default>) is relative and will resolve to C:\projects\appveyor\i686-w64-mingw32\<default>. Is this what you wanted?
May 11 01...```
FAIL: src/test/test_keygen.sh
=============================
May 11 01:50:30.175 [warn] Path for GeoIPFile (<default>) is relative and will resolve to C:\projects\appveyor\i686-w64-mingw32\<default>. Is this what you wanted?
May 11 01:50:30.175 [warn] Path for GeoIPv6File (<default>) is relative and will resolve to C:\projects\appveyor\i686-w64-mingw32\<default>. Is this what you wanted?
Tor didn't declare that there would be no encryption
FAIL src/test/test_keygen.sh (exit status: 5)
SKIP: src/test/fuzz_static_testcases.sh
```
Edit: when we fix this bug, we should revert #26830 and #26853, which skips these tests on Windows
**Trac**:
**Username**: saperTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/25978UseEntryGuards 0 disables EntryNodes2020-06-13T15:25:13ZTracUseEntryGuards 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/legacy/trac/-/issues/25965Document default value of Nickname parameter [patch]2020-06-13T15:25:09ZTracDocument default value of Nickname parameter [patch]While responding to an inquiry on IRC regarding [[Plinth issue #1294: tor: let the user verify if the relay is connected](https://salsa.debian.org/freedombox-team/plinth/issues/1294|Freedombox)] I was wondering what happens if the `Nickn...While responding to an inquiry on IRC regarding [[Plinth issue #1294: tor: let the user verify if the relay is connected](https://salsa.debian.org/freedombox-team/plinth/issues/1294|Freedombox)] I was wondering what happens if the `Nickname` is not set.
I had to refer to the source code to find out.
I have published a change that fixes this:
http://repo.or.cz/tor/appveyor.git/shortlog/refs/heads/default_nickname
("default_nickname" branch on http://repo.or.cz/tor/appveyor.git)
**Trac**:
**Username**: saperTor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/25857::/128 is not the IPv6 equivalent of 0.0.0.0/02020-06-13T15:24:33ZTrac::/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/legacy/trac/-/issues/25602Fix two comment typos in hs_cell.c2020-06-13T15:23:30ZIsis LovecruftFix two comment typos in hs_cell.cTor: 0.3.4.x-finalIsis LovecruftIsis Lovecrufthttps://gitlab.torproject.org/legacy/trac/-/issues/25188Spec bug in formal definition of Document in dir-spec.txt2020-06-13T15:21:48ZTracSpec bug in formal definition of Document in dir-spec.txtI was attempting to write a parser that reads vote/consensus documents using the the formal definition [here](https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n210). However, I noticed an ambiguity.
Using only the formal defi...I was attempting to write a parser that reads vote/consensus documents using the the formal definition [here](https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n210). However, I noticed an ambiguity.
Using only the formal definition, the following:
```
directory-signature 13241234321 12343234
-----BEGIN SIGNATURE-----
00thisisvalidbase64data12345
-----END SIGNATURE-----
```
Could be potentially parsed as
```
Document(
Item(
KeywordLine(
Keyword(KeywordChar+("directory-signature")),
WS,
ArgumentChar+("13241234321 12343234"),
NL
)
),
Item(
KeywordLine(
Keyword(KeywordChar+("-----BEGIN")),
WS,
ArgumentChar+("SIGNATURE-----"),
NL
)
),
Item(
KeywordLine(
Keyword(KeywordChar+("00thisisvalidbase64data12345"))
WS,
ArgumentChar+("SIGNATURE-----"),
NL
)
),
Item(
KeywordLine(
Keyword(KeywordChar+("-----END")),
WS,
ArgumentChar+("SIGNATURE-----"),
NL
)
),
)
```
When the correct parsing would be
```
Document(
Item(
KeywordLine(
Keyword(KeywordChar+("directory-signature")),
WS,
ArgumentChar+("13241234321 12343234"),
NL
),
Object(
BeginLine(
"-----BEGIN ",
Keyword(KeywordChar+("SIGNATURE")),
"-----",
NL
),
Base64-encoded-data("00thisisvalidbase64data12345"),
EndLine(
"-----END ",
Keyword(KeywordChar+("SIGNATURE")),
"-----",
NL
),
),
),
)
```
A potential change to the spec (assuming that keywords will never start with "-") that would prevent would be to replace
```
Keyword = KeywordChar+
KeywordChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-'
```
with
```
Keyword = KeywordStartChar KeywordChar*
KeywordStartChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9'
KeywordChar ::= 'A' ... 'Z' | 'a' ... 'z' | '0' ... '9' | '-'
```
**Trac**:
**Username**: witchof0x20Tor: 0.3.4.x-final