Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:53:07Zhttps://gitlab.torproject.org/legacy/trac/-/issues/17604Try to use only one canonical connection2020-06-13T15:53:07ZMike PerryTry to use only one canonical connectionFor #16861, I would like to experiment with padding between relays, as well as generally keep relay-to-relay orconns open much longer. This will be beneficial against attacks like Torscan (https://eprint.iacr.org/2012/432.pdf), as well a...For #16861, I would like to experiment with padding between relays, as well as generally keep relay-to-relay orconns open much longer. This will be beneficial against attacks like Torscan (https://eprint.iacr.org/2012/432.pdf), as well as related netflow-based attacks that attempt to determine the guard node of a connection by using netflow data to accomplish the same thing as the Torscan attack.
Unfortunately, the logic for preferring orconns (is_canonical and channel_is_better()) is a mind-bender, but it appears to be the case that we may have situations where multiple orconns can be opened between relays where each side disagrees over which connection is canonical. This can happen because the source port won't match the orport in the descriptor of the remote relay for incoming connections. It will also be the case for nodes that make outgoing connections from different IP address than those in their descriptor.
I asked on #tor-dev, and two relay operators reported cases of such multiple connections to relays.
I think the following changes will improve the situation:
1. Mark all authenticated connections as canonical (everything with link proto v3 and higher will authenticate, yes?)
2. Alter channel_is_better() to prefer older orconns in the case of multiple canonical connections, and use the orconn with more circuits on it in case of age ties.
I think age is more important than number of circuits because we want to avoid giving an attacker the ability to switch an orconn between relays by creating a new one and opening a bunch of circuits on it. channel_is_better() is doing the opposite of this behavior right now, on both fronts.Tor: 0.3.1.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/17857Create a consensus param to disable (netflow) padding if RSOS is enabled2020-06-13T15:10:29ZteorCreate a consensus param to disable (netflow) padding if RSOS is enabledBecause RSOS and Proposal 252 both appear to cause an onion service to make a lot of orconns to many relays, the total overhead of the netflow padding defense will be much larger for these services.
In an ideal world, we'd find some way...Because RSOS and Proposal 252 both appear to cause an onion service to make a lot of orconns to many relays, the total overhead of the netflow padding defense will be much larger for these services.
In an ideal world, we'd find some way to minimize the number of orconns that these services make, because the increased level of connection multiplexing would be better against traffic analysis attacks, and thus also mean less overhead for padding defenses (including netflow padding, but beyond that as well).
In the meantime, however, we should provide the ability to disable netflow padding via the consensus for these services. With a consensus param, we can monitor the netflow padding overhead in relay extra-info descriptors, and experiment with turning padding for RSOS/SOS on and off while observing the change in total overhead at relays.Tor: 0.3.1.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/17868base64_decode_nopad() destination buffer length problem2020-06-13T14:59:07ZDavid Gouletdgoulet@torproject.orgbase64_decode_nopad() destination buffer length problemTL;DR; the `base64_decode_nopad()` doesn't work.
Here is a concrete example. We have `40 bytes` of binary data that we want to encode. With padding, that is using `base64_encode()` we end up with a size of `56 bytes`. Those resulting by...TL;DR; the `base64_decode_nopad()` doesn't work.
Here is a concrete example. We have `40 bytes` of binary data that we want to encode. With padding, that is using `base64_encode()` we end up with a size of `56 bytes`. Those resulting bytes, when passed to `base64_decode()`, the check on the destination buffer done in that function makes it that we need `42 bytes` and not the original `40 bytes`. This is due because of the padding.
One solution, instead of explicitly adding 2 bytes like it's been done in many places in the code, it is to use the `_nopad()` interface. However, the `base64_decode_nopad()` simply adds some `=` at the end with a new source buffer and passes along the base64_decode() function. However the `dstlen` that is the destination buffer length where the decoded data will go is not updated to reflect the new length of the source buffer so the call fails because of the `dstlen` check in the decode function.
Passing 40 bytes for `dstlen` and 54 for `srclen` (which is the expected value _without_ padding), the nopad() call changes `srclen` to 56 bytes but then `dstlen` should be 42 bytes else the call fails.
I'm not sure how to fix that properly apart from making `_nopad()` call allocating a new source buffer if needed. I would much prefer that than the caller adding bytes beforehand making the code cryptic and honestly unsafe to any future length changes.
Thoughts?Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18054prop224: Decide how to proceed with torrc options2020-06-13T14:53:26ZDavid Gouletdgoulet@torproject.orgprop224: Decide how to proceed with torrc optionsWith next-gen HS, we'll have both new and legacy system running in parallel. However, we should encourage as much as possible the adoption of the new system when setting up a new hidden service.
From a torrc perspective, we should proba...With next-gen HS, we'll have both new and legacy system running in parallel. However, we should encourage as much as possible the adoption of the new system when setting up a new hidden service.
From a torrc perspective, we should probably use the same options as we have now but making tor code a bit more smarter when parsing them. One idea would be to add an option that indicates if the user wants the legacy protocol or not:
Something that could look like:
```
HiddenServiceLegacy 1
HiddenServiceDir <PATH>
HiddenServicePort ...
```
And `HiddenServiceLegacy` by default would be 0. This option should be deprecated over time.
Another possibility is NOT having this config option and only if "private_key" file exists in the `HiddenServiceDir` and it's `RSA1024`, we switch to legacy. Without it, we go next-gen. So in other words, we DO NOT let a user setup a legacy HS unless she has a key for it placed in the HS directory. This will allow current HS setup to still work after upgrade and not make operators add an extra option.
Basically, the key type would be our heuristic to switch from legacy to next-gen.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18329Let bridges indicate when they don't want BridgeDB to distribute their address2020-06-13T18:28:59ZKarsten LoesingLet bridges indicate when they don't want BridgeDB to distribute their addressRight now, bridges can decide whether they want to be a public bridge that gets distributed via BridgeDB or a private bridge that only gets used by clients who learn its address via some other, private channel. The default is that a bri...Right now, bridges can decide whether they want to be a public bridge that gets distributed via BridgeDB or a private bridge that only gets used by clients who learn its address via some other, private channel. The default is that a bridge is a public bridges, unless it sets `PublishServerDescriptor 0` in its `torrc` file. This works fine with respect to BridgeDB not distributing private bridges. But a lesser known problem is that a bridge that doesn't publish its descriptor also does not contribute to bridge usage statistics on Metrics that are based on bridge extra-info descriptors.
The major use case that comes to mind is a bundled bridge whose address is shipped together with Tor Browser or another application. In the past we tried to remind operators of these bridges to also publish descriptors, so that their statistics are included on Metrics. But it turns out that some censors, who carefully scrape bridge addresses from BridgeDB, do not extract bridge addresses from the various bundles. Still, bundled bridges see a large number of bridge users and we should really include them in the statistics.
Another use case could be private bridges that somebody sets up for themselves and their friends. Maybe these operators would be fine contributing to the statistics if that doesn't automatically mean they need to share their bridge with other users.
I think this feature is relatively easy to build. We would need:
- a new descriptor line "bridgedb off", or something even more intuitive and extensible, that tells BridgeDB that this bridge's address should not be distributed,
- a new torrc option or extension of an existing option, maybe "PublishServerDescriptor bridge-auth" or, again, something more intuitive, to include the line above in the descriptor, and
- an extension of BridgeDB to ignore bridges with this line when parsing descriptors.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/18859A new SOCKS connection should use a pre-built circuit for its first stream2020-06-13T15:20:49ZArthur EdelsteinA new SOCKS connection should use a pre-built circuit for its first streamSince #3455, we use SOCKS auth isolation in Tor Browser to separate URL bar domains to different tor circuits. When the user browses to a new URL bar domain, a new SOCKS connection is opened with a SOCKS username/password unique to the s...Since #3455, we use SOCKS auth isolation in Tor Browser to separate URL bar domains to different tor circuits. When the user browses to a new URL bar domain, a new SOCKS connection is opened with a SOCKS username/password unique to the site's domain.
By telneting to the tor control port, I observed that immediately after I entered a new URL bar domain in a Tor Browser tab, a new circuit was built and assigned the SOCK_USERNAME and SOCKS_PASSWORD for that URL bar domain.
It seems there would be better performance if we could use an existing, pre-built (yet-unused) circuit when a new SOCKS connection opens, and assign the SOCKS_USERNAME and SOCKS_PASSWORD to the pre-built circuit. That way the user wouldn't have to wait for a circuit to be established after requesting a new website.
I don't know yet whether this is something that can be adjusted by config settings or if we would need to patch tor somehow.Tor: 0.3.1.x-finalArthur EdelsteinArthur Edelsteinhttps://gitlab.torproject.org/legacy/trac/-/issues/19418i2d_RSAPublicKey retval ignored in multiple callsites2020-06-13T14:58:40ZGeorge Kadianakisi2d_RSAPublicKey retval ignored in multiple callsitesHello. Here follows a bug report by `Guido Vranken` received through the hackerone program.
There are various places in the codebase where we don't check the retval of `i2d_RSA_PublicKey()` (or its callers). That function can fail in ca...Hello. Here follows a bug report by `Guido Vranken` received through the hackerone program.
There are various places in the codebase where we don't check the retval of `i2d_RSA_PublicKey()` (or its callers). That function can fail in cases of OOM, and this is something we should be handling correctly. This is a similar case to #17686.Tor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/19564SR: use macros to compute our base64 encoded length2020-06-13T14:59:16ZDavid Gouletdgoulet@torproject.orgSR: use macros to compute our base64 encoded lengthTicket #19531 once done should be adding some macros to compute the length of encoded base64 string.
Let's use them for these in `shared_random.h`:
- `SR_COMMIT_BASE64_LEN`
- `SR_REVEAL_BASE64_LEN`
- `SR_SRV_VALUE_BASE64_LEN`Ticket #19531 once done should be adding some macros to compute the length of encoded base64 string.
Let's use them for these in `shared_random.h`:
- `SR_COMMIT_BASE64_LEN`
- `SR_REVEAL_BASE64_LEN`
- `SR_SRV_VALUE_BASE64_LEN`Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19824/var/run/tor/control socket not created because of /var/run/tor permission issue2020-06-13T14:59:54Zadrelanos/var/run/tor/control socket not created because of /var/run/tor permission issueUsing Tor `0.2.8.6` from deb.torproject.org, `/var/run/tor/control` is no longer created because of a permission issue. As a manual workaround, `sudo chmod --recursive 700 /var/run/tor` works.
The symptom in Tor's log is the following:
...Using Tor `0.2.8.6` from deb.torproject.org, `/var/run/tor/control` is no longer created because of a permission issue. As a manual workaround, `sudo chmod --recursive 700 /var/run/tor` works.
The symptom in Tor's log is the following:
```
Aug 03 17:36:33.000 [warn] Permissions on directory /var/run/tor are too permissive.
```
Rather than `755` Tor's `/lib/systemd/system/tor@default.service` should use `700`. I.e. rather than using:
```
ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d /var/run/tor
```
`/lib/systemd/system/tor@default.service` should use:
```
ExecStartPre=/usr/bin/install -Z -m 02700 -o debian-tor -g debian-tor -d /var/run/tor
```Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19966torproxy goes south with more than 1 connection attempt per second to a hidde...2020-06-13T15:00:28ZTractorproxy goes south with more than 1 connection attempt per second to a hidden serviceI have a web service running as a tor hidden service. I have a test script that connects to the hidden service through tor proxy, sends a short string, gets a short reply, and then the hidden service closes the connection. Each time th...I have a web service running as a tor hidden service. I have a test script that connects to the hidden service through tor proxy, sends a short string, gets a short reply, and then the hidden service closes the connection. Each time the test script connects, it uses a different socks username, so it should get a fresh tor circuit each time.
This works mostly ok with Tor v0.2.7.6 (git-7a489a6389110120) running on Windows 7 with Libevent 2.0.22-stable, OpenSSL 1.0.1t and Zlib 1.2.8. With four test scripts, it makes about 1 connection per second. Obviously, with any network, it is going to get some connection and network errors, but it recovers eventually.
With Tor v0.2.8.6 (git-4d217548e3f05569) running on Windows 7 with Libevent 2.0.22-stable, OpenSSL 1.0.1t and Zlib 1.2.8, it doesn't run so well. Up to about one connection every two seconds, it runs ok, but as soon as I go above that, tor proxy goes south and starts refusing all connections and the logging error messages shown below. This behavior makes is unsuitable/unreliable to use in a "production" environment.
It seems to not matter what version of tor I use on the hidden service side--only the version on the client side seems to matter, and that is where the errors messages are seen.
This is the contents of my torrc file, which works under v0.2.7.6 but not under v0.2.8.6.
Log notice stdout
LogMessageDomains 1
SafeLogging 0
MaxClientCircuitsPending 200
KeepalivePeriod 15
SocksTimeout 60
NewCircuitPeriod 1
LearnCircuitBuildTimeout 1
CircuitBuildTimeout 60
NumEntryGuards 20
The error messages are:
Aug 23 18:30:32.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:32.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:34.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:34.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:35.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:35.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:35.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:35.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:36.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:36.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:36.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:36.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:36.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:36.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:37.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:37.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:37.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:37.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:37.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:37.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:37.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:37.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:38.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:38.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:39.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:39.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:39.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:39.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:39.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:40.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:40.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:40.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:40.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:40.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:40.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:40.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:40.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:41.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:41.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:41.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:41.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:41.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:41.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:41.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:41.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:41.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:41.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:41.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:41.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:41.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:41.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:41.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:41.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:42.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:42.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:42.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:42.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:42.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:42.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:42.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:42.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:42.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:42.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:42.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:42.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:43.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:43.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:43.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:43.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:43.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:43.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:43.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:43.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:43.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:43.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:43.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:43.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:43.000 [warn] {REND} Fetching v2 rendezvous descriptor failed. Retrying at another directory.
Aug 23 18:30:43.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:43.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
Aug 23 18:30:43.000 [notice] {REND} Closing stream for 'vgfdgkr7tudleiq3.onion': hidden service is unavailable (try again later).
**Trac**:
**Username**: AlanTor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20267Use -DOPENSSL_SYS_WIN32 on Windows2020-06-13T15:01:50ZteorUse -DOPENSSL_SYS_WIN32 on WindowsTor fails to compile on Windows MinGW/msys with an error about X509_NAME being an integer literal.
This is because OPENSSL_SYS_WIN32 is not defined, but it should be.
When we are on Win32, we should define this preprocessor directive.Tor fails to compile on Windows MinGW/msys with an error about X509_NAME being an integer literal.
This is because OPENSSL_SYS_WIN32 is not defined, but it should be.
When we are on Win32, we should define this preprocessor directive.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20341torrc man page missing components for Bridge line2020-06-13T15:02:01ZTractorrc man page missing components for Bridge lineThe man page for torrc Bridge currently has an entry:
Bridge [transport] IP:ORPort [fingerprint]
an example line i was just given had a bit more than this:
Bridge [transport] IP:ORPort [fp] [cert=...] ] iat-mode=0
perhaps a descripti...The man page for torrc Bridge currently has an entry:
Bridge [transport] IP:ORPort [fingerprint]
an example line i was just given had a bit more than this:
Bridge [transport] IP:ORPort [fp] [cert=...] ] iat-mode=0
perhaps a description of iat-mode and its values would be helpful? and extend the config line?
**Trac**:
**Username**: stefanibTor: 0.3.1.x-finalTaylor YuTaylor Yuhttps://gitlab.torproject.org/legacy/trac/-/issues/20458Integration tests should be run locally before committing code changes2020-06-13T15:02:19ZChelsea KomloIntegration tests should be run locally before committing code changesCurrently, it is easy to submit a patch for code changes without first running integration tests locally.
Two changes could help with this:
1. Adding this information to documentation for contributors
2. Adding a make task that runs all...Currently, it is easy to submit a patch for code changes without first running integration tests locally.
Two changes could help with this:
1. Adding this information to documentation for contributors
2. Adding a make task that runs all necessary tasks before contributing new code, which are:
`make check-spaces`
`make check`
`make test-network-all`
We should investigate how to handle:
- Someone not having have chutney
- Someone not having the necessary network connection for integration tests to succeed
- If chutney tests fail because of flakiness (race conditions for example) rather than legitimate failures.Tor: 0.3.1.x-finalChelsea KomloChelsea Komlohttps://gitlab.torproject.org/legacy/trac/-/issues/20509Directory authorities should reject relays with #20499 bug2020-07-31T12:44:02ZRoger DingledineDirectory authorities should reject relays with #20499 bugOnce we resolve #20499, or more precisely, once we figure out which versions it affects, we should teach the directory authorities to withhold the Guard flag from relays that are running those versions.
Right now you can't bootstrap fro...Once we resolve #20499, or more precisely, once we figure out which versions it affects, we should teach the directory authorities to withhold the Guard flag from relays that are running those versions.
Right now you can't bootstrap from e.g. sofia, which is a huge guard running 0.2.9.3-alpha.
Then later -- or maybe this will turn out to be the easiest solution for everything -- we can teach the directory authorities to simply reject descriptors from relays running these buggy versions.
[I'm not sure which milestone to put this in, since it will need to get into a majority of directory authorities for it to matter. :/ ]Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20571When we are really satisfied that it is right, tell protover.c about prop224 ...2020-06-13T15:02:57ZNick MathewsonWhen we are really satisfied that it is right, tell protover.c about prop224 HSDir supportThis will be trivial to do, but nontrivial to know when we should do it.
prop224-supporting hidden services and relays will need to know which Tor relays they should use to upload and download the new kind of descriptors. So, they shoul...This will be trivial to do, but nontrivial to know when we should do it.
prop224-supporting hidden services and relays will need to know which Tor relays they should use to upload and download the new kind of descriptors. So, they should use the preferred mechanism for it.
As of proposal 264, that's protocol subversions.
We should only advertise support for this server-side once we're pretty sure we aren't changing the server side any more.Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/20908Display the fingerprint when downloading consensuses from fallbacks2020-06-13T15:04:06ZteorDisplay the fingerprint when downloading consensuses from fallbacksJust using this for the bug number, will be fixed in #18828.Just using this for the bug number, will be fixed in #18828.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/20913Increase fallback stability, flag percentage, and bandwidth2020-06-13T16:05:54ZteorIncrease fallback stability, flag percentage, and bandwidthIn #18828, I had to decrease the fallback criteria to get ~160 fallbacks.
It would be great to increase these to:
* Stability: 3 months+ (from 7 days)
* Flags: 95%+ (from 90%)
* Bandwidth: 2MBytes/s+ (from 1MByte/s)In #18828, I had to decrease the fallback criteria to get ~160 fallbacks.
It would be great to increase these to:
* Stability: 3 months+ (from 7 days)
* Flags: 95%+ (from 90%)
* Bandwidth: 2MBytes/s+ (from 1MByte/s)Tor: 0.3.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/20988Test fgets_eagain fails on FreeBSD-amd642020-06-13T15:13:26ZcypherpunksTest fgets_eagain fails on FreeBSD-amd64According to the [BSD Buildbot](https://buildbot.pixelminers.net/builders)
```
util/fgets_eagain:
FAIL src/test/test_util.c:3952: assert(retptr OP_EQ buf): 0x0 vs 0x7fffffffe944
[fgets_eagain FAILED]
```
This means that fgets retur...According to the [BSD Buildbot](https://buildbot.pixelminers.net/builders)
```
util/fgets_eagain:
FAIL src/test/test_util.c:3952: assert(retptr OP_EQ buf): 0x0 vs 0x7fffffffe944
[fgets_eagain FAILED]
```
This means that fgets returns a null pointer on partial lines instead of the buffer as expected.
Previously this test was passing but started failing with [build #105](https://buildbot.pixelminers.net/builders/FreeBSD-amd64/builds/105). Looking at the changes to libc it looks like this is caused by [revision 305413](https://svnweb.freebsd.org/base/head/lib/libc/stdio/fgets.c?r1=305413&r2=305412&pathrev=305413) (which was added earlier in the same month the test started failing).
I'm unsure whether FreeBSD is right and other libc implementations are wrong or the other way around.Tor: 0.3.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/21008hs: Remove the introduction point private key material from hs_descriptor.h2020-06-13T15:04:36ZDavid Gouletdgoulet@torproject.orghs: Remove the introduction point private key material from hs_descriptor.hWe need to change the `curve25519_keypair_t` from `hs_desc_intro_point_t` to a public key only because both client and service will use that field.We need to change the `curve25519_keypair_t` from `hs_desc_intro_point_t` to a public key only because both client and service will use that field.Tor: 0.3.1.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21028tor never checks TLS certificate lifetimes2020-06-13T15:04:42Zteortor never checks TLS certificate lifetimesWe have tor_tls_check_lifetime(), why don't we use it?
This could be an issue if a relay never rotates its certificate, or its certificate is out of date because its clock is wrong.We have tor_tls_check_lifetime(), why don't we use it?
This could be an issue if a relay never rotates its certificate, or its certificate is out of date because its clock is wrong.Tor: 0.3.1.x-final