The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-07-24T12:27:48Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/2077Overwriting files can fail on Windows2020-07-24T12:27:48ZTracOverwriting files can fail on WindowsUsing Firefox 3.6.10, Vista x64 hm prem, SP2.
Crashes w/ older Tor versions were rare for me. Since installing alpha ver listed, several crashes in 2 days. Doing nothing diff (except later ver of Firefox). No warning / signs of thing...Using Firefox 3.6.10, Vista x64 hm prem, SP2.
Crashes w/ older Tor versions were rare for me. Since installing alpha ver listed, several crashes in 2 days. Doing nothing diff (except later ver of Firefox). No warning / signs of things going bad before get crash notice (Tor has stopped working).
These seem to be main warnings from log:
Vidala log errors:
Oct 15 12:59:21.741 [Warning] Error replacing "C:\Users\<user name>\AppData\Roaming\tor\state": File exists
Oct 15 12:59:21.743 [Warning] Unable to write state to file "C:\Users\<user name>\AppData\Roaming\tor\state"
Note: the user\AppData path is not protected - the acct I was running in Vista at time of Tor crash has full access to the paths \ files mentioned above.
The file: state.tmp DOES exist in the location mentioned.
I can open / read - state.tmp - (after Tor crash & Tor is shut down). Has no obvious errors msgs in the file.
There's another file: "lock" (w/ 0 bytes) in same folder as state.tmp (after crash & Tor / Vidalia are shut down).
Properties of the "lock" file show was created yesterday 10/14, & last mod 10/15. Its file attribs are "AN" - archived, not indexed? Other than that, no real info on it.
Err Rpt from Windows Vista x64 prepared to send to MS:
Problem signature:
Problem Event Name: APPCRASH
Application Name: tor.exe
Application Version: 0.0.0.0
Application Timestamp: 4ca65e57
Fault Module Name: tor.exe
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 4ca65e57
Exception Code: c0000005
Exception Offset: 000c3bf9
OS Version: 6.0.6002.2.2.0.768.3
Locale ID: 1033
Additional Information 1: fd00
Additional Information 2: ea6f5fe8924aaa756324d57f87834160
Additional Information 3: fd00
Additional Information 4: ea6f5fe8924aaa756324d57f87834160
**Trac**:
**Username**: joebtTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/3266gabelmoo publishes only 1 extra-info descriptor per week2020-06-27T14:08:16ZKarsten Loesinggabelmoo publishes only 1 extra-info descriptor per weekI noticed that gabelmoo started publishing exactly 1 extra-info descriptor per **week** a couple of weeks ago. Here are the number of server descriptors and extra-info descriptors that gabelmoo published per day in 2011:
```
date ...I noticed that gabelmoo started publishing exactly 1 extra-info descriptor per **week** a couple of weeks ago. Here are the number of server descriptors and extra-info descriptors that gabelmoo published per day in 2011:
```
date | platform | serverdescs | extrainfos
------------+-----------------------------------------------------------+-------------+------------
2011-01-01 | Tor 0.2.2.20-alpha (git-aae58deb2cdcaad0) on Linux x86_64 | 2 | 2
2011-01-02 | Tor 0.2.2.20-alpha (git-aae58deb2cdcaad0) on Linux x86_64 | 1 | 1
2011-01-03 | Tor 0.2.2.20-alpha (git-aae58deb2cdcaad0) on Linux x86_64 | 1 | 1
2011-01-04 | Tor 0.2.2.20-alpha (git-aae58deb2cdcaad0) on Linux x86_64 | 2 | 2
2011-01-05 | Tor 0.2.2.20-alpha (git-aae58deb2cdcaad0) on Linux x86_64 | 1 | 1
2011-01-06 | Tor 0.2.2.20-alpha (git-aae58deb2cdcaad0) on Linux x86_64 | 1 | 1
2011-01-07 | Tor 0.2.2.20-alpha (git-aae58deb2cdcaad0) on Linux x86_64 | 1 | 1
2011-01-08 | Tor 0.2.2.20-alpha (git-aae58deb2cdcaad0) on Linux x86_64 | 2 | 2
2011-01-09 | Tor 0.2.2.20-alpha (git-aae58deb2cdcaad0) on Linux x86_64 | 1 | 1
2011-01-10 | Tor 0.2.2.20-alpha (git-aae58deb2cdcaad0) on Linux x86_64 | 1 | 1
2011-01-11 | Tor 0.2.2.20-alpha (git-aae58deb2cdcaad0) on Linux x86_64 | 2 | 2
2011-01-12 | Tor 0.2.2.20-alpha (git-aae58deb2cdcaad0) on Linux x86_64 | 2 | 2
2011-01-13 | Tor 0.2.2.20-alpha (git-aae58deb2cdcaad0) on Linux x86_64 | 1 | 1
2011-01-14 | Tor 0.2.2.20-alpha (git-aae58deb2cdcaad0) on Linux x86_64 | 1 | 1
2011-01-15 | Tor 0.2.2.20-alpha (git-aae58deb2cdcaad0) on Linux x86_64 | 2 | 2
2011-01-16 | Tor 0.2.2.20-alpha (git-aae58deb2cdcaad0) on Linux x86_64 | 1 | 3
2011-01-16 | Tor 0.2.2.21-alpha (git-5f63f0d6312d9f0d) on Linux x86_64 | 2 | 3
2011-01-17 | Tor 0.2.2.21-alpha (git-5f63f0d6312d9f0d) on Linux x86_64 | 2 | 2
2011-01-18 | Tor 0.2.2.21-alpha (git-5f63f0d6312d9f0d) on Linux x86_64 | 4 | 3
2011-01-19 | Tor 0.2.2.21-alpha (git-5f63f0d6312d9f0d) on Linux x86_64 | 2 | 2
2011-01-20 | Tor 0.2.2.21-alpha (git-5f63f0d6312d9f0d) on Linux x86_64 | 1 | 1
2011-01-21 | Tor 0.2.2.21-alpha (git-5f63f0d6312d9f0d) on Linux x86_64 | 1 | 3
2011-01-21 | Tor 0.2.2.19-alpha (git-13e9a2b19d4a65d9) on Linux x86_64 | 2 | 3
2011-01-22 | Tor 0.2.2.19-alpha (git-13e9a2b19d4a65d9) on Linux x86_64 | 2 | 2
2011-01-23 | Tor 0.2.2.19-alpha (git-13e9a2b19d4a65d9) on Linux x86_64 | 1 | 1
2011-01-24 | Tor 0.2.2.19-alpha (git-13e9a2b19d4a65d9) on Linux x86_64 | 1 | 1
2011-01-25 | Tor 0.2.2.19-alpha (git-13e9a2b19d4a65d9) on Linux x86_64 | 2 | 2
2011-01-26 | Tor 0.2.2.19-alpha (git-13e9a2b19d4a65d9) on Linux x86_64 | 2 | 2
2011-01-27 | Tor 0.2.2.19-alpha (git-13e9a2b19d4a65d9) on Linux x86_64 | 1 | 1
2011-01-28 | Tor 0.2.2.19-alpha (git-13e9a2b19d4a65d9) on Linux x86_64 | 1 | 1
2011-01-29 | Tor 0.2.2.19-alpha (git-13e9a2b19d4a65d9) on Linux x86_64 | 2 | 2
2011-01-30 | Tor 0.2.2.19-alpha (git-13e9a2b19d4a65d9) on Linux x86_64 | 1 | 1
2011-01-31 | Tor 0.2.2.19-alpha (git-13e9a2b19d4a65d9) on Linux x86_64 | 1 | 1
2011-02-01 | Tor 0.2.2.19-alpha (git-13e9a2b19d4a65d9) on Linux x86_64 | 2 | 2
2011-02-02 | Tor 0.2.2.19-alpha (git-13e9a2b19d4a65d9) on Linux x86_64 | 2 | 2
2011-02-03 | Tor 0.2.2.19-alpha (git-13e9a2b19d4a65d9) on Linux x86_64 | 1 | 5
2011-02-03 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 13 | 5
2011-02-04 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 24 | 5
2011-02-05 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 23 | 7
2011-02-06 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 24 | 6
2011-02-07 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 24 | 9
2011-02-08 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 25 | 12
2011-02-09 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 23 | 13
2011-02-10 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 24 | 13
2011-02-11 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 24 | 11
2011-02-12 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 24 | 11
2011-02-13 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 23 | 12
2011-02-14 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 24 | 11
2011-02-15 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 25 | 10
2011-02-16 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 23 | 12
2011-02-17 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 24 | 12
2011-02-18 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 24 | 11
2011-02-19 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 24 | 9
2011-02-20 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 24 | 14
2011-02-21 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 24 | 9
2011-02-22 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 25 | 11
2011-02-23 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 24 | 12
2011-02-24 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 24 | 9
2011-02-25 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 26 | 13
2011-02-26 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 25 | 11
2011-02-27 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 28 | 12
2011-02-28 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 25 | 12
2011-03-01 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 26 | 6
2011-03-02 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 24 | 5
2011-03-03 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 24 | 7
2011-03-04 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 24 | 5
2011-03-05 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 24 | 9
2011-03-06 | Tor 0.2.2.22-alpha (git-e5e38e55b33b2cc0) on Linux x86_64 | 10 | 4
2011-03-06 | Tor 0.2.2.19-alpha (git-35fcec38809f9805) on Linux x86_64 | 2 | 4
2011-03-07 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 15 | 8
2011-03-08 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 26 | 14
2011-03-09 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 23 | 11
2011-03-10 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 13
2011-03-11 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 13
2011-03-12 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 12
2011-03-13 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 10
2011-03-14 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 26 | 15
2011-03-15 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 28 | 17
2011-03-16 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 12
2011-03-17 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 13
2011-03-18 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 11
2011-03-19 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 10
2011-03-20 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 10
2011-03-21 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 10
2011-03-22 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 25 | 10
2011-03-23 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 10
2011-03-24 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 9
2011-03-25 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 10
2011-03-26 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 10
2011-03-27 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 9
2011-03-28 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 12
2011-03-29 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 26 | 7
2011-03-30 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 5
2011-03-31 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 22 | 5
2011-04-01 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 8
2011-04-02 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 22 | 9
2011-04-03 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 12
2011-04-04 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 11
2011-04-05 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 25 | 10
2011-04-06 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 13
2011-04-07 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 11
2011-04-08 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 12
2011-04-09 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 15
2011-04-10 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 11
2011-04-11 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 11
2011-04-12 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 25 | 11
2011-04-13 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 22 | 12
2011-04-14 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 13
2011-04-15 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 7 | 4
2011-04-16 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 18 | 6
2011-04-17 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 6
2011-04-18 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 8
2011-04-19 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 25 | 11
2011-04-20 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 12
2011-04-21 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 10
2011-04-22 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 11
2011-04-23 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 11
2011-04-24 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 10
2011-04-25 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 | 10
2011-04-26 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 25 | 8
2011-04-27 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 23 |
2011-04-28 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 23 |
2011-04-29 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 19 |
2011-04-30 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 22 |
2011-05-01 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 23 |
2011-05-02 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 |
2011-05-03 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 25 | 1
2011-05-04 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 23 |
2011-05-05 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 |
2011-05-06 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 |
2011-05-07 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 |
2011-05-08 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 |
2011-05-09 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 |
2011-05-10 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 25 | 1
2011-05-11 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 |
2011-05-12 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 23 |
2011-05-13 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 |
2011-05-14 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 |
2011-05-15 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 |
2011-05-16 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 |
2011-05-17 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 25 | 1
2011-05-18 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 |
2011-05-19 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 |
2011-05-20 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 |
2011-05-21 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 24 |
2011-05-22 | Tor 0.2.2.22-alpha (git-20569f9297fad087) on Linux x86_64 | 17 |
```
There are a few irregularities in this table; see also legacy/trac#3265. In this ticket, I'm mostly worried why gabelmoo started publishing only a single extra-info descriptor per week from May 3 on. The exact publication times of the last extra-info descriptors are:
```
gabelmoo | 2011-04-25 15:11:50
gabelmoo | 2011-04-25 18:11:27
gabelmoo | 2011-04-25 20:10:54
gabelmoo | 2011-04-26 03:10:27
gabelmoo | 2011-04-26 04:10:44
gabelmoo | 2011-04-26 05:12:30
gabelmoo | 2011-04-26 08:11:24
gabelmoo | 2011-04-26 08:42:22
gabelmoo | 2011-04-26 10:12:09
gabelmoo | 2011-04-26 13:11:09
gabelmoo | 2011-04-26 14:11:11
gabelmoo | 2011-05-03 08:42:15
gabelmoo | 2011-05-10 08:41:46
gabelmoo | 2011-05-17 08:41:47
```
Note the almost exact 1-week interval at the end.
It looks like gabelmoo is not the only affected relay, but it's the one with the clearest pattern.
Any idea what's going on?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/3943self-test the socks port before bootstrapping is complete?2020-06-27T14:07:46ZRoger Dingledineself-test the socks port before bootstrapping is complete?Some users (e.g. those in legacy/trac#3941) have local firewalls that will let them open a high numbered port, but not let any applications connect to it. When we set 'socksport auto' for them, they can end up in this situation.
One opt...Some users (e.g. those in legacy/trac#3941) have local firewalls that will let them open a high numbered port, but not let any applications connect to it. When we set 'socksport auto' for them, they can end up in this situation.
One option would be for Tor to make a socks connection to itself on the socksport it just opened, and make a connection to .noconnect or the equivalent (which I believe we disabled for no good reason, but that's a separate issue). If that test fails, log a more useful error and prevent bootstrapping from reaching 100%.
(The socksport test can happen in parallel to the rest of bootstrapping, so in all reasonable cases it shouldn't be holding anything up.)
It's unclear to me how often this feature will be useful in practice -- for example, perhaps the firewalls that prevent apps from reaching these ports would still allow the app that bound the port to reach it.
But it seems like the sort of feature that will come in handy down the road when debugging weird firewall situations. And the weird firewalls sure aren't going to go away anytime soon.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6504Support Windows environment variables in HiddenServiceDir2020-07-24T13:39:18ZTracSupport Windows environment variables in HiddenServiceDirExpansion should be done each time the hidden service dir is opened, and stored unexpanded. Actually, my impression is that if you use the right Win32 API calls to open the location, tor itself doesn't need to worry about expansion. Win3...Expansion should be done each time the hidden service dir is opened, and stored unexpanded. Actually, my impression is that if you use the right Win32 API calls to open the location, tor itself doesn't need to worry about expansion. Win32 will take care of any necessary.
One direct benefit to you devs is that you could then use '%UserProfile%' in the HiddenServiceDir examples for Windows in your documentation, such as the one discussed in !legacy/trac#4798, yielding the appropriate location in every version that Tor supports.
This behavior could/should eventually broadened to all options for which a path can be specified (e.g. DataDirectory, GeoIPFile, PidFile), so if the fix would affect the opening of other paths (I haven't looked through the source code), all the better. If the fix isn't in a core function, I'd be happy to add a new, broader, ticket.
P.S. The version I'm using is actually 0.2.2.37, but I don't see it in the list.
**Trac**:
**Username**: criticoderTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7134Add statistics on time spent on crypto operations2020-07-23T17:53:24ZKarsten LoesingAdd statistics on time spent on crypto operationsWe'd like to find out how much of Tor's time is spent on which crypto operations, and we'd want to answer this question over time.
These statistics would help us understand the implications of other design shifts -- like directory guard...We'd like to find out how much of Tor's time is spent on which crypto operations, and we'd want to answer this question over time.
These statistics would help us understand the implications of other design shifts -- like directory guards, where one of the desired side effects is a reduced number of TLS handshakes for relays because clients handshake with fewer relays. Another benefit could be that we'd have better data on hardware requirements for the Torouter and similar projects, in particular crypto operations performed by an average relay or bridge.
Probably the easiest way to achieve the "answer over time" part would be to have relays/bridges add a new line to their extra-info descriptors, and later look at metrics archives to see how things changed over time. There should not be too big privacy implications if we make the granularity sufficiently big.
We might want to make this feature optional, since it takes time to check the time. (Gotta find out how many nanoseconds for a hi-resolution timers vs how many nanoseconds for encrypting a cell. That would be part of the design.)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7798Use directory guards even when consensus isn't live2021-06-18T18:21:27ZNick MathewsonUse directory guards even when consensus isn't liveOur initial directory guard implementation only works when we have a live consensus to find out the directory guards' IP addresses. So it's an improvement, but it's hardly a perfect solution.
We should instead remember our guards' IP a...Our initial directory guard implementation only works when we have a live consensus to find out the directory guards' IP addresses. So it's an improvement, but it's hardly a perfect solution.
We should instead remember our guards' IP addresses in our state file, and try to use our directory guards even when we don't have a consensus. This will require consideration about handling our guards being down and handling the network being down.https://gitlab.torproject.org/tpo/core/tor/-/issues/7961Publish transports that bind on IPv6 addresses2021-11-19T21:12:13ZGeorge KadianakisPublish transports that bind on IPv6 addressesCurrently, `pt_get_extra_info_descriptor_string()` uses `router_pick_published_address()` to retrieve our external IP address so that it can write it in our extra-info descriptor along with the TCP port that our transport listens on.
Th...Currently, `pt_get_extra_info_descriptor_string()` uses `router_pick_published_address()` to retrieve our external IP address so that it can write it in our extra-info descriptor along with the TCP port that our transport listens on.
The bad news are that `router_pick_published_address()` only returns IPv4 addresses, and we will probably have to refactor it, or do something like this:
~~ https://gitweb.torproject.org/tor.git/blob/ebf30613ea41bbed3340851e839da9b7db4351c5:/src/or/router.c#l1775 ~~
(wrong commit reference)
for IPv6 addresses.
Not sure if this can get in 0.2.4.x. I guess it depends on how quickly we implement it, and how complex the changes are going to be.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/8225"We stalled too much while trying to write X bytes to address [scrubbed]. If...2020-07-24T14:12:20ZTrac"We stalled too much while trying to write X bytes to address [scrubbed]. If this happens frequently, either something is wrong with your network connection, or with theirs.Hello, long-time Tor exit node operator here. My apartment complex has free internet -- 10 ping (!) 30Mbps down / 20 Mbps up. A fiber connection is fed out to managed switches on the property.
My Windows 7 Desktop has run a Tor exit n...Hello, long-time Tor exit node operator here. My apartment complex has free internet -- 10 ping (!) 30Mbps down / 20 Mbps up. A fiber connection is fed out to managed switches on the property.
My Windows 7 Desktop has run a Tor exit node flawlessly for a year.
On another internet connection in my apartment, I wanted to start up another Tor server. For this, I reloaded the OS on a windows XP machine, updated it, an installed Tor. Tor runs, but gives this error message every 3-15 minutes, dozens if not hundreds of times a day:
_"We stalled too much while trying to write X bytes to address [scrubbed]. If this happens frequently, either something is wrong with your network connection, or with theirs." _
The Tor server should be transmitting several TB a month, but it's doing about 50MB a DAY!
The network connection works great, the Tor install is new, and the computer is fresh. How can we fix this?
**Trac**:
**Username**: spiffytexanTor: unspecifiedRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/8337Trusteer crashes Tor Browser2022-02-03T19:06:44ZMoritz BartlTrusteer crashes Tor BrowserTrusteer Rapport, a security software recommended by a lot of US banks, crashes Tor Browsers based on FF 17ESR. The bare Firefox 17ESR works.
Symptom: Vidalia tries to launch Tor browser after connecting to Tor, and silently disappears ...Trusteer Rapport, a security software recommended by a lot of US banks, crashes Tor Browsers based on FF 17ESR. The bare Firefox 17ESR works.
Symptom: Vidalia tries to launch Tor browser after connecting to Tor, and silently disappears after a while without any error messages. The Windows Event viewer shows:
Faulting application name: tbb-firefox.exe, version: 17.0.3.4799, time stamp: 0x51247233
Faulting module name: RapportTanzan17.DLL, version: 3.5.1205.20, time stamp: 0x5111eda5
Exception code: 0xc0000005
Fault offset: 0x0000975d
Faulting process id: 0x628
Faulting application start time: 0x01ce12f38252b6ad
Faulting application path: C:\Users\username\Desktop\Tor Browser\FirefoxPortable\App\Firefox\tbb-firefox.exe
Faulting module path: C:\Program Files (x86)\Trusteer\Rapport\bin\RapportTanzan17.DLL
Report Id: c5a8fe6d-7ee6-11e2-b3e3-001fbc01a9d1https://gitlab.torproject.org/tpo/core/tor/-/issues/9208Allow node operator to avoid Guard flag2022-05-23T20:38:01ZcypherpunksAllow node operator to avoid Guard flagFor various reasons node operator may wish to not become guard node. Add cfg option for publishing such wish to directory server.For various reasons node operator may wish to not become guard node. Add cfg option for publishing such wish to directory server.https://gitlab.torproject.org/tpo/tpa/team/-/issues/40643Backup Stack Exchange Tor site2022-03-14T16:04:12ZLunarBackup Stack Exchange Tor siteIt looks like we are going live with the Tor Stack Exchange Q&A site. There is going to be a lot of valuable thoughts in there, and it is probably a good idea to have our own backups in case Stack Exchange falls, fails or bails on the To...It looks like we are going live with the Tor Stack Exchange Q&A site. There is going to be a lot of valuable thoughts in there, and it is probably a good idea to have our own backups in case Stack Exchange falls, fails or bails on the Tor project.
It should probably be done using a query run regularly against http://data.stackexchange.com/ or maybe using the data dumps http://www.clearbits.net/creators/146-stack-exchange-data-dumpLunarLunarhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/10155Allow delayed node start2020-07-17T11:02:21ZMatthew FinkelAllow delayed node startIt will be useful to allow nodes to be started after a certain amount of time, especially when interested in its effect on the consensus.It will be useful to allow nodes to be started after a certain amount of time, especially when interested in its effect on the consensus.https://gitlab.torproject.org/tpo/core/tor/-/issues/10922tor connected to bwauth produces lots of pathbias_count_use_attempt BUG messages2022-06-17T16:17:46ZSebastian Hahntor connected to bwauth produces lots of pathbias_count_use_attempt BUG messagesI'm setting up a new bwauth currently. I'm seeing many (~1000 / hour) BUG messages in its logfile:
[notice] Tor 0.2.4.20 (git-0d50b03673670de6) opening new log file.
[notice] pathbias_count_use_attempt(): Bug: Used circuit is in strange...I'm setting up a new bwauth currently. I'm seeing many (~1000 / hour) BUG messages in its logfile:
[notice] Tor 0.2.4.20 (git-0d50b03673670de6) opening new log file.
[notice] pathbias_count_use_attempt(): Bug: Used circuit is in strange path state new. Circuit is a General-purpose client currently open.
The config for the tor process (it is a relay to evade static throttling):
```
SocksPort 9110
ControlPort 9111
Log notice file ./data/tor/tor.log
DataDirectory ./data/tor
PidFile ./data/tor/tor.pid
CookieAuthentication 1
Nickname gabelmoobwscan
RelayBandwidthRate 20480
RelayBandwidthBurst 20480
OrPort 9999
ContactInfo Sebastian <tor@sebastianhahn.net>
ExitPolicy reject *:*
```https://gitlab.torproject.org/tpo/core/tor/-/issues/11119Write a proposal for client-side key pinning2022-06-17T14:12:06ZNick MathewsonWrite a proposal for client-side key pinningProposal 220 suggests that we pin RSA and Ed25519 identity keys to one another authority-side. Roger suggested to me that we also consider doing client-side identity pinning.Proposal 220 suggests that we pin RSA and Ed25519 identity keys to one another authority-side. Roger suggested to me that we also consider doing client-side identity pinning.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/11214Gmail talkgadget/hangouts/chat infinite loop2020-11-18T22:06:47ZcypherpunksGmail talkgadget/hangouts/chat infinite loopVersion: Tor Browser Bundle 3.5.2.1
*please relocate to appropriate thread if incorrect*
Gmail allows for two types of chat: by default, hangouts, and by choice, legacy chat. These operate in a frame on the lower left of Gmail. Legacy c...Version: Tor Browser Bundle 3.5.2.1
*please relocate to appropriate thread if incorrect*
Gmail allows for two types of chat: by default, hangouts, and by choice, legacy chat. These operate in a frame on the lower left of Gmail. Legacy chat works, but reverting to legacy chat from hangouts is impossible from Tor Browser Bundle 3.5.2.1, where an infinite loop interferes.
1. Gmail load attempted with restrictive NoScript settings. Options appear: loosen restrictions, or use HTML only.
2. mail.google.com is whitelisted in NoScript, as well as (optionally) some of the following domains:
a. clients6.google.com
b. plus.google.com
c. talkgadget.google.com
d. www.google.com
3. Page is reloaded. The following error message appears in the lower left chat frame: "Something's not right. We're having trouble connecting to Google. We'll keep trying...\n This may be caused by network or proxy issues. <a href="https://support.google.com/hangouts/?p=not_right_error&hl=en">Learn more</a>.
4. apis.google.com is whitelisted in NoScript, as recommended on the linked support page. Gmail is refreshed.
Infinite loop:
5. Hangouts loads, with contact list visible. Within seconds, it disappears and is replaced with a Sign In button.
6. The Sign In button is clicked. A pop-up appears with a log-in page from domain accounts.google.com. Password is entered; user signs in. Page declares success, instructs user to close pop-up and refresh Gmail.
7. Go to step 5.
This bug prevents users from being able to use Google chat at all, since reverting to legacy chat requires accessing the main menu in talkgadget/hangouts.
Tried many combinations of NoScript whitelists. None works.https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/12547Get analysed data from bridge reachability tests to tor-devs2021-09-09T14:26:41ZArturo FilastòGet analysed data from bridge reachability tests to tor-devsThis means setting up a web server on the post processing machine (the one running the collector) with some access control so that tor devs can read the reports.This means setting up a web server on the post processing machine (the one running the collector) with some access control so that tor devs can read the reports.https://gitlab.torproject.org/tpo/core/tor/-/issues/13260Transform code to cleaner c99 style2021-09-16T14:35:28ZNick MathewsonTransform code to cleaner c99 styleFor legacy/trac#13233, we added a loose c99 requirement for building Tor. If we decide to keep it through the 0.2.6.x series, we can beautify our code a little.For legacy/trac#13233, we added a loose c99 requirement for building Tor. If we decide to keep it through the 0.2.6.x series, we can beautify our code a little.https://gitlab.torproject.org/tpo/community/support/-/issues/13677Update Tor Browser 4.x videos2021-07-09T19:47:23ZSheriefUpdate Tor Browser 4.x videosSponsor O requires support (just me) to add Tor Browser videos showing verification, installation and usage. But we're swapping Erinn's key soon and recording videos showing her key will confuse users.Sponsor O requires support (just me) to add Tor Browser videos showing verification, installation and usage. But we're swapping Erinn's key soon and recording videos showing her key will confuse users.SheriefSheriefhttps://gitlab.torproject.org/tpo/core/tor/-/issues/14006Hidden service error: "We'd like to launch a circuit to handle a connection, ...2022-10-11T23:40:44ZGeorge KadianakisHidden service error: "We'd like to launch a circuit to handle a connection, but we already have 32 general-purpose client circuits..."The HS operator in https://lists.torproject.org/pipermail/tor-dev/2014-December/007956.html saw this Tor log:
```
Dec 11 13:08:59.000 [notice] We'd like to launch a circuit to handle a
connection, but we already have 32 general-purpose c...The HS operator in https://lists.torproject.org/pipermail/tor-dev/2014-December/007956.html saw this Tor log:
```
Dec 11 13:08:59.000 [notice] We'd like to launch a circuit to handle a
connection, but we already have 32 general-purpose client circuits
pending. Waiting until some finish. [268 similar message(s) suppressed
in last 600 seconds]
```
His network seems to be flaky so this might be the result of crappy network. However, we might want to investigate a bit further, since that message was supressed 250 times.
I can imagine situations in very busy hidden services, where 32 clients try to access them at the same time, which means that it tries to establish 32 circuits at the same time which might cause this problem.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/15532Tor Browser 4.5 displays signature validation error during update2022-07-09T21:55:01ZMike PerryTor Browser 4.5 displays signature validation error during updateI suspect this is due to the fact that we allow an update to proceed if it is signed with either my mar signing key or gk's mar signing key, but nonetheless TBB 4.5 displays two error messages while updating on Linux:
"ERROR: Error verif...I suspect this is due to the fact that we allow an update to proceed if it is signed with either my mar signing key or gk's mar signing key, but nonetheless TBB 4.5 displays two error messages while updating on Linux:
"ERROR: Error verifying signature"
"ERROR: Not all signatures were verified".
We should ensure the signature validation behavior is actually correct, and if so remove these error messages for the stable release.