Bug#975977: tor generates invalid adress for hiddenservice when runninf on armv5tel architectures
On Thu, 17 Dec 2020 14:30:56 +0200 George Kadianakis wrote: > Bernhard Übelacker writes: > > > Hello Peter, > > > > Am 16.12.20 um 11:08 schrieb Peter Palfrader: > >> Hi Bernhard! > > > >> Can you try to rebuild tor with __attribute__((aligned(8))) for the > >> keccak_state as suggested in > >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975977#44 > >> and then let us know if the issue is still there? > >> > > > > I rebuilt the tor package with this change [1] below (I hope I > > placed it correctly). > > > > With this I found "disassemble /r keccak_finalize" produces the > > exact same instructions, but now the pointer given to keccak_finalize > > seems to be aligned at a 8 byte boundary. > > > > Now the strd placed at armv5tel the same sequence as > > on armv7 to the "a" member [3]. > > > > And I guess hostname contains now the expected value: > > > > $ cat hs/hostname > > upxkcswnvepfls7vcy5vuixy54hlugfjnzhvl5ygfbjtm7znkyahcvad.onion > > > > Kind regards, > > Bernhard > > > > Thanks a lot for the diagnosis and testing, Bernhard and Arnd. > > I submitted a patch for this here: > https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/243 > > Thanks again! > > Hi Peter Tested the 4.5.5-rc that was uploaded into the buster-backports All seems to be in working perfectly Cheers
Bug#975977: tor generates invalid adress for hiddenservice when runninf on armv5tel architectures
Bernhard Übelacker writes: > Hello Peter, > > Am 16.12.20 um 11:08 schrieb Peter Palfrader: >> Hi Bernhard! > >> Can you try to rebuild tor with __attribute__((aligned(8))) for the >> keccak_state as suggested in >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975977#44 >> and then let us know if the issue is still there? >> > > I rebuilt the tor package with this change [1] below (I hope I > placed it correctly). > > With this I found "disassemble /r keccak_finalize" produces the > exact same instructions, but now the pointer given to keccak_finalize > seems to be aligned at a 8 byte boundary. > > Now the strd placed at armv5tel the same sequence as > on armv7 to the "a" member [3]. > > And I guess hostname contains now the expected value: > > $ cat hs/hostname > upxkcswnvepfls7vcy5vuixy54hlugfjnzhvl5ygfbjtm7znkyahcvad.onion > > Kind regards, > Bernhard > Thanks a lot for the diagnosis and testing, Bernhard and Arnd. I submitted a patch for this here: https://gitlab.torproject.org/tpo/core/tor/-/merge_requests/243 Thanks again!
Bug#975977: tor generates invalid adress for hiddenservice when runninf on armv5tel architectures
Hello Peter,
Am 16.12.20 um 11:08 schrieb Peter Palfrader:
Hi Bernhard!
Can you try to rebuild tor with __attribute__((aligned(8))) for the
keccak_state as suggested in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975977#44
and then let us know if the issue is still there?
I rebuilt the tor package with this change [1] below (I hope I
placed it correctly).
With this I found "disassemble /r keccak_finalize" produces the
exact same instructions, but now the pointer given to keccak_finalize
seems to be aligned at a 8 byte boundary.
Now the strd placed at armv5tel the same sequence as
on armv7 to the "a" member [3].
And I guess hostname contains now the expected value:
$ cat hs/hostname
upxkcswnvepfls7vcy5vuixy54hlugfjnzhvl5ygfbjtm7znkyahcvad.onion
Kind regards,
Bernhard
[1]
diff --git a/src/ext/keccak-tiny/keccak-tiny.h
b/src/ext/keccak-tiny/keccak-tiny.h
index a9c8ed6..dd26386 100644
--- a/src/ext/keccak-tiny/keccak-tiny.h
+++ b/src/ext/keccak-tiny/keccak-tiny.h
@@ -21,7 +21,7 @@ typedef struct keccak_state {
size_t offset;
uint8_t finalized : 1;
-} keccak_state;
+} __attribute__((aligned(8))) keccak_state;
/* Initialize a Keccak instance suitable for SHA-3 hash functions. */
int keccak_digest_init(keccak_state *s, size_t bits);
[2]
(gdb) bt
#0 0x005c4ac4 in xorin8 (len=136, src=, dst=) at
../src/ext/keccak-tiny/keccak-tiny-unrolled.c:21
#1 keccak_finalize (s=s@entry=0xbeffef98) at
../src/ext/keccak-tiny/keccak-tiny-unrolled.c:189
[3]
(gdb) stepi
0x005c4ac0 21return _le64toh(r);
1: x/i $pc
=> 0x5c4ac0 : strdr2, [r4]
(gdb) x/8xb &((keccak_state *) 0xbeffef98)->a
0xbeffef98: 0x000x000x000x000x000x000x000x00
(gdb) stepi
0x005c4ac4 21return _le64toh(r);
1: x/i $pc
=> 0x5c4ac4 : bhi 0x5c4a90
(gdb) x/8xb &((keccak_state *) 0xbeffef98)->a
0xbeffef98: 0x2e0x6f0x6e0x690x6f0x6e0x200x63
(gdb) display/x $r2
2: /x $r2 = 0x696e6f2e
(gdb) display/x $r4
3: /x $r4 = 0xbeffef98
Bug#975977: tor generates invalid adress for hiddenservice when runninf on armv5tel architectures
Hi Bernhard! On Sun, 13 Dec 2020, Bernhard Übelacker wrote: > Dear Maintainer, > I tried to collect some more information and compared this > situation on real hardware armv5tel with an armv7 and > it looks like in keccak_finalize the following instruction > stores different data to memory depending on the arm hardware: > >0x005c4ac0 :f0 20 c4 e1 strdr2, [r4] > > In the failing case this is stored: > (gdb) x/8xb &((keccak_state *) 0xbeffef5c)->a > 0xbeffef5c: 0x6f0x6e0x200x630x000x000x00 > 0x00 > > And in the good case this: > (gdb) x/8xb &((keccak_state *) 0xbeffef5c)->a > 0xbeffef5c: 0x2e0x6f0x6e0x690x6f0x6e0x20 > 0x63 > > While on both the registers r2 and r3 contain: > r2 0x696e6f2e 1768845102 > r3 0x63206e6f 1663069807 > > In the attached files are some more details leading to the above result. Can you try to rebuild tor with __attribute__((aligned(8))) for the keccak_state as suggested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975977#44 and then let us know if the issue is still there? -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Bug#975977: tor generates invalid adress for hiddenservice when runninf on armv5tel architectures
On Tue, 15 Dec 2020, George Kadianakis wrote:
> Bernhard Übelacker writes:
>
> > Dear Maintainer,
> > I tried to collect some more information and compared this
> > situation on real hardware armv5tel with an armv7 and
> > it looks like in keccak_finalize the following instruction
> > stores different data to memory depending on the arm hardware:
> >
> > 0x005c4ac0 :f0 20 c4 e1 strdr2, [r4]
> >
> > In the failing case this is stored:
> > (gdb) x/8xb &((keccak_state *) 0xbeffef5c)->a
> > 0xbeffef5c: 0x6f0x6e0x200x630x000x000x00
> > 0x00
> >
> > And in the good case this:
> > (gdb) x/8xb &((keccak_state *) 0xbeffef5c)->a
> > 0xbeffef5c: 0x2e0x6f0x6e0x690x6f0x6e0x20
> > 0x63
> >
> > While on both the registers r2 and r3 contain:
> > r2 0x696e6f2e 1768845102
> > r3 0x63206e6f 1663069807
> >
> > In the attached files are some more details leading to the above result.
> >
>
> Woah Bernhard, that's some top-notch detective work!
>
> I wonder what this means? Does this mean that strd is broken on that
> armv5tel, or that we are running gcc with the wrong flags for this
> architecture?
Arnd Bergmann on #debian-arm points out that
113 setout8(const uint8_t *src, uint8_t *dst, size_t len) {
114 const uint64_t *si = (const uint64_t*)src; // Always aligned.
line 114 of src/ext/keccak-tiny/keccak-tiny-unrolled.c has undefined behavior
and that 0xbeffef5c is not actually aligned.
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Operating System
| `-https://www.debian.org/
Bug#975977: tor generates invalid adress for hiddenservice when runninf on armv5tel architectures
I notice that the store crosses a cacheline boundary on an ARMv5 CPU with 32-byte cache lines. I see that the xorin8 function on line 104 of https://fossies.org/linux/tor/src/ext/keccak-tiny/keccak-tiny-unrolled.c assumes that the 'dst' pointer has 8 byte alignment, but the gdb output only shows 4 byte alignment, which matches the data structure definition for keccak_state in https://fossies.org/linux/tor/src/ext/keccak-tiny/keccak-tiny.h I would suggest adding __attribute__((aligned(8))) to the structure definition to force 8-byte alignment, which would make the code more portable and avoid undefined behavior (casting a pointer to a type of higher alignment). I don't think this is actually supposed to be undefined behavior for an ARMv5 CPU, as long as the destination for the 'strd' instruction has at least four byte alignment, but since gcc never creates this instruction sequence on valid code, a hardware erratum may have gone unnoticed for a long time. Arnd
Bug#975977: tor generates invalid adress for hiddenservice when runninf on armv5tel architectures
Bernhard Übelacker writes: > Dear Maintainer, > I tried to collect some more information and compared this > situation on real hardware armv5tel with an armv7 and > it looks like in keccak_finalize the following instruction > stores different data to memory depending on the arm hardware: > > 0x005c4ac0 :f0 20 c4 e1 strdr2, [r4] > > In the failing case this is stored: > (gdb) x/8xb &((keccak_state *) 0xbeffef5c)->a > 0xbeffef5c: 0x6f0x6e0x200x630x000x000x00 > 0x00 > > And in the good case this: > (gdb) x/8xb &((keccak_state *) 0xbeffef5c)->a > 0xbeffef5c: 0x2e0x6f0x6e0x690x6f0x6e0x20 > 0x63 > > While on both the registers r2 and r3 contain: > r2 0x696e6f2e 1768845102 > r3 0x63206e6f 1663069807 > > In the attached files are some more details leading to the above result. > Woah Bernhard, that's some top-notch detective work! I wonder what this means? Does this mean that strd is broken on that armv5tel, or that we are running gcc with the wrong flags for this architecture? The only relevant google result I could find is this post from 2007: https://www.redhat.com/archives/rhl-devel-list/2007-June/msg01002.html
Bug#975977: tor generates invalid adress for hiddenservice when runninf on armv5tel architectures
Dear Maintainer, I tried to collect some more information and compared this situation on real hardware armv5tel with an armv7 and it looks like in keccak_finalize the following instruction stores different data to memory depending on the arm hardware: 0x005c4ac0 :f0 20 c4 e1 strdr2, [r4] In the failing case this is stored: (gdb) x/8xb &((keccak_state *) 0xbeffef5c)->a 0xbeffef5c: 0x6f0x6e0x200x630x000x000x000x00 And in the good case this: (gdb) x/8xb &((keccak_state *) 0xbeffef5c)->a 0xbeffef5c: 0x2e0x6f0x6e0x690x6f0x6e0x200x63 While on both the registers r2 and r3 contain: r2 0x696e6f2e 1768845102 r3 0x63206e6f 1663069807 In the attached files are some more details leading to the above result. Kind regards, Bernhard (gdb) bt #0 0x7f719ac4 in xorin8 (len=136, src=, dst=) at ../src/ext/keccak-tiny/keccak-tiny-unrolled.c:21 #1 keccak_finalize (s=0xbeffef5c) at ../src/ext/keccak-tiny/keccak-tiny-unrolled.c:189 #2 0x7f71a410 in hash (out=0xbefff1a8 "", outlen=32, in=, inlen=48, bits=256, delim=6 '\006') at ../src/ext/keccak-tiny/keccak-tiny-unrolled.c:353 #3 0x7f71a640 in sha3_256 (out=out@entry=0xbefff1a8 "", outlen=outlen@entry=32, in=in@entry=0xbefff15c ".onion checksum\243\356\241Jͩ\036U\313\365\026;Z\"\370\357\016\272\030\251nOU\367\006(S6\177-V", inlen=inlen@entry=48) at ../src/ext/keccak-tiny/keccak-tiny-unrolled.c:389 #4 0x7f6fb5e8 in crypto_digest256 (digest=digest@entry=0xbefff1a8 "", m=m@entry=0xbefff15c ".onion checksum\243\356\241Jͩ\036U\313\365\026;Z\"\370\357\016\272\030\251nOU\367\006(S6\177-V", len=len@entry=48, algorithm=algorithm@entry=DIGEST_SHA3_256) at ../src/lib/crypt_ops/crypto_digest.c:153 #5 0x7f651948 in build_hs_checksum (key=key@entry=0x7f837df4, version=version@entry=3 '\003', checksum_out=checksum_out@entry=0xbefff1a8 "") at ../src/feature/hs/hs_common.c:748 #6 0x7f6530b0 in hs_build_address (key=key@entry=0x7f837df4, version=, addr_out=addr_out@entry=0x7f837da0 "") at ../src/feature/hs/hs_common.c:1001 ... # Buster armel chroot 2020-12-13 on another Buster armel # uname -a Linux qnap119 4.19.0-12-marvell #1 Debian 4.19.152-1 (2020-10-18) armv5tel GNU/Linux # cat /proc/cpuinfo processor : 0 model name : Feroceon 88FR131 rev 1 (v5l) BogoMIPS: 400.00 Features: swp half thumb fastmult edsp CPU implementer : 0x56 CPU architecture: 5TE CPU variant : 0x2 CPU part: 0x131 CPU revision: 1 Hardware: Marvell Kirkwood (Flattened Device Tree) Revision: # chroot/bin/busybox mount -o rbind /dev chroot/dev # chroot/bin/busybox mount -o rbind /proc chroot/proc # chroot/bin/busybox mount -o rbind /sys chroot/sys # cd debian-10-buster-armel-chroot # env -i TERM=xterm LANG=de_DE.UTF-8 /usr/sbin/chroot chroot /bin/su - # apt install openssl tor # dpkg -l tor ... ii tor0.3.5.12-1 armelanonymizing overlay network for TCP # exit # unshare -n /bin/bash # env -i TERM=xterm LANG=de_DE.UTF-8 /usr/sbin/chroot chroot /bin/su -l benutzer $ mkdir hs $ chmod go-rwx -R hs $ echo 'PT0gZWQyNTUxOXYxLXNlY3JldDogdHlwZTAgPT0AAACg6zoxlQ2hy7C6fUoTgIa0GLMk/YdVs2ic6jUDCzztZeLWcfqwCQ5/KoPk9v99cuWKO5mNpVrDtbOc27UUyC7e' | base64 -d > hs/hs_ed25519_secret_key $ echo '6bff2f57fcd69049091dcfa42b08fb84919d60dac919cbb16e3df1d960bb7843 ./hs/hs_ed25519_secret_key' | sha256sum -c ./hs/hs_ed25519_secret_key: OK $ cat < torrc HiddenServiceDir /home/benutzer/hs HiddenServicePort 80 127.0.0.1:8080 EOF $ /usr/sbin/tor -f torrc Log 'info stdout' ... ^C $ cat hs/hostname upxkcswnvepfls7vcy5vuixy54hlugfjnzhvl5ygfbjtm7znkyac43yd.onion # apt build-dep tor # apt install gdb tor-dbgsym mkdir /home/benutzer/source/tor/orig -p cd/home/benutzer/source/tor/orig apt source tor cd $ rm hs/hostname $ gdb -q --args /usr/sbin/tor -f torrc Log 'info stdout' (gdb) set width 0 (gdb) set pagination off (gdb) directory /home/benutzer/source/tor/orig/tor-0.3.5.12/src (gdb) b build_hs_checksum (gdb) run (gdb) print sizeof(*key) $3 = 32 (gdb) x/32xb key 0x6e2de4: 0xa30xee0xa10x4a0xcd0xa90x1e0x55 0x6e2dec: 0xcb0xf50x160x3b0x5a0x220xf80xef 0x6e2df4: 0x0e0xba0x180xa90x6e0x4f0x550xf7 0x6e2dfc: 0x060x280x530x360x7f0x2d0x560x00 (gdb) next (gdb) next (gdb) next 748 crypto_digest256((char *) checksum_out, data, sizeof(data), (gdb) print sizeof(data) $4 = 48 (gdb) x/48xb data 0xbefff17c: 0x2e0x6f0x6e0x690x6f0x6e0x200x63 0xbefff184: 0x680x650x630x6b0x730x750x6d0xa3 0xbefff18c: 0xee0xa10x4a0xcd0xa90x1e0x550xcb 0xbefff194: 0xf50x160x3b0x5a0x220xf80xef0x0e 0xbefff19c: 0xba0x180xa90x6e
Bug#975977: tor generates invalid adress for hiddenservice when runninf on armv5tel architectures
Hello Jean-Francois! Thanks for the help with the debugging. As can be seen by https://gitlab.torproject.org/tpo/core/tor/-/issues/40210#note_2717474 we suspect that something is wrong with the way that Tor computes onion service checksums or with the way that your OpenSSL computes SHA3 hashes. I have made a small debug branch that prints some useful debugging info: https://gitlab.torproject.org/asn/tor/-/commits/40210-debug Please try reproducing with that branch and check your tor logs for lines that look like this and post them to this ticket: """ Dec 02 14:06:21.429 [warn] checksum data: 2E6F6E696F6E20636865636B73756DD75A980182B10AB7D54BFED3C964073A0EE172F3DAA62325AF021A68F707511A03 Dec 02 14:06:21.429 [warn] debug sha3: 42538602949F370AA331D2C07A1EE7FF26CAAC9CC676288F94B82EB2188B8465 """ Depending on the results we will probably need to do some more debugging to find the real issue. Thanks a lot! :)
Bug#975977: tor generates invalid adress for hiddenservice when runninf on armv5tel architectures
On Mon, Nov 30, 2020 at 01:29:04PM +, Peter Palfrader wrote: > On Fri, 27 Nov 2020, Jean-Francois Paris wrote: > > > I believe that tor generates invalid hidden service onion addresses when > > running on armv5tel platform > > I don't have access to an armv5tel system, but at least running armel on > ARMv7 cpus (both abel.d.o and harries.d.o) I cannot reproduce this > issue. Hi peter I replayed the below. the shasum is matching however I have the following hostname upxkcswnvepfls7vcy5vuixy54hlugfjnzhvl5ygfbjtm7znkyac43yd.onion It is not going to be easy to fix if you cannot replicate. Let me know if I can help Regards jf > > Here's what I tried: > > } [sid_armel-dchroot] weasel@harris:~$ cat torrc > } HiddenServiceDir /home/weasel/hs > } HiddenServicePort 80 127.0.0.1:8080 > > } [sid_armel-dchroot] weasel@harris:~$ mkdir hs > } [sid_armel-dchroot] weasel@harris:~$ chmod go-rwx -R hs > } [sid_armel-dchroot] weasel@harris:~$ > > } [sid_armel-dchroot] weasel@harris:~$ echo > 'PT0gZWQyNTUxOXYxLXNlY3JldDogdHlwZTAgPT0AAACg6zoxlQ2hy7C6fUoTgIa0GLMk/YdVs2ic6jUDCzztZeLWcfqwCQ5/KoPk9v99cuWKO5mNpVrDtbOc27UUyC7e' > | base64 -d > hs/hs_ed25519_secret_key > > } [sid_armel-dchroot] weasel@harris:~$ echo > '6bff2f57fcd69049091dcfa42b08fb84919d60dac919cbb16e3df1d960bb7843 > ./hs/hs_ed25519_secret_key' | sha256sum -c > } ./hs/hs_ed25519_secret_key: OK > > > } [sid_armel-dchroot] weasel@harris:~$ /usr/sbin/tor -f torrc Log 'info > stdout' > } # And kill it using ^C after a few seconds > > And then I get > } [sid_armel-dchroot] weasel@harris:~$ cat hs/hostname > } upxkcswnvepfls7vcy5vuixy54hlugfjnzhvl5ygfbjtm7znkyahcvad.onion > > on armel, armhf, and also amd64. > > > -- > | .''`. ** Debian ** > Peter Palfrader | : :' : The universal > https://www.palfrader.org/ | `. `' Operating System > | `-https://www.debian.org/
Bug#975977: tor generates invalid adress for hiddenservice when runninf on armv5tel architectures
Hello Jean-Francois, is it possible that you send us a sample of keys generated plus the onion address that failed to verify? Due to our lack of an armv5tel machine, this would be our most effective approach to eventually debug this problem. Thanks a lot!
Bug#975977: tor generates invalid adress for hiddenservice when runninf on armv5tel architectures
On Fri, 27 Nov 2020, Jean-Francois Paris wrote: > I believe that tor generates invalid hidden service onion addresses when > running on armv5tel platform I don't have access to an armv5tel system, but at least running armel on ARMv7 cpus (both abel.d.o and harries.d.o) I cannot reproduce this issue. Here's what I tried: } [sid_armel-dchroot] weasel@harris:~$ cat torrc } HiddenServiceDir /home/weasel/hs } HiddenServicePort 80 127.0.0.1:8080 } [sid_armel-dchroot] weasel@harris:~$ mkdir hs } [sid_armel-dchroot] weasel@harris:~$ chmod go-rwx -R hs } [sid_armel-dchroot] weasel@harris:~$ } [sid_armel-dchroot] weasel@harris:~$ echo 'PT0gZWQyNTUxOXYxLXNlY3JldDogdHlwZTAgPT0AAACg6zoxlQ2hy7C6fUoTgIa0GLMk/YdVs2ic6jUDCzztZeLWcfqwCQ5/KoPk9v99cuWKO5mNpVrDtbOc27UUyC7e' | base64 -d > hs/hs_ed25519_secret_key } [sid_armel-dchroot] weasel@harris:~$ echo '6bff2f57fcd69049091dcfa42b08fb84919d60dac919cbb16e3df1d960bb7843 ./hs/hs_ed25519_secret_key' | sha256sum -c } ./hs/hs_ed25519_secret_key: OK } [sid_armel-dchroot] weasel@harris:~$ /usr/sbin/tor -f torrc Log 'info stdout' } # And kill it using ^C after a few seconds And then I get } [sid_armel-dchroot] weasel@harris:~$ cat hs/hostname } upxkcswnvepfls7vcy5vuixy54hlugfjnzhvl5ygfbjtm7znkyahcvad.onion on armel, armhf, and also amd64. -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal https://www.palfrader.org/ | `. `' Operating System | `-https://www.debian.org/
Bug#975977: tor generates invalid adress for hiddenservice when runninf on armv5tel architectures
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 liblzma55.2.4-1 ii libssl1.1 1.1.1d-0+deb10u3 ii libsystemd0 241-7~deb10u4 ii libzstd11.3.8+dfsg-3 ii lsb-base10.2019051400 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages tor recommends: ii logrotate3.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 pn mixmaster pn obfs4proxy pn socat pn tor-arm pn torbrowser-launcher -- Configuration Files: /etc/tor/torrc changed: HiddenServiceDir /var/lib/tor/torshare/ HiddenServicePort 80 127.0.0.1:81 -- no debconf information
