Stop assuming that every extend_info contains an IPv4 address in get_lspecs_from_extend_info()

addr can be an IPv6 address

changed milestone to %Tor: 0.3.2.x-final

added actualpoints::0.2 component::core tor/tor ipv6 milestone::Tor: 0.3.2.x-final owner::teor parent::23820 points::0.2 priority::medium prop224 resolution::fixed severity::normal single-onion status::closed tor-hs type::defect version::tor 0.3.2.1-alpha labels

These tickets aren't urgent, and they involve major refactoring. Deferring to 0.3.3

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

This is safe, because all client extend infos are IPv4.

Even if they are not, if addr is an IPv6 address, the IPv4 address ends up being 0.0.0.0. And it gets rejected in hs_get_extend_info_from_lspecs() by extend_info_addr_is_allowed().

In my commit ab53577d8c in my branch bug23820_032 (#23820 (moved)), I fixed this issue. (We will add IPv6 support to that function in #23577 (moved).)

Trac:
Status: new to needs_review
Version: N/A to Tor: 0.3.2.1-alpha
Actualpoints: N/A to 0.2
Points: N/A to 0.2
Parent: #23493 (moved) to #23820 (moved)
Milestone: Tor: 0.3.3.x-final to Tor: 0.3.2.x-final

Trac:
Cc: N/A to neel@neelc.org

Assigning this to "teor". In theory, this will be fixed by #23820 (moved) so change its status so it doesn't end up in the next review group :).

Trac:
Status: needs_review to assigned
Owner: N/A to teor

Merged via #23820 (moved)

Trac:
Resolution: N/A to fixed
Status: assigned to closed

closed

changed time estimate to 1h 36m

added 1h 36m of time spent

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