TROVE-2024-005: hspool::Pool doesn't read the vanguard mode from the config

The vanguards.mode from the config is only read by VanguardMgr. The hspool::Pool always runs in VanguardMode::Lite mode. Its VanguardMode is only read from the config if reconfigure() is called (so in other words, only if the configured vanguards.mode is updated while arti is running and application.watch_configuration is true).

This happens because the Pool is initialized with Pool::default(), which sets the inner VanguardMode stored in Pool to VanguardMode::default().

This is very bad, and leads to a split brain situation

• the HsPathBuilder reads the (accurate) VanguardMode from the VanguardMgr. This is the VanguardMode configured by the user.
• HsCircPool, on the other hand, reads the VanguardMode from its Pool, which is always VanguardMode::Lite (unless the user sets watch_configuration = true and reloads the config while arti is running). As a result, if vanguards are disabled, it fails to apply the same-family and same-subnet restrictions we usually apply when selecting stubs for non-vanguards circuits, which can lead to de-anonymization. It will also unnecessarily extend client HsDir, client intro, and svc rend circuits by one hop. Confusingly, when vanguards.mode = "disabled" in the config, these circuits will be built using pick_path, not pick_path_with_vanguards, which means we do apply the same-family and same-subnet restrictions within the circuit stub, but not when matching the stub with a circuit target.

The fact that we store the VanguardMode in two separate places (in VanguardMgr and in Pool) is a code smell. Ideally the loaded configuration should be centralized and shared between the two (which would prevent split-brain situations like this one)

---

Impact: if vanguards are disabled

• client HsDir, client intro, and svc rend circuits are incorrectly extended by an extra hop
• we do not apply same-family and same-subnet restrictions when matching circuit stubs with the circuit target (so the stub can, for example, contain relays from the same family as the circuit target)

In my opinion this falls into the "Any bug that can remotely cause clients to de-anonymize themselves." category, which according to our security policy, should be considered a high-severity issue.