Arti does not support hostnames in proxy_ports config
Summary
The proxy_port
config only supports IP addresses, not hostnames.
Having it to work for hostnames would be useful, like in containerized environments.
Steps to reproduce
- Build and Arti container with
--features=onion-service-service
. - Try with the following configuration:
[onion_services."default"]
proxy_ports = [
["80", "httpd:80"],
]
Minimum Reproducible Example
Using either Docker or Podman:
-
Build and Arti container with
--features=onion-service-service
:- Either use this example with
podman build -t arti:alpine
. - Or pull an image with
podman pull containers.torproject.org/tpo/onion-services/onimages/arti:alpine
.
- Either use this example with
-
Create the following configuration file (
onionservice.toml
):
[onion_services."default"]
proxy_ports = [
["80", "httpd:80"],
]
- Create a network and setup a backend HTTP server:
podman network create onionservice
podman pull containers.torproject.org/tpo/onion-services/onimages/httpd
podman run -d --net onionservice --name httpd httpd
- Run Arti from the container, adding it to the
onionservice
network, so thehttpd
host is reachable:
podman volume create arti
podman run --rm -it --net onionservice --name arti \
--mount type=volume,src=arti,target=/home/arti \
--mount type=bind,src=onionservice.toml,target=/srv/arti/configs/onionservice.toml \
arti:alpine
What is the current bug behavior?
Arti refuses to start:
podman run --rm -it --net onionservice --name arti \
--mount type=volume,src=arti,target=/home/arti \
--mount type=bind,src=onionservice.toml,target=/srv/arti/configs/onionservice.toml \
arti:alpine
arti: error: read configuration: Config contents not as expected: Couldn't load configuration: Could not parse onion service target type "httpd:80" for key "default.onion_services.default" in srv/arti/configs/onionservice.toml TOML file
What is the expected behavior?
It would be expected to have a normal bootstrap sequence:
podman run --rm -it --net onionservice --name arti \
--mount type=volume,src=arti,target=/home/arti \
--mount type=bind,src=onionservice.toml,target=/srv/arti/configs/onionservice.toml \
arti:alpine
2025-04-02T11:24:31Z INFO arti::subcommands::proxy: Starting Arti 1.4.2 in SOCKS proxy mode on localhost port 9150 ...
2025-04-02T11:24:31Z INFO arti_client::client: Using keystore from "/home/arti/.local/share/arti/keystore"
2025-04-02T11:24:31Z INFO tor_hsservice: Generated a new identity for service default: [scrubbed]
2025-04-02T11:24:31Z INFO tor_hsservice: Launching onion service nickname=default
2025-04-02T11:24:31Z INFO tor_hsservice::ipt_mgr: HS service default failed to select IPT relay: error: bad or insufficient netdir: No directory information available
2025-04-02T11:24:31Z INFO tor_dirmgr: Didn't get usable directory from cache.
2025-04-02T11:24:31Z INFO arti::socks: Listening on [::1]:9150.
2025-04-02T11:24:31Z INFO arti::socks: Listening on 127.0.0.1:9150.
2025-04-02T11:24:31Z INFO tor_dirmgr::bootstrap: 1: Looking for a consensus. attempt=1
2025-04-02T11:24:31Z INFO tor_hsservice::ipt_mgr: HS service default failed to select IPT relay: error: bad or insufficient netdir: No directory information available
2025-04-02T11:24:31Z WARN tor_chanmgr::transport::default: Connection to [scrubbed] failed: error: Network unreachable (os error 101)
2025-04-02T11:24:32Z INFO arti::reload_cfg: Successfully reloaded configuration.
2025-04-02T11:24:34Z INFO tor_dirmgr::bootstrap: 1: Downloading certificates for consensus (we are missing 9/9). attempt=1
It would also be expected that the Arti container would pass requests to the httpd
container.
The expected bootstrap happens when httpd
is replaced with an IP like 127.0.0.1
, but it's difficult to track which IP a backend currently have, especially with containers.
With C Tor, this is possible with HiddenServicePort 80 httpd:80
(check the Onimages README for a working example).
Environment
- Arti version: 1.4.2.
- Operating system:
- Host: Debian GNU/Linux 12.10 (bookworm).
- Container: Alpine 3.21.3.
Possible fixes
While strict validation of proxy endpoints is desired, the requirement for only valid IP addresses could be relaxed, allowing for hostnames (but not invalid IPs).