Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:13:31Zhttps://gitlab.torproject.org/legacy/trac/-/issues/4130Should relays use begindir or naked dirport connections?2020-06-13T14:13:31ZRoger DingledineShould relays use begindir or naked dirport connections?In #4115 it was noted that bridges were using naked dirport connections. That was clearly a bug, and has been fixed.
But it is less clear what public relays should do.
In favor: encrypting dir fetches improves their resistance to tampe...In #4115 it was noted that bridges were using naked dirport connections. That was clearly a bug, and has been fixed.
But it is less clear what public relays should do.
In favor: encrypting dir fetches improves their resistance to tampering on the wire, including tampering of unauthenticated stuff like the X-Your-Address-Is and Date http headers.
Against: it increases the load they place on the authorities, both in terms of CPU (all those bonus TLS handshakes) and sockets (since TLS connections are held open for a while).Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/7201Expand remaining parts of xxx-new-crypto-sketch2020-06-13T14:24:08ZKarsten LoesingExpand remaining parts of xxx-new-crypto-sketchNick thinks there's probably another proposal or two to be had in the remaining parts of xxx-new-crypto-sketch that haven't been expanded yet, like the parts where we have better signatures on stuff and get away from remaining users of R...Nick thinks there's probably another proposal or two to be had in the remaining parts of xxx-new-crypto-sketch that haven't been expanded yet, like the parts where we have better signatures on stuff and get away from remaining users of RSA1024 and SHA1. He thinks we could and should write a proposal in 2013.https://gitlab.torproject.org/legacy/trac/-/issues/6027Directory authorities on IPv62020-06-13T14:29:48ZLinus Nordberglinus@torproject.orgDirectory authorities on IPv6Directory authorities don't know enough about IPv6. There are a lot
of issues here, two of which are mentioned in #4847:
- init_keys()
- dirserv_generate_networkstatus_vote_obj()Directory authorities don't know enough about IPv6. There are a lot
of issues here, two of which are mentioned in #4847:
- init_keys()
- dirserv_generate_networkstatus_vote_obj()Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/10461tor seems to ignore "DirServer" option2020-06-13T14:33:29ZTractor seems to ignore "DirServer" optionI've got the following 3 directives in my torrc:
DirServer 95.223.60.130:443 23155386E3B4B93B0294DB3A6263A8FAFE273255
DirServer 89.245.227.226:9001 6CB447C4CBCC4F5BDB4BA096902C2956CB534999
DirServer 109.228.139.83:9001 9DD97868543CB3CF4...I've got the following 3 directives in my torrc:
DirServer 95.223.60.130:443 23155386E3B4B93B0294DB3A6263A8FAFE273255
DirServer 89.245.227.226:9001 6CB447C4CBCC4F5BDB4BA096902C2956CB534999
DirServer 109.228.139.83:9001 9DD97868543CB3CF432B96C082DFAC1FD16F6768
but none of the above statements seem to have been honoured by tor as I get this in my logs (debug-level):
[notice] {GENERAL} 0 entries in guards
[info] {CIRC} compute_weighted_bandwidths(): Empty routerlist passed in to consensus weight node selection for rule weight as guard
[info] {CIRC} smartlist_choose_node_by_bandwidth(): Empty routerlist passed in to old node selection for rule weight as guard
[info] {DIR} directory_pick_generic_dirserver(): No router found for consensus network-status fetch; falling back to dirserver list.
[info] {DIR} router_pick_dirserver_generic(): No dirservers are reachable. Trying them all again.
[notice] {DIR} While fetching directory info, no running dirservers known. Will try again later. (purpose 14)
[info] {GENERAL} or_state_save(): Saved state to "/var/lib/tor/tor/state"
Why?
I don't usually set the DirServer options, but, as of yesterday, my tor gets stuck at 5% when I shutdown tor after getting the following log:
{PROTOCOL} Received a bad CERTS cell from [scrubbed]:9001: The link certificate didn't match the TLS public key
I then wiped out the entire /var/lib/tor directory (to force fresh consensus download) and then got this when I tried to start tor (again, debug-level):
=============================
Dec 21 11:17:24.000 [notice] {GENERAL} 0 entries in guards
Dec 21 11:17:24.000 [info] {CIRC} compute_weighted_bandwidths(): Empty routerlist passed in to consensus weight node selection for rule weight as guard
Dec 21 11:17:24.000 [info] {CIRC} smartlist_choose_node_by_bandwidth(): Empty routerlist passed in to old node selection for rule weight as guard
Dec 21 11:17:24.000 [info] {DIR} directory_pick_generic_dirserver(): No router found for consensus network-status fetch; falling back to dirserver list.
Dec 21 11:17:24.000 [debug] {DIR} directory_initiate_command_rend(): anonymized 0, use_begindir 1.
Dec 21 11:17:24.000 [debug] {DIR} directory_initiate_command_rend(): Initiating consensus network-status fetch
Dec 21 11:17:24.000 [info] {APP} connection_ap_make_link(): Making internal direct tunnel to [scrubbed]:443 ...
Dec 21 11:17:24.000 [debug] {NET} connection_add_impl(): new conn type Socks, socket -1, address (Tor_internal), n_conns 3.
Dec 21 11:17:24.000 [debug] {DIR} circuit_get_open_circ_or_launch(): considering 1, $7BE683E65D48141321C5ED92F075C55364AC7123
Dec 21 11:17:24.000 [debug] {CIRC} onion_pick_cpath_exit(): Launching a one-hop circuit for dir tunnel.
Dec 21 11:17:24.000 [info] {CIRC} onion_pick_cpath_exit(): Using requested exit node '$7BE683E65D48141321C5ED92F075C55364AC7123~7BE683E65D48141321C at 193.23.244.244'
Dec 21 11:17:24.000 [debug] {CIRC} onion_extend_cpath(): Path is 0 long; we want 1
Dec 21 11:17:24.000 [debug] {CIRC} onion_extend_cpath(): Chose router $7BE683E65D48141321C5ED92F075C55364AC7123~7BE683E65D48141321C at 193.23.244.244 for hop 1 (exit is 7BE683E65D48141321C5ED92F075C55364AC7123)
Dec 21 11:17:24.000 [debug] {CIRC} onion_extend_cpath(): Path is complete: 1 steps long
Dec 21 11:17:24.000 [debug] {CIRC} circuit_handle_first_hop(): Looking for firsthop '193.23.244.244:443'
Dec 21 11:17:24.000 [info] {CIRC} circuit_handle_first_hop(): Next router is [scrubbed]: Not connected. Connecting.
Dec 21 11:17:24.000 [notice] {CONTROL} Bootstrapped 5%: Connecting to directory server.
Dec 21 11:17:24.000 [debug] {CHANNEL} channel_tls_connect(): In channel_tls_connect() for channel 0xb797c2e8 (global id 0)
Dec 21 11:17:24.000 [debug] {CHANNEL} channel_set_identity_digest(): Setting remote endpoint digest on channel 0xb797c2e8 with global ID 0 to digest 7BE683E65D48141321C5ED92F075C55364AC7123
Dec 21 11:17:24.000 [debug] {NET} connection_connect(): Connecting to [scrubbed]:443.
Dec 21 11:17:25.000 [debug] {NET} connection_connect(): Connection to [scrubbed]:443 in progress (sock 4).
Dec 21 11:17:25.000 [debug] {NET} connection_add_impl(): new conn type OR, socket 4, address 193.23.244.244, n_conns 4.
Dec 21 11:17:25.000 [debug] {CHANNEL} channel_tls_connect(): Got orconn 0xb797c3c0 for channel with global id 0
Dec 21 11:17:25.000 [debug] {CHANNEL} channel_register(): Registering channel 0xb797c2e8 (ID 0) in state opening (1) with digest 7BE683E65D48141321C5ED92F075C55364AC7123
Dec 21 11:17:25.000 [debug] {CHANNEL} channel_add_to_digest_map(): Added channel 0xb797c2e8 (global ID 0) to identity map in state opening (1) with digest 7BE683E65D48141321C5ED92F075C55364AC7123
Dec 21 11:17:25.000 [debug] {CHANNEL} channel_set_cell_handlers(): Setting cell_handler callback for channel 0xb797c2e8 to 0xb7668500
Dec 21 11:17:25.000 [debug] {CHANNEL} channel_set_cell_handlers(): Setting var_cell_handler callback for channel 0xb797c2e8 to 0xb7667340
Dec 21 11:17:25.000 [debug] {CIRC} circuit_handle_first_hop(): connecting in progress (or finished). Good.
Dec 21 11:17:25.000 [info] {APP} connection_ap_make_link(): ... application connection created and linked.
Dec 21 11:17:25.000 [debug] {NET} connection_add_impl(): new conn type Directory, socket -1, address 193.23.244.244, n_conns 5.
Dec 21 11:17:25.000 [info] {DIR} directory_send_command(): Downloading consensus from 193.23.244.244:443 using /tor/status-vote/current/consensus-microdesc/14C131+27B6B5+49015F+585769+805509+D586D1+E8A9C4+ED03BB+EFCBE7.z
Dec 21 11:17:25.000 [info] {GENERAL} or_state_save(): Saved state to "/var/lib/tor/tor/state"
Dec 21 11:17:25.000 [debug] {NET} conn_read_callback(): socket -1 wants to read.
Dec 21 11:17:25.000 [info] {EDGE} connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
Dec 21 11:17:25.000 [info] {EDGE} connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
Dec 21 11:17:25.000 [debug] {DIR} connection_dir_finished_flushing(): client finished sending command.
Dec 21 11:17:25.000 [debug] {NET} conn_read_callback(): socket 4 wants to read.
Dec 21 11:17:25.000 [info] {CONTROL} control_event_bootstrap_problem(): Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Connection refused; CONNECTREFUSED; count 1; recommendation ignore)
Dec 21 11:17:25.000 [debug] {CHANNEL} channel_close_for_error(): Closing channel 0xb797c2e8 due to lower-layer error
Dec 21 11:17:25.000 [debug] {CHANNEL} channel_change_state(): Changing state of channel 0xb797c2e8 (global ID 0) from "opening" to "closing"
Dec 21 11:17:25.000 [debug] {CHANNEL} channel_remove_from_digest_map(): Removed channel 0xb797c2e8 (global ID 0) from identity map in state closing (4) with digest 7BE683E65D48141321C5ED92F075C55364AC7123
Dec 21 11:17:25.000 [debug] {CHANNEL} connection_mark_for_close_internal_(): Calling connection_mark_for_close_internal_() on an OR conn at src/or/connection.c:2828
Dec 21 11:17:25.000 [debug] {NET} conn_close_if_marked(): Cleaning up connection (fd -1).
Dec 21 11:17:25.000 [debug] {CIRC} circuit_n_chan_done(): chan to NULL/193.23.244.244:443, status=0
Dec 21 11:17:25.000 [info] {CIRC} circuit_n_chan_done(): Channel failed; closing circ.
Dec 21 11:17:25.000 [info] {OR} circuit_build_failed(): Our circuit died before the first hop with no connection
Dec 21 11:17:25.000 [info] {APP} connection_ap_fail_onehop(): Closing one-hop stream to '$7BE683E65D48141321C5ED92F075C55364AC7123/193.23.244.244' because the OR conn just failed.
Dec 21 11:17:25.000 [debug] {CIRC} circuit_increment_failure_count(): n_circuit_failures now 1.
Dec 21 11:17:25.000 [debug] {CHANNEL} channel_change_state(): Changing state of channel 0xb797c2e8 (global ID 0) from "closing" to "channel error"
Dec 21 11:17:25.000 [info] {HANDSHAKE} connection_or_note_state_when_broken(): Connection died in state 'connect()ing with SSL state (No SSL object)'
Dec 21 11:17:25.000 [debug] {NET} connection_remove(): removing socket -1 (type OR), n_conns now 5
Dec 21 11:17:25.000 [debug] {NET} conn_close_if_marked(): Cleaning up connection (fd -1).
Dec 21 11:17:25.000 [debug] {NET} connection_remove(): removing socket -1 (type Socks), n_conns now 4
Dec 21 11:17:25.000 [info] {GENERAL} connection_free_(): Freeing linked Socks connection [waiting for circuit] with 152 bytes on inbuf, 0 on outbuf.
Dec 21 11:17:25.000 [debug] {NET} conn_read_callback(): socket -1 wants to read.
Dec 21 11:17:25.000 [info] {HTTP} connection_dir_client_reached_eof(): 'fetch' response not all here, but we're at eof. Closing.
Dec 21 11:17:25.000 [debug] {NET} conn_close_if_marked(): Cleaning up connection (fd -1).
=============================
Repeat ad-nauseum! The above log seems to stem from the fact that it looks as though dannenberg ($7BE683E65D48141321C5ED92F075C55364AC7123/193.23.244.244) doesn't accept connections on ports 443 or 80 anymore (is it down?), grinding my tor bootup to a screeching halt - something I tried to offset by explicitly setting 3 "DirServer" options, but to no avail.
Secondly, why is tor insisting on downloading its descriptors/data from that directory and not trying some other - is dannenberg the only one? I seriously doubt it!
**Trac**:
**Username**: mr-4Tor: unspecifiedNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/12464When Tor 0.2.6.x is closer to done, profile relays running Tor 0.2.6.x and op...2020-06-13T14:37:01ZNick MathewsonWhen Tor 0.2.6.x is closer to done, profile relays running Tor 0.2.6.x and optimize accordinglySee #11332 for the ticket where we did this in 0.2.5, for experience and ideas.See #11332 for the ticket where we did this in 0.2.5, for experience and ideas.Tor: 0.2.6.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/12466Possible primary guard node skip when some guards are down2020-06-13T14:37:02ZGeorge KadianakisPossible primary guard node skip when some guards are downThis is another possible guard node skip (similar to #12450), that can make Tor skip some of the higher priority guards and prefer guards in the lower end of the list.
#12450 applies even for `NumEntryGuards=1`, but this one applies onl...This is another possible guard node skip (similar to #12450), that can make Tor skip some of the higher priority guards and prefer guards in the lower end of the list.
#12450 applies even for `NumEntryGuards=1`, but this one applies only when `NumEntryGuards` is larger than 1.
So, this loop [0] in `choose_random_entry_impl()`:
https://gitweb.torproject.org/tor.git/blob/d064773595f1d0bf1b76dd6f7439bff653a3c8ce:/src/or/entrynodes.c#l1035
will try to add guards to `live_entry_guards` till it contains `NumEntryGuards` entry guards, which is **3** currently.
Finally this code [1] will pick one of them:
https://gitweb.torproject.org/tor.git/blob/d064773595f1d0bf1b76dd6f7439bff653a3c8ce:/src/or/entrynodes.c#l1133
Let's assume that our state file contains many guards (50 or so), so we have plenty of nodes to add to our `live_entry_guards`. It also so happens that the third entry guard in our `entry_guards` list just went dead.
So, now we need to make a circuit. We go over loop [0], and add the first three guards to `live_entry_guards`, then [1] picks the third entry node to be used by the circuit. Unfortunately, since that node is down, the circuit dies. And we go back to `choose_random_entry_impl()` to get a new entry node.
So, now we go over the loop [0], and we add the first two entry guards and the fourth one (since the 3rd entry guard is now marked as unreachable). If [1] now picks the fourth entry guard, we have "skipped" our primary guards and selected a lower priority one.
As a matter of fact, we can imagine this procedure happening a lot of times, and if we are very unlucky, Tor will keep on adding new dead entry guards to our `live_entry_guards` list and then it will keep on choosing them. This will result in a `live_entry_guards` list always containing the first two entry guards (let's call them the primary entry guards) and then the 48th entry guard in our list. Then Tor will choose the 48th entry guard and succeed on making a circuit, and there you have it, we just picked a very low priority entry guard for our circuit.
This is theoretically possible, but not very likely to happen in practice. But since we are trying to pay more attention to guard node security, maybe it should be fixed.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/12877Investigate Unmeasured relays that get the Fast flag2020-06-13T14:37:52ZGeorge KadianakisInvestigate Unmeasured relays that get the Fast flagI was looking at some consensuses today, and I noticed that there are many `Unmeasured` relays with the `Fast` flag, which doesn't seem right.
For example, in `valid-after 2014-08-17 12:00:00` we have:
```
r k33ac R5oMCf+qgKvU/WE6nmB5/7...I was looking at some consensuses today, and I noticed that there are many `Unmeasured` relays with the `Fast` flag, which doesn't seem right.
For example, in `valid-after 2014-08-17 12:00:00` we have:
```
r k33ac R5oMCf+qgKvU/WE6nmB5/7/Vhlc E3tqtWZ92BE1vbOP4Wg1PKp241c 2014-08-17 02:11:59 50.38.49.173 443 9030
s Fast HSDir Running Stable V2Dir Valid
v Tor 0.2.4.23
w Bandwidth=20 Unmeasured=1
```
This is an investigative trac ticket, since I'm not sure if this behavior is a feature or a bug yet.https://gitlab.torproject.org/legacy/trac/-/issues/13361Using 'undocumented' option accept6 fails2020-06-13T14:39:24ZTracUsing 'undocumented' option accept6 failsI've been working on upgrading my tor-relay to use IPv6
For IPv4 I reject exiting, I'm on a single IP ftth network, exiting from this IP is /bad/ ;)
However since IPv6 is now available in tor exiting on IPv6 would be a good strategy to...I've been working on upgrading my tor-relay to use IPv6
For IPv4 I reject exiting, I'm on a single IP ftth network, exiting from this IP is /bad/ ;)
However since IPv6 is now available in tor exiting on IPv6 would be a good strategy to benefit the network more.
Hence configuration was added:
ORPort [2A02:80C0:FF70:f600::2]:9001
OutboundBindAddress [2a02:80c0:ff70:f600::2]
IPv6Exit 1
ExitPolicy accept6 *:*
ExitPolicy reject *:* # no exits allowed
Adding accept6 does not throw errors, without it atlas shows my node not allowing exiting of IPv6.
However it seems that unfortunately and expectantly accept6 /also/ allows exiting of IPv4
Config-file+build options can be provided if needed, contact me at gijsje+tor [AT] heteigenwijsje [DOT] nl
Running on FreeBSD 10 x64
nodename: heteigenwijsje
**Trac**:
**Username**: gizahhttps://gitlab.torproject.org/legacy/trac/-/issues/13804Implement negative caching for HS descriptor2020-06-13T14:40:28ZDavid Gouletdgoulet@torproject.orgImplement negative caching for HS descriptorA negative cache object will have to expire at some point to be removed from cache else a memory DoS would be trivial here.
I guess for that we will need to have an expiry time of the cache object and how many bad fetch before caching t...A negative cache object will have to expire at some point to be removed from cache else a memory DoS would be trivial here.
I guess for that we will need to have an expiry time of the cache object and how many bad fetch before caching the desc.
We have to be careful also on the rate we accept negative caching to avoid memory exhaustion if let say we get 10k bad desc request in 10 seconds.https://gitlab.torproject.org/legacy/trac/-/issues/13415tor fails LibreSSL compiliation and chutney basic2020-06-13T14:40:34Zteortor fails LibreSSL compiliation and chutney basicI'm having trouble getting LibreSSL to work with tor git on OS X 10.9.
**Configuring**
Here are the issues I've found and fixed in the configure invocation:
* configure --with-openssl-dir= detects the wrong bin/openssl if "$OPENSSL_DIR...I'm having trouble getting LibreSSL to work with tor git on OS X 10.9.
**Configuring**
Here are the issues I've found and fixed in the configure invocation:
* configure --with-openssl-dir= detects the wrong bin/openssl if "$OPENSSL_DIR/bin/openssl" isn't in the path before all other openssl executables.
* configure --enable-static-openssl requires LDFLAGS="$OPENSSL_DIR/lib":$LDFLAGS to link properly, at least on OS X.
I'm pretty sure these issues will affect all (non-system/non-standard) SSLs.
Can we make configuring with non-system SSLs easier by prepending "$OPENSSL_DIR/bin" and "$OPENSSL_DIR/lib" to the PATH and LDFLAGS respectively?
Happy to do the fix, but it may take me some time as I'm not familiar with autoconf scripts.
**Testing with Chutney**
Once I get tor/LibreSSL to compile, the unit tests pass flawlessly.
But I see the following log entries in chutney clients, which I really don't have any idea how to fix (I'm going to try boringssl next):
[notice] We weren't able to find support for all of the TLS ciphersuites that we wanted to advertise. This won't hurt security, but it might make your Tor (if run as a client) more easy for censors to block.
[notice] To correct this, use a version of OpenSSL built with none of its ciphers disabled.
[info] TLS error while handshaking with "127.0.0.1": wrong cipher returned (in SSL routines:SSL3_GET_SERVER_HELLO:SSLv3 read server hello B)
[info] int connection_tls_continue_handshake(or_connection_t *)(): tls error [misc error]. breaking connection.
[info] void circuit_n_chan_done(channel_t *, int)(): Channel failed; closing circ.
[info] void circuit_build_failed(origin_circuit_t *)(): Our circuit died before the first hop with no connection
[info] void connection_ap_fail_onehop(const char *, cpath_build_state_t *)(): Closing one-hop stream to '$<KEY>/127.0.0.1' because the OR conn just failed.
[info] void connection_or_note_state_when_broken(or_connection_t *)(): Connection died in state 'handshaking (TLS) with SSL state SSLv3 read server hello B in HANDSHAKE'
[info] void control_event_bootstrap_problem(const char *, int, or_connection_t *)(): Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 8; recommendation ignore)
[info] 8 connections have failed:
[info] 8 connections died in state handshaking (TLS) with SSL state SSLv3 read server hello B in HANDSHAKE
chutney routers are similar, with these extra lines on init:
[info] int crypto_global_init(int, const char *, const char *)(): NOT using OpenSSL engine support.
[info] int evaluate_evp_for_aes(int)(): This version of OpenSSL has a known-good EVP counter-mode implementation. Using it.
[info] void tor_tls_init()(): OpenSSL LibreSSL 2.0 looks like version 0.9.8m or later; I will try SSL_OP to enable renegotiation
chutney authorities also include these extras:
[info] or_connection_t *connection_or_connect(const tor_addr_t *, uint16_t, const char *, channel_tls_t *)(): Client asked me to connect to myself. Refusing.
[info] void log_unsupported_ciphers(smartlist_t *)(): The unsupported ciphers were: ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-RC4-SHA:ECDHE-RSA-RC4-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:EDH-RSA-DES-CBC3-SHA:AES128-SHA:CAMELLIA128-SHA:AES256-SHA:CAMELLIA256-SHA:DES-CBC3-SHA:RC4-SHA
[info] TLS error while handshaking with "127.0.0.1": sslv3 alert illegal parameter (in SSL routines:SSL3_READ_BYTES:SSLv3 read client certificate A)https://gitlab.torproject.org/legacy/trac/-/issues/14784Implement status/fresh-relay-descs controller command2020-06-13T14:42:34ZSebastian HahnImplement status/fresh-relay-descs controller commandThis command will generate a fresh relay/ei pair and return it to the controller.This command will generate a fresh relay/ei pair and return it to the controller.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/14958address/get_if_addrs_ifaddrs and address/get_if_addrs_ioctl fail in FreeBSD j...2020-06-13T14:43:26ZTracaddress/get_if_addrs_ifaddrs and address/get_if_addrs_ioctl fail in FreeBSD jailsWhen running Tor 2.6.3-alpha tests on FreeBSD 10.1 (inside a jail) I receive two FAILs.
http://pastebin.com/74nXVS7e
Verbose output:
```
$ ./src/test/test --verbose --info address/get_if_addrs_ifaddrs
Feb 19 22:41:59.715 [info] int cr...When running Tor 2.6.3-alpha tests on FreeBSD 10.1 (inside a jail) I receive two FAILs.
http://pastebin.com/74nXVS7e
Verbose output:
```
$ ./src/test/test --verbose --info address/get_if_addrs_ifaddrs
Feb 19 22:41:59.715 [info] int crypto_early_init()(): OpenSSL version matches version from headers (100010af: OpenSSL 1.0.1j-freebsd 15 Oct 2014).
Feb 19 22:41:59.715 [info] int crypto_strongest_rand(uint8_t *, size_t)(): Reading entropy from "/dev/urandom"
Feb 19 22:41:59.715 [info] int crypto_global_init(int, const char *, const char *)(): NOT using OpenSSL engine support.
Feb 19 22:41:59.715 [info] int evaluate_evp_for_aes(int)(): This version of OpenSSL has a known-good EVP counter-mode implementation. Using it.
Feb 19 22:41:59.715 [info] int crypto_strongest_rand(uint8_t *, size_t)(): Reading entropy from "/dev/urandom"
address/get_if_addrs_ifaddrs: [forking]
OK src/test/test_address.c:227: assert(smartlist_len(results) >= 1): 1 vs 1
FAIL src/test/test_address.c:228: assert(smartlist_contains_localhost_tor_addr(results))
[get_if_addrs_ifaddrs FAILED]
1/1 TESTS FAILED. (0 skipped)
```
```
./src/test/test --verbose --info address/get_if_addrs_ioctl
Feb 19 22:44:26.198 [info] int crypto_early_init()(): OpenSSL version matches version from headers (100010af: OpenSSL 1.0.1j-freebsd 15 Oct 2014).
Feb 19 22:44:26.199 [info] int crypto_strongest_rand(uint8_t *, size_t)(): Reading entropy from "/dev/urandom"
Feb 19 22:44:26.199 [info] int crypto_global_init(int, const char *, const char *)(): NOT using OpenSSL engine support.
Feb 19 22:44:26.199 [info] int evaluate_evp_for_aes(int)(): This version of OpenSSL has a known-good EVP counter-mode implementation. Using it.
Feb 19 22:44:26.199 [info] int crypto_strongest_rand(uint8_t *, size_t)(): Reading entropy from "/dev/urandom"
address/get_if_addrs_ioctl: [forking]
OK src/test/test_address.c:440: assert(result)
OK src/test/test_address.c:441: assert(smartlist_len(result) >= 1): 1 vs 1
FAIL src/test/test_address.c:443: assert(smartlist_contains_localhost_tor_addr(result))
[get_if_addrs_ioctl FAILED]
1/1 TESTS FAILED. (0 skipped)
```
**Trac**:
**Username**: reezerrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/15248autoconf: drop workarounds for libevent <1.32020-06-13T14:44:17ZNick Mathewsonautoconf: drop workarounds for libevent <1.3All of our checks for u_int_* in configure.ac are unneeded, since Libevent stopped littering its headers with those in 1.3.
Similarly, there are functions that we're checking for which libevent probably has unconditionally in all the ve...All of our checks for u_int_* in configure.ac are unneeded, since Libevent stopped littering its headers with those in 1.3.
Similarly, there are functions that we're checking for which libevent probably has unconditionally in all the versions we support.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15381cosmetic issue in log message : v0.1.2.3 versus 0.2.3.42020-06-13T14:44:30Ztoralfcosmetic issue in log message : v0.1.2.3 versus 0.2.3.4The following 2 subsequent log messages let me wonder, why there's a "v" in one, but not in the other (or why is there)
```
Mar 19 21:18:25.000 [notice] Tor 0.2.6.5-rc (git-e0b77cd3194d705f) opening log file. ...The following 2 subsequent log messages let me wonder, why there's a "v" in one, but not in the other (or why is there)
```
Mar 19 21:18:25.000 [notice] Tor 0.2.6.5-rc (git-e0b77cd3194d705f) opening log file.
Mar 19 21:18:25.258 [notice] Tor v0.2.6.5-rc (git-e0b77cd3194d705f) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.1l and Zlib 1.2.8.
```Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/15233Form a plan for killing off 0.2.2 and 0.2.32020-06-13T14:45:50ZNick MathewsonForm a plan for killing off 0.2.2 and 0.2.3#9476 is looking tricky; we should make a plan for what to do if it turns out maxmially tricky, and a plan for what to do when we're finally done with 0.2.3 as well.#9476 is looking tricky; we should make a plan for what to do if it turns out maxmially tricky, and a plan for what to do when we're finally done with 0.2.3 as well.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/5460Write proposal(s) to implement improved relay/circuit crypto authentication2020-06-13T14:50:11ZMike PerryWrite proposal(s) to implement improved relay/circuit crypto authenticationWe need to write a proposal to determine the best way to provide authentication to our circuit crypto, so that cells that have been tagged/tampered with/duplicated cause circuit failure at the 2nd hop, not the third.
As I understand it...We need to write a proposal to determine the best way to provide authentication to our circuit crypto, so that cells that have been tagged/tampered with/duplicated cause circuit failure at the 2nd hop, not the third.
As I understand it, there are two competing possibilities:
1. Self-authenticating crypto (BEAR/LION/LIONESS, others?)
2. Per-hop MAC
The main disadvantage of 1 is that it's likely slow and not very many people use it. The disadvantage of 2 is that it requires us to disclose path length count and position to nodes, as well as have MACs that either grow with increased path length, or become less secure with increased path length.
There are probably other issues. I believe the current plan is to produce both options in one or more proposals and compare and contrast them.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/15235Identify the state of IPv6 support in Tor2020-06-13T14:50:13ZNick MathewsonIdentify the state of IPv6 support in TorWhat works for IPv6 today? What doesn't? What's hard to configure?
* Can clients use ipv6 to connect to Tor?
* Can clients resolve Ipv6 addresses with Tor?
* Does automapping to ipv6 addresses work?
* Can we exit to ipv6?
* Can bridge...What works for IPv6 today? What doesn't? What's hard to configure?
* Can clients use ipv6 to connect to Tor?
* Can clients resolve Ipv6 addresses with Tor?
* Does automapping to ipv6 addresses work?
* Can we exit to ipv6?
* Can bridges be IPv6-only? (no, I don't think so)
* Can relays be IPv6 only? (no)
And many more.
We should ideally not only hand-check tehse issues, but write tests for some of them.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/6411Adding hidden services through control socket2020-06-13T15:02:53ZTracAdding hidden services through control socketOkay, first off, I should say: 1) I'm relatively new to Tor and 2) I don't know C that well.
A while back, I thought that it was a bad idea to have the hidden service hostname/privkey being written to the filesystem, unless it's either ...Okay, first off, I should say: 1) I'm relatively new to Tor and 2) I don't know C that well.
A while back, I thought that it was a bad idea to have the hidden service hostname/privkey being written to the filesystem, unless it's either a tmpfs or an encrypted volume. For programs like Torchat (or alike), it would seem better to be able to hide the private key/hostname in an encrypted file (for example) versus in a filesystem.
In the patch, I have added an ADDSERVICE command (after it's authenticated), and its arguments are:
[hostname] [private key] [vport0] [rport0] [vport1] [rport1] ... [vport*] [rport*]
I wasn't sure about which status codes to use, so I just used whatever. The code is rather inefficient, frankly because I'm awful at C and I'm probably causing a memory leak by not freeing some memory.
**Trac**:
**Username**: kevinevansTor: 0.2.7.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/13338Rewrite tor-fw-helper in Go (or another memory-safe language)2020-06-13T15:04:39ZRoger DingledineRewrite tor-fw-helper in Go (or another memory-safe language)Our firewall helper is scary because the code it pulls in is unmaintained garbage that's probably full of security vulnerabilities.
Yawning mentioned the idea of having go versions of these things. That would sure be swell. If they were...Our firewall helper is scary because the code it pulls in is unmaintained garbage that's probably full of security vulnerabilities.
Yawning mentioned the idea of having go versions of these things. That would sure be swell. If they were maintained.
Even if not, it would still be better than not maintaining the C versions.Tor: 0.2.7.x-finalYawning AngelYawning Angelhttps://gitlab.torproject.org/legacy/trac/-/issues/15426Update ciphers.inc to match ciphers from current Firefox2020-06-13T15:05:46ZcypherpunksUpdate ciphers.inc to match ciphers from current FirefoxFirefox changed ciphersuits since we last updated ciphers.inc. We need to re-run get_mozilla_ciphers.py on the most recent stable Firefox and openssl, to generate a new ciphers.inc.
We should fix get_mozilla_ciphers if it needs it; the ...Firefox changed ciphersuits since we last updated ciphers.inc. We need to re-run get_mozilla_ciphers.py on the most recent stable Firefox and openssl, to generate a new ciphers.inc.
We should fix get_mozilla_ciphers if it needs it; the code may have rotted a bit.Tor: 0.3.0.x-finalNick MathewsonNick Mathewson