Add helper functin that validates a .onion address

Make a function that validates an HS address and can return either a reason as a string or an error code indicating the error type (maybe use errno values for that?).

int is_valid_rendservice_addr(const char *addr, char **reason);

changed milestone to %Tor: 0.2.7.x-final in legacy/trac

added component::core tor/tor in Legacy / Trac milestone::Tor: 0.2.7.x-final in Legacy / Trac owner::dgoulet in Legacy / Trac priority::medium in Legacy / Trac resolution::invalid in Legacy / Trac status::closed in Legacy / Trac tor-hs in Legacy / Trac type::enhancement in Legacy / Trac labels

Sounds fine; what's the use case?

Replying to nickm:

Sounds fine; what's the use case?

This legacy/trac#14847 (moved) would use it. Also a SOCKS connection requesting a .onion would use it. More and more places in the code validate a .onion which we could simply make a function for it. Basically, every entry point in the tor code that parses a .onion would be useful.

A lot of this logic is in parse_extended_hostname; you could refactor it out of there, but you'd need to split out the part that changes the address.

Since I'm partly to blame for requesting this, this is also a future-proofing measure so that when we do move to Ed25519 onions, we don't have a ton of slightly different ".onion" validation checks in our code that all need to be changed.

Also legacy/trac#6411 (moved) will use this.

Replying to nickm:

A lot of this logic is in parse_extended_hostname; you could refactor it out of there, but you'd need to split out the part that changes the address.

I agree, I would do a simple refactor here to create a "is valid onion address" function that parse_extended_hostname could use. Simple move around code so we can have one that validates and can take a const char and the other can parse it like it does right now.

Hrm actually, looking at rend_valid_service_id, seems what we want...

Is this enough to make sure the decode32 will always work?

strspn(query, BASE32_CHARS) != REND_SERVICE_ID_LEN_BASE32`

Ok closing this, rend_valid_service_id is exactly what's needed. Let's not forget to update it when prop224 is implemented :).

Trac:
Resolution: N/A to invalid
Status: new to closed

closed

moved from legacy/trac#15244 (moved)

added Feature label and removed 1 deleted label

added 1 deleted label and removed 1 deleted label