-----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
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:
- 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.
- 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.
- %include /etc/torrc.d/*.conf syntax is very flexible so that Tor
does not have to decide which extension names should be parsed.
- %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.
- 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
-
iry -
teor