Replicate Vidalia's ability to close arbitrary circuits
The main goal is to enable users to debug potentially buggy or malicious exit nodes. For example, you get an unexpected HTTPS or SSH warning, write down the info about your exit node, and close that circuit to get a fresh one and confirm your suspicions.
- For HTTPS, one can already use Torbutton's New Identity feature to achieve the same result. IIRC the upcoming Torbutton's per-tab circuits viewer will have a "New circuit for this tab" feature, that will make it even better.
- For other kinds of connections (ssh, imaps, pop3s, etc.) then there are two ways:
- either using arm to trigger a New Identity, which is not that crazy: close the software that initiated the connection, open a root terminal (which may be a blocker in itself), run "arm", type "m", "down arrow" then "enter"
- or restarting Tor, e.g. by disconnecting and reconnecting from the network using the NM applet
Also, it would be good if arm directly allowed to close one arbitrary circuit: https://trac.torproject.org/projects/tor/ticket/14979.
#11 Updated by intrigeri almost 4 years ago
- Assignee set to sajolida
- QA Check set to Info Needed
FTR, I've now accepted that #9001 is not going to block #6841, and will likely never happen, so it cannot reasonably block anything. Sorry it took me so long to do this move. And apparently I was the only one insisting on having #9001, which was the only blocker to implement what this ticket is about in Onion Circuits (as opposed as implementing it in Nyx). So let's implement it in Onion Circuits, right?
So I have a few questions.
- do you want to implement this feature? Any ETA?
- how long do you think it would take me to do it? I wonder if I could do this in the next few days, perhaps.
sajolida: do you feel that this is a blocker for #6841? See the ticket description for how users could do this outside of Onion Circuits, until Onion Circuits supports this feature. Sorry if we already have had this discussion and I'm rehashing it, I don't mean to insist endlessly (the ML discussion was not summed up in the end, and I won't re-read it now). Let's keep in mind, though, that removing Vidalia might partly or entirely fix #10576, so one needs to balance the drawbacks of (temporarily) losing this feature (for those who use it) against the corresponding potential advantages (for everyone). As you have guessed, I'm personally not convinced we should block on this, especially if not blocking on it allows us to fix #6841 in 2.2 instead of 3 months later in 2.4, but I don't care that much and can live with blocking on it.
#12 Updated by intrigeri almost 4 years ago
- Assignee changed from sajolida to alant
- Parent task deleted (
- QA Check deleted (
#18 Updated by sajolida over 2 years ago
- Assignee deleted (
- Priority changed from Normal to Low
- Starter set to Yes
Next step is to propose a UI design but I don't want to have this on my plate right now.
It could probably be an "Easy" task for some new contributor wanting to do som UI design.