Save retrieved bridge information in our state file
Currently, Tor clients don't remember anything about bridges after a restart. So for example, if there was a torrc Bridge line without a fingerprint specified, and Tor retrieves the fingerprint from the descriptor, it won't save it on the disk.
Or, if a bridge changed IP:PORT, but we managed to get its new ip:port using the bridge authority (see legacy/trac#12599 (moved)), we will not save this down either.
Fortunately, Sebastian wrote proposal192 about this issue: https://gitweb.torproject.org/torspec.git/tree/proposals/192-store-bridge-information.txt
We should re-read the proposal, revise it as needed and implement it.
Activity
changed milestone to %Tor: unspecified in legacy/trac
added 034-removed-20180328 in Legacy / Trac 034-triage-20180328 in Legacy / Trac AffectsTails in Legacy / Trac component::core tor/tor in Legacy / Trac milestone::Tor: unspecified in Legacy / Trac points::4.5 in Legacy / Trac priority::high in Legacy / Trac severity::normal in Legacy / Trac sponsor::M in Legacy / Trac status::new in Legacy / Trac tor-pt in Legacy / Trac type::task in Legacy / Trac labels
FWIW, Tails wants this because, if they start saving the state file in persistent storage, then it would make it easier for Tails users to use bridges since they wouldn't need to type in the bridge line each time at boot. I'd like to prioritise getting this one done so that we can help them out with that.
Trac:
Priority: normal to major
Tails clients who use Macs want this, but many of them still would have to type bridge lines manually in the "Tails Greeter | Network Configuration" panel. Tails > Application > Configure Persistence is available only if Tails starts from USB disk. This Tails persistence option is unavailable if Tails starts from DVD disk. Tails clients have been filing reports and making complaints for a long time about a persistent bug that prevents Tails starting from USB disk in iMacs and Macs.
This bug appears to be a widespread problem that affects a large number of Tails clients who use iMacs and Macs. Maybe Tails needs some help with this.
www.reddit.com [https://www.reddit.com/r/tails/comments/4gi6uj/tails_error_failed_failed_to_show_plymouth_boot/]
www.reddit.com [https://www.reddit.com/r/tails/comments/4gjzu5/upgrade_tails_to_23_and_my_usb_wont_restart_again/ ]
Trac:
Username: in spatium
Severity: N/A to Normal
Reviewer: N/A to N/A
The link to the proposal in the description of the ticket was pointing to something weird so I changed it. I hope I didn't mess up.
I don't have time to dive into the proposal right now but, at first sight, the related efforts in Tails are:
- Persistent Tor state, because right now no state is stored: https://tails.boum.org/blueprint/persistent_Tor_state/.
- Persistent Tor configuration, because we likely don't want to always reuse the same bridges across different Wi-Fi networks for example: https://tails.boum.org/blueprint/network_connection/.
Trac:
Description: Currently, Tor clients don't remember anything about bridges after a restart. So for example, if there was a torrc Bridge line without a fingerprint specified, and Tor retrieves the fingerprint from the descriptor, it won't save it on the disk.Or, if a bridge changed IP:PORT, but we managed to get its new ip:port using the bridge authority (see legacy/trac#12599 (moved)), we will not save this down either.
Fortunately, Sebastian wrote proposal192 about this issue: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/192-store-bridge-information.txt
We should re-read the proposal, revise it as needed and implement it.
to
Currently, Tor clients don't remember anything about bridges after a restart. So for example, if there was a torrc Bridge line without a fingerprint specified, and Tor retrieves the fingerprint from the descriptor, it won't save it on the disk.
Or, if a bridge changed IP:PORT, but we managed to get its new ip:port using the bridge authority (see legacy/trac#12599 (moved)), we will not save this down either.
Fortunately, Sebastian wrote proposal192 about this issue: https://gitweb.torproject.org/torspec.git/tree/proposals/192-store-bridge-information.txt
We should re-read the proposal, revise it as needed and implement it.
moved from legacy/trac#12600 (moved)
added Task label and removed 1 deleted label
added Pluggable Transports label and removed 1 deleted label
@tpo/anti-censorship We do this now, right? Can we close this ticket?
Yeah, this ticket never got done. I don't know why we closed it.
The idea of the ticket was to learn bridge information and remember it in our state file, so for example if our bridge changes location (compared to the originally configured address in torrc), we can continue to use it at the new address even across restart.
This design is needed for the original bridge plan, where clients would start out with a few bridges, but be able to learn their new locations (if they moved) by querying the bridge authority.
I guess we could close it as wont-fix, on the theory that we never finished building the original bridge design and maybe we never will. Was that the choice?
