Opened 4 years ago

Closed 4 years ago

#15244 closed enhancement (invalid)

Add helper functin that validates a .onion address

Reported by: dgoulet Owned by: dgoulet
Priority: Medium Milestone: Tor: 0.2.7.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-hs
Cc: Yawning Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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);

Child Tickets

Change History (7)

comment:1 Changed 4 years ago by nickm

Sounds fine; what's the use case?

comment:2 in reply to:  1 Changed 4 years ago by dgoulet

Replying to nickm:

Sounds fine; what's the use case?

This #14847 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.

comment:3 Changed 4 years ago by 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.

comment:4 in reply to:  3 Changed 4 years ago by yawning

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 #6411 will use this.

comment:5 in reply to:  3 Changed 4 years ago by dgoulet

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.

comment:6 Changed 4 years ago by dgoulet

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`

comment:7 Changed 4 years ago by dgoulet

Resolution: invalid
Status: newclosed

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

Note: See TracTickets for help on using tickets.