The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:02:10Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13822Raise ROUTER_REQUIRED_MIN_BANDWIDTH2020-06-27T14:02:10ZRoger DingledineRaise ROUTER_REQUIRED_MIN_BANDWIDTHor.h:#define ROUTER_REQUIRED_MIN_BANDWIDTH (20*1024)
But we raised the recommended minimum listed on the website to 100KB, and then again recently to 250KB.
Now, we should be aware that this #define is used for both relays and bridges....or.h:#define ROUTER_REQUIRED_MIN_BANDWIDTH (20*1024)
But we raised the recommended minimum listed on the website to 100KB, and then again recently to 250KB.
Now, we should be aware that this #define is used for both relays and bridges. But a tiny bridge is increasingly looking like it will drag down users who use it. But we also don't want to skew the incentives so a 100KB/s bridge sets her BandwidthRate to 250KB so her bridge can start.
In any case, I think raising from 20 to 100 is an easy and wise step. We should discuss whether raising to 250 is wise too.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13823chutney intervals are too short for successful bootstrap, particularly under ...2020-06-27T14:02:10Zteorchutney intervals are too short for successful bootstrap, particularly under high CPU load on OS XSplit from legacy/trac#13718:
Occasionally, the CPU load on my test machine will increase (or some other condition affecting the scheduler will occur), and a bootstrap race condition will cause the test to fail 50-100% of the time for a...Split from legacy/trac#13718:
Occasionally, the CPU load on my test machine will increase (or some other condition affecting the scheduler will occur), and a bootstrap race condition will cause the test to fail 50-100% of the time for a few hours. Then it will start working again. The commands run are exactly the same each time. I'll be excluding these results from the tests, because they happen with or without the changes.
Perhaps lengthening some of the default intervals chutney uses would solve this.teorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13831Update to November GeoIP2 database2020-06-27T14:02:09ZKarsten LoesingUpdate to November GeoIP2 database[geoip-nov2014](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/geoip-nov2014) contains the updated geoip file with IPv4 ranges and is supposed to be merged into maint-0.2.3.
[geoip6-nov2014](https://gitweb.torprojec...[geoip-nov2014](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/geoip-nov2014) contains the updated geoip file with IPv4 ranges and is supposed to be merged into maint-0.2.3.
[geoip6-nov2014](https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/geoip6-nov2014) contains the updated geoip6 file with IPv6 ranges and is supposed to be merged into maint-0.2.4 (the first maint-* branch that contains a geoip6 file).Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13836Stuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 3...2020-06-27T14:02:09ZRoger DingledineStuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 3; recommendation warn)A user in #tor sees
```
Nov 24 14:34:52.000 [notice] Opening Socks listener on 127.0.0.1:9150
Nov 24 14:34:52.000 [notice] Bootstrapped 5%: Connecting to directory server
Nov 24 14:34:52.000 [notice] Bootstrapped 10%: Finishing handshake...A user in #tor sees
```
Nov 24 14:34:52.000 [notice] Opening Socks listener on 127.0.0.1:9150
Nov 24 14:34:52.000 [notice] Bootstrapped 5%: Connecting to directory server
Nov 24 14:34:52.000 [notice] Bootstrapped 10%: Finishing handshake with directory server
Nov 24 14:34:55.000 [warn] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 3; recommendation warn)
Nov 24 14:34:55.000 [warn] 3 connections have failed:
Nov 24 14:34:55.000 [warn] 3 connections died in state handshaking (TLS) with SSL state SSLv2/v3 read server hello A in HANDSHAKE
```
Now, the "3 connections died" warning is kind of nice I guess, but the "DONE; DONE" part is not useful. What was the actual message that caused us to decide "recommendation warn"?
This ticket looks a lot like legacy/trac#10431 except that one thinks it's fixed, so I'm opening a new one to look for further causes.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13837Mitigate guard discovery by pinning middle node2020-06-27T14:02:09ZGeorge KadianakisMitigate guard discovery by pinning middle nodeHello,
inspired by the recent discussions on guard discovery, I went ahead
and implemented a small patch for Tor that tries to help defend
against Hidden Service guard discovery attacks.
It basically allows the operator to specify a se...Hello,
inspired by the recent discussions on guard discovery, I went ahead
and implemented a small patch for Tor that tries to help defend
against Hidden Service guard discovery attacks.
It basically allows the operator to specify a set of nodes that will
be pinned as middle nodes in Hidden Service rendezvous circuits. The
option only affects HS rendezvous circuits and nothing else.
Of course, it doesn't fix guard discovery, it just pushes guard
discovery to the next hop, so that they need to compromise two boxes
to win.
You can find my branch in 'sticky_mids' at
https://git.torproject.org/user/asn/tor.git .
(Here it is in HTTP shape:
https://gitweb.torproject.org/user/asn/tor.git/shortlog/refs/heads/sticky_mids )
[This is the trac version of https://lists.torproject.org/pipermail/tor-dev/2014-November/007730.html]Tor: 0.3.3.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13838Potential HS guard discovery using bw stats2020-06-27T14:02:09ZGeorge KadianakisPotential HS guard discovery using bw statsBandwidth stats are included in extra-info descriptor for 15 minute intervals.
This allows an attacker to do a guard discovery attack, by modulating traffic he sends to an HS every 15 minutes and then checking all the relay stats to see ...Bandwidth stats are included in extra-info descriptor for 15 minute intervals.
This allows an attacker to do a guard discovery attack, by modulating traffic he sends to an HS every 15 minutes and then checking all the relay stats to see which one matches the modulation.
It was mentioned by Aaron here:
https://lists.torproject.org/pipermail/tor-dev/2014-November/007829.html
It's clear we need to increase the reporting period, so that the modulation is hidden inside the noise of unrelated traffic. We should probably increase the reporting period to every 6-12 hours or a full day. Is something using the 15-minute interval measurements that would break if we decreased the reporting frequency?
Also, is this a sufficient fix or do we need to do more?Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13839Exit Policy says accept *:* but relay doesn't have Exit flag2020-06-27T14:02:09ZteorExit Policy says accept *:* but relay doesn't have Exit flaglegacy/trac#13718 has revealed an issue where chutney-run tor authorities don't flag anything as an Exit. This was resolved in legacy/trac#13161 with TestingDirAuthVoteExit, but a more elegant solution (or a root cause) needs to be found...legacy/trac#13718 has revealed an issue where chutney-run tor authorities don't flag anything as an Exit. This was resolved in legacy/trac#13161 with TestingDirAuthVoteExit, but a more elegant solution (or a root cause) needs to be found in order to properly test legacy/trac#13718.
Workarounds are available:
TestingDirAuthVoteExit *
~~AssumeReachable 0~~ _(not actually a workaround)_
But they make it harder to justify that the test results apply to real-world tor bootstraps, or even chutney configs without special-case configurations.
This issue is like legacy/trac#11264, and could have the same root cause (a conflict between the setting of the exit flag and exit policy summaries), although this seems unlikely.teorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13840Refactor? Use END_CIRC_REASON_TORPROTOCOL rather than "1" in connection_exit_...2020-06-27T14:02:09ZRoger DingledineRefactor? Use END_CIRC_REASON_TORPROTOCOL rather than "1" in connection_exit_begin_conn()In the function comment for connection_exit_begin_conn() we see
```
* Return -(some circuit end reason) if we want to tear down <b>circ</b>.
* Else return 0.
```
and then at the front of the function we see
```
if (rh.length > RELAY_...In the function comment for connection_exit_begin_conn() we see
```
* Return -(some circuit end reason) if we want to tear down <b>circ</b>.
* Else return 0.
```
and then at the front of the function we see
```
if (rh.length > RELAY_PAYLOAD_SIZE)
return -1;
```
Now, it happens that 1 is END_CIRC_REASON_TORPROTOCOL, which is a legitimate reason to use in this case. But did we just get lucky?
Later there's also a
```
if (r < -1) {
return -1;
```
If we want to go wilder with the change here, I think this function actually only ever returns 0 and -1, so it's not actually following the function comment and we could get rid of that part of it instead?Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13856Make sure #9262 didn't introduce new OOM opportunities2020-06-27T14:02:09ZNick MathewsonMake sure #9262 didn't introduce new OOM opportunitiesIIUC, the legacy/trac#9262 changes don't introduce any big new queues or structures, so the OOM handler doesn't need any more changes to think about them. But I just merged legacy/trac#9262, and now I'm too tired to look for data struct...IIUC, the legacy/trac#9262 changes don't introduce any big new queues or structures, so the OOM handler doesn't need any more changes to think about them. But I just merged legacy/trac#9262, and now I'm too tired to look for data structure changes. So, this ticket should remind us/me to confirm that we don't need more OOM handler hacking for that, and then put it to bed.Tor: unspecifiedAndrea ShepardAndrea Shepardhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13862No error message when fatally failing to open files in DataDirectory2020-06-27T14:02:09ZTracNo error message when fatally failing to open files in DataDirectoryDue to installing packages from conflicting sources, I ended up with a Tor installation where the tor daemon (with `User toranon`) could access the DataDirectory, but not open the files in it for lack of permissions.
In this situation, ...Due to installing packages from conflicting sources, I ended up with a Tor installation where the tor daemon (with `User toranon`) could access the DataDirectory, but not open the files in it for lack of permissions.
In this situation, tor exits quickly with only the following messages:
```
Nov 30 00:07:12.878 [notice] Tor v0.2.5.10 (git-42b42605f8d8eac2) running on Linux with Libevent 2.0.18-stable, OpenSSL 1.0.1e-fips and Zlib 1.2.7.
Nov 30 00:07:12.878 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Nov 30 00:07:12.878 [notice] Read configuration file "/usr/share/tor/defaults-torrc".
Nov 30 00:07:12.878 [notice] Read configuration file "/etc/tor/torrc".
Nov 30 00:07:12.881 [notice] Opening Socks listener on 127.0.0.1:9050
Nov 30 00:07:12.881 [notice] Opening Control listener on 127.0.0.1:9151
Nov 30 00:07:12.881 [notice] Caching new entry toranon for toranon
Nov 30 00:07:12.881 [notice] Caching new entry toranon for toranon
```
There are no explicit `Log` directives in torrc.
Except for exit status 1, there is no indication to the user that something has gone wrong, and what the problem could be. We should print a helpful error message.
**Trac**:
**Username**: sqrt2Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13865Enable Tor to load Torrc from <stdin> removing the need to write it to filesy...2020-06-27T14:02:08ZnaifEnable Tor to load Torrc from <stdin> removing the need to write it to filesystemThis ticket is to enable Tor to load Torrc from <stdin> remove the need to write it.
Tor wrapper libraries such as txtorcon from meejah, today write "torrc" in temporary directory when starting Tor.
It would be good if Tor could load T...This ticket is to enable Tor to load Torrc from <stdin> remove the need to write it.
Tor wrapper libraries such as txtorcon from meejah, today write "torrc" in temporary directory when starting Tor.
It would be good if Tor could load Torrc from standard input, that way wrapper libraries starting Tor would be able to dynamically "feed" Tor a configuration file, without having to write to filesystem.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13885AllowDotExit strange behavior2020-06-27T14:02:08ZTracAllowDotExit strange behaviorWhen I upgraded from tor 0.2.2 (I know, it's old) to the current 0.2.5, the behavior of AllowDotExit changed. I use this feature in order to create stable passive FTP connections to servers, and it doesn't work anymore.
I turned on stre...When I upgraded from tor 0.2.2 (I know, it's old) to the current 0.2.5, the behavior of AllowDotExit changed. I use this feature in order to create stable passive FTP connections to servers, and it doesn't work anymore.
I turned on stream debugging in the console, and this is what I see when I try to connect to a an ArchLinux FTP mirror by specifying an exit node (whose policy I did check):
650 STREAM 35 NEWRESOLVE 0 ftp.sjtu.edu.cn.kramse.exit:34303 PURPOSE=DNS_REQUEST
650 STREAM 35 NEW 18 ftp.sjtu.edu.cn.kramse.exit:34303 SOURCE_ADDR=(Tor_internal):49683 PURPOSE=DNS_REQUEST
650 STREAM 35 SENTRESOLVE 18 ftp.sjtu.edu.cn.kramse.exit:34303
650 STREAM 35 SUCCEEDED 18 ftp.sjtu.edu.cn.kramse.exit:34303
650 STREAM 35 REMAP 18 202.38.97.230.kramse.exit:34303 SOURCE=EXIT
650 STREAM 35 CLOSED 18 202.38.97.230.kramse.exit:34303 REASON=DONE
650 STREAM 36 NEW 0 202.38.97.230:21 SOURCE_ADDR=127.0.0.1:49684 PURPOSE=USER
650 STREAM 36 SENTCONNECT 6 202.38.97.230:21
650 STREAM 36 REMAP 6 202.38.97.230:21 SOURCE=EXIT
650 STREAM 36 SUCCEEDED 6 202.38.97.230:21
650 STREAM 37 NEWRESOLVE 0 my-linux-box:34303 PURPOSE=DNS_REQUEST
650 STREAM 37 NEW 6 my-linux-box:34303 SOURCE_ADDR=(Tor_internal):49685 PURPOSE=DNS_REQUEST
650 STREAM 37 SENTRESOLVE 6 my-linux-box:34303
650 STREAM 37 FAILED 6 my-linux-box:34303 REASON=RESOLVEFAILED
650 STREAM 37 CLOSED 6 my-linux-box:34303 REASON=DONE
getinfo circuit-status
250+circuit-status=
18 BUILT $E46979A3053D43ADF187463A6E4856C875BC8C89~teller,$52F9083EE37A143BD03F77CF35ED1B7DC9108BE8~somethingsomething,$0078FFEABB3B87512DD6701C2930D8FCA128F97D~TelosTorExit5,$EC116BCB80565A408CE67F8EC3FE3B0B02C3A065~kramse BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2014-12-03T04:54:10.556288
17 BUILT $E46979A3053D43ADF187463A6E4856C875BC8C89~teller,$516BC3FDE382EBE5C6D1BA63056C071F28E65747~trockner,$D1271A1E15C568DA709D3A1E68188EEAE8DDB834~worfedpm BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2014-12-03T04:51:34.986853
7 BUILT $E46979A3053D43ADF187463A6E4856C875BC8C89~teller,$F596E1B1EF98E1DDBBDC934DB722AF54069868F6~bauruine202,$B7580D392853F23597E11575F061B8097ADD92B6~spfTOR1e3 BUILD_FLAGS=NEED_CAPACITY,NEED_UPTIME PURPOSE=GENERAL TIME_CREATED=2014-12-03T04:49:01.986921
6 BUILT $E46979A3053D43ADF187463A6E4856C875BC8C89~teller,$5A16F7E31B26F286889F20027F57A5E253AF3F23~servbr4a,$E801BFE9048106FB3E39A1B076CB03648CE93D8F~Gertrude BUILD_FLAGS=NEED_CAPACITY,NEED_UPTIME PURPOSE=GENERAL TIME_CREATED=2014-12-03T04:49:01.371019
5 BUILT $E46979A3053D43ADF187463A6E4856C875BC8C89~teller,$1C90D3AEADFF3BCD079810632C8B85637924A58E~splitDNA,$D6DF9D18146CBEFE005CAB010E5E11C297DB87D2~TapLink BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=GENERAL TIME_CREATED=2014-12-03T04:48:22.986518
4 BUILT $E46979A3053D43ADF187463A6E4856C875BC8C89~teller,$D3EC9A20C83E1E3050CA3759B8957D91D2DE128C~Oezie,$1B89A79F50A9B3F46A8AB07B14C5662DA3364ED3~4Privacy BUILD_FLAGS=IS_INTERNAL,NEED_CAPACITY,NEED_UPTIME PURPOSE=GENERAL TIME_CREATED=2014-12-03T04:48:21.990858
.
250 OK
getinfo stream-status
250-stream-status=36 SUCCEEDED 6 202.38.97.230:21
250 OK
I don't know why it's trying to resolve my own box, but whatever.
Anyway, when I see what circuit the stream is attached to, I get this:
getinfo stream-status
250-stream-status=36 SUCCEEDED 6 202.38.97.230:21
250 OK
Why isn't it attached to circuit 18? That's the one with the exit node I specified...
As a result, when I try to initiate the data connection, it comes from a different IP, so the server pretends to be down as a self-protection mechanism (other servers also send back ICMP responses, so it seems server dependent):
650 STREAM 41 NEW 0 202.38.97.230:41474 SOURCE_ADDR=127.0.0.1:49687 PURPOSE=USER
650 STREAM 41 SENTCONNECT 18 202.38.97.230:41474
650 STREAM 41 DETACHED 18 202.38.97.230:41474 REASON=TIMEOUT
650 STREAM 41 SENTCONNECT 17 202.38.97.230:41474
650 STREAM 41 DETACHED 17 202.38.97.230:41474 REASON=TIMEOUT
650 STREAM 41 SENTCONNECT 20 202.38.97.230:41474
650 STREAM 41 DETACHED 20 202.38.97.230:41474 REASON=TIMEOUT
650 STREAM 41 SENTCONNECT 21 202.38.97.230:41474
650 STREAM 41 FAILED 21 202.38.97.230:41474 REASON=END REMOTE_REASON=INTERNAL
650 STREAM 41 CLOSED 21 202.38.97.230:41474 REASON=END REMOTE_REASON=INTERNAL
This used to work in 0.2.2. Here are the only non commented lines in my config that I'm using to debug this:
AllowDotExit 1
AllowUnverifiedNodes middle,rendezvous
Log notice syslog
RunAsDaemon 1
User tor
Group tor
DataDirectory /var/lib/tor
ControlPort 9051
**Trac**:
**Username**: nixscripterTor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13897Tor emits an ORCONN event but can't provide router status information2020-06-27T14:02:08ZtoralfTor emits an ORCONN event but can't provide router status informationSometimes when I get an ORCONN event, requesting its router status entry with "GETINFO ns/id/<fingerprint>" balks with...
```
GETINFO request contained unrecognized keywords: ns/id/5AC9C5AA75BA1F18D8459B326B4B8111A856D290
```
This is s...Sometimes when I get an ORCONN event, requesting its router status entry with "GETINFO ns/id/<fingerprint>" balks with...
```
GETINFO request contained unrecognized keywords: ns/id/5AC9C5AA75BA1F18D8459B326B4B8111A856D290
```
This is surprising since it seems like tor should have a router status entry available if it's emitting an ORCONN about it.
This is discussed in...
https://trac.torproject.org/projects/tor/ticket/13879https://gitlab.torproject.org/tpo/core/tor/-/issues/13901Tor fails when connecting to hidden services2020-06-27T14:02:08ZTracTor fails when connecting to hidden servicesDear Tor-Team,
I've set up a server with tor, which should provide 4 hidden services.
The server is located in Germany.
I configured them, and so far, everything worked fine.
I performed a check 20 minutes later in the same network, th...Dear Tor-Team,
I've set up a server with tor, which should provide 4 hidden services.
The server is located in Germany.
I configured them, and so far, everything worked fine.
I performed a check 20 minutes later in the same network, they were all available.
I'm now at home, 4 km away from the server, and I can't connect to any of the hidden services I set up.
All of them should be reachable via port 22 (ssh), some via port 443 (https).
I've tried the following:
helmut@linux:~> torify ssh superuser@<onion addr>.onion
results either in socks errors, or in timeouts after ~ 60 s.
Trying to enter the URLs in Tor Browser gives a timeout most of the time, sometimes a "connection reset".
So, the hidden services are not down - at least, not at all, but they're not alive, too.
I can reach the example hidden service.
I would be glad if anybody could help me.
Best wishes,
Helmut
P.S.: Please ignore my bad english, since I'm still going to school.
**Trac**:
**Username**: stackoverflowhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13924Reachability testing and channel is_local assume private addresses are local2020-06-27T14:02:07ZteorReachability testing and channel is_local assume private addresses are localSplit from legacy/trac#13718.
The way tor determines reachability is broken for test, internal, and local networks.
When we set is_local on a channel, we assume private addresses are local ~~DirAllowPrivateAddresses is 0~~. We then use...Split from legacy/trac#13718.
The way tor determines reachability is broken for test, internal, and local networks.
When we set is_local on a channel, we assume private addresses are local ~~DirAllowPrivateAddresses is 0~~. We then use is_local to determine whether a connection is from another router.
To properly bootstrap a testing tor network on private address(es), we must assume that every incoming OR connection is remote.
So we ignore is_local when TestingTorNetwork is 1.
~~I'm working on a patch that, when we're on a local address and DirAllowPrivateAddresses is 1, then checks whether we're connecting to our own digest, or another router's.~~
~~When we don't (yet) have this information (e.g. a reverse proxied connection), I think it's safer to assume local, and defer confirmation of reachability until we know who is at the other end. (This is no worse than the current behaviour.)~~teorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13928Tor Authorities reachability testing is predictable and sequential2020-06-27T14:02:07ZteorTor Authorities reachability testing is predictable and sequentialIn the tor network, all tor authorities test reachability in the same, predictable sequence. Each authority uses the same sequence, and, if started at similar times (a 10 second window ever 1280 seconds), they will start at the same poin...In the tor network, all tor authorities test reachability in the same, predictable sequence. Each authority uses the same sequence, and, if started at similar times (a 10 second window ever 1280 seconds), they will start at the same point. (This is a particular issue with test networks.)
I'd like to randomise the start point and progression of the sequence, while keeping the property that each 1280 second cycle tests all routers.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13936circuit_has_opened() should be called for rendezvous circuit2020-06-27T14:02:07ZDavid Gouletdgoulet@torproject.orgcircuit_has_opened() should be called for rendezvous circuitIn `circuit_get_open_circ_or_launch()`, for a rendezvous circuit, we directly called `rend_client_rendcirc_has_opened()` but I think `circuit_has_opened()` should be prefered here which then use a specialized function for each circuit pu...In `circuit_get_open_circ_or_launch()`, for a rendezvous circuit, we directly called `rend_client_rendcirc_has_opened()` but I think `circuit_has_opened()` should be prefered here which then use a specialized function for each circuit purpose. Also, it fires a controller event where the former did not.
Side effect is that `connection_ap_attach_pending()` is called right after but I don't think it affects anything here but that needs review of course.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13941log_new_relay_greeting() called for hidden-service keygen2020-06-27T14:02:07Zmeejahlog_new_relay_greeting() called for hidden-service keygeninit_key_from_file() in router.c calls log_new_relay_greeting() which congratulates you for running a relay -- however, init_key_from_file() is also called from rendservice.c rend_service_load_keys() which leads to a misleading log-messa...init_key_from_file() in router.c calls log_new_relay_greeting() which congratulates you for running a relay -- however, init_key_from_file() is also called from rendservice.c rend_service_load_keys() which leads to a misleading log-message if you add a new hidden-service.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13942Incorrect HiddenServiceDir ownership cause Tor to die2020-06-27T14:02:07ZmeejahIncorrect HiddenServiceDir ownership cause Tor to dieIf you use an existing HiddenServiceDir for a new hidden-service but it has incorrect ownership, Tor dies with "set_options(): Bug: Acting on config options left us in a broken state. Dying."If you use an existing HiddenServiceDir for a new hidden-service but it has incorrect ownership, Tor dies with "set_options(): Bug: Acting on config options left us in a broken state. Dying."Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13945constant micodesc erros over >= 2 days2020-06-27T14:02:07ZTracconstant micodesc erros over >= 2 daysHello - For at leat two days tor/vidalia been giving error notices. The last three showing up in the vidalia Message Log (Basic) are:
[Thu Dec 11 11:22:21 2014] Tor Software Error - The Tor software encountered an internal bug. Please r...Hello - For at leat two days tor/vidalia been giving error notices. The last three showing up in the vidalia Message Log (Basic) are:
[Thu Dec 11 11:22:21 2014] Tor Software Error - The Tor software encountered an internal bug. Please report the following error message to the Tor developers at bugs.torproject.org: "microdesc_cache_clean(): Bug: [0]: ID=93F1DD316F1044B2A173F21CF6D084F0DDBCF62E. md=025FBA98, rs=05F3C668, ri=043CF998. Microdesc digest in RS does match. RS okay in networkstatus.
"
[Thu Dec 11 11:22:21 2014] Tor Software Error - The Tor software encountered an internal bug. Please report the following error message to the Tor developers at bugs.torproject.org: "microdesc_cache_clean(): Bug: Microdescriptor seemed very old (last listed 168 hours ago vs 168 hour cutoff), but is still marked as being held by 1 node(s). I found 1 node(s) holding it. Current networkstatus is 1 hours old. Hashtable badness is 0.
"
[Thu Dec 11 11:22:21 2014] Tor Software Error - The Tor software encountered an internal bug. Please report the following error message to the Tor developers at bugs.torproject.org: "microdesc_cache_clean(): Bug: [0]: ID=2BC1C6359F2B4411DA277385F58582D04B4DDA34. md=0254B390, rs=0337A960, ri=04273D40. Microdesc digest in RS does match. RS okay in networkstatus.
"
The Message Log (Advanced) tab shows:
Dec 11 11:22:21.459 [Warning] microdesc_cache_clean(): Bug: [0]: ID=93F1DD316F1044B2A173F21CF6D084F0DDBCF62E. md=025FBA98, rs=05F3C668, ri=043CF998. Microdesc digest in RS does match. RS okay in networkstatus.
Dec 11 11:22:21.474 [Warning] microdesc_cache_clean(): Bug: Microdescriptor seemed very old (last listed 168 hours ago vs 168 hour cutoff), but is still marked as being held by 1 node(s). I found 1 node(s) holding it. Current networkstatus is 1 hours old. Hashtable badness is 0.
Dec 11 11:22:21.474 [Warning] microdesc_cache_clean(): Bug: [0]: ID=2BC1C6359F2B4411DA277385F58582D04B4DDA34. md=0254B390, rs=0337A960, ri=04273D40. Microdesc digest in RS does match. RS okay in networkstatus.
Dec 11 12:15:38.112 [Notice] Heartbeat: Tor's uptime is 7 days 17:50 hours, with 11 circuits open. I've sent 10.01 GB and received 10.04 GB.
At the same time (as can be seen from the last line above) the bridge is working fine & carrying a lot of traffic. Globe does show a periodicity in traffic that may reflect these errors; I'm not sure if the errors inhibit traffic or not.
I can supply complete logs for the past two days if you need them. HTH eliaz
**Trac**:
**Username**: eli