mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.0.1 2021-10-29T12:39:04Z 2021-10-29T12:39:04Z Nick Mathewson nickm@torproject.org 2021-10-29T12:39:04Z urn:sha1:1ee24ce6537373448d8fd5fb074768c6887cb90b Instead of putting a fully qualified name in the text, in most cases we should just use the short name of the type or function we're referring to. In other words, instead of saying [`crate::module::Foo`], we should typically say [`Foo`](crate::module::Foo). 2021-10-26T16:03:23Z Nick Mathewson nickm@torproject.org 2021-10-25T15:45:37Z urn:sha1:72ebaed16bc5c4e79c29fe135b62b28f945bdcd0 We must not apply our new path-bias behavior (where we blame a guard if it gives us too many indeterminate circuit failures) if the path was not chosen at random. If too many random paths fail, we know that's suspicious, since the other relays are a random sample. But if a bunch of user-provided paths fail, that could simply be because the user's chosen exit is down. 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-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 2021-10-07T18:03:21Z Nick Mathewson nickm@torproject.org 2021-10-07T18:03:21Z urn:sha1:0ff56a3138beb966da148235cb7af35786216a37 By the time I merge this, most of the comments should have tickets to go with them. 2021-10-07T16:09:29Z Nick Mathewson nickm@torproject.org 2021-10-06T21:19:32Z urn:sha1:00acc5c5b80ed000f14376734f41afb819bd27c4 Also, refactor our message handling to be more like the tor_proto reactors. The previous code had a bug where, once the stream of events was exhausted, we wouldn't actually get any more notifications. 2021-10-07T14:45:42Z Nick Mathewson nickm@torproject.org 2021-09-10T15:18:24Z urn:sha1:0779923d6474bb72427d19b2e504b3fd370b78a2 There are some missing parts here (like persistence and tests) and some incorrect parts (I am 90% sure that the "exploratory circuit" flag is bogus). Also it is not integrated with the circuit manager code.