Re: [tor-dev] Proposal: only parse .torrc files in torrc.d directory

[teor <teor2345@xxxxxxxxx>]

> On 6 Feb 2018, at 05:37, iry <iry@xxxxxxxxxx> 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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev