- tor-dev - lists.torproject.org

Re: [tor-dev] Proposal: only parse .torrc files in torrc.d directory
by iry 05 Feb '18

05 Feb '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi teor! > Could you please look at existing .d folders of any other projects > tell me what you think? Perhaps discuss this with Tor Project. > [...] From my quick search, it appears that the Debian feature > request is still open, and no other distro is using torrc.d yet. > But you should check, too. I went through all Tor packages listed here: https://trac.torproject.org/projects/tor/wiki/doc/packages and no distros shipped a torrc with %include line enabled. I know Whonix will not use torrc.d before next stable version. I also did a grep -r -i "%include" on Tails source code and I do not think Tails has enabled it by default. nickm suggested proposed to create a new syntax to take care of the compatibility: > %include /etc/torrc.d/*.conf Here is my thoughts on this: 1. I agree that "[a]nybody who currently has a working setup will have it fail if we start requiring a suffix that they didn't know to provide", which is not good for compatibility. But, letting people still use or will be able to use a setting that is not recommended anymore seems also not to be a very good idea? Considering the potential danger of parsing all the files, shall we go a little bit aggressive? I would rather break people's current potentially dangerous settings. What do you think? 2. Since no distros I know has enabled this feature by default, I guess there are only a very small number of users has enabled this feature. Will an info in the release note saying "%include /etc/torrc.d/ will only pase files suffixed with .torrc files" be enough to inform them? Maybe we can even document the manual migration somewhere. 3. %include /etc/torrc.d/*.conf syntax is very flexible so that Tor does not have to decide which extension names should be parsed. 4. %include /etc/torrc.d/*.conf syntax explicitly says which extension name will be used rather than the implicit document. 5. But is it a good idea to make the syntax that flexible? For example, anon-connection-wizard will generate a torrc files in torrc.d directory, I (and maybe many other developers) prefer writing to a file that I can guarantee it will be parsed in most case. If I write to 40_anon-connection-wizard.conf but some people set to pase .torrc or anything else only, it will be not be very good? (I do not want anon-connection-wizard to touch /etc/tor/torrc) Finally, do you think it is a good idea to switch to the ticket for further discussion to avoid cross posting and high volume on @tor-dev? Thank you very much! Best Regards, iry -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEzKSpZKlpRovTotu+oUtNvG3N1TwFAlp4pFoACgkQoUtNvG3N 1TwSkRAAnBRytWCeP8ocCOJ0FmJZVq4ANznDWWBoYg+iaRPUMYbU/Tro0j7ljJMe snf0ji+Eu8DqTjg/HgmQ9gVuiJNWE7jfvnaAE7nDxeqd23J68ek5yHeIwonnaVPq IrWeCQDAAUUz42rAcoHBsy/tGS/kiq0OMf3yf6Pzq02UsQ4Ob46kD4ySNnirRXce a/mJG1zMXoAYnM84bKnm6bD4Gx5qiyK+O61e70z4b4ArPqRpxmfQoU5RAELMHAFU hq9JtdxN/FBvNq7NUOboAYcX1FdkWLLEaQXWB/sgtS94OvCIX0hfrtis0/UFPTe5 wQN1FQCFBpPkHOLuvszNln9WvPf0XSWqCDVdZh7Fd9GrELfrVwEJYC2+1rukPWZq U0ZJ0smDkdijHBc53i6+23175GyaQ+uMoSebouQ2vh9hbf2qx1EMnSFc5pSz8y5b eJgUA6WFZvcTgUFmwYpe3X2E3QcoYHD8UNoBZiD0ehXrWTcxScT0kWNcF06v3dhr 4Doo9wxDmF/ZusRrpyTRCZ5LsPCCL1spphxNqlCIm9MsfUCHBUbULBKn+uV2fNb6 4Xk2gu6eA258ZEfYDhottLpsk8V15Jx7F+Jz/W0zlL5OCwDzhPcG44C7OfEzeW5u h42Jw6YsQkAgGXnKzRG9lW7emVkLLhF0wlCSeWY8QxHGnxShdLY= =EnSw -----END PGP SIGNATURE-----

2 1

onionoo: varnish 503
by nusenu 05 Feb '18

05 Feb '18

https://onionoo.torproject.org/details?search=123 > Error 503 Backend fetch failed > > Backend fetch failed > Guru Meditation: > Varnish cache server thanks for having a look -- https://mastodon.social/@nusenu twitter: @nusenu_

2 1

Re: [tor-dev] Proposal: only parse .torrc files in torrc.d directory
by iry 04 Feb '18

04 Feb '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > To be more precise, most tools accept files ending in ".conf". We > might want tor to accept ".conf" for consistency. > > I suggest we also accept files called "torrc", or ending in > ".torrc". This should probably also include files called literally > ".torrc". > Thank you for your suggestions, teor! I have updated it in the ticket. > Since this is a breaking change, we might want to check if any > distribution has adopted another naming scheme, and avoid breaking > that naming schem I agree. I will wait for a little bit before implementing it so that we may get more input on the issue. :) > If you'd like your patch to be reviewed quickly: * put the ticket > in 0.3.3, because it's a bugfix * change the status to "needs > review" once you have a patch Thank you so much for your instructions! Best Regards, iry -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEzKSpZKlpRovTotu+oUtNvG3N1TwFAlp3dnwACgkQoUtNvG3N 1TycXQ//X5m4c9gucDY2idIHULxzIDdfgAFnPOyjzyqDLjM8y4/Uu/3xV4SX3gX8 M2qguNmqMX2+OuoWTHPo+4S+L4qS12XibUha1lwcWxjXGyPkZ7iwIvj7a0RoBsb1 Ln6DcpBGcPt61trQg4eBLI2JbAOQRXh3J/jl9djNzs64uj/0WtxXcUhBDPiJyPz1 yunB8EuO3NJIZ9n1SoT6d9HpF8oLPu4E9PkhFi0uflPKdZhwAUqCLW4J4zqlK2eB 8cQezMHvqNmTYS9pmQgw6lz0xAL+6NQZWUeFLFE+TvIqB8RwFQkAcb3mfTfDFvpf K/tOiSF+9OvMEVonB1efWUhaxSBHc8MwQFfWaWTNNndHkO6lVGYtwPC7UfrteTY5 cr0oB6xE5U+La/2GnwP5i2200v0IgNi1S82okXIbGbMyEgEXzkC4+6xIsq40ksGy 8hRHEusLz8FUefKioxdiyPmHZgrq1jzQGSgFQKafKLR0YkfFgnbIX1alMgVIatS0 xbr53GXtQVY658T/lAdXSIqwb5regJ9NB/+LtB7HvzFbFMCnT4g1yDYLSsiwWX/z 2KJH8+OOKy6WMRmoTbMXb1J+WnBTVfazUc+fOs4IK2tlnMDs7TukcS9FtNHS1G1d AlgML+AfnuO3m8SKR1Vsbl5PRypA7Vz0a4kkzy1dLgpaqVxP6Rw= =vdE1 -----END PGP SIGNATURE-----

2 1

onionoo.tpo stuck at 2018-01-21 22:00
by nusenu 04 Feb '18

04 Feb '18

Hi Karsten, just wanted to let you know that the delta between relays_published and current time is unusually high. https://onionoo.torproject.org/details?limit=0 {"version":"5.0", "build_revision":"0bce98a", "relays_published":"2018-01-21 22:00:00", This is currently blocking ornetradar reports. thanks for having a look, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

2 11

Re: [tor-dev] Proposal: only parse .torrc files in torrc.d directory
by iry 04 Feb '18

04 Feb '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> Therefore, may I propose to let Tor parse only the files whose >> name ends with .torrc ? > > Yes, this is standard behaviour among many tools. > >> Or maybe even only parse number_filename.torrc for better >> consistency and for more clear priority order? > > No, this is counter-intuitive. It will confuse many users. It is > not how most other tools work. Thank you so much for the feedback, teor! I have opened the ticket #25140 for this. Shall I try to make a patch on this? Or is it preferred to leave it to developers from TPO? Thank you very much! Best Regards, iry -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEzKSpZKlpRovTotu+oUtNvG3N1TwFAlp2hnAACgkQoUtNvG3N 1Tz3GBAAghKBKm7JVd5PyO7HGBClshO/fUOG2ippVm5hY9sgmzVPxVauJC+CWJN9 RH6YfJwyLJeAHu0o3YD1+LBHvccxTKKQYL48q8aopfWkh8ALk4h9+O5hwpPPIsGC qV7iJ+v4QfpxYkhAUFh8FOy+m5WqsOurScBzcjEnmu2IpIkpnwv1NKLaVrArpMv9 lrGtQds/7dCYC57boSUNgTTJtbuqgNhRBM1oqkGisHsKBiLYExvztS22aLj9uVEX km5c+JJuwEKuuordP4YiFMdES1UYx9Bdm/LrUNWG4dB/ZfjwZYSu/KPsqQcDwmNy 25iovL5KUkVg8S05QwdcCnXm2B5oofLMJ4hW0bkjozjLUt3na131uJumOR7Q2W9f 9aKAGwRzQ624rDHn3SWCC1HKMhP0Y6EhCDyzX5914kRakikas6hmtUWmrSqFvZLO p0WzWuNB05BdRXImTXxPdLyOxasB/eMt31mQXKBSSiwdzJxe3rfnDb//P2vcv9ex ofQNx672qtAgmHp9WWeKY6qas36sZeckEigIlcUN27KFBwDyCGfCebk5tPIGDzC9 aAqmiTqqYCqphHb3i/xX3WwGwk6+Q1ixezOfYFxbAOa96NUDV2ldYIXgBcsAWh/+ RbZ8hI/oOwAug/C9ig5xFpZAy86bbqDApG6wrGNg5gp3qVKDlnA= =zlMh -----END PGP SIGNATURE-----

2 1

Proposal: only parse .torrc files in torrc.d directory
by iry 03 Feb '18

03 Feb '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Dear Tor Developers, I have been testing and using the torrc.d feature for a while, and here is a potential improvement we may make. Currently, when using a torrc.d directory, for example: > %include /etc/torrc.d/ Every file in the directory will be treated and parsed as a valid Tor configuration file. However, sometime, this may not be what users and developers want. For example, users may use /etc/torrc.d/50_user.torrc as the place to put their own torrc configurations. But sometimes, when they use a text editor to edit it, the text editor will leave a /etc/torrc.d/50_user.torrc~ file which will also be treated as a valid torrc file. Another example that also happens very frequently is, when dpkg does an update on /etc/torrc.d/30_distribution.torrc, users' previous configuration can be saved as /etc/torrc.d/30_distribution.torrc.dpkg-old which will also be parsed by Tor. In best case users will just be frustrated because Tor does not work as expected and in worst case this could be dangerous. This could be a severe problem especially because of the following reasons: 1. filename.torrc~ filename.torrc.dpkg-old has higher priority than filename.torrc when Tor does the parsing. 2. In most cases, this will happen without being noticed by the normal suer. Therefore, may I propose to let Tor parse only the files whose name ends with .torrc ? Or maybe even only parse number_filename.torrc for better consistency and for more clear priority order? Thank you very much! Looking forward to hearing your insights! Best Regards, iry -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEzKSpZKlpRovTotu+oUtNvG3N1TwFAlp2Oa0ACgkQoUtNvG3N 1TxfBA/9FfFhBfI08ocI6Wluodg58lppbG+N1LOGxoTSH2iq53P7GaWvZd9OULP1 ezTDbnlPJ3jreBYRnze8/MaUFA/x6wJTAcyM71xktwuR1Np47StY8ishZnbLpI5z D7r65kKZyxrcCht99oSOFuqakVb0bFJJJRF1rvgt9gDHZT9+0V1/GVAv0w1SEb7J LYazQyjtIgCJQaDdZvRsulnlBuFF6KvVNZp4EEKfggihM480SJV1gRExDBrEYQEN BqtYixEe2P2MHPZSV7Szp28D87I391GwrHuLGsrlhL92OPPygVlc+Amyw9rEMij4 y/sXlSN+62Q2UV2CvFGzxSJBNhstJ4Meh91yKDf+Lm0CER5ydEUWtLJLYaIGmjS/ iQNQUd/6Y2dIyzeZuXFm03cfIXtQNdQFAhahNvNEeUOcJ4Qk4IsHXUi7MSzHcQTb lv0E/2IzleXWp57L9rDPayA7eUpNMHlZkVyH42WunGcK+uz6PIT/bvBc5L1b/z3/ zkaPleDivBV5czlBtQIwRURibbUuveDtGfacM/3pmQ5XuYYaA6UvRExHePMeQvM+ Y01YTMlEcqL4LcjHSJiGamdWRPtGazbXVT1bl4VRJ1RqGqrvFE65I+xdg01UnSWy tgsOUhEwrMUxUdsumNpb6sEgpUmZ/NzKbi7zgGywEmxVkUN67lc= =zue4 -----END PGP SIGNATURE-----

2 1

Re: [tor-dev] No Control Socket when DisableNetwork 1
by iry 03 Feb '18

03 Feb '18

> My first suggestion would be > [...] > My second suggestion would be to get a Tor binary and run it yourself, > not as part of a package. If it works there, then you know that your > next steps are to figure out why your package isn't working for you Hi Yawning and Roger! Thank you so much for trying to reproduce the bug and teaching me on the generic Tor debugging steps! I agree with you that: > If you can get a minimal case reproducing the bug without a package, > systemd, etc, in the picture, that's a great time to file a trac ticket. It turns out, to successfully reproduce this, we need: 0. set DisableNetwork to 1 1. use User option as part of the Tor configuration 2. run sudo Tor from a different user in a different group Here are the specific steps to reproduce it. I tested it on Debian Stretch but it should be distribution independent: user@host:~$ cat /home/user/my.torrc DataDirectory /tmp/tor ControlSocket /tmp/tor/control.sock ControlSocketsGroupWritable 1 CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /tmp/tor/control.authcookie SocksPort unix:/tmp/tor/socks.sock user@host:~$ sudo /usr/bin/install -Z \ -m 02755 -o debian-tor \ -g debian-tor -d /tmp/tor user@host:~$ ls -ld /tmp/tor/; ls -l /tmp/tor/ drwxr-s--- 2 debian-tor debian-tor 40 Feb 3 18:19 /tmp/tor/ total 0 user@host:~$ sudo /usr/bin/tor \ -f /home/user/my.torrc \ --User debian-tor \ --DisableNetwork 1 There should be control.sock, but not: user@host:~$ ls -ld /tmp/tor/; sudo ls -l /tmp/tor/ drwx--S--- 2 debian-tor debian-tor 100 Feb 3 20:00 /tmp/tor/ total 8 -rw-r----- 1 debian-tor debian-tor 32 Feb 3 20:00 control.authcookie -rw------- 1 debian-tor debian-tor 0 Feb 3 20:00 lock -rw------- 1 debian-tor debian-tor 215 Feb 3 20:00 state To let Tor really open the control.sock, we need to reload Tor (yes, even though we just start it): user@host:~$ ps -A | grep tor 863 ? 00:00:00 xenstore-watch 927 ? 00:00:04 tor-controlport 11851 pts/0 00:00:00 tor user@host:~$ sudo /bin/kill -HUP 11851 user@host:~$ ls -ld /tmp/tor/; sudo ls -l /tmp/tor/ drwx--S--- 2 debian-tor debian-tor 120 Feb 3 20:01 /tmp/tor/ total 8 -rw-r----- 1 debian-tor debian-tor 32 Feb 3 20:01 control.authcookie srw-rw---- 1 debian-tor debian-tor 0 Feb 3 20:01 control.sock -rw------- 1 debian-tor debian-tor 0 Feb 3 20:01 lock -rw------- 1 debian-tor debian-tor 215 Feb 3 20:01 state I guess the reason Yawning was not able to reproduce it is because User option was not set: user@host:~$ sudo -u debian-tor \ /usr/bin/tor -f /home/user/my.torrc \ --DisableNetwork 1 [notice] Opening Control listener on /tmp/tor/control.sock I was thinking Tor fixing /tmp/tor/ to 2700 may be the reason, but then I cannot explain why this will work with /tmp/tor/ set to 2700: user@host:~$ sudo /usr/bin/tor \ -f /home/user/my.torrc \ --User debian-tor \ --DisableNetwork 0 [notice] Opening Control listener on /tmp/tor/control.sock Would you please share some insights on the this? For temporary workaround using systemd in Debian, I put this line in the [Service] section of /lib/systemd/system/tor(a)default.service : ExecStartPost=/bin/kill -HUP ${MAINPID} Best Regards, iry

1 0

small fixes for the sources.list generator (and new options)
by nusenu 03 Feb '18

03 Feb '18

Hi, since the tor relay guide depends on that page and it has a few issues I made some small fixes to it: https://www.torproject.org/docs/debian.html.en Bug 25107: sources.list generator: remove yakkety (we do not offer packages for it) Bug 25107: sources.list generator: add Ubuntu Artful Aardvark (17.10) Bug 25107: sources.list generator: remove zesty (we do not offer packages for it) Bug 25107: sources.list generator: add nightly-master option Bug 24994: point to the actual content describing alpha/stable differences Bug 25107: sources.list generator: update tor alpha version to 0.3.3.x Bug 25107: Update the tor alpha version (noscript page version) Bug 25107: fix sources.list generator for Debian Buster If someone with commit privileges has time to review and merge before the weekend that would be great. https://github.com/nusenu/torproject-webwml/tree/debian_sources.list_genera… Note: I did not care about the "(from source)" option. -- https://mastodon.social/@nusenu twitter: @nusenu_

2 3

stem support for v3 ephemeral onion services
by Micah Lee 31 Jan '18

31 Jan '18

Now that Tor Browser 7.5 is released and includes the tor 0.3.2 series, which supports next generation onion services, I would love to make OnionShare use these by default. Here is the issue [1]. OnionShare is written in python3 and relies on stem to communicate with the Tor controller. Although tor now supports v3 ephemeral onion services, stem still doesn't. Just take make sure, here's a quick test, with Tor Browser 7.5 (providing tor 0.3.2.9) open in the background, and using stem 1.6.0: == from stem.control import Controller c = Controller.from_port(port=9151) c.authenticate() tor_version = c.get_version().version_str print("Tor version: {}".format(tor_version)) print("Creating ephemeral onion service") res = c.create_ephemeral_hidden_service({ 80: 8080 }, await_publication=True, key_type='NEW', key_content='BEST') print("{}.onion".format(res.service_id)) == When executed, it still creates a v2 onion address: (env) user@dev ~/tmp $ python3 onionv3.py Tor version: 0.3.2.9 Creating ephemeral onion service wrvsjo4nlww3edsi.onion Right now OnionShare is blocked by stem supporting v3 onions. Does anyone know when we can expect support for this? [1] https://github.com/micahflee/onionshare/issues/461

4 5

Starting with contributing to Anonymous Local Count Statistics.
by Aruna Maurya 31 Jan '18

31 Jan '18

Hey! I was going through the Tor Volunteer page and came across the Anonymous local count statistics project. As a student it would be a great starting point and an even bigger opportunity to get a chance to collaborate and learn in the process. I would like to contribute to it, and would love to start as soon as possible. It would be great if someone could guide me through. Thanks for your time!! -- Regards, Aruna Maurya, CSE,B.tech, Blog <https://themindreserves.wordpress.com/> | Medium <https://medium.com/@arunamaurya>

2 1