Don't print bridge IPs/fingerprints in WARN/NOTICE log messages

By default, we currently print out bridge IP:ports and fingerprints in tor's log messages at the notice and warn levels. Users often copy+paste these logs to various public places when trying to debug why their connection isn't working.

I understand that this is probably useful information to give to the support desk for debugging why tor isn't working… but would it be doable to have the support people ask, "Hey could you add SafeLogging 0 to your torrc?" or something?

I think the default should be to sanitise bridge IP:ports and fingerprints at these levels.

changed milestone to %Tor: unspecified

added 034-removed-20180328 034-triage-20180328 component::core tor/tor milestone::Tor: unspecified points::2 priority::medium severity::major sponsor::M status::new tor-bridge type::defect labels

I'm willing to take this ticket (and the changes should be trivial), if we think that doing this is a good idea.

I think these can should be covered by safelog, yeah.

Trac:
Milestone: N/A to Tor: 0.2.8.x-final

I'm not decided yet on whether to safelog the bridge's fingerprint or use the bridge's hashed fingerprint. I guess I'll decide when I get around to doing this ticket.

Trac:
Status: new to assigned
Owner: N/A to isis

It seems wise to check with the support folks, e.g. Colin and Nima, about whether this interaction actually happens with them. "Just add this line to your torrc" is an impossible step for most users, especially now that Tor Browser hides your torrc file so well.

(I don't see "sometimes users share their bridges" as that big a deal, in that without help those people are going to become non-users anyway.)

Trac:
Points: N/A to small/medium

Could be fixed at the same time at #7457 (moved), perhaps. It's the same lines of code at least.

These seem like features, or like other stuff unlikely to be possible this month. Bumping them to 0.2.9

Trac:
Milestone: Tor: 0.2.8.x-final to Tor: 0.2.9.x-final

Tagging these bridge- and PT- items as S-can.

Trac:
Sponsor: N/A to SponsorS-can

Trac:
Keywords: tor-bridge 028-triage deleted, 028-triage, tor-bridge added

small/medium => 2.

Trac:
Points: small/medium to 2

Adding to my august tickets.

Trac:
Keywords: N/A deleted, TorCoreTeam201608 added

Defer some of my 029 tickets to 030

Trac:
Milestone: Tor: 0.2.9.x-final to Tor: 0.3.0.x-final

Deferring these to 0.3.1.x as nonbugfixes.

Trac:
Milestone: Tor: 0.3.0.x-final to Tor: 0.3.1.x-final

Clear sponsorS and sponsorU from open tickets in 0.3.1

Trac:
Sponsor: SponsorS-can to N/A

Deferring to 0.3.2

Trac:
Milestone: Tor: 0.3.1.x-final to Tor: 0.3.2.x-final

Trac:
Keywords: 028-triage deleted, N/A added

Trac:
Keywords: TorCoreTeam201608 deleted, N/A added

Trac:
Severity: N/A to Blocker
Reviewer: N/A to N/A
Sponsor: N/A to SponsorM

Trac:
Severity: Blocker to Major

I'm still not clear that this one is worth it. Individual bridge addresses are not that precious (so the downside of including details about them in logs which are generally not shared is limited), and the benefits to users of having useful log lines, for those relatively advanced users who know how to find their log lines, seems like a somewhat useful upside.

Looks like the same ticket as #18491 (moved) ?

Doesn't IP addresses to first hops risk incriminating a person linked to a lost laptop or mobile containing this data?

These feature and bugfix tickets have no patches. The earliest they will get done is 0.3.4.

Trac:
Milestone: Tor: 0.3.2.x-final to Tor: 0.3.4.x-final

Trac:
Keywords: N/A deleted, 034-triage-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

Trac:
Keywords: N/A deleted, 034-removed-20180328 added

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

Trac:
Milestone: Tor: 0.3.4.x-final to Tor: unspecified

Trac:
Owner: isis to N/A

Change tickets that are assigned to nobody to "new".

Trac:
Status: assigned to new

changed time estimate to 16h

mentioned in issue #18491 (moved)

mentioned in issue #18491 (moved)

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