mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.0.1 2021-10-27T15:13:46Z 2021-10-27T15:13:46Z Nick Mathewson nickm@torproject.org 2021-10-27T15:13:46Z urn:sha1:134c04a67adebff719011b608dabfa6da60ed247 2021-10-26T16:03:23Z Nick Mathewson nickm@torproject.org 2021-10-25T15:06:54Z urn:sha1:8c69b5d389a71e19054f13b973ea9d0e74f28ca9 We now track, for every guard: the total number of successful circuits we've built through it, along with the total number of "indeterminate" circuits. Recall that a circuit's status is "indeterminate" if it has failed for a reason that _might_ be the guard's fault, or might not be the guard's fault. For example, if extending to the second hop of the circuit fails, we have no way to know whether the guard deliberately refused to connect there, or whether the second hop is just offline. But we don't want to forgive all indeterminate circuit failures: if we did, then a malicious guard could simply reject any second hops that it didn't like, thereby filtering the client into a chosen set of circuits. As a stopgap solution, this patch now makes guards become permanently disabled if the fraction of their circuit failures becomes too high. See also general-purpose path bias selection (arti#65), and Mike's idea for changing the guard reachability definition (torspec#67). This patch doesn't do either of those. Closes #185. 2021-10-21T17:34:38Z Nick Mathewson nickm@torproject.org 2021-10-21T17:34:38Z urn:sha1:f3dc66d9646ae016dfad8808145d2d3249078d15 2021-10-21T17:31:38Z Nick Mathewson nickm@torproject.org 2021-10-21T17:31:38Z urn:sha1:8a99833777b81cb3cad7ea677510f9c886967401 2021-10-20T17:13:15Z Nick Mathewson nickm@torproject.org 2021-10-20T17:13:15Z urn:sha1:c8cfbda3394b6541deb09e9116cb495587f1318f 2021-10-20T13:37:53Z Nick Mathewson nickm@torproject.org 2021-10-20T13:37:53Z urn:sha1:7b6ed9dab6a673b9b563fa3818806cec4b208240 It's useful to know now only if we now have the lock, but also if we just got it for the first time. 2021-10-19T20:21:12Z Nick Mathewson nickm@torproject.org 2021-10-19T20:21:12Z urn:sha1:445ec6d22053d3f76534844b6c02aefa1fbaedd7 (One represents code that I forgot to write.) 2021-10-19T15:26:22Z Nick Mathewson nickm@torproject.org 2021-10-19T15:26:22Z urn:sha1:89d1fb1767579b2a7cb8b2e15036847c8de5d4f4 We can use this in the case where we don't get the lock on the state file, because another process is running. 2021-10-13T15:24:37Z Nick Mathewson nickm@torproject.org 2021-10-13T15:24:37Z urn:sha1:f15cde80de0b5f6f81a7426addba35c3c7506112 The previous code would report all failures to build a circuit as failures of the guard. But of course that's not right: If we fail to extend to the second or third hop, that might or might not be the guard's fault. Now we use the "pending status" feature of the GuardMonitor type so that an early failure is attributed to the guard, but a later failure is attributed as "Indeterminate". Only a complete circuit is called a success. We use a new "GuardStatusHandle" type here so that we can report the status early if there is a timeout. 2021-10-13T14:55:44Z Nick Mathewson nickm@torproject.org 2021-10-13T14:55:44Z urn:sha1:e625b2cff5f3f1c04ecaa026c46c0ea82e824b1a