Re: [tor-dev] The Tor project as a GSoC voucher for Whonix?
Damian Johnson: > Thanks teor! Quite side note: it would be helpful if such questions > are broached earlier in the process. Google has been calling for org > applications for several weeks now. Asking roughly a day before the > deadline creates last minute confusion and reduces the chances of an > affirmative response. > > On Tue, Feb 5, 2019 at 8:06 AM teor wrote: >> >> Dear Whonix Community, >> >> On February 5, 2019 2:20:18 PM UTC, iry wrote: >>> >>> >>> teor: >>>> Dear Whonix Community, >>>> >>>> On February 4, 2019 11:52:44 PM UTC, iry wrote: >>>> Dear Tor Developers, >>>> >>>> Whonix is applying to be a Google Summer of Code organization this >>>> year. I am writing on behalf of Whonix to ask if the Tor project >>>> could be a voucher for Whonix. Specifically, in the application >>>> form, it asks: >>>> >>>>>>> If you are a new organization to GSoC, is there a Google >>>>>>> employee or previously participating organization who will >>>>>>> vouch for you? If so, please enter their name, contact email, >>>>>>> and relationship to your organization. >>>> >>>> Whonix community would be really appreciated if Tor can be our >>>> voucher this year. And please feel free to contact me to provide >>>> the information described above anytime before the deadline >>>> (February 6, 2019 at 20:00 UTC). >>>> >>>> Thank you very much! >>>> >>>> Cheers, iry >>>> >>>> I have forwarded your request to the Tor Core Contributors. >>>> >>>> Some of us were at a hackfest and FOSDEM last week. A few are still >>>> working or travelling. So I am not sure how many of us will check >>>> our emails in the next 36 hours. >>>> >>>> I hope we will have a response for you around 24 hours from now. >>>> >>> >>> Thank you so much for your help, teor! >>> >>> We really appreciate it! >> >> Tor won't be able to vouch for Whonix for GSoC 2019. I understand that you >> are on a tight deadline, so I wanted to let you know as soon as possible. >> >> I have received a range of responses from Tor Core Contributors over the >> past few hours. A number of people raised concerns about the Whonix >> community's culture, and whether it would be a good experience for students. >> >> I hope that we can give a more detailed and helpful response later. But it >> may take us some time, because we are still working through our internal >> community processes. >> >> T >> >> -- >> teor Thank you for your response, teor and Damian! I agree it would be better to ask earlier and I will remember that! iry ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] permission denied when running snowflake-client with debian-tor user
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Tor developers, I met a problem when trying to use the snowflake-client binary extracted from TBB 8.0a8 with the system Tor. Specifically, it seems snowflake-client cannot be run by debian-tor user, regardless of the permissions it is given. I am posting the full steps below. A better formatted version of it can be found here: http://forums.whonix.org/t/replacing-meek-snowflake/5190/18 > Here is the original permission and ownership of snowflake-client: > > user@host:~$ ls -l snowflake-client -rwx-- 1 user user 14160744 > Jun 4 06:17 snowflake-client > > It can be executed by user user: > > user@host:~$ sudo -u user ./snowflake-client 2018/06/04 06:18:21 > > > --- Starting Snowflake Client --- 2018/06/04 06:18:21 No HTTP > signaling detected. Using manual copy-paste signaling. 2018/06/04 > 06:18:21 Waiting for a "signal" pipe... ^C > > We now change the permission to let it executable by user > debian-tor: > > user@host:~$ sudo chmod 777 snowflake-client > > > user@host:~$ sudo -u debian-tor ./snowflake-client 2018/06/04 > 06:18:43 > > Noticed the permission denied: > > --- Starting Snowflake Client --- 2018/06/04 06:18:43 No HTTP > signaling detected. Using manual copy-paste signaling. 2018/06/04 > 06:18:43 Waiting for a "signal" pipe... 2018/06/04 06:18:43 open > signal: permission denied > > We now change its ownership to debian-tor:debian-tor: > > user@host:~$ sudo chown debian-tor:debian-tor snowflake-client > user@host:~$ ls -l snowflake-client -rwxrwxrwx 1 debian-tor > debian-tor 14160744 Jun 4 06:17 snowflake-client > > Still, permission denied: > > user@host:~$ sudo -u debian-tor ./snowflake-client 2018/06/04 > 06:19:15 > > > --- Starting Snowflake Client --- 2018/06/04 06:19:15 No HTTP > signaling detected. Using manual copy-paste signaling. 2018/06/04 > 06:19:15 Waiting for a "signal" pipe... 2018/06/04 06:19:15 open > signal: permission denied > > However, when executing it by user, it works fine: > > user@host:~$ sudo -u user ./snowflake-client 2018/06/04 06:19:22 > > > --- Starting Snowflake Client --- 2018/06/04 06:19:22 No HTTP > signaling detected. Using manual copy-paste signaling. 2018/06/04 > 06:19:22 Waiting for a "signal" pipe... ^C I didn't find any special requirement for the user who runs snowflake-client from the documentation, so it would be extremely helpful and appreciated if you could share some insights on this problem. :) Best Regards, iry -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEzKSpZKlpRovTotu+oUtNvG3N1TwFAlseXpcACgkQoUtNvG3N 1Tx/fBAAvnl84inklNYJ4N0QRz9X9FAtmTlTTb4mrtW+WM36oaDEFigSZeha7pmw er+oV1hG1SlHf6iel2i6YyUXAi7r6YURqlv0fFtLMaelfAIda/ywEMwVsJ19VHzn qPPEADQVY4c55KuOgkhCMSTxGUn2wXbM+PpFf/WTaZ40gjPOjucUXUxlhwj6X6EX wTBiUEq2yjs4xyWSfgOinFuoPqLG5Hfx/z+1ZSyL2R0yeeK1kSiB5kD90mwfOeKq EM32xbYLy4OmQQ3cABHB2mn0wDaS8E2t22sHXhPNANdJTdM/ztcjI7BZjNMUz1Ig aQEVpLE2yvVQu4O3nyThLnH/b08z4a6oVVE7JQpG9rmLfoFuUbJ6vTF+l6nQTJOY mnkiL6RwGVerm612OXFOLBpHSBbToEX12tqqjC569s/OExcFzHpiiTg22HcOYab/ YSu4zUTX23wRBQhOkBQ7EL+idHGK7lwGN5d0Y45H7cwOoIXwXTu3ff1e6yjuT9Bx Pc+tlkw7vJGB5jhFuW9EYvjrWDklbpR7HZ7TTSkDvGvzXUkAZnCzyBAnePxwQbid 45Vwsn7QCFISsZdXCS53RPoVPbNGcSQTyWn4gv/U37Fb/pZ1LYYAJFcNOl5HB8fl nhXL9D7Mey/79n3hepChBUXpaNeHX9J+7R91A8tUjzz9irmhU8o= =Aie4 -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal: only parse .torrc files in torrc.d directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Thank you so much for the immediate feedback, teor! Could you please help me to review the requirements (TODO list) below: * %include /etc/torrc.d means parsing all the files in the directory * implement %include /etc/torrc.d/*.extension syntax * let Tor log each config file it loads * warn on potentially unexpected files * document *.conf as the recommend usage * document how to manually migrate from * to *.conf * recommend /etc/torrc.d/*.conf as "a default extension for packagers" > In my experience, mailing lists are good for discussion, trac > tickets are good for tasks, and gitlab/oniongit are good for code > review. Got it! Thank you very much! Best Regards, iry -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEzKSpZKlpRovTotu+oUtNvG3N1TwFAlp4wsIACgkQoUtNvG3N 1Tx3JA/5AXuMfqo7jww4LeRvIUfs69+Fu98MV8X1GLKaTnqDH7MnDhOW5KxUY8HU FbVK040GhV7UGMCP83fCbSnFVw4uNFMENToYVFB649Lg5/BAOzbvQ0Lc6i1B+fUt W5rq3rzJxvMSG3q8EXPgxxHWUGl2AKzGkKBeIxc4WYt1aZX9FXpbVCZn3Rnu5Gj1 OeesVXdkO0TGb0r99qEBg7CqGUUT28L8VveiJlZHyRUFpwrKdBlX8hVhpIaQYEDV 9NXMTtRd4eHUFrRs7ZINpg6LiUKcicVVOHj1p0qx1DV5T9tdXVpBemHTJQtmQAU+ 3iJgyoNHDez0WBlIwhXm0zr3QFot2/MV2D+yKAIJGwVlWOtEFnqUGyX+LwxD6XQ8 Qzj4XcOLbs+hIB6h/QPXGgQnP7seLZhJMQAReMu64uvGx+zt15Avm3DAbz5rgwnR pYQatcG/2/6sESgNz4NXjPaxz6nokylsKSMaynd1aHHzsOc3vLVWRbHbMvSoC8Mu iKeUhhg01pO6eSzAzM9tnFGb0TaSrjR5NSnq3BoFeSnPNqZdsmehBOMMFXtj68QC Dn78/gC0++W0DZONXSf2HdARwP+asNTzMnyobQHw3ikgLtCxCNjCLOTycyrCMkNS Ar8cbOEVaDG802JWUMdWnFbbE6CfNWh5egx3jSzw19NDM+qGM8E= =mJnZ -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal: only parse .torrc files in torrc.d directory
-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- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal: only parse .torrc files in torrc.d directory
-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- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal: only parse .torrc files in torrc.d directory
-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- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Proposal: only parse .torrc files in torrc.d directory
-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- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] No Control Socket when DisableNetwork 1
> 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/000: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@default.service : ExecStartPost=/bin/kill -HUP ${MAINPID} Best Regards, iry signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] No Control Socket when DisableNetwork 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Tor Developers, According to the Tor manual: https://www.torproject.org/docs/tor-manual-dev.html.en > DisableNetwork 0|1 When this option is set, we don’t listen for or > accept any connections other than controller connections, and we > close (and don’t reattempt) any outbound connections. Controllers > sometimes use this option to avoid using the network until Tor is > fully configured. (Default: 0) However, it seems when DisableNetwork is set to 1, /var/run/tor/control does not exist anymore making us cannot get a controller from socket file. (stem.control.Controller.from_socket_file() is affected in this case: https://stem.torproject.org/api/control.html#stem.control.Controller.fro m_socket_file) To reproduce this, I tested both Tor 0.3.1.9 and 0.3.2.9 on Debian Stretch: When DisableNetwork 0, run: systemctl --no-pager restart tor@default > user@host:~$ ls -l /var/run/tor/ total 1328 srw-rw 1 debian-tor > debian-tor 0 Jan 19 21:14 control -rw-r- 1 debian-tor > debian-tor 32 Jan 19 21:14 control.authcookie -rw-r- 1 > debian-tor debian-tor 1350116 Jan 19 21:14 log srw-rw-rw- 1 > debian-tor debian-tor 0 Jan 19 21:14 socks -rw-r--r-- 1 > debian-tor debian-tor 6 Jan 19 21:14 tor.pid When DisableNetwork 1, run: systemctl --no-pager restart tor@default > user@host:~$ ls -l /var/run/tor/ total 1244 -rw-r- 1 debian-tor > debian-tor 32 Jan 19 21:00 control.authcookie -rw-r- 1 > debian-tor debian-tor 1269005 Jan 19 21:00 log I searched on Tor-trac but did not find any similar report. Therefore, would you please tell me wether Tor intentionally behaves like this or this is a bug? (If this is a bug, I can definitely help to report it to Tor-trac.) Thank you so much! Best Regards, iry -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEzKSpZKlpRovTotu+oUtNvG3N1TwFAlpifX0ACgkQoUtNvG3N 1TwLsBAAn8W3H7VMwiR9UwnVJoXOZ0iWRLbF/JdtDUjXcG1/cQmK5aEHtbVCy4Jl VOWYKBJeHxZAmHlBC+ZR3E/vyDesatjPDIPvzUuwYN3T0COFpMyN71ipOjs1KqYP GFFgLFzClQHvnThe59TIEomVcdXIt9ebPU3QmVxnNhvB/KKggKOgTuYd/n8R0efe 0kAl5/8vZZv4/IiorRkF/ltQwmnOTR1V2H1OrOOHM/AyxLGfwGO9KffznRDX/BN4 AdM4MWpMh3+DKCKgJZpf3Gzwcn7d6DvL74YQVIhmwofoxEOCBD/f+iYeJKkoVPw7 Pd8YHkYvXqCRqHBFfTEe4BtZdcxK2k3FXbUcbKahFDYMtdotdzknf542f6+Bbt+p hmiuJT8bX/Kn2dBzonbqJuh2XEBA2y6OqqhJaVoJr5l6tWyghp18BsA2m6W4mg2H ApkUTv0YsQ8guXckfJP2LOhXxKWN0yncQ7bMzGZSfSwtqGwrDxFFWk2V8vXIrWWL X5pz3oObvQB9eUJcKix2C29kJSGBry68Ts1x4MnL14CDw0WqNqAqe0O3IAiCANjl CU+z9P129eb/pdYXW/OTFnVyWhQBXNvCRHTZB7Yvym+dN4B6MD3uOkH9THf9BaCF yVCOK1c04/sfqADnpE3Rhkr98iix3N2gbdOod/10T+GyG4OBh64= =Oh0M -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Feature Request: please consider ship default, Tor bridges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Roger: > On Thu, Aug 17, 2017 at 07:57:53PM +0000, iry wrote: >> Btw, Collateral Freedom seems to be one of the most effective >> ways to circumvent Internet censorship in China. Circumvention >> tools that depend on Collateral Freedom usually works fine, >> including meek, lantern, psiphon3 etc. Therefore, I see a lot of >> potential work which may benefit the Internet freedom in China. >> For example: 1. package meek into Debian 2. host (part of the) >> BridgeDB mirror on Github or AWS 3. #22402: >> https://trac.torproject.org/projects/tor/ticket/22402 > Some hopefully useful thoughts along these lines: > Hi Roger! Thank you for sharing your insights! > A) Most places around the world that need bridges these days need > pluggable transport bridges, not just vanilla bridges. So if we > want to bundle bridge addresses, we should bundle PT bridge > addresses. > I agree! This also makes me think about a small potential improvement on the design of BridgeDB web. When users click the big "Just give me some bridge" on https://bridges.torproject.org/options , they will be provided with vanilla bridges instead of obfs4 bridges. However, those users who choose not to use "Advanced Options" are most likely to be inexperienced and have no idea on what obfd4, PT etc are. Therefore, is it a good idea to provide obfs4 bridges, rather than vanilla ones, in "Just give me some bridge" for better usability and higher success rate? > B) ...and that means we need to make sure that those PTs are well > packaged in Debian too, since the Tor deb by itself would not be > able to use them. > Agreed. I can help to report a bug against obfs4proxy on Debian BTS when the idea is mature. > C) I wonder if we could use the new %include torrc directive in > this situation: https://bugs.torproject.org/1922 I don't have a say on the final decision, but this is also what I am thinking about:> 3. "Bridge" + plain text which is ready to be appended to a torrc file > or to be one of the torrc files in /etc/torrc.d/ (or whatever > torrc.d path Debain decides to use) > That is, when you apt-get install obfs4proxy, is that the right > time to populate /etc/torrc.d/obfs4-bridges with some (probably > commented out to start) lines that let you use those bridges if > you want? How about not commenting out the bridge info as the switch? Instead, user who would like to use bridge can comment out or add the following two lines in /etc/tor/torrc: #UseBridges 1 #ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy I have being considering /etc/torrc.d/ as a place to store all the available settings and considering /etc/tor/torrc as a panel that let user decide what they would like to enable and disable. But I am not sure if this is a good way to think about the relationship between /etc/tor/torrc and /etc/torrc.d/ One thing I am concerned about is, when applying the method above, how can user choose different PTs in the future? For example, when meek in packaged into Debian, the meek package will probably also have a /etc/torrc.d/meek-bridges file. Can we just choose to use obfs4 or meek in /etc/tor/torrc by switching between the following two lines? #ClientTransportPlugin obfs4 exec /usr/bin/obfs4proxy #ClientTransportPlugin meek exec /usr/bin/meek-client (I can test with that, but people who is familiar with the mechanism behind it can probably answer that.) Best, iry -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJZmHZUAAoJEKFLTbxtzdU8Y2gP+wfDoSOTprVqe4rByzHVhUup LXvy4WnfHeUq03t+H8W5QwJCPdsFssFZae/EsfUU5Q490GqhAFryi8rHmOHluSGl FmX9SIxQXT3RV7iEFN7w4qKqYHLEKrRTklWOLrDauHZe3eJEUyn49VCROtBat88Y bdnrav4D443fFD/ugk8C3K5u4oNEWgtaq9natsLkPFbXpNcB06gd/S23Vj4VsOP0 +FUmIHmtzzMk0iTAVjGrW8X/z6/lyqk6Nj/lvwfNhdIJ5gbk5F848sl71VBeK3of Q7rdCjglZ3/tPRfrE+d40cfQWmOpw7doozC7LKdDbxCtx/LJ0WFq2PvwmO+uUFOG 3QMAV0w58JWsUsLW80ifcx7T+0O7QeAMASqWqKva7d1Y2PgqNCJfDJDHOX/KuEy3 TUi8o5WkIUUtyPaMwnYXW9VkaEKIHBXxfjYBwg0llfGU9HKJmTj+yCrMMHB2t0m0 OlZUFx9E7U11mhWzGM64sICHuob8VjwsLgLPMJc1+ocDobo0HrJr1ZtWmMZScp60 SpK35EwU8jKZJTSXtI/SKtDdHGhGmxm4NvLy26TWSqHbEzlcelK+yqkifnLHr3tb we61NdV2ZA7XCrp+o3Q7NprMjRGtaP1aze2bQTjJfkLDdrShkZFw3/hYk75cRpvk tkf7Tl4oLtoa5lnNhB/S =sP5G -END PGP SIGNATURE- 0x6DCDD53C.asc Description: application/pgp-keys 0x6DCDD53C.asc.sig Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Feature Request: please consider ship default Tor bridges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 David Fifield: > On Thu, Aug 17, 2017 at 05:19:44PM +0000, iry wrote: >> A set of Tor bridges are shipped with Tor browser bundle[0], >> helping users in Tor-censored area to connection to the Tor >> network. Since system Tor users may also face the censorship >> problem, shall we ship some Tor bridges along with the tor >> package? >> >> The request is firstly reported[0] to Debian BTS and I got the >> following reply by Peter: >> >>> If upstream starts shipping bridges with their Tor releases, >>> that would naturally result in the Tor package shipping >>> bridges as well. >>> >>> I do not know whether that's a good idea or not, but I don't >>> think deviating from upstream would be particularly >>> worthwhile. > > To get an idea of how frequently the list of default bridges has > changed, see the tbb-bridges keyword in the bug tracker: > https://trac.torproject.org/projects/tor/query?keywords=~tbb-bridges ol=time=id=summary=keywords=status=1=time > > > Thank you very much for informing us the way to check default bridges' update frequency. The frequency is generally once per month while sometime three times a month. This RSS feed may be helpful to immediately inform us the new changes: https://trac.torproject.org/projects/tor/query?keywords=~tbb-bridges mat=rss=id=summary=keywords=status=time=1 =time >> The default bridge shipped with tor package should be exactly >> the same bridges contained in bridge_prefs.js[0] shipped with >> the latest stable TBB. This is because: 1. The servers hosting >> default bridges are set up for huge amount of traffic; 2. The >> servers hosting default bridges are probably audited by TPO for >> better security; 3. Using a different set of bridges will >> distinguish the anon-connection-wizard bridge users from the TBB >> bridge users, which compromises their anonymity. > > There is an argument for using a different set of default bridges: > when one of the Tor Browser ones gets blocked, it won't affect the > Debian ones. For example, for a while, Orbot had some additional > bridges that Tor Browser did not have. When the firewall of China > blocked the Tor Browser bridges, the Orbot ones continued working > for another nine months (until they got blocked for a different > reason). We know that at least China and Kazakhstan pay attention > to the default Tor Browser bridges (and China blocks them as soon > as they enter the source code, even before a release). > So having a few bridges that are not shared with Tor Browser has > that advantage, at least. Thank you for offering me the interesting information. I did not realize this advantage before. The advantages 1 and 2 which I mentioned above will still be valid as long as the bridges are TPO proved. Therefore, it sounds to be a good idea to have some unique bridges shipped with Debian Tor (if including Tor bridges is a good idea). > Of course, it's basically security by obscurity, because a censor > that can discover the Tor Browser bridges can (in theory) also > discover some other static list of bridges. But in practice it > will take censors time to build automation to read from a new list, > default bridges are security by obscurity anyway, though > surprisingly effective for that. That is true. Using security by obscurity strategy in censorship circumvention is more like a resource competition. When the adversary is a country like China, we may not be confident to win in long term. Btw, Collateral Freedom seems to be one of the most effective ways to circumvent Internet censorship in China. Circumvention tools that depend on Collateral Freedom usually works fine, including meek, lantern, psiphon3 etc. Therefore, I see a lot of potential work which may benefit the Internet freedom in China. For example: 1. package meek into Debian 2. host (part of the) BridgeDB mirror on Github or AWS 3. #22402: https://trac.torproject.org/projects/tor/ticket/22402 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJZlfU8AAoJEKFLTbxtzdU8OOoQAIv+tJcNTi6hUExD2H/e8Wh6 YICR3OwSIp6v1kYD6aXWW+sL5OQzBe4K8pJsSD6IQzukfswytGd4BuTqYj2oiZSz kBKWas9CdHF2nC3MThCL65ImSzPgg+z1hOsy1f7ur0yFh0tj7yCKaXQFQqCMOO5+ lGxMYJfjF22zIHg9j3Q/IgrMNojBOLKtFD9KLNOURA1WMJGnVzrTx4lEyw9WaKBI A/eK1ZZWpRIiEYVyvvItU+/a54ax1Pirt2G4bZVKMnmiZ4evhjU8MuTOFPYRq/YI bUe6G4YJvNgqVxj0RmSTxaJHfX2KHOUEZQMR4uhmWMVTch0093rQBk1ICJy89tyz PWZmOzyp2H8QVSPxFPR5+5xzeinLDR5FsUc3Q9XeD1MiIlSk5W+EKGfQzVHpawGq lfo8kBN+iExTx4KErJPLreqv3iol9XUQgN/kD4SjDaHlM/YXt34NpOHfdafFdqDj yAwvAeGL5gSwDiV//Mie7fB493dcssaR70kl02hM51LuNywf0mzt0iYA9pyCv9Zo vzDskzAYElIKoWQBIkt15R22uC0bG6VW/BaeHS2SXRqIDLEsaq/f46E+D/IP+8o5 kMU/M3JygjvtyM+iKbnEOvxRBVfCLL0c0rO57TOdGd5Ijmrlqcpf
[tor-dev] Feature Request: please consider ship default Tor bridges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello Tor people! A set of Tor bridges are shipped with Tor browser bundle[0], helping users in Tor-censored area to connection to the Tor network. Since system Tor users may also face the censorship problem, shall we ship some Tor bridges along with the tor package? The request is firstly reported[0] to Debian BTS and I got the following reply by Peter: > If upstream starts shipping bridges with their Tor releases, that > would naturally result in the Tor package shipping bridges as > well. > > I do not know whether that's a good idea or not, but I don't think > deviating from upstream would be particularly worthwhile. The following is some related information which may help the future discussion: The possible formats to hold those bridges can be: 1. JSON which is also the way tor-connection-wizard used so far[1]; 2. plain text which is the same formatt given by the BridgeDB[2] by Tor Project; 3. "Bridge" + plain text which is ready to be appended to a torrc file or to be one of the torrc files in /etc/torrc.d/ (or whatever torrc.d path Debain decides to use) The default bridge shipped with tor package should be exactly the same bridges contained in bridge_prefs.js[0] shipped with the latest stable TBB. This is because: 1. The servers hosting default bridges are set up for huge amount of traffic; 2. The servers hosting default bridges are probably audited by TPO for better security; 3. Using a different set of bridges will distinguish the anon-connection-wizard bridge users from the TBB bridge users, which compromises their anonymity. What do you think? Looking forward to hearing your insights! Best, iry [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872456 [1]: https://gitweb.torproject.org/builders/tor-browser-bundle.git/tree/Bundl e-Data/PTConfigs/bridge_prefs.js?h=7.5a3-linux [2]: https://github.com/irykoon/anon-connection-wizard/blob/master/usr/share/ anon-connection-wizard/bridges_default [3]: https://bridges.torproject.org/options Best, iry -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJZldAaAAoJEKFLTbxtzdU8QHEP/0DyAtD95JOKEkDulsyuuVfx uYT+5WGaRSFntqRq91RcNkHLHDy61JtLXhr5VIcz/tYIIe3TVZhI9idqbPgJMZc+ xxS/4r5qhkkcJ5X99xo7Jerz/0Y/4CKboREAkSstz15RL3FNLF6mwFZgWsiZ4rMa SkruE8qchz1KIUuWKZyx3HioloZgIHQkvqQ6fE4asGIs8gnaKeofpSwRGq85/Vcq T8D0WTqCFweLFaYzCWMtO7bVKXrfqC8rGLesLPJhxZbl0MJ3H/5TdvbPHn6VwRH0 AZCT5q7A+0fC/+HHwsn9SFhMo0TaIOtZBonOH58X3OEamKrmJOwqESvCPqILtMC3 pU2PtoOSDQEd684b2hxoR+0uRMOew+CJ+U7lzyh7yYU9x3jv//9CsFGcKcD+FoFG zrkDPJ75uzYGJjHZUFpnk8opwVy49TghYiVvjwm9/PXXQVvEiCGNEt7W1wTHX3Ja DygMsGN8GXg6AqWRESg4NcI8N/4U2EUEt+Li45u0qsTJ/uYmfamsC/WoacfjznaD JQVKjJQlhuk7F3qUPuxtxaGCLopLJd/uAUyYaI/HPrFeR3uIawSzCW9prTkk/E7n wAop3mErdp6JYnTacUb4pcYINIQf1c7FymbngrAmJzljxH4apZpBPugitAYvtJ2X 2OBJpUV0CtEJH3poicdq =oct9 -END PGP SIGNATURE- 0x6DCDD53C.asc Description: application/pgp-keys 0x6DCDD53C.asc.sig Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Default parsing order of config files in Debain tor package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Daniel! Thank you so much for your immediate, detailed and informative answer. I really like the example you offered as it clearly illustrates the parsing order. Your answer is very helpful for me to decide where I should place the %include line and Tor config files. I really appreciate your help. Best, iry Daniel: > The precedence for tor options is the following (1 overrides 2, > etc...): > > 1. Command line options. 2. Configuration file options (your > /etc/torrc). 3. Defaults file options (your > /usr/share/tor/tor-service-defaults-torrc). > > In the same file, options that appear later override earlier > options. > > Currently, there is no torrc.d directory created when you install > the tor package. However, you can use a %include in the > configuration file or in the defaults file. When you insert a > %include in a file, it works as if all the options for the included > file or folder were written on the line of the %include. If you're > including a folder, the files will be processed in lexicographic > order and files starting with a dot will be ignored. > > Here is an example: > > tor-service-defaults-torrc: SomeOption 0 %include /etc/tor/torrc.d/ > # SomeOption is now 2 SomeOption 3 # SomeOption is now 3 > > /etc/tor/torrc.d/01_one: SomeOption 1 > > /etc/tor/torrc.d/02_two: SomeOption 2 > > > With this configuration, the value for some option is 3. But we can > have a torrc with %include too: > > /etc/torrc: SomeOption 4 # SomeOption is now 4 %include > /etc/tor/foo.torrc # SomeOption is now 5 SomeOption 6 # SomeOption > is now 6 > > /etc/tor/foo.torrc: SomeOption 5 > > With both these files, the value for SomeOption is 6. > > There are also different types of options and some can take > multiple values. For more information see the section "Mid-level > semantics" on this file: > https://gitweb.torproject.org/tor.git/tree/doc/torrc_format.txt > > Best regards, Daniel -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJZWZ1gAAoJEKFLTbxtzdU84gAQAKVu8UcbYHXIaZ+sUkiENUeW lSBnvOHeRcIBAOe1LfClgkAFiVWhHwfG2ll7cGDTiMxn7IuDlv+sUFtwpqRVFgYH kOxJiVS1kORQJ8t8DuXh3rQZTUTKOkhCCepb8maHeCSED0yUGSXs+wzpFMAyKJk+ 2B73YR/hQd2XgpZx9LcpfkdznTXF/jpOPZthZWFAkwm1yNAlvwAmfXgADV4lQy5K RRCwYmAgdSS9OLrDMj0G1lVnvsr7qUgfePzLpp1FBkMf/E8nhL6NBCK+jJc+BA+R 3YKn5pKtJ5/KaAwutQ5nlI3+mdVoDnJI0wWGHxL6ZJPwfCMANqkrbRa8/Wq0i7ZB u1sG9aWJzTXPaI/OZQ8VE5bvh9mLSfwo0RpzYv8CVsFgu2VnMPk5EW13d33+Dzjz 5GVcA0s0V1AA7uZ/NGUrcUZ/jO+z5Argre7RxkCnAgjItKb2vJK5hGnj7gVQO0il bcx+e47MyLVNoi7tOaoJmOusEEMQB1wMG6S1Pc+o/apqW6p2VEUKrTh+DSp72+LX zDPOxAleJjbntXZkGrDO0nay21y1LWYL2bOHpWomjd03f9v6br/n9oofNX6pN7Xn B9FIOa0PxzCT2BwcROnEDEB9mCHDbIRSEvuwpbbdz3StRW3pLzU1Q2e6WO+eF7dH OpDeWlO5/Z6IJKV4eesz =9riT -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Default parsing order of config files in Debain tor package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, Tor developers! With the implementation of torrc.d, there will be at least two Tor config files and one Tor config directory by default in Debian tor package. However, I am not able to find the documents on what the parsing order Tor follows. My guess is that: 1. /usr/share/tor/tor-service-defaults-torrc is parsed first 2. /etc/torrc.d is parsed next (in lexical order) 3. /etc/torrc is parsed at last 4. and the lines in config files parsed later will overwrite similar lines in config files that are parsed earlier Could anyone familiar with the problem help me please? This will be really helpful to my future work and I really appreciate your help! Thank you very much! Best, iry -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJZWPgFAAoJEKFLTbxtzdU8HpoP/3dz869rQmlAMC4v/2UAO0F+ hPtC/L27ILeICraQRc2sJOsf7FTueKD/a6GadUbCbWBwWyyzdBXotqADnmJdvNnm hSgkE1mYz27+eI2NUd7UpHs+NrP7FXdjufGkHxZfJPrhTbGKPCC66HouT+T1vdh5 PTRBjc6M/+C2yRuteGRcAW6Be3NJ+3HRuFC5THJd6b+p0WmP+OYXdVlq7cXuY3zj ffaXvX7WGOH2J+ALIaspc0wjLiieUCq5wrO7REkeUM0TuqjhWWGBhANqVM1Qrfs+ 0jWPRklFq/7BkfySUZA88H6D5pkpBX3eVDsUlduxvoSS/F8ksWzAIdMMFaz9a7tR GpCEBBmbJIN3d4ApF78h//Y9XkaBsAotf40YEC4uZ4h3iW4rlyojWuU7N78A36PL MJ0IdUm52hWy7ySRDFi9lr7y1xtGQ9qO1gAYCq7D+qeKte+E7UO/QKZjOkAMBBir hxLimroNtL708rcDzLegstWt5Rpf2iJOYP1wOYnAeYfkSeXXW5KQBDJEd1botJg6 YRa69iICoLBNY+4z6i3t5lVlMolqPyAAwEfA1j4yXBrtBed8ISKx4V44y5JeGnZ2 SjMfHM6XJB95Bu8sWVQc1dQ+eBBiFYHbP4s4n1+jsTbmImg2bc+LauxChwRmAHek o9KiSasLITPC7zIv1m2o =KrAy -END PGP SIGNATURE- 0x6DCDD53C.asc Description: application/pgp-keys 0x6DCDD53C.asc.sig Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Problems on torrc.d-style configuration directories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi teor and Daniel! Thank you so much for your reply! Your instructions are really helpful to me. teor: > You probably need a %include directive in /etc/tor/torrc. I tried to add %include directive in /etc/tor/torrc and /usr/share/tor/tor-service-defaults-torrc separately. And both of them worked well :) teor: > If you get this working, please submit a patch to the Debian bug > tracker. No problem! But please forgive my ignorance, could you please explain a little bit more to me that why I should report it to Debian BTS, instead of tpo? In other words, what is the relationship between packages.debian.org and deb.torproject.org? According to cypherpunks[0]: > The first released tor version with this feature is 0.3.1.1-alpha. > As usual there will be alpha packages on deb.torproject.org > > If you want this feature _now_ you can use the nightly builds: > https://deb.torproject.org/torproject.org/dists/tor-nightly-master-str etch However, > the highest tor version in Debian BTS right now is 3.0.8-1.[1], which means the feature has not been included into Debian? My current thought is deb.torproject.org is the upstream of packages.debian.org in terms of tor package. So a change made in deb.torproject.org will be adopted by packages.debian.org after a while. The following is my testing environment which may be helpful to the problem: I tested the torrc.d feature in both Debian 8 and Whonix13(based on Debian8). Instead of downloading from packages.debian.org, I download tor from: > deb http://deb.torproject.org/torproject.org jessie main deb-src > http://deb.torproject.org/torproject.org jessie main deb > http://deb.torproject.org/torproject.org tor-nightly-master-jessie > main The Tor version I tested was: > Tor version 0.3.1.3-alpha-dev (git-a73d0fe9a87df762+b433dff) Again, thank you very much, teor and Daniel! I really appreciate your help! Best, iry [0]: https://trac.torproject.org/projects/tor/ticket/1922 [1]: https://packages.debian.org/source/experimental/tor -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJZUb3/AAoJEKFLTbxtzdU8jQsP/2B29N3WpkypE7DQ1A2wtjd9 MP3Blz9lbJH8LQJw+juaHhzslokCXwpGJSl7OfyqhRL44VkXnTllfd88HacW5luM PqZ4OeljB2UYrpDM7TypjdA+RXmSLTKNCmFifCESQPcmsu97qxlcvkgtF69fJ8eX p/22PEOjsqnows37rYp0AZiLa7x9I1dZdjzD6tHfKNVylM5AuuyOExAZKlx90rlW lL1nCJEuw/d6HBtVWWBgYDjeAMg5G0TpO2gU1j/A7kEzgZxWID6q/r1TvpDp1pi3 aJhjmyeZn2rVwdGPFX03pp7DWJetbYA5CuhGFucjPtkdXDCh2guuSsivcM6obpiA EmI4QtedGGhy2Xp1ufLAHP89TuuSU1n9VaioHSpLlGkQA9v2PRjW4ChBVJwP6mVt 9XGhY7TgEQMVZWL/brCNI6aeCf8rfaBSHtMwAR6xQ6ofvYAjl7X1BpNOSx4s73B/ CWnGxvMNDPuu1scxkOF0y3M68p+xgT0UuHTx4JjUTQtESFTqtdua5JxLyzE2qGyz pwzFjFzwoPBav5TPY7MB8WN79GImZFUiELA6vOL4CLaXEMCepsXYDhdP/3JLkD0e GQfliduoa2KGUijKrzy+ZVrKwBjF63ylbKGrxJHnX1SB8OftYbdlIQRvhzwHwaOL uSfnWGIg3Fo0fKs1/F/Q =L3H9 -END PGP SIGNATURE- 0x6DCDD53C.asc Description: application/pgp-keys 0x6DCDD53C.asc.sig Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Problems on torrc.d-style configuration directories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello everyone! I met some troubles when testing the new torrc.d-style configuration directories feature (https://trac.torproject.org/projects/tor/ticket/1922). Could anyone share some ideas on the problem, please? I will be really appreciated. The following is what I did: 1. add the following line to /etc/apt/sources.list.d/torproject.list: deb http://deb.torproject.org/torproject.org tor-nightly-master-jessie main 2. update Tor to nightly version: sudo apt-get update 3. tor --version: Tor version 0.3.1.3-alpha-dev (git-a73d0fe9a87df762+b433dff). 4. sudo mkdir /etc/tor/services-available 5. sudo cp anon-connection-wizard.torrc /etc/tor/services-available/ 6. sudo mkdir /etc/tor/services-enable 7. sudo ln -s /etc/tor/services-available/anon-connection-wizard.torrc /etc/tor/services-enable/anon-connection-wizard.torrc 8. reload tor 9. since bridges are used in the anon-connection-wizard.torrc, when we use arm to check the connections, tor should connect to one of the bridges, if torrc.d style configuration worked. However, it didn't work. I also tried to remove the /etc/tor/torrc, and tor could not find a torrc file anymore. The latest related discussion on the ticket is as follows: > Weasel and I (aka Hans) sketched out how we would use it in the > Debian package, closely following the Apache pattern but with > naming that is more appropriate in Tor: > > /etc/tor/torrc:: %include /etc/tor/services-enabled/*.torrc > %include /etc/tor/instances-enabled/*.torrc > > These dirs are present for the actual snippet files: > /etc/tor/services-available /etc/tor/instances-available > > These dirs include relative symlinks to *-available: > /etc/tor/services-enabled /etc/tor/instances-enabled > > For example: /etc/tor/services-enabled/sparkleshare.torrc --> > ../services-available/sparkleshare.torrc > > The sparkleshare package would include: > > /etc/tor/services-available/sparkleshare.torrc > > The davical package would include: > > /etc/tor/services-available/davical.torrc So I assumed it still worked. Could anyone please help me point out what I have done wrong? Or could anyone please point me to some docs about the new feature? I can see the source code of core Tor and write some docs on this, if this will be helpful, btw :) I really appreciate your help! Thank you! Best, iry -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJZRvsbAAoJEKFLTbxtzdU86OkP/REdnsdcJJHoGyTdyXYoqJ6n NgW3cKlEGjCZF5bxIQ+lIG6q85j3EfflPDov97VrVyCE8xr6TFG0dDs/sE4rPE/h GjYhBzM1WC5o55vyvdehTh80wl3/hSj/LehCJLOpBKAjoxuzeDHtyrkd3LG22y8i mi93wgfxBuEbqvstDVipWfJt/5JbBLtXS/QainQqFwwFHRxJpIZcSgvWR5UAXAyS IQLW7m91lwl9W/irQvhM8d4nnk0ciTGMPKoyEt3FWHs9jP9ewKvIvWlxJVYZEefW LlLHMVzbyqWZWnkLkCBNyBfZZ0Rk16YFrUuMkTUH83LO/kBSlWFOj3idN5gYwda/ aanJhtopLH1u1nP10TqF6c4e6Bu6tfCOUh8sdOp8s7iB7MJHvaPU3lJM1vDk55u1 +fSxcDOm7NuN7xrJ3elUKS+oeOU8Ah4h43L/9lJgrIZ6zdIdI1f0E4QXlIWbKIbf dkQJrG760R/6jG6JMnbiOFPwoFelLna1hX6USpbnVEfhh33n3t/t5EpK5kH/q2m9 /lCkMcBpa5XXVquGaeCCQ+2X4wQ31wlhka12GADtVkq3SohOnfKzRauJYN8OcHZH eNZlDMbO8j3y9IHEdM+mhT8a7XnnZokFINSjmjnOnAQdk8A8QjB5V/TIZQB1uJwd 1uUyayVwl9SQHy3P6yuH =SLHC -END PGP SIGNATURE- 0x6DCDD53C.asc Description: application/pgp-keys 0x6DCDD53C.asc.sig Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev