mirrors/arti.git/crates/tor-guardmgr, branch arti-v0.0.1

Bump all crate versions to 0.0.1

2021-10-29T15:05:51Z

Improve some documentation links

2021-10-29T12:39:04Z

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).

Update our disclaimers and limitations sections.

2021-10-27T15:13:46Z

Add Futureproof wrapper type, use for GuardDisabled enum

2021-10-27T14:10:44Z

The Futureproof type lets you serialize and deserialize types whose representations might change (most useful for enums that might grow additional variants). It uses #[serde(untagged)] to accomplish this. This gets used in order to make the `disabled` field of `Guard` more robust against future guard disablement reasons being added. A test was also added to verify correct behaviour of the new type.

Add #[serde(flatten)] HashMap fields to serializable objects

2021-10-27T12:31:52Z

As per arti#175, we'd like to be able to handle newer Arti versions storing additional state in the persisted state files, without dropping this data on the floor when we write out changes to these files. Use the #[serde(flatten)] mechanism to achieve this, by adding catch-all HashMap fields to all structs that are at risk of this happening to them.

Avoid a strange borrow syntax in tor_guardmgr::sample

2021-10-26T16:03:23Z

I'm not sure what I was thinking here.

Do not blame a guard for failures on non-random circuits.

2021-10-26T16:03:23Z

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.

Implement a "lightweight" form of pathbias detection.

2021-10-26T16:03:23Z

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.

guardmgr: Don't use guards that are marked as unlisted.

2021-10-25T14:27:13Z

Closes #202.

Merge branch 'share_state'

2021-10-21T17:34:38Z