- tor-dev - lists.torproject.org

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

03 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 29 Jan '18

29 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 29 Jan '18

29 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

trac component for check.tpo?
by nusenu 26 Jan '18

26 Jan '18

what is the correct trac component to report that check.tpo is down? Webpages/Website? http://downforeveryoneorjustme.com/check.torproject.org -- https://mastodon.social/@nusenu twitter: @nusenu_

2 1

Re: [tor-dev] Marker branch for current tor release(s)
by teor 25 Jan '18

25 Jan '18

Hi, Tor branches are a question for tor-dev@, I am directing all responses there. Also, I fixed the top-post. > On Jan 5, 2018 00:48, "Andreas Krey" <a.krey(a)gmx.de> wrote: > > https://www.torproject.org/download/download.html.en in the source code 'tab' > states the current stable and alpha version of tor. > > Would it be possible to publish the current states as branches 'stable' and > 'alpha' (or 'testing', or 'unstable') in the git repo? What do you mean by "alpha" and "stable" ? When tor 0.3.2.9 is released next week, there will be no alpha version. When this happens, do you want master, or the latest stable? When there are multiple supported tor versions, which one should be stable? At the moment, we support 0.2.5 and 0.2.9 as long-term support, and 0.3.0 and 0.3.1 as regular releases. Should stable be 0.3.1 (and change to 0.3.2 next week)? Do you want a long-term support branch as well? Should it be 0.2.5 or 0.2.9? > That would help us tor-from-source builders to just fetch the repo, and > if the respective branch changes, to rebuild and redeploy. Looking for a > new release tag or screen-scraping said web page is a bit hairy, and feels > unnecessary. If you want something that's easier to scrape, and signed, check for new source releases at: https://dist.torproject.org/ We provide the latest Tor Browser version through a URL (which I can't remember right now). Maybe we could do the same thing with Tor. > On 5 Jan 2018, at 23:17, Chad MILLER <chad(a)cornsilk.net> wrote: > > I second this. > > There's a recommended-versions list in the consensus, but you have to already have Tor available and running to get it. No, you don't need Tor: $ curl http://197.231.221.211:9030/tor/status-vote/current/consensus-microdesc | grep server-versions | tr "," "\n" | tail -1 0.3.2.8-rc Or you can do this far more reliably in Python using stem: https://stem.torproject.org/ > Maybe also publish in a DNS TXT record or something? Is that secure? Can you sign a TXT record? T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------

4 7