Exits tracked with TrackHostExits should not reset on hup

Using TrackHostExits with a long TrackHostExitsExpire should mean Exits are only rotated if they go down. I don't see a reason why we should forget the trackings we set up earlier when we got a hup and the TrackingHostExits* options didn't change, especially because some Tor packages like the debian package hup tor frequently.

[Automatically added by flyspray2trac: Operating System: All]

changed milestone to %Tor: 0.2.2.x-final

added component::core tor/tor milestone::Tor: 0.2.2.x-final priority::high resolution::fixed status::closed tor-client type::defect version::0.2.1.25 labels

Worth fixing if that's what people want, though I suspect there are others who definitely do want their tracked exits reset on a HUP. Seems like a fine case for a boolean option.

Trac:
Milestone: N/A to N/A
Keywords: N/A deleted, N/A added
Parent: N/A to N/A

This should be fairly easy for anybody who reads C and can track the control flow for the SIGNAL command from handle_control_signal() down through signal_callback() to do_hup().

Trac:
Description: Using TrackHostExits with a long TrackHostExitsExpire should mean Exits are only rotated if they go down. I don't see a reason why we should forget the trackings we set up earlier when we got a hup and the TrackingHostExits* options didn't change, especially because some Tor packages like the debian package hup tor frequently.

[Automatically added by flyspray2trac: Operating System: All]

to

Using TrackHostExits with a long TrackHostExitsExpire should mean Exits are only rotated if they go down. I don't see a reason why we should forget the trackings we set up earlier when we got a hup and the TrackingHostExits* options didn't change, especially because some Tor packages like the debian package hup tor frequently.

[Automatically added by flyspray2trac: Operating System: All]
Keywords: N/A deleted, easy added
Milestone: N/A to Tor: 0.2.3.x-final

Whoops, I was thinking of a different bug. This one should be fairly easy too, modulo the flushing issues.

ugh. No, I was thinking of this bug.

Because debian's tor package hups tor daily, I think this one is important to resolve in the 0.2.3 timeframe: it can quite reasonably bite users in a way they'll find impossible to track down.

Speaking of which, is there a full list of things that Tor will flush/reset/etc on hup? The list has changed over the years, but if a user wants to predict whether this will happen, where would she look?

Trac:
Points: N/A to N/A
Priority: minor to major
Summary: Exits tracked with TrackHostExits reset on hup to Exits tracked with TrackHostExits should not reset on hup
Actualpoints: N/A to N/A

The patch is easy enough to do. One thing to note, though: right now, addressmap_clear_transient() clears three things: DNS results, virtual address mappings, and trackexithost mappings. Do we want to clear all of these on HUP? Some? None?

Replying to nickm:

The patch is easy enough to do. One thing to note, though: right now, addressmap_clear_transient() clears three things: DNS results, virtual address mappings, and trackexithost mappings. Do we want to clear all of these on HUP? Some? None?

We want to clear TrackHostExits mappings on SIGHUP iff they are for hosts not listed in TrackHostExits after the HUP. More generally, we want to clear a TrackHostExits mapping whenever TrackHostExits changes and the mapped host is not in the new TrackHostExits list.

We should clear virtual address mappings on SIGHUP iff AutomapHostsOnResolve is off after the HUP.

We shouldn't clear DNS results on SIGHUP.

Tossing this into 0.2.2.x -- if debian is hupping hourly, we'll need to fix this one.

Trac:
Milestone: Tor: 0.2.3.x-final to Tor: 0.2.2.x-final

err, daily. same point though.

Trac:
Keywords: easy deleted, N/A added

See branch bug1345 in my public repository. It's more or less straightforward, but wasn't totally trivial.

Trac:
Status: new to needs_review

bug1345 looks good.

consider_recording_trackhost's documentation comment seems to be wrong, though. (But it's no more wrong than it was before.)

revised and merged.

Trac:
Status: needs_review to closed
Resolution: None to fixed

Trac:
Keywords: N/A deleted, tor-client added

Trac:
Component: Tor Client to Tor

closed

moved to tpo/core/tor#1345 (closed)