mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.0.4 2022-01-11T17:52:00Z 2022-01-11T17:52:00Z Nick Mathewson nickm@torproject.org 2022-01-11T17:52:00Z urn:sha1:08d3ed978f8fae1e75647f17d409e9e92d46ab6e guardmgr: Use a better persistent data format Closes #176 See merge request tpo/core/arti!233 2022-01-11T17:00:09Z Nick Mathewson nickm@torproject.org 2022-01-10T18:04:31Z urn:sha1:b89ce48490bf643a0e62b26b7575bbe58fbb9df3 2022-01-11T17:00:09Z Nick Mathewson nickm@torproject.org 2022-01-10T16:04:27Z urn:sha1:70a2e2e751f92052dc29e609b8807cbe7f8be448 Previously we stored only one guard sample, in a state file called "default_guards". That's not future-proof, since we want to have multiple samples in the future. (`guard-spec.txt` specifies separate samples for highly restrictive filters, and for bridge usage.) This patch changes our behavior so that we can store multiple samples in a new "guards" file. I had thought about automatically migrating from the previous file format and location, but I don't think that's necessary given our current (lack of) stability guarantees. Closes #176. 2022-01-11T16:35:16Z Nick Mathewson nickm@torproject.org 2022-01-10T20:54:23Z urn:sha1:f89b0bc752bb45211e265404dd1dbe3ecf568be9 This test should only fail very rarely (around 1/2.4e8) when guards are chosen from a list of 20 with uniform probability. But that wasn't what we were doing on the mock test network: we were choosing from a list of 10 viable guards, with nonuniform probability. As a fix, we change the test network probabilities so that the guards _are_ chosen with a uniform probability for this test, and we use a modified version of the test network where there are indeed 20 Guard-flagged relays with the required DirCache=2 protocol. Closes #276. 2022-01-06T20:58:36Z Nick Mathewson nickm@torproject.org 2022-01-06T20:11:38Z urn:sha1:723894b9eaa271e82006316f237e8978663a451f 2022-01-06T20:58:23Z Nick Mathewson nickm@torproject.org 2022-01-06T15:23:42Z urn:sha1:5ac0fcb7ef603e0d145a619ee148ce1262aa31f8 We need this information to know if it's okay to migrate to a new NetDir, or if we need to download more information first. Part of #178. 2022-01-06T14:52:21Z Nick Mathewson nickm@torproject.org 2022-01-06T14:52:21Z urn:sha1:db65fdd04e299f168ebf497a8c6e2cc5db19712e If we don't know a current microdescriptor for a guard, we can't use it for multihop circuits, since we don't know its onion keys. This is part of a fix for #178. 2021-12-28T20:15:40Z Daniel Eades danieleades@hotmail.com 2021-12-28T20:15:40Z urn:sha1:592642a9e6c1c03e525f8b452f4b97e6fd17ff9b 2021-12-14T18:33:47Z Neel Chauhan neel@neelc.org 2021-12-14T18:33:47Z urn:sha1:ee16c690756df8cc4c3717d10c57b34888158623 2021-12-07T17:00:40Z eta tor@eta.st 2021-12-02T11:44:29Z urn:sha1:b14c5f370eef0a4fc1d2504ce54de1a921472567 `tor-rtcompat`'s `TlsConnector` trait previously included a method to create a TLS-over-TCP connection, which implied creating a TCP stream inside that method. This commit changes that, and makes the function wrap a TCP stream, as returned from the runtime's `TcpProvider` trait implementation, instead. This means you can actually override `TcpProvider` and have it apply to *all* connections Arti makes, which is useful for issues like arti#235 and other cases where you want to have a custom TCP stream implementation. This required updating the mock TCP/TLS types in `tor-rtmock` slightly; due to the change in API, we now store whether a `LocalStream` should actually be a TLS stream inside the stream itself, and check this property on reads/writes in order to detect misuse. The fake TLS wrapper checks this property and removes it in order to "wrap" the stream, making reads and writes work again.