Your message dated Fri, 17 Oct 2025 13:18:00 +0200
with message-id <[email protected]>
and subject line Re: Bug#975977: tor generates invalid adress for hiddenservice
when runninf on armv5tel architectures
has caused the Debian Bug report #975977,
regarding tor generates invalid adress for hiddenservice when runninf on
armv5tel architectures
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
975977: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975977
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: tor
Version: 0.3.5.10-1
Severity: normal
Dear Maintainer,
I believe that tor generates invalid hidden service onion addresses when
running on armv5tel platform
How to reproduce
1. install tor on armv5tel machines
2. enable the hiddenservice directives in the configuration
3. restart tor
4. try to connect to the .onion address genreated by tor (saved in the hostname
file)
5. tor browser return and "Invalid Onionsite Address / Details: 0xF6 — The
provided .onion address is invalid. This error is returned due to one of the
following reasons: the address checksum doesn't match, the ed25519 public key
is invalid, or the encoding is invalid."
I know for sure that the generated keys are correct. I tried running tor with
the same generated keys on x86_64 and armhf. tor will generate a new hostname
(with only characters at the end of the url varying) and the tor browser can
connect to the service
I tried generating new keys on the x86_64 (tor browser can connect to the URL)
and then deploying on the armv5tel machine (tor node will again amend the last
few chars of the .onion) and the tor browser will generate a similar 0xF6 error
THerefore I believe that this is an architecture related bug
I also replicated the exact same misbehavior using the latest packages
available in the buster backport
-- System Information:
Debian Release: 10.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: armel (armv5tel)
Kernel: Linux 4.19.0-12-marvell
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages tor depends on:
ii adduser 3.118
ii libc6 2.28-10
ii libcap2 1:2.25-2
ii libevent-2.1-6 2.1.8-stable-4
ii libgcc1 1:8.3.0-6
ii liblzma5 5.2.4-1
ii libssl1.1 1.1.1d-0+deb10u3
ii libsystemd0 241-7~deb10u4
ii libzstd1 1.3.8+dfsg-3
ii lsb-base 10.2019051400
ii zlib1g 1:1.2.11.dfsg-1
Versions of packages tor recommends:
ii logrotate 3.14.0-4
ii tor-geoipdb 0.3.5.10-1
ii torsocks 2.3.0-2
Versions of packages tor suggests:
pn apparmor-utils <none>
pn mixmaster <none>
pn obfs4proxy <none>
pn socat <none>
pn tor-arm <none>
pn torbrowser-launcher <none>
-- Configuration Files:
/etc/tor/torrc changed:
HiddenServiceDir /var/lib/tor/torshare/
HiddenServicePort 80 127.0.0.1:81
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 0.4.5.5-rc-1
This should be fixed upstream, due to [1] mentioning "Fixes bug 40210",
with these versions:
0.4.5.3-rc
0.4.4.7
0.4.3.8
0.3.5.13
Using as fixing version 0.4.5.5-rc-1 because
this is the first fixed version in unstable.
[1] https://gitlab.torproject.org/tpo/core/tor/-/raw/main/ChangeLog
--- End Message ---
