Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:19:54Zhttps://gitlab.torproject.org/legacy/trac/-/issues/5974Add configuration option for indicating if a directory authority is on IPv6 o...2020-06-13T14:19:54ZLinus Nordberglinus@torproject.orgAdd configuration option for indicating if a directory authority is on IPv6 or notBackground from #5534:
TODO: Add a configuration option telling tor if it's supposed to
have IPv6 connectivity. This will be something like
AuthorityHasIPv6Connectivity 0|1|auto. Clients and ordinary relays
will have to detect t...Background from #5534:
TODO: Add a configuration option telling tor if it's supposed to
have IPv6 connectivity. This will be something like
AuthorityHasIPv6Connectivity 0|1|auto. Clients and ordinary relays
will have to detect this.
This should be an option for authorities only for use until we have
good automatic detection of IPv6 connectivity.
The idea is that an authority with this option set to 0 will emit "a"
lines with IPv6 relay addresses without performing reachability tests.
The reasoning behind it is that relays on IPv6 shouldn't be punished
by directory authorities not on IPv6.
Regarding its default value, I think that 'auto' would be a good
default. Once we have automatic detection in place, leaving this
option out will make no difference. In the meantime 'auto' will turn
into '0' and authorities will by default let "a" lines through.
Regarding automatic detection, I wonder how we can do that without
leaking information. Is it possible? If not, how much can we leak?
Should we add more config option(s) for enabling more leaky strategies?Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/6779Add errno to "Failed to terminate process..." message2020-06-13T14:22:24ZGeorge KadianakisAdd errno to "Failed to terminate process..." message`tor_process_handle_destroy()` should print the `errno` if it failed to terminate the process.`tor_process_handle_destroy()` should print the `errno` if it failed to terminate the process.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5486Add IPv6 support to bridge authorities2020-06-13T14:18:31ZLinus Nordberglinus@torproject.orgAdd IPv6 support to bridge authoritiesFix the IPv4-only:isms we'll find when trying to run a bridge
authority on IPv6.Fix the IPv4-only:isms we'll find when trying to run a bridge
authority on IPv6.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/7098Add safe-cookie authentication to Extended ORPort and TransportControlPort2020-06-13T14:23:35ZGeorge KadianakisAdd safe-cookie authentication to Extended ORPort and TransportControlPortSafe-cookie authentication makes sure that the control port is only
accessed by clients that are aware of a secret cookie.
We should also protect the Extended ORPort and the
TransportControlPort in the same way, to make sure that only l...Safe-cookie authentication makes sure that the control port is only
accessed by clients that are aware of a secret cookie.
We should also protect the Extended ORPort and the
TransportControlPort in the same way, to make sure that only legit
pluggable transport proxies can access these ports.
Looking at control-spec.txt, it seems that the safe-cookie
authentication protocol follows the protocol format of the control
port protocol. Also, `control.c:handle_control_authchallenge()` is
designed specifically for control-port connections and cannot be used
in other parts of the codebase as it is.
This leaves us with (at least) three options:
1) Abstract `handle_control_authchallenge()` a bit, so that it's usable
by other parts of the codebase too. Modify the code as little as we
can, and leave it using the control-spec protocol format.
Pros:
+ We get to use safe-cookie auth in the transport ports, and maybe
in other ports in the future.
+ Refactoring `handle_control_authchallenge()` will be as easy and
painless as we can.
Cons:
+ The safe-cookie authentication protocol will have the format of
the control port, which will make it look funny when used in
front of other ports.
2) Abstract handle_control_authchallenge() so that it can be used as a
generic local-system authentication mechanism for Tor. This
involves removing all the control-port stuff from the protocol
(including the '250' return codes), simplifying the HMAC-SHA256
static strings, and making a beautiful API for the authentication.
Pros:
+ We get to use safe-cookie authentication in the transport ports.
+ We get a flexible local-system authentication mechanism that can
also be used nicely in the future when Tor's architecture becomes
modular.
Cons:
+ It will require some aesthetic refactoring of the safe-cookie
authentication protocol, and writing some spec files.
+ The implementation will be more troublesome than 1).
+ We will need to provide backwards compatibility for the current
safe-cookie authentication protocol.
3) Make a new variant of safe-cookie authentication protocol for the
transport ports. The protocol of the new variant will resemble the
protocol of the Extended ORPort and the TransportControlPort.
Next time we need a local-system authentication mechanism, we will
have to make yet another variant of the safe-cookie authencation
protocol.
Pros:
+ We don't get to abstract anything, and we simply copy/paste and
edit code. We also get to use safe-cookie authenication in
transport ports.
Cons:
+ Next time we need a local-system authentication system we will
need to redo this.
----
I haven't looked at the safe-cookie code enough to decide how easy it
is to be abstracted, but I'm drifting towards 1) or 2).
If we agree that safe-cookie authentication is a reasonable protocol
to protect any future Tor ports (we will have more of them as Tor
becomes more modular, won't we?), then maybe we should do 2) and
future-proof ourselves.
What do you say?Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/5547Add support for resolving destination names to IPv6 and exiting to IPv6 desti...2020-06-13T14:18:47ZKarsten LoesingAdd support for resolving destination names to IPv6 and exiting to IPv6 destinationsItem 24 from [org/sponsors/SponsorF/Year2](org/sponsors/SponsorF/Year2) is: "Support for resolving destination names to IPv6 and exiting to IPv6 destinations."
Summarizing [phase 5 of the IPv6 roadmap](https://gitweb.torproject.org/tors...Item 24 from [org/sponsors/SponsorF/Year2](org/sponsors/SponsorF/Year2) is: "Support for resolving destination names to IPv6 and exiting to IPv6 destinations."
Summarizing [phase 5 of the IPv6 roadmap](https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-ipv6-roadmap.txt#l143), this deliverable consists of the following substeps:
- We'll need to get our DNS resolver to support IPv6 addresses, and our clients to decide which address to report to the client and which to use.
- Transport IPv6 traffic and exit to IPv6 servers. The issues to solve here are exit policies; formulating an approach similar to the notion of topologically close in IPv4 (same /16) to IPv6, unless it doesn't make sense; and implementing the specified enhancements to RELAY_BEGIN cells from tor-spec.
- We need to extend TorDNSEL/TorBEL and the part of ExoneraTor that processes the TorDNSEL/TorBEL output.
- We also need to update VisiTor to handle IPv6 addresses in web server logs and compare them to exit lists. (There are zero known VisiTor users, so this should be considered optional.)
Anything else we need to do here?
Scheduling this ticket for November, not for July, because we'll be busy making clients talk to private and public bridges (phases 3 and 4 of the IPv4 roadmap) until [June](https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorG#Phase3:June302012).Tor: 0.2.4.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/7896Add transport information in boot logs related to bridges2020-06-13T14:26:19ZGeorge KadianakisAdd transport information in boot logs related to bridgesWhen a Tor client boots with bridges enabled, it spits out some logs related to those bridges:
```
[Notice] Learned fingerprint 844B1F53FFD548C998F8D3B01B7E19FA07C32222 for bridge 1.2.3.4:5678
[Notice] new bridge descriptor 'bla' (fresh...When a Tor client boots with bridges enabled, it spits out some logs related to those bridges:
```
[Notice] Learned fingerprint 844B1F53FFD548C998F8D3B01B7E19FA07C32222 for bridge 1.2.3.4:5678
[Notice] new bridge descriptor 'bla' (fresh): $844B1F53FFD548C998F8D3B01B7E19FA07C2222~bla at 1.2.3.4
```
In use cases where we have multiple bridges using multiple pluggable transports, it would be nice if those log messages also mentioned pluggable transport information.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/7766Add xsltproc to the list of asciidoc-helper's Debian packages2020-06-13T14:25:49ZDavid Fifielddcf@torproject.orgAdd xsltproc to the list of asciidoc-helper's Debian packagesWhen I build Tor on a new machine, I install the recommended docbook-xsl, docbook-xml, and libxl2-utils, and asciidoc still doesn't work. I have to remember that the other package I need is xsltproc, so let's add it to the list.When I build Tor on a new machine, I install the recommended docbook-xsl, docbook-xml, and libxl2-utils, and asciidoc still doesn't work. I have to remember that the other package I need is xsltproc, so let's add it to the list.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6423Adding, removing or changing an IPv6 OR port isn't a cosmetic change2020-06-13T14:21:22ZLinus Nordberglinus@torproject.orgAdding, removing or changing an IPv6 OR port isn't a cosmetic changerouter_differences_are_cosmetic() needs to take a potential IPv6 OR
port in consideration when deciding if a router has changed
substantially or not.router_differences_are_cosmetic() needs to take a potential IPv6 OR
port in consideration when deciding if a router has changed
substantially or not.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/3589Advertise bridge pluggable transports using extra-info lines2020-06-13T17:50:01ZGeorge KadianakisAdvertise bridge pluggable transports using extra-info linesWe should implement the "Advertising bridge methods" section of proposal 180.We should implement the "Advertising bridge methods" section of proposal 180.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/7489Allow hidden services on IPv6 addresses2020-06-13T14:25:03ZNick MathewsonAllow hidden services on IPv6 addressesWith everything else we're doing for IPv6, we should allow HS operators to run a hidden service on a local IPv6 address. I believe Andrea was interested in this one.With everything else we're doing for IPv6, we should allow HS operators to run a hidden service on a local IPv6 address. I believe Andrea was interested in this one.Tor: 0.2.4.x-finalAndrea ShepardAndrea Shepardhttps://gitlab.torproject.org/legacy/trac/-/issues/12227ASan stack-buffer-overflow in prune_v2_cipher_list -- not exploitable2020-06-13T14:36:44ZstarlightASan stack-buffer-overflow in prune_v2_cipher_list -- not exploitableFound a minor buffer overflow when
running live relay with 'tor' and
'openssl' both compiled with
AddressSanitizer.
tortls.c:1492: unsigned char cipherid[2];
should be three characters and the
final byte initialized to zero for
...Found a minor buffer overflow when
running live relay with 'tor' and
'openssl' both compiled with
AddressSanitizer.
tortls.c:1492: unsigned char cipherid[2];
should be three characters and the
final byte initialized to zero for
ssl2_get_cipher_by_char()
to function correctly and to avoid
an ASan access exception.
Tested patch that resolves this
issue is attached.
Compiled with gcc 4.8.1 and with
these added options:
tor-0.2.4.22
-O1 # instead of -O2
-fsanitize=address
-fno-omit-frame-pointer
openssl-1.0.1h
-fstack-protector-all
--param ssp-buffer-size=1
-fsanitize=address
-fno-omit-frame-pointer
-DOPENSSL_NO_BUF_FREELISTTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/9640assertion bug in directory_initiate_command_rend using tor2web mode2020-06-13T14:31:26Zcypherpunksassertion bug in directory_initiate_command_rend using tor2web modecompiled tor-0.2.4.16-rc with --enable-tor2web-mode and set Tor2webMode 1
When opening a socks connection (e.g. usewithtor curl some.onion) it crashes:
[err] directory_initiate_command_rend(): Bug: src/or/directory.c:999: directory_ini...compiled tor-0.2.4.16-rc with --enable-tor2web-mode and set Tor2webMode 1
When opening a socks connection (e.g. usewithtor curl some.onion) it crashes:
[err] directory_initiate_command_rend(): Bug: src/or/directory.c:999: directory_initiate_command_rend: Assertion !(is_sensitive_dir_purpose(dir_purpose) && !anonymized_connection) failed; aborting.
src/or/directory.c:999 directory_initiate_command_rend: Assertion !(is_sensitive_dir_purpose(dir_purpose) && !anonymized_connection) failed; aborting.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/7350Assertion chan->state == CHANNEL_STATE_OPENING || chan->state == CHANNEL_STAT...2020-06-13T14:24:40ZAndrea ShepardAssertion chan->state == CHANNEL_STATE_OPENING || chan->state == CHANNEL_STATE_OPEN || chan->state == CHANNEL_STATE_MAINT failedI saw this while trying to reproduce #7267:
src/or/channel.c:1668 channel_write_cell_queue_entry: Assertion chan->state == CHANNEL_STATE_OPENING || chan->state == CHANNEL_STATE_OPEN || chan->state == CHANNEL_STATE_MAINT failed; aborting...I saw this while trying to reproduce #7267:
src/or/channel.c:1668 channel_write_cell_queue_entry: Assertion chan->state == CHANNEL_STATE_OPENING || chan->state == CHANNEL_STATE_OPEN || chan->state == CHANNEL_STATE_MAINT failed; aborting.
The stack trace is:
#0 0x00007ffff69619b5 in raise () from /lib64/libc.so.6
#1 0x00007ffff696305f in abort () from /lib64/libc.so.6
#2 0x000000000047fbd9 in channel_write_cell_queue_entry (chan=0x1409340, q=0x7fffffffdd90) at src/or/channel.c:1666
#3 0x00000000004801ef in channel_write_cell (chan=0x1409340, cell=0x7fffffffddf0) at src/or/channel.c:1748
#4 0x00000000004831b6 in channel_send_destroy (circ_id=62492, chan=0x1409340, reason=8) at src/or/channel.c:2598
#5 0x0000000000498a5f in circuit_mark_for_close_ (circ=0x198fe80, reason=8, line=1047,
file=0x5753a9 "src/or/circuitlist.c") at src/or/circuitlist.c:1442
#6 0x0000000000497996 in circuit_unlink_all_from_channel (chan=0x11a7720, reason=8) at src/or/circuitlist.c:1047
#7 0x000000000047ec78 in channel_closed (chan=0x11a7720) at src/or/channel.c:1288
#8 0x00000000004d50b8 in connection_or_about_to_close (or_conn=0x26e2c80) at src/or/connection_or.c:601
#9 0x00000000004bf91a in connection_about_to_close_connection (conn=0x26e2c80) at src/or/connection.c:633
#10 0x0000000000409108 in connection_unlink (conn=0x26e2c80) at src/or/main.c:385
#11 0x000000000040aa69 in conn_close_if_marked (i=18) at src/or/main.c:932
#12 0x000000000040a151 in close_closeable_connections () at src/or/main.c:702
#13 0x000000000040be70 in run_scheduled_events (now=1352251511) at src/or/main.c:1535
#14 0x000000000040c396 in second_elapsed_callback (timer=0xd7afc0, arg=0x0) at src/or/main.c:1691
#15 0x000000000054f892 in periodic_timer_cb (fd=-1, what=1, arg=0xd7afc0) at src/common/compat_libevent.c:599
#16 0x00007ffff772f930 in event_process_active (base=0x7e04d0, flags=<value optimized out>) at event.c:395
#17 event_base_loop (base=0x7e04d0, flags=<value optimized out>) at event.c:547
#18 0x000000000040cbdd in do_main_loop () at src/or/main.c:1987
#19 0x000000000040e19d in tor_main (argc=3, argv=0x7fffffffe638) at src/or/main.c:2699
#20 0x00000000004087a4 in main (argc=3, argv=0x7fffffffe638) at src/or/tor_main.c:30Tor: 0.2.4.x-finalAndrea ShepardAndrea Shepardhttps://gitlab.torproject.org/legacy/trac/-/issues/14129Assertion failure in dns.c, possibly connected to UDP DoS attack2020-06-13T14:41:35ZTracAssertion failure in dns.c, possibly connected to UDP DoS attackI run a full exit node, and today I was hit by a udp denial of service. Standard botnet garbage, really. But something surprising happened:
Jan 7 10:54:51 testbed Tor[4289]: Circuit handshake stats since last time: 92457/94799 TAP, 209...I run a full exit node, and today I was hit by a udp denial of service. Standard botnet garbage, really. But something surprising happened:
Jan 7 10:54:51 testbed Tor[4289]: Circuit handshake stats since last time: 92457/94799 TAP, 209527/209991 NTor.
Jan 7 15:28:03 testbed Tor[4289]: eventdns: All nameservers have failed
Jan 7 15:28:03 testbed Tor[4289]: eventdns: All nameservers have failed
Jan 7 15:28:03 testbed Tor[4289]: eventdns: Nameserver 8.8.8.8:53 is back up
Jan 7 15:28:03 testbed Tor[4289]: eventdns: Nameserver 8.8.8.8:53 is back up
Jan 7 15:28:48 testbed Tor[4289]: eventdns: All nameservers have failed
Jan 7 15:28:48 testbed Tor[4289]: eventdns: All nameservers have failed
Jan 7 15:28:48 testbed Tor[4289]: eventdns: Nameserver 8.8.8.8:53 is back up
Jan 7 15:28:48 testbed Tor[4289]: eventdns: Nameserver 8.8.8.8:53 is back up
Jan 7 15:29:01 testbed Tor[4289]: eventdns: All nameservers have failed
Jan 7 15:29:01 testbed Tor[4289]: eventdns: All nameservers have failed
Jan 7 15:29:01 testbed Tor[4289]: eventdns: Nameserver 8.8.8.8:53 is back up
Jan 7 15:29:01 testbed Tor[4289]: eventdns: Nameserver 8.8.8.8:53 is back up
Jan 7 15:29:23 testbed Tor[4289]: eventdns: All nameservers have failed
Jan 7 15:29:23 testbed Tor[4289]: eventdns: All nameservers have failed
Jan 7 15:29:23 testbed Tor[4289]: eventdns: Nameserver 8.8.8.8:53 is back up
Jan 7 15:29:23 testbed Tor[4289]: eventdns: Nameserver 8.8.8.8:53 is back up
Jan 7 15:30:04 testbed Tor[4289]: eventdns: All nameservers have failed
Jan 7 15:30:04 testbed Tor[4289]: eventdns: All nameservers have failed
Jan 7 16:06:15 testbed Tor[4289]: tor_assertion_failed_(): Bug: src/or/dns.c:1136: connection_dns_remove: Assertion 0 failed; aborting.
Jan 7 16:06:15 testbed Tor[4289]: tor_assertion_failed_(): Bug: src/or/dns.c:1136: connection_dns_remove: Assertion 0 failed; aborting.
Jan 7 16:06:15 testbed Tor[4289]: Bug: Assertion 0 failed in connection_dns_remove at src/or/dns.c:1136. Stack trace:
Jan 7 16:06:15 testbed Tor[4289]: Bug: Assertion 0 failed in connection_dns_remove at src/or/dns.c:1136. Stack trace:
Jan 7 16:06:15 testbed Tor[4289]: Bug: /usr/bin/tor(log_backtrace+0x29) [0x50dbe9]
Jan 7 16:06:15 testbed Tor[4289]: Bug: /usr/bin/tor(log_backtrace+0x29) [0x50dbe9]
Jan 7 16:06:15 testbed Tor[4289]: Bug: /usr/bin/tor(tor_assertion_failed_+0x7a) [0x51af6a]
Jan 7 16:06:15 testbed Tor[4289]: Bug: /usr/bin/tor(tor_assertion_failed_+0x7a) [0x51af6a]
Jan 7 16:06:15 testbed Tor[4289]: Bug: /usr/bin/tor(connection_dns_remove+0x240) [0x4fa6e0]
Jan 7 16:06:15 testbed Tor[4289]: Bug: /usr/bin/tor(connection_dns_remove+0x240) [0x4fa6e0]
Jan 7 16:06:15 testbed Tor[4289]: Bug: /usr/bin/tor() [0x428ed9]
Jan 7 16:06:15 testbed Tor[4289]: Bug: /usr/bin/tor() [0x428ed9]
Jan 7 16:06:15 testbed Tor[4289]: Bug: /usr/bin/tor() [0x429209]
Jan 7 16:06:15 testbed Tor[4289]: Bug: /usr/bin/tor() [0x429209]
Jan 7 16:06:15 testbed Tor[4289]: Bug: /usr/lib64/libevent-2.0.so.5(event_base_loop+0x40c) [0x3758b7d8f5c]
Jan 7 16:06:15 testbed Tor[4289]: Bug: /usr/lib64/libevent-2.0.so.5(event_base_loop+0x40c) [0x3758b7d8f5c]
Jan 7 16:06:15 testbed Tor[4289]: Bug: /usr/bin/tor(do_main_loop+0x215) [0x42afd5]
Jan 7 16:06:15 testbed Tor[4289]: Bug: /usr/bin/tor(do_main_loop+0x215) [0x42afd5]
Jan 7 16:06:15 testbed Tor[4289]: Bug: /usr/bin/tor(tor_main+0x15d5) [0x42dc05]
Jan 7 16:06:15 testbed Tor[4289]: Bug: /usr/bin/tor(tor_main+0x15d5) [0x42dc05]
Jan 7 16:06:15 testbed Tor[4289]: Bug: /lib64/libc.so.6(__libc_start_main+0xf5) [0x3758abecab5]
Jan 7 16:06:15 testbed Tor[4289]: Bug: /lib64/libc.so.6(__libc_start_main+0xf5) [0x3758abecab5]
Jan 7 16:06:15 testbed Tor[4289]: Bug: /usr/bin/tor() [0x427e31]
Jan 7 16:06:15 testbed Tor[4289]: Bug: /usr/bin/tor() [0x427e31]
I have been having issues with DNS connectivity due to the high packet (~100k pps) rate, which means tor has been without consistent DNS for about a half hour before this died.
Having tor crash was extremely surprising.
I am running tor on Gentoo, tor version:
# tor --version
Tor version 0.2.6.1-alpha (git-5a601dd2901644a5).
My suspicion is that DNS requests piled up in an internal tor buffer of some sort, and that got maxed out resulting in an oops.
I'll try to keep an eye on this. Let me know if more information is needed for debugging.
**Trac**:
**Username**: jowrTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8031Assertion fast_memeq(md->body, "onion-key", 9) failed;2020-06-13T14:26:41ZcypherpunksAssertion fast_memeq(md->body, "onion-key", 9) failed;I am running Tor v0.2.4.6-alpha (git-b13c6becc892d971) running on Linux with Libevent 1.4.13-stable and OpenSSL 0.9.8o.
The system is running i686 debian linux 2.6.38.2 with some grsec patches applied.
Tor crashed with the following me...I am running Tor v0.2.4.6-alpha (git-b13c6becc892d971) running on Linux with Libevent 1.4.13-stable and OpenSSL 0.9.8o.
The system is running i686 debian linux 2.6.38.2 with some grsec patches applied.
Tor crashed with the following message in the console:
==== console
[... cut... ] [notice] Opening Directory listener on 0.0.0.0:3128
src/or/microdesc.c:492 microdesc_cache_rebuild: Assertion
fast_memeq(md->body, "onion-key", 9) failed; aborting.
Aborted.
==== // end of console
==== /var/log/tor/log from just before:
Jan 17 23:44:09.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [50 similar message(s) suppressed in last 60 seconds]
Jan 17 23:45:09.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [184 similar message(s) suppressed in last 60 seconds]
Jan 17 23:46:09.000 [warn] Your computer i
==== // end of /var/log/tor/log (it ends abruptly)
The log is big (17M) and dates a year or so back.
Looking through it now, I discovered that it routinely complained about things such as:
====
Jan 04 09:04:31.000 [warn] Failing because we have 1016 connections already. Please raise your ulimit -n. [272740629 similar message(s) suppressed in last 21600 seconds]
Jan 04 09:48:12.000 [warn] Cannot seed RNG -- no entropy source found.
Jan 04 09:55:16.000 [warn] Couldn't open "/var/lib/tor2/state.tmp" (/var/lib/tor2/state) for writing: Too many open files
Jan 04 09:55:16.000 [warn] Unable to write state to file "/var/lib/tor2/state"; will try again later
====
This feels like mismanagement on my part, but the console didn't say anything about it, so I never checked the logs before. It was running in a chroot and I must have forgotten to give it read permission for the chrooted /dev/{u,}random.
I hope this has nothing to do with the bug, but maybe a new change request should be added to write messages like that on the console?
I am available on irc as "sadoper" if you need further information.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6979Assertion on router.c:164 when disabling ORPort2020-06-13T14:23:09ZTracAssertion on router.c:164 when disabling ORPortFrom the Vidalia Message Log:
[Tue Sep 25 14:37:20 2012] The Tor Software is Running - You are currently running version "0.2.2.39 (git-bec76476efb71549)" of the Tor software.
[Tue Sep 25 14:37:39 2012] Tor Software Error - The Tor soft...From the Vidalia Message Log:
[Tue Sep 25 14:37:20 2012] The Tor Software is Running - You are currently running version "0.2.2.39 (git-bec76476efb71549)" of the Tor software.
[Tue Sep 25 14:37:39 2012] Tor Software Error - The Tor software encountered an internal bug. Please report the following error message to the Tor developers at bugs.torproject.org: "get_server_identity_key(): Bug: router.c:164: get_server_identity_key: Assertion server_mode(get_options()) failed; aborting.
"
There were several previous instances of this error, without the notice to report.
It's about time this came thru - I haven't been able to get this ver. to talk to my local and router firewalls, and with the fws down, the pgm hangs on my bridge identifying itself. For what it may be worth, here are some of the unexpected and AFAIKS incorrect log entries:
Sep 25 09:45:56.354 [Info] internal circ (length 3, last hop maushaus): Ramsgate(open) $BDB507AC02DC3AF1890A58F318FE68FC64CACCDE(open) $E31ABC8D5BD40F936A758B1C149B75F973E7AD2F(closed)
Sep 25 10:14:36.453 [Info] internal circ (length 3, last hop maushaus): srvph3xat(open) CCN(open) $E31ABC8D5BD40F936A758B1C149B75F973E7AD2F(waiting for keys)
HTH eli----
gpg: 0x3E346824
**Trac**:
**Username**: eliTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/7533AUTHDIR_NEWDESCS vaguely documented2020-06-13T14:25:08ZDamian JohnsonAUTHDIR_NEWDESCS vaguely documentedThe AUTHDIR_NEWDESCS events lack sufficient information for me to parse them. At present all the spec has is...
```
4.1.8. Descriptors uploaded to us in our role as authoritative dirserver
Syntax:
"650" "+" "AUTHDIR_NEWDESCS" CR...The AUTHDIR_NEWDESCS events lack sufficient information for me to parse them. At present all the spec has is...
```
4.1.8. Descriptors uploaded to us in our role as authoritative dirserver
Syntax:
"650" "+" "AUTHDIR_NEWDESCS" CRLF Action CRLF Message CRLF
Descriptor CRLF "." CRLF "650" SP "OK" CRLF
Action = "ACCEPTED" / "DROPPED" / "REJECTED"
Message = Text
```
https://gitweb.torproject.org/torspec.git/blob/HEAD:/control-spec.txt#l1505
Questions that I have are...
* What meaning does the "Message" have? What characters can it contain? Can it have newlines?
* The Actions should have a description for what the actions mean, and say if new values are allowed or not.
* What format does the "Descriptor" take? Is this a server descriptor? Microdescriptor? Router status entry? What version?Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8218Authorities mark every relay as down-for-an-hour at every restart2020-06-13T14:27:27ZRoger DingledineAuthorities mark every relay as down-for-an-hour at every restartIn https://trac.torproject.org/projects/tor/ticket/1035#comment:40 I reported
```
Jul 07 14:08:27.000 [info] rep_hist_note_router_reachable(): Router BFA1BA13CAC96F8C13689FE1FDC65359ED6AC6D7 still seems Running, but its address appears t...In https://trac.torproject.org/projects/tor/ticket/1035#comment:40 I reported
```
Jul 07 14:08:27.000 [info] rep_hist_note_router_reachable(): Router BFA1BA13CAC96F8C13689FE1FDC65359ED6AC6D7 still seems Running, but its address appears to have changed since the last time it was reachable. I'm going to treat it as having been down for 7200 seconds
```
I see those in practice on moria1 still:
```
$ grep -i "still seems" moria1-info|grep "Feb 12"|wc -l
501
```
The issue is this code:
```
addr_changed = at_addr &&
tor_addr_compare(at_addr, &hist->last_reached_addr, CMP_EXACT) != 0;
port_changed = at_port && at_port != hist->last_reached_port;
```
where last_reached_foo always starts out empty, so the first comparison always shows a change.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8711authorities should say on their flag-threshold lines in their vote whether th...2020-06-13T14:28:43ZRoger Dingledineauthorities should say on their flag-threshold lines in their vote whether they have enough Measured lines that they're counting non-Measured relays as 0 bandwidthauthorities should say on their flag-threshold lines in their vote whether they have enough Measured lines that they're counting non-Measured relays as 0 bandwidth
that will help karsten to track and explain changes over timeauthorities should say on their flag-threshold lines in their vote whether they have enough Measured lines that they're counting non-Measured relays as 0 bandwidth
that will help karsten to track and explain changes over timeTor: 0.2.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6621Authorities shouldn't set Running unless all advertised OR ports are reachable2020-06-13T14:21:54ZLinus Nordberglinus@torproject.orgAuthorities shouldn't set Running unless all advertised OR ports are reachableProp 186 says
An authority shouldn't list a node as Running unless every
or-address line it advertises looks like it will work.
Authorities don't consider a potential IPv6 OR port when deciding
whether a relay is running or not.
I...Prop 186 says
An authority shouldn't list a node as Running unless every
or-address line it advertises looks like it will work.
Authorities don't consider a potential IPv6 OR port when deciding
whether a relay is running or not.
I suggest we fix that but have auths not on IPv6
(AuthDirHasIPv6Connectivity == 0) not take IPv6 reachability into
account.Tor: 0.2.4.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.org