- tor-relays - lists.torproject.org

Did 'Sandbox 1' break Tor for anyone else on 0.4.5.6?
by William Kane 16 Mar '21

16 Mar '21

Hi everyone, Ever since I upgraded to tor version 0.4.5.6, enabling tor's built-in seccomp sandbox completely breaks tor, i.e. it gets killed by the kernel on start for a seccomp violation (fstat(..)) - sandboxing worked fine on 0.4.4.6, my system configuration did not change between the updates. Not specifying 'Sandbox 1' in the torrc allows tor to fully start as usual, I had to disable it post-update in order to be able to continue running my relay. /etc/tor/torrc: ORPort 37.157.195.83:38619 ORPort [2a02:2b88:2:1::3239:0]:38619 Nickname michaelscott ContactInfo ttallink(a)googlemail.com ControlPort 9051 SocksPort 0 CookieAuthentication 1 ExitPolicy reject *:* DataDirectory /var/lib/tor # Sandbox 1 ShutdownWaitLength 120 MaxMemInQueues 672MB /usr/lib/systemd/system/tor.service: [Unit] Description=Anonymizing Overlay Network After=network.target [Service] User=tor Type=simple ExecStart=/usr/bin/tor -f /etc/tor/torrc ExecReload=/usr/bin/kill -HUP $MAINPID KillSignal=SIGINT LimitNOFILE=32768 PrivateDevices=yes [Install] WantedBy=multi-user.target /etc/systemd/system/tor.service.d/override.conf: [Service] PrivateTmp=yes ProtectHome=yes ProtectSystem=strict ProtectKernelLogs=yes ProtectKernelModules=yes ProtectKernelTunables=yes ProtectControlGroups=yes NoNewPrivileges=yes RestrictSUIDSGID=yes RestrictAddressFamilies=AF_INET AF_INET6 ReadWritePaths=/var/lib/tor CapabilityBoundingSet=CAP_NET_BIND_SERVICE TimeoutStopSec=2min 15s I'm running ArchLinux with the 5.11.4 kernel, Tor is still sandboxed by systemd so this is not a huge issue but I would like to be able to continue using the built-in sandbox as well as systemd's sandboxing options in order to maximize process isolation. Did anyone else run into this? I would have posted a bug report but due to various reason I am not able to do so right now. I figured this was happening because I do not grant the CAP_DAC_READ_SEARCH capability, but I'm not so sure anymore if that's the reason. Any help is greatly appreciated. - William

2 1

Re: [tor-relays] I was banned from PayPal
by potlatch 13 Mar '21

13 Mar '21

Hello kantorkel and Tor ops, To put a little meat on the bone of this situation, I did not receive an email from PayPal--I was informed that I was banned when I tried to make a payment for VPS hosting. During the week before this ban, I had sent funds to both Flokinet for an exit relay in Finland and to ITLDC.com for VPS hosting in Poland--both exit relays. I used the PayPal support email to ask for the reason I was banned and to ask for re-instatement. I have heard nothing back. I had surmised that someone was monitoring payments to off-shore hosting companies and maybe they assumed I was supporting a news agency--I don't know really. If that is the case, why haven't the hosting sites been banned as well? The message in my PayPal account referred to a violation of the user agreement. Here is the full text of the message: -We're unable to continue offering our services -Thank you for using PayPal as your payment partner. -Unfortunately, we are unable to continue offering our services -to you at this time due to the nature of your business and/or -activity in your account and the risk it poses to PayPal. This -decision can't be overturned. -If you owe refunds to any of your buyers, you can use the money -in your PayPal account to refund them. -Money in your PayPal account will be held for 180 days. After -180 days, we'll email you information on how to withdraw your -money. The only transactions on this account over the past 3-months were VPS lease payments off-shore. I looked up the user agreement to determine where I had violated the rules and found only a single reference to operating servers: -Service Requiring Pre-Approval: -Providing file sharing services or access to newsgroups; or -selling alcoholic beverages, non-cigarette tobacco products, --e-cigarettes or prescription drugs/devices. I have a zoom meeting with two attorneys from EFF.org on March 18. Stay tuned....and maybe ban PayPal. --potlatch Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, March 11, 2021 12:06 AM, Matthias Marx <kantorkel(a)hamburg.freifunk.net> wrote: > Hi Potlatch, > > would you mind sharing PayPal's email / full message with me? > > Regards from Hamburg > kantorkel > > Am 3/11/21 um 12:42 AM schrieb potlatch: > > > Today I received a message from PayPal that paying for Tor relay server leases was a direct violation of my usage agreement. I have been paying off-shore VPS hosts for my Tor server leases with PayPal for at least ten years. Very interesting that they act now. > > They specifically state the ban was for: > > Providing file sharing services or access to newsgroups; or selling alcoholic beverages, non-cigarette tobacco products, e-cigarettes or prescription drugs/devices. > > They further state that the ban is permanent and not reversible. > > I liked using PayPal because it was a safe way to pay and didn't expose my credit card information. Before PayPal I used a prepaid card which I will probably go back too. > > --Potlatch > > Sent with ProtonMail https://protonmail.com Secure Email. > > > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

3 2

Fallback EOL
by Anders Burmeister 13 Mar '21

13 Mar '21

We lost Fallback relay 775B0FAFDE71AADC23FFC8782B7BEB1D5A92733E Had it’s EOL due to a major incident in data center. We are all sorry Regards /anders

1 0

I was banned from PayPal
by potlatch 12 Mar '21

12 Mar '21

Today I received a message from PayPal that paying for Tor relay server leases was a direct violation of my usage agreement. I have been paying off-shore VPS hosts for my Tor server leases with PayPal for at least ten years. Very interesting that they act now. They specifically state the ban was for: Providing file sharing services or access to newsgroups; or selling alcoholic beverages, non-cigarette tobacco products, e-cigarettes or prescription drugs/devices. They further state that the ban is permanent and not reversible. I liked using PayPal because it was a safe way to pay and didn't expose my credit card information. Before PayPal I used a prepaid card which I will probably go back too. --Potlatch Sent with [ProtonMail](https://protonmail.com) Secure Email.

10 9

Thoughts and insight before bridge moving
by a tor op 09 Mar '21

09 Mar '21

Hello I was thinking of perhaps asking and checking if the list has some comments on thoughts I have. I'm attaching a picture, hope that's not a problem, guess it's better than providing a URL to a file upload place (or maybe that's ok too?). I've been running a TOR bridge node for some years and need to rebuild/move it. For some time I wasn't sure how useful it was, whether or not it contributed in a useful way and I don't think it still has all the flags it could/should have? So, for you around here with an even deeper experience of the network, looking at the stats, are there any particular insights that can be drawn from there? Is it a useful bridge, stats that could or should look differently, anything else? BTW, there's a huge spike in connections on 9 Aug -20 (and there's been similar occasions earlier too) does that coincide with known attacks on the network or what? I guess, should I want to continue providing service, that it's useful or possibly preferred to move over the keys/config (?) to indicate same admin (and for users if there's no noticeable interruption the move won't even be noticed I suppose). TIA, a tor op

4 4

Bridge operator iat_mode setting
by torjoy 04 Mar '21

04 Mar '21

Hi All, I work with time and frequency references and run some tor bridges. What is the objective of "iat_mode" setting? Is an good timming reference important for this setting? For now, i'm adminstrating 3 briges, one with iat_mode=0, iat_mode=1 and iat_mode=2. Could you explain or forward me to some reading about it? Best regards, Luiz Sent with [ProtonMail](https://protonmail.com) Secure Email.

9 14

difficulty installing
by potlatch 03 Mar '21

03 Mar '21

I've been deploying Tor nodes for over a decade--maybe several dozen or more. I still have ten nodes operating in six developing or smaller countries. Many are exits. Recently, I leased a VPS in a Eastern European country with permission to use it as an exit relay. This brought back some bad memories of a year ago when I last tried to make the Tor software function. The problems then are the problems I have now. I'm disappointed by the state of the installation packages and documentation these days (since a year ago at least). Tor won't start after the initialization message. But it displays 'If you do want to run an exit Relay, please set the ExitRelay option to 1 to disable this warning, and for forward compatibility'. Where the hell is the Exit Relay option? Then there is the issue of not being able to acquire the Tor keys or for the VPS to find the key-ring. Another message: 'The repository '[https://deb.torproject.org/torproject.org](https://ded.torproject.org/torpr… stretch InRelease' is not signed. Data from such a repository can't be authenticated and is therefore potentially dangerous to use.' So, is it just that the documentation is messed up or has everyone given up on the Tor project? Nyx has never completely worked for me. Never with a local config file. I think there are some python utilities that need to be installed to make it work. I never asked but no one ever offered. The documentation is silent regarding this point. The old ARM software would give me an idea of how many file descriptors I was using and if I had provided enough. Arm also filled in the users list with column information instead of providing mostly ????. I donate regularly to Tor, EFF and Riseup. It's what I believe in. Does Tor need some volunteer help? I can only code python--would that help? potlatch in WA State Sent with [ProtonMail](https://protonmail.com) Secure Email.

3 2

IPv6 auto-discovery vs. privacy extensions
by Onion Operator 01 Mar '21

01 Mar '21

Saluton, My relay started to log this message since 0.4.5.5: Auto-discovered IPv6 address [...]:443 has not been found reachable. However, IPv4 address is reachable. Publishing server descriptor without IPv6 address. [2 similar message(s) suppressed in last 2400 seconds] I think it started with the introduction of IPv6 auto-discovery. The problem, as I understand it, is that my relay has IPv6 privacy extensions enabled and therefore the IPv6 detection logic gets fooled. Indeed the IPv6 I see in the logs is one of the temporary addresses used as client towards other relays. Relevant config is: ORPort 443 IPv4Only ORPort [...]:443 IPv6Only I added the IPv{4,6}Only options only in searching a solution to this problem, before 0.4.5.5 the IPv6 relay worked perfectly without. In reading the documentation of AddressDisableIPv6 I got the impression that if (any?) ORPort is configured with IPv4Only the IPv6 auto-discovery gets disabled but evidence does not support my understanding. Is it a bug? Any other way to disable IPv6 auto-discovery? -- flev

4 4

Re: [tor-relays] bug message from 02/28/2020 on 4.5.6
by William Kane 01 Mar '21

01 Mar '21

Hi Matt, this is non fatal and as you can see by the most recent log entries, you could ignore it - anyway, some contributor warned about this occurring with more recent tor builds since the way tor probes for listening sockets has changed / it now always binds to all IPv4 & IPv6 addresses and then does reachability checks for each? It was something along the lines of that. What if you manually specify your listening IP addresses and port like I do: ORPort 37.157.195.83:38619 ORPort [2a02:2b88:2:1::3239:0]:38619 This should satisfy tor, at least it does on 0.4.4.6 which is the newest version available through the official ArchLinux repositories, not sure about 0.4.5.x branch which states the following in it's change log: This release series introduces significant improvements in relay (IPv6) address discovery. That would be much safer and cleaner than tor trying to guess which addresses it's supposed to bind to anyway :-) Thank you for running a relay! Best Regards, William 2021-03-01 12:49 GMT, William Kane <ttallink(a)googlemail.com>: > Hi Matt, > > this is non fatal and as you can see by the most recent log entries, > you could ignore it - anyway, some contributor warned about this > occurring with more recent tor builds since the way tor probes for > listening sockets has changed / it now always binds to all IPv4 and > IPv6 addresses an does reachability checks for each? > > It was something along the lines of that. > > What if you manually specify your listening IP addresses and port like I > do: > > ORPort 37.157.195.83:38619 > ORPort [2a02:2b88:2:1::3239:0]:38619 > > This should satisfy tor, at least it does on 0.4.4.6 which is the > newest version available through the official ArchLinux repositories, > not sure about 0.4.5.x branch which states the following in it's > changelog: > > This release series introduces significant improvements in relay > (IPv6) address discovery. > > That would be much safer and cleaner than tor trying to guess which > addresses it's supposed to bind to anyway :-) > > Hope I helped, > William > > > > 2021-02-28 15:28 GMT, tor <tor(a)kevinandmatt.com>: >> Hi All, >> This popped up today after running successfully for about a week. >> -matt >> >> >> x 09:32:50 [NOTICE] Self-testing indicates your ORPort *.*.*.*:443 is >> reachable from the outside. Excellent. Publishing server descriptor. >> x 09:32:50 [NOTICE] Now checking whether IPv4 ORPort *.*.*.* :443 is >> reachable... (this may take up to 20 minutes -- look for log messages >> indicating success) >> x 09:32:26 [NOTICE] External address seen and suggested by a directory >> authority: *.*.*.* >> x 09:30:52 [NOTICE] Bootstrapped 100% (done): Done >> x 09:30:52 [NOTICE] Bootstrapped 95% (circuit_create): Establishing a >> Tor >> circuit >> x 09:30:52 [NOTICE] Bootstrapped 90% (ap_handshake_done): Handshake >> finished with a relay to build circuits >> x 09:30:52 [NOTICE] Bootstrapped 89% (ap_handshake): Finishing handshake >> with a relay to build circuits >> x 09:30:52 [NOTICE] Bootstrapped 85% (ap_conn_done): Connected to a >> relay >> to build circuits >> x 09:30:52 [NOTICE] Bootstrapped 80% (ap_conn): Connecting to a relay to >> build circuits >> x 09:30:52 [NOTICE] Bootstrapped 75% (enough_dirinfo): Loaded enough >> directory info to build circuits >> x 09:30:51 [NOTICE] Bootstrapped 68% (loading_descriptors): Loading >> relay >> descriptors >> x 09:30:51 [NOTICE] Bootstrapped 63% (loading_descriptors): Loading >> relay >> descriptors >> x 09:30:51 [NOTICE] Bootstrapped 55% (loading_descriptors): Loading >> relay >> descriptors >> x 09:30:50 [NOTICE] Bootstrapped 50% (loading_descriptors): Loading >> relay >> descriptors >> x 09:30:50 [NOTICE] Bootstrapped 45% (requesting_descriptors): Asking >> for >> relay descriptors >> x 09:30:50 [NOTICE] Bootstrapped 15% (handshake_done): Handshake with a >> relay done >> x 09:30:50 [NOTICE] Bootstrapped 14% (handshake): Handshaking with a >> relay >> x 09:30:50 [WARN] Bug: >> /usr/lib/aarch64-linux-gnu/libevent-2.1.so.6(+0x21a10) [0xffff8575ba10] >> (on >> Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(+0x81854) [0xaaaae3745854] (on Tor >> 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(+0x21419c) [0xaaaae38d819c] (on Tor >> 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(consider_publishable_server+0x5c) >> [0xaaaae377099c] (on Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(router_rebuild_descriptor+0x90) >> [0xaaaae3770588] (on Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(router_build_fresh_descriptor+0x44) >> [0xaaaae377016c] (on Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(+0xabaa0) [0xaaaae376faa0] (on Tor >> 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(relay_addr_learn_from_dirauth+0x1a8) >> [0xaaaae38d6bb0] (on Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(tor_bug_occurred_+0x164) >> [0xaaaae37c15dc] (on Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: /usr/bin/tor(log_backtrace_impl+0x68) >> [0xaaaae37b5fc0] (on Tor 0.4.5.6 ) >> x 09:30:50 [WARN] Bug: Tor 0.4.5.6: Non-fatal assertion !(!ei) failed in >> relay_addr_learn_from_dirauth at >> ../src/feature/relay/relay_find_addr.c:235. Stack trace: (on Tor 0.4.5.6 >> ) >> x 09:30:50 [WARN] tor_bug_occurred_(): Bug: >> ../src/feature/relay/relay_find_addr.c:235: >> relay_addr_learn_from_dirauth: >> Non-fatal assertion !(!ei) failed. (on Tor 0.4.5.6 ) >> x 09:30:50 [NOTICE] Unable to find IPv4 address for ORPort 443. You >> might >> want to specify IPv4Only to it or set an explicit address or set Address. >> x 09:30:50 [NOTICE] Opened Control listener connection (ready) on >> /run/tor/control >> qj 09:30:50 [NOTICE] Opening Control listener on /run/tor/control >> >

1 0

bug message from 02/28/2020 on 4.5.6
by tor 28 Feb '21

28 Feb '21

Hi All, This popped up today after running successfully for about a week. -matt x 09:32:50 [NOTICE] Self-testing indicates your ORPort *.*.*.*:443 is reachable from the outside. Excellent. Publishing server descriptor. x 09:32:50 [NOTICE] Now checking whether IPv4 ORPort *.*.*.* :443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) x 09:32:26 [NOTICE] External address seen and suggested by a directory authority: *.*.*.* x 09:30:52 [NOTICE] Bootstrapped 100% (done): Done x 09:30:52 [NOTICE] Bootstrapped 95% (circuit_create): Establishing a Tor circuit x 09:30:52 [NOTICE] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits x 09:30:52 [NOTICE] Bootstrapped 89% (ap_handshake): Finishing handshake with a relay to build circuits x 09:30:52 [NOTICE] Bootstrapped 85% (ap_conn_done): Connected to a relay to build circuits x 09:30:52 [NOTICE] Bootstrapped 80% (ap_conn): Connecting to a relay to build circuits x 09:30:52 [NOTICE] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits x 09:30:51 [NOTICE] Bootstrapped 68% (loading_descriptors): Loading relay descriptors x 09:30:51 [NOTICE] Bootstrapped 63% (loading_descriptors): Loading relay descriptors x 09:30:51 [NOTICE] Bootstrapped 55% (loading_descriptors): Loading relay descriptors x 09:30:50 [NOTICE] Bootstrapped 50% (loading_descriptors): Loading relay descriptors x 09:30:50 [NOTICE] Bootstrapped 45% (requesting_descriptors): Asking for relay descriptors x 09:30:50 [NOTICE] Bootstrapped 15% (handshake_done): Handshake with a relay done x 09:30:50 [NOTICE] Bootstrapped 14% (handshake): Handshaking with a relay x 09:30:50 [WARN] Bug: /usr/lib/aarch64-linux-gnu/libevent-2.1.so.6(+0x21a10) [0xffff8575ba10] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(+0x81854) [0xaaaae3745854] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(+0x21419c) [0xaaaae38d819c] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(consider_publishable_server+0x5c) [0xaaaae377099c] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(router_rebuild_descriptor+0x90) [0xaaaae3770588] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(router_build_fresh_descriptor+0x44) [0xaaaae377016c] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(+0xabaa0) [0xaaaae376faa0] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(relay_addr_learn_from_dirauth+0x1a8) [0xaaaae38d6bb0] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(tor_bug_occurred_+0x164) [0xaaaae37c15dc] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: /usr/bin/tor(log_backtrace_impl+0x68) [0xaaaae37b5fc0] (on Tor 0.4.5.6 ) x 09:30:50 [WARN] Bug: Tor 0.4.5.6: Non-fatal assertion !(!ei) failed in relay_addr_learn_from_dirauth at ../src/feature/relay/relay_find_addr.c:235. Stack trace: (on Tor 0.4.5.6 ) x 09:30:50 [WARN] tor_bug_occurred_(): Bug: ../src/feature/relay/relay_find_addr.c:235: relay_addr_learn_from_dirauth: Non-fatal assertion !(!ei) failed. (on Tor 0.4.5.6 ) x 09:30:50 [NOTICE] Unable to find IPv4 address for ORPort 443. You might want to specify IPv4Only to it or set an explicit address or set Address. x 09:30:50 [NOTICE] Opened Control listener connection (ready) on /run/tor/control qj 09:30:50 [NOTICE] Opening Control listener on /run/tor/control

1 0