Re: convention on listen port local or all network interfaces etc. - revision 2
A convention on listen port local or all network interfaces etc. would
At the moment it looks like there is no convention for where server
applications are configured to listen by default, on localhost vs. all
interfaces. Looks like deciding that is up to the upstream author of the
software as well as the packager. Then it's up to the system
administrator to decide on where the server application should listen.
There is no great place for derivatives to globally modify this setting.
Usually applications using Tor ephemeral hidden services such as
ricochet-im, onionshare, ZeroNet, unMessage listen on localhost only.
Whonix is a Debian derivative with focus on anonymity, privacy and
security. To oversimplify it, we preconfigure Debian with these goals in
Due to Whonix's workstation, gateway split design, applications using
Tor ephemeral hidden services need to listen on the workstation's
external interface rather than on the workstation's localhost.
A global configuration file such as `/etc/ricochet-im.conf` works for
system administrators, but not for derivatives.
Why is a config folder `/etc/ricochet-im.d` strongly preferred over a
config file `/etc/ricochet-im.conf`? When a config file such as
`/etc/ricochet-im.conf` is owned by one package `ricochet-im`, it cannot
be owned by another package. If another package was to modify it using
`sed` or so, then dpkg would regard that file as user modified. The
problem is, next time that config file is changed by upstream, this
throws an interactive dpkg conflict resolution dialog at the user, which
is a usability bug. (example ) `sed` style config modifications are a
Debian policy violation as well.
So far we at Whonix had discussions with ricochet-im, onionshare,
ZeroNet and unMessage. They are all interested to make their
applications compatible with Whonix. However, asking each individual
project to `/etc/application-specific.d` folder where Whonix then could
drop a `/etc/application-specific.d/30_whonix.conf` that says
`listen=10.152.152.10` is a lot duplicate effort and not that desirable
for these applications because they have not yet any need for
Having these applications auto detect Whonix also does not seem like
great solution. Seems unsafe. If the auto detection code kicks in as a
false positive, users would be at risk. Since it's Whonix specific and
general solutions reusable by anyone are to be preferred. At least that
is my interpretation of *nix philosophy.
May the following convention be suggested.
* Parse in lexical order.
** Optionally, custom folders
** Similar to how systemd would parse these folders. I.e. for example
start with parsing `/usr/lib/listen.d/30_default.conf`, followed by
`/usr/lib/listen.d/31_other.conf`, followed by
`/usr/local/etc/listen.d/30_user.conf`, followed by
`/etc/listen.d/30_user.conf`, followed by `/etc/listen.d/40_user.conf`
and so forth.
* The file used to group the configurations would be `/etc/listen.conf`,
with the contents:
# lines starting with # are ignored
# custom configurations may be added here
** In theory, any path could be added to this file, even within `$HOME`.
However, we are still uncertain of the usefulness of adding
configurations to `$HOME` instead of one of the ones within `/usr/` and
`/etc/`. It would make it possible to make customizations when the user
does not have privileges to write outside of `$HOME`, but running a
server on a system which you do not have such access seems unlikely.
Feedback on this is also appreciated.
* `.conf` files would contain options such as:
# lines starting with # are ignored
# global fallback setting for all listeners
# web interfaces
# listen incoming IP
# optional application specific listen port
Would mean listen on `0.0.0.0` as well as on `127.0.0.1`.
This disable listeners by previous lower priority configuration files,
one could use `listen_ip=`. For example:
Would result in listening on `127.0.0.1` only. This is similar to how
systemd parses systemd unit files.
To prevent different applications to parse the configuration
differently, to avoid unexpected results, it would be useful to have a
python library and command line tool to query it.
Any questions? Any suggestions? What do you think?
Feedback on the ticket  and pull requests on the repository  are