- tor-dev - lists.torproject.org

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

website patches for new Tor relay guide sidenav entry
by nusenu 30 Jan '18

30 Jan '18

Hi Silvia, I submitted a (trivial) patch (in #24881) to add links to the new tor relay guide on the website and to remove previous guides that have been merged into the new guide. I noticed that since than new commits have been merged and these patches will probably no longer apply cleanly. I will try to ensure they apply (rebase) shortly before you have time to look at them if you can tell me approximately when that will be. thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

2 2

non-anonymous ephemeral onion services with stem
by Micah Lee 30 Jan '18

30 Jan '18

The stem documentation for create_ephemeral_hidden_service [1] says: "Changed in version 1.5.0: Added support for non-anonymous services." But I can't figure out to actually use this feature. There doesn't seem to be a new argument to say if you want your onion service to be non-anonymous. It also says, "Changed in version 1.5.0: Added the basic_auth argument." But there's a new basic_auth argument you can pass into the function to use that. [1] https://stem.torproject.org/api/control.html#stem.control.Controller.create…

5 12