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-----
On 6 Feb 2018, at 05:37, iry <iry@riseup.net> wrote:
…
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.
nickm is right: we released this feature in a stable release. Let's not break it.
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?
I would rather not break existing configs in stable releases. Instead, I think we can: * document the recommend usage * warn on potentially unexpected files Tor already warns on most duplicate options, so the issue should be obvious in most cases. Does Tor log each config file name when it is loaded? Logging the file name would help users to debug issues like this.
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.
I think these are good things to do.
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.
This seems like a good design.
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)
We should recommend a default extension for packagers. But our standard advice to users in situations like this is: "Don't do that then" In particular, our advice is: "If you modify your torrc, your tor might not work like you expect"
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?
I don't mind. In my experience, mailing lists are good for discussion, trac tickets are good for tasks, and gitlab/oniongit are good for code review. Please let us know on this list if you move the discussion elsewhere. T
participants (2)
-
iry -
teor