[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #5603 [Tor Client]: get_configured_bridge_by_addr_port_digest is not robust
#5603: get_configured_bridge_by_addr_port_digest is not robust
------------------------+---------------------------------------------------
Reporter: asn | Owner:
Type: defect | Status: new
Priority: major | Milestone: Tor: 0.2.3.x-final
Component: Tor Client | Version:
Keywords: | Parent:
Points: | Actualpoints:
------------------------+---------------------------------------------------
Comment(by asn):
Replying to [comment:3 nickm]:
> I think that kind of change might not necessary; the
bridge_add_from_config() code could just change instead. That is, you
could change the logic from:
>
> {{{
> if ((b = get_configured_bridge_by_addr_port_digest(...)) {
> b->marked_for_removal = 0;
> return;
> }
> }}}
>
> to:
>
> {{{
> if ((b = get_configured_bridge_by_addr_port_digest(...)) &&
> addr matches && port matches && digest matches && transport
matches..) {
> b->marked_for_removal = 0;
> return;
> }
> }}}
Hm, true. This sounds more sane.
A complication that might occur is that we can end up having bridges with
the same addr/port but with different digests/transports. This does not
make much sense, and does not go well with the way that
`find_transport_by_bridge_addrport()` works.
Maybe we should start returning an `int` in `bridge_add_from_config()`,
signal such conflicts by return `-1`, and then killing tor while it reads
the config? I'm not sure how we should treat such conflicts otherwise
(ignore the new bridge and warn the user?).
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5603#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs