nyxnor/onionjuggler

[FEATURE REQUEST] whonix support

Opened this issue · 45 comments

nyxnor commented

Is your feature request related to a problem? Please describe.

It is missing setting the correct configuration file on

onionjuggler/configure.sh

Line 239 in 4006a3d

"Debian"*|*"buntu"*|"Armbian"*|"Rasp"*|"Tails"*|"Linux Mint"*|"LinuxMint"*|"mint"*) . "${topdir}"/etc/onionjuggler/debian.conf;;

it just needs to test if its the GW and if it is the WS, than block it and warn to run on GW.

same flow as was done here basically

onionjuggler/usr/bin/onionjuggler-cli

Lines 657 to 666 in 4006a3d

if test -f /usr/share/anon-gw-base-files/gateway; then ## Whonix Gateway
if [ "${whonix_gateway_service}" = "1" ]; then
target_ip_default="127.0.0.1" ## Service should use Gateway ip (127.0.0.1)
elif command -v qubesdb-read >/dev/null; then
target_ip_default="$(qubesdb-read /qubes-ip)" ## Qubes-Whonix
else
target_ip_default=10.152.152.11 ## Non-Qubes-Whonix
fi
elif test -f /usr/share/anon-ws-base-files/workstation; then ## Whonix Workstation
error_msg "Create onion services on Whonix Gateway, not on Whonix Workstation"

Describe the solution you'd like

Describe alternatives you've considered

Additional context

nyxnor commented

ClientOnionAuthDir should be considered differently.

onionjuggler/usr/bin/onionjuggler-cli

Line 928 in 4006a3d

grep -q "ClientOnionAuthDir" "${tor_conf_tmp}" && { printf %s"\nClientOnionAuthDir ${tor_data_dir_auth}\n\n" | tee -a "${tor_conf_tmp}"; }

This expects the configuration to be present on the indicated torrc (tor_conf). But it is not present on 50_user.conf, also, the directory is called auth_dir on Whonix.

As was done on tor-ctrl and onion-wash, onionjuggler-cli should --verify-config and grep from there, not from a single file.

The same applies to every other non HS options, which happens to be only ControlPort and CookieAuthentication for Vanguards.

onionjuggler/usr/bin/onionjuggler-cli

Line 1371 in 4006a3d

if ! grep -q "ControlPort ${tor_control_port}" "${tor_conf_tmp}" && ! grep -q "ControlSocket" "${tor_conf_tmp}"; then

onionjuggler/usr/bin/onionjuggler-cli

Line 1376 in 4006a3d

if ! grep -q "CookieAuthentication 1" "${tor_conf_tmp}" && ! grep -q "HashedControlPassword" "${tor_conf_tmp}"; then

nyxnor commented

backup

does not apply to whonix and never will because the file needs to be transfered from one vm to another.
For this, follow: http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Onion_Services#Step_7:_Backup_the_Tor_Onion_Service_Private_Key

nyxnor commented

modifying user configuration

tor-control-panel has its own configuration file, which really helps avoid user modification.

one example is

the function will fail if there are commented lines or empty lines between the hs options. this is because it only read lines start with HiddenService and it doens't know where to stop, but maybe it should consider empty lines and commented lines but not other configuration options?

Anyway, if the user doesn't mess with the configuration in a way that would break the script, it would be with an extra included file, or I should find a better way for that function to work.

It prints correctly, it just does not delete correctly, leaving the temporary copy in a broken state, tor will show the the configuration is invalid and it won't be replaced. Tor will not reload and no configuration will be modified. This is leaves tor up and not broken, which is great, but still shows problems with the script.

nyxnor commented

Eval does not like the first characters of a variable being a number, and the file is saved to the current dir without the first characters 50_user_conf_tmp becomes 0_user_conf_tmp

./onionjuggler-cli: 1: eval: 50_user_conf_tmp=/tmp/50_user_conf.IMB3eN: not found
Saving a copy of /usr/local/etc/torrc.d/50_user.conf to /tmp/50_user_conf.IMB3eN
Including Hidden Service configuration to 0_user_conf_tmp
nyxnor commented

Improved safe_edit to be more short.

adf3b05
b631e5e
7ee61bf
8d54cf9
32d78f5

nyxnor commented

It is now possible to create onion services on the gateway for the workstation with:

onionjuggler-cli --activate -s ssh -p 22

for the gateway itself:

onionjuggler-cli --activate -s ssh -p 22 -g
nyxnor commented

auth-server and auth-client also working.

nyxnor commented

web

Does not work. Webserver is installed by default and I am thinking of removing it because:

  1. onionjuggler-cli is installed on the gateway, this means nginx would be installed there and it should not. http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Onion_Services#Step_1:_Install_Server_Software
  2. it expects to read the tor_conf, which is on the gateway, not on the workstation, to get the service name and check if it exists, so the web server configuration file can be saved with a intuitive name and it is sure that the service exists before creating a web server config for nothing.

This leads me to think that onionjuggler has to be divided in more scripts, at least separate client options (web, location) from the rest. Still, this does not solve point 2. As the workstation can't see the hs config in the torrc, a workaround needs to be made by providing the target ports for the webserver to listen to.

conclusion

https://forums.whonix.org/t/improve-onion-service-usability-by-script-gui/9117/8

So onionjuggler-cli should be separate in more scripts, the web part depends on a webserver being installed, in this case, nginx. The rest doesn't.
On the Workstation, it only makes sense to install location and focus on web. So there will be 2 debian packages for whonix, one will be installed on the WS and one on the GW.

nyxnor commented

todo

Changes marked as complete means that was completed on my local branch, could be still not pushed to github yet.

  • default target ip alternative for whonix set on configuration file
  • implement options on --web that does not require it to read the tor configuration file and the parameters will be specified on the cli.
  • move --web to a separate script
  • configure.sh install should allow installation of select scripts
  • do not install webserver on the GW.
  • create a second deb package for onionjuggler-cli-web
  • tui should check which scripts exists to set the main menu, something like command -v onionjuggler-cli-web and add it to the dialog if existent,
nyxnor commented

This is wrong because as the command is ran on the Gateway, it gets the gateway qube ip, not the workstation qube ip.

   elif command -v qubesdb-read >/dev/null; then 
     target_ip_default="$(qubesdb-read /qubes-ip)" ## Qubes-Whonix

....

the default target ip is 127.0.0.1, but this can be made a configuration option so no need to specify the WS qube ip every time to set the target.

on WS:

qubesdb-read /qubes-ip

on GW

echo "tor_hiddenserviceport_target_addr=WS_QUBE_IP" | sudo tee -a /etc/onionjuggler/conf.d/file.conf

cd46fbc

nyxnor commented

requirements_ws="grep sed nginx whiptail"
scripts_ws="onionjuggler-cli-web onionjuggler-cli-location"

requirements_gw="tor grep sed tar openssl basez git python3-stem whiptail"
scripts_gw="onionjuggler-cli-auth-server onionjuggler-cli-auth-client onionjuggler-cli-vanguards"

For the separate scripts to work indepdently, each one will need option parsin, so the common functions gotta go to /usr/share so every script can source from there.

adrelanos commented

For the separate scripts to work indepdently, each one will need option parsin, so the common functions gotta go to /usr/share so every script can source from there.

Yes.

building separate deb packages

https://askubuntu.com/questions/548662/how-to-create-multiple-debian-packages-using-the-same-debian-directory

https://askubuntu.com/questions/246718/change-environment-variables-in-debian-rules-according-to-debian-control-targets/908351#908351

This is certainly possible. You'd need multiple .install files.

And additional package would have to be declared in debian/control.

To split into multiple packages, let's consider the source code structure.

  • / - root of source package
    • /package-one/ - root of package-one
      • /package-one/usr - /usr folder of package-one

Good idea? I also wondering about an additional /src folder. Perhaps then auto-generation of the .install file would be simpler.

adrelanos commented

50_user.conf

If auto-generated by a script, better not to use /usr/local/etc/torrc.d/50_user.conf. Example:

/usr/local/etc/torrc.d/40_tor_control_panel.conf

backup

Yes, that seems pretty Whonix (actually VM) specific. Getting an onion service private key out of a VM is certainly non-trivial usability wise. Adding a reminder, link to documentation might be helpful. Other than that, seems pretty difficult and probably best if out of scope of initial implementation. Even later, seems pretty difficult (Qubes qrexec based) to improve upon.

maybe it should consider empty lines and commented lines but not other configuration options?

Why not ignore empty and commented lines? Maybe I don't understand something.

Not sure parsing should be done. Perhaps more robust to just do auto generation of config files?

eval

Are you sure eval is needed? Didn't look closely yet what you're doing but it shouldn't be that complex? Would source work instead? source is great to parse/process config snippets with variables. For example, all of Whonix build script doesn't require eval.

nyxnor commented

This is certainly possible. You'd need multiple .install files.
https://github.com/nyxnor/onionjuggler/blob/main/debian/onionjuggler.install

The debian installation is default to using debian.conf, later rethink how to make it use other debian derivatives such as whonix for building specific deb packages.

Good idea? I also wondering about an additional /src folder. Perhaps then auto-generation of the .install file would be simpler.

I don't understand.

If auto-generated by a script, better not to use /usr/local/etc/torrc.d/50_user.conf.

Reminder to change this later, to 45_onionjuggler.conf or somethinkg like it.

maybe it should consider empty lines and commented lines but not other configuration options?

Why not ignore empty and commented lines? Maybe I don't understand something.
Not sure parsing should be done. Perhaps more robust to just do auto generation of config files?

Issue #51

onionjuggler/usr/bin/onionjuggler-cli

Line 500 in c10a8de

service_block(){

Why not ignore?

Because of user modification, if the script is the only modifier of that file, than it is ok.

For example, this would work to delete the lines:

HiddenServiceDir /var/lib/tor/services/hs1
HiddenServiceVersion 3
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 22 127.0.0.1:22
## 80 for http and 22 for ssh
HiddenServiceDir /var/lib/tor/services/hs1
HiddenServiceVersion 3
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 22 127.0.0.1:22

But this wouldn't:

HiddenServiceDir /var/lib/tor/services/hs1
HiddenServiceVersion 3

HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 22 127.0.0.1:22
HiddenServiceDir /var/lib/tor/services/hs1
HiddenServiceVersion 3
## http port
HiddenServicePort 80 127.0.0.1:80
## ssh port
HiddenServicePort 22 127.0.0.1:22

And I don't want it to only break on empty lines between blocks, so this can be valid:

HiddenServiceDir /var/lib/tor/services/hs1
HiddenServiceVersion 3
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 22 127.0.0.1:22

HiddenServiceDir /var/lib/tor/services/hs2
HiddenServiceVersion 3
HiddenServicePort 8080 127.0.0.1:8080

and this also can be valid:

HiddenServiceDir /var/lib/tor/services/hs1
HiddenServiceVersion 3
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 22 127.0.0.1:22
HiddenServiceDir /var/lib/tor/services/hs2
HiddenServiceVersion 3
HiddenServicePort 8080 127.0.0.1:8080

and by valid I mean, it will only delete the correct service block, no more, no less.

Comments on top are ignored, the comments will not be deleted, just the configuration lines.
Comments in the middle or empty lines will make that function break and in the end no change will be made, which does not break tor because of safe_edit() and verify_config_tor() but still the script would not work as expected

Deleting blocks of lines are difficult, because I am thinking how to would read that file.
It understands empty lines between HiddenServicePort lines and it would assign all of them to the last HiddenServiceDir set before those ports lines.

Are you sure eval is needed? Didn't look closely yet what you're doing but it shouldn't be that complex? Would source work instead? source is great to parse/process config snippets with variables. For example, all of Whonix build script doesn't require eval.

Yes and that was not an eval proble, it is a shellscript rule, variables can not start with numbers. Anyway, that problem was fixed.
The use of eval is required to assign a variable temporary file to a temporary variable.
safe_edit tmp tor_conf gets the tor_conf file, makes a temporary copy, example /tmp/torrc.XXXXXX, then eval ${key}_tmp="/tmp/torrc.XXXX". Eval is needed for that. The only use case right now is for tor_conf, but in the future, it can be used to test webserver configuration for example, if nginx -t fails, then don't apply modifications to /etc/nginx/sites-enabled/.

nyxnor commented

On one hand, I was not wanting to separate script before because

  • shellcheck warns about unused variables, and using directives for that is a pain for every occurrence
  • declaring default values per file instead of sourced file is also a pain because later it could lead to different values for the same variable on different files
  • repeated option parsing and help messages that will need to be updated repeatedly

On the other hand

  • smaller chunks of code on separate files for new people to the codebase to review
  • plugin like script instead of --backup inside onionjuggler-cli, the cli will call onionjuggler-cli-backup, so you can modify a onionjuggler-cli-backup just for whonix with a debian patch and not modify upstream.
adrelanos commented

To split into multiple packages, let's consider the source code structure.

  • / - root of source package
    • /package-one/ - root of package-one
      • /package-one/usr - /usr folder of package-one

Or...

  • / - root of source package
    • /src - src of source package
      • /src/package-one/ - root of package-one
      • /src/package-one/usr - /usr folder of package-one

The debian installation is default to using debian.conf,

Ok.

later rethink how to make it use other debian derivatives such as whonix for building specific deb packages.

Whonix package anon-apps-config would drop a config snippet into a config.d folder, i.e. /etc/onionjuggler/conf.d/30_whonix.conf.

Since you already created a whonix.conf it would also be great to keep/maintain that file upstream, here. Then it could be moved to /usr/share/doc/onionjuggler or so. In that case, Whonix package anon-apps-config would just add a symlink.

Or since the config is sourceed it could auto-detect Whonix and only set these changes if Whonix was detected.

nyxnor commented

To split into multiple packages, let's consider the source code structure.

Now I get it. I am currently separating the scripts, so after I commit, we should review this.

Whonix package anon-apps-config would drop a config snippet into a config.d folder, i.e. /etc/onionjuggler/conf.d/30_whonix.conf.
Since you already created a whonix.conf it would also be great to keep/maintain that file upstream, here. Then it could be moved to /usr/share/doc/onionjuggler or so. In that case, Whonix package anon-apps-config would just add a symlink.
Or since the config is sourceed it could auto-detect Whonix and only set these changes if Whonix was detected.

Yes.

nyxnor commented

#54 (comment)
Now, after separating the scripts and configuration, I can see better on how to separate the debian packages. But I don't know which would be the best approach?

  • Consider every plugin a deb package?
  • Default package installs everything or no plugins?
nyxnor commented

This is what I am thinking:

Package: onionjuggler
Architecture: all
Depends: tor, sudo, grep, sed, whiptail, qrencode

Package: onionjuggler-auth
Architecture: all
Depends: onionjuggler, openssl, basez,

Package: onionjuggler-web
Architecture: all
Depends: onionjuggler, nginx | apache2,

Package: onionjuggler-vanguards
Architecture: all
Depends: onionjuggler, python3, python3-stem, git

Package: onionjuggler-auth
Architecture: all
Depends: onionjuggler, tar,

All the plugins have dependency on the main configuration because the functions will be installed from the main onionjuggler package. Of course this could be removed but I don't see a reason right now, as you would be able to activate and deactivate a service without the main config.

Renaming from plugins to modules because:

  • plugins are normally a piece of software that you can plug into an application to provide new functionality
  • while module adds features to a specific application.

That is why your download prosody-modules (module) and pidin-otr (plugin).

nyxnor commented

The debian packages will take some time for me to learn how to properly separate them with #54 (comment)

But if installing from git, the ws and the gw have their own conf now, so running:

sudo ./configure.sh -i

will install correctly on each host.

adrelanos commented
nyxnor commented
  • Consider every plugin a deb package?
    If it's sufficiently complex, yes.

Lets take onionjuggler-cli-web for example. It is not complex but it should not be installed on the gateway, as the webserver will be installed as a dependency.

The other dependencies of the other packages are very light, but normally installing webservers comes with a lot of security concerns.

Can be a plugin strucutre but a small number of packages or even just 1
package is better than many packages.

Can you suggest how you'd separate onionjuggler?
This was my model, but haven't done anything yet.

Another possibility is installed core onionjuggler and then onionjuggler-modules with all the plugins/modules, but this would install the webserver on the GW which is unwanted.

pkg onionjuggler

  • onionjuggler-tui
  • onionjuggler-cli
  • functions
  • configurations

pkg onionjuggler-modules

  • onionjuggler-cli-auth
  • onionjuggler-cli-web
  • onionjuggler-cli-vanguards
  • onionjuggler-cli-backup

But backup will not work on whonix and web should not be installed on the GW because of webserver. So if you know and alternative for this, pls share.

adrelanos commented

These are good questions. I don't know and would suggest Debian Mentors. Lots of search results. Then either asking Debian Mentors on IRC and/or the Debian Mentors mailing list.

https://mentors.debian.net/

https://wiki.debian.org/DebianMentors

https://lists.debian.org/debian-mentors/

nyxnor commented

on IRC they sent me this introduction https://mentors.debian.net/intro-maintainers/ after my questions. So it feels like I have to submit the package before asking questions about how to organize it. This will take some time to process.

I should submit via https://www.debian.org/devel/wnpp/

  1. The debian package is ready
  2. The debian package installs everything on the gateway and on the workstation, which is unwanted.
  3. I haven't found a way to make the same deb package for debian and whonix
  4. I don't want to submit a debian package that wouldn't work on whonix, because I am using whonix daily now.
  5. Another possibility is whonix hosting a different deb package for onionjuggler, ws and gw.

You don't need to respond, sometimes I write things just so I can remember why some actions were taken or not and why that direction.

adrelanos commented

Seems like there's a solution...

Debian package:
Primarily for Debian.

How to make it Whonix compatible? Maybe a solution by Whonix? Idea...

Perhaps see https://github.com/Kicksecure/kicksecure-meta-packages/blob/master/debian/control and look for textual string:

dummy-dependency

A new dependency could be invented named:
dummy-dependency-webserver

Which would Provides: nginx, apache2.

(Similar to the other already existing dummy-dependency packages.)

That would fit to be added here:
https://github.com/Whonix/anon-meta-packages/blob/master/debian/control

Then in Whonix, any unwanted dependency wouldn't be installed thanks to dummy-dependency-webserver or even if needed more generally dummy-dependency-tor-ctrl or even dummy-dependency-anon-gateway.

Let me know if you need help with the dummy-dependency, I should be able to get that done soonish if a good way forward.

The last step would be either:

  • the script refusing the run in the gateway and explaining why (if [ -e /usr/share/anon-gw-base-files/gateway ]; then) (preferably?),
  • or anon-gw-anonymizer-conf using config-package-dev hide any scripts unwanted on the gateway.
  1. I don't want to submit a debian package that wouldn't work on whonix, because I am using whonix daily now.

Great to know!

You don't need to respond, sometimes I write things just so I can remember why some actions were taken or not and why that direction.

Alright. :)

nyxnor commented

dummy-dependency-weberser seems to be the solution.

the script refusing the run in the gateway and explaining why (if [ -e /usr/share/anon-gw-base-files/gateway ]; then) (preferably?),

There are 5-6 scripts now, I would need to repeat that code inside every script. I am thinking of introducing an onionjuggler.conf configuration block (as is prohibit) from running specified script, the script would detect if it should be run or not from the configuration, not per system base.

Thanks for the help, hope to get this working on Whonix.

adrelanos commented

That sounds great!

nyxnor commented

Debian/Whonix

sudo apt install -y devscripts
sudo mk-build-deps --remove --install -y
sudo dpkg-buildpackage -b --no-sign
sudo dpkg -i ../onionjuggler_*.deb

Debian (end)
Whonix (continue)

if test -f /usr/share/anon-ws-base-files/workstation; then
  sudo cp WS_CONF /etc/onionjuggler/conf.d/whonix-workstation.conf
elif test -f /usr/share/anon-gw-base-files/gateway; then
  sudo cp GW_CONF /etc/onionjuggler/conf.d/whonix-gateway.conf
fi
nyxnor commented

so what I did is the following:

onionjuggler_plugin conf.
If empty, all plugins are enabled, if any specified, example, web, then that script will error out saying it is disabled in settings.

All the scripts will be installed, but only those allowed to run will be run.

I think I finished the work for whonix , but of course I need to test and retest on the GW and WS cause there are a lot of functionality. Anyway, treat this repository on a disposable GW and WS.

adrelanos commented 
if test -f /usr/share/anon-ws-base-files/workstation; then
  sudo cp WS_CONF /etc/onionjuggler/conf.d/whonix-workstation.conf
elif test -f /usr/share/anon-gw-base-files/gateway; then
  sudo cp GW_CONF /etc/onionjuggler/conf.d/whonix-gateway.conf
fi

Where would that be added?

Ideally, declarative programming (declarative vs imperative) should be preferred. What I mean, during Debian packaging it's preferable to place the files where they belong using folder/.install file instead of scripting in postinst. That is because declarative style is easier to understand by others, later on.

So instead of need for sudo cp somewhere (or other auto-generated files), would be preferably if this could be more static (less scripting).

For the separate scripts to work indepdently, each one will need option parsin, so the common functions gotta go to /usr/share so every script can source from there.

Sounded nice for that.

nyxnor commented

Where would that be added?

I was thinking of this: Whonix package anon-apps-config would drop a config snippet into a config.d folder, i.e. /etc/onionjuggler/conf.d/30_whonix.conf.

Because if I package for debian.org, than anon-apps-config could manage to make onionjuggler work on whonix, but to put on the debian.install, I need to see how dh-exec would work with that, and this means for the time being you would package the package directly for whonix.

Edit:
text above is horrible, let me try again:

  • If I submit the package for debian, then anon-apps-config would need to take care of adding those configuration files to conf.d
  • even if I submit my package for debian, but your prefer to package and host on deb.whonix.org for whaterver reason (faster updates, keep the software in check), then I'd need help on how to make that work with debian/onionjuggler.install.
  • from my debian experience, updates take ages if the debian sponsor does not care much or if the process hangs.

Sounded nice for that.

Already done :)

nyxnor commented

onionjuggler-tui does not have yet a --gateway option to say the service if for the gateway, not for the workstation.

  • add gateway flag on the tui if detected that the script is being run on the GW.
  • block gateway from using unix sockets, only allow tcp.

finished on edd5051

nyxnor commented

First run fails on gateway service creation if I use a non existent file, it won't be created as of not, it just fails

$ sudo onionjuggler-tui 
grep: /usr/local/etc/torrc.d/45_onionjuggler.conf: No such file or directory
Saving a copy of /usr/local/etc/torrc.d/45_onionjuggler.conf to /tmp/45_onionjuggler.conf.jQFJBS
cp: cannot stat '/usr/local/etc/torrc.d/45_onionjuggler.conf': No such file or directory
Including Hidden Service configuration to /tmp/45_onionjuggler.conf.jQFJBS

HiddenServiceDir /var/lib/tor/services/ssh
HiddenServiceVersion 3
error: Please set the Workstation Qube IP address using the option 'tor_hiddenserviceport_target_addr' on /etc/onionjuggler/conf.d/*.conf

Exiting script onionjuggler-cli
Deleting /tmp/45_onionjuggler.conf.jQFJBS
Press ENTER to return to the TUI!

Edit:

corrected with 63ca7d5 and 285a8c1

adrelanos commented
nyxnor commented

Bonus wish: onion-juggler pointing out by using a config comment
somewhere or so the Whonix snippet by anon-apps-config to make it easier
to grasp for others how Whonix support was implemented.

Edit: done in edd5051

There is not much secret, I can include some comments later, but here is a sketch:

  • Mostly configs default to debian.

  • Except on WS:

## web is the only useful plugin for the WS
onionjuggler_plugin="web"
## requirements only used if installing with configure.sh
requirements="grep sed qrencode ${dialog_box} ${webserver}"
  • Except on GW:
## only allow plugins that are useful and works on the gateway
## backup not possible because of VMs
## web should be on the WS
## vanguards maybe could be included but it is installed from git, not from deb pkg
onionjuggler_plugin="auth-server,auth-client"
## webserver does not matter of web plugin is disabled
webserver="nginx"
## removed webserver from GW requirements
## requirements does not affect if building the debian package
## it is only used by configure.sh
requirements="tor grep sed tar openssl basez qrencode ${dialog_box}"
## included directory
tor_conf_dir="/usr/local/etc/torrc.d"
## select unique torrc for the script
tor_conf="${tor_conf_dir}/45_onionjuggler.conf"
## default ClientOnionAuthDir
tor_data_dir_auth="${tor_data_dir}/authdir"

So, building the deb package has very minimal dependencies:

Depends: tor, grep, sed,
  whiptail,
  openssl, basez,
  tar,
  git, python3, python3-stem,
  nginx | apache2 | dummy-dependency-webserver,
Recommends: qrencode,
  • tor, grep, sed - just to be sure (used in every script)
  • whiptail - because it is debian default, but can also be dialog (onionjuggler-tui)
  • openssl, basez - onion authentication, debian comes with openssl but not basez (onionjuggler-cli-auth-client and onionjuggler-cli-auth-server)
  • tar - backup, don't know if already installed on debian or whonix (onionjuggler-cli-backup)
  • git, python3, python3-stem - vanguards. Even though it is not going to be installed on whonix, python3 and python3-stem are already installed, so extraneous dependency is git (onionjuggler-cli-vanguards)
  • nginx | apache2 | dummy-dependency-webserver - solved by dummy dependency for the GW. (onionjuggler-cli-web)
  • qrencode - only used if installed, that is why it is on the recommended list.
nyxnor commented

what is missing:

nyxnor commented

whonix is supported, some scripts can run on the workstation and most of them on the gateway.

closing as completed.

If bugs appear for Whonix in the future, better to create a new issue because this got too long.

nyxnor commented

still related to implementation, there is a simple problem to be solved for qubes whonix:

  • the configuration file persistence.

Currently, it is only checking /etc/, not /usr/loca/etc.

For me to also read.
https://www.whonix.org/wiki/Qubes#Qubes_Persistence

I am thinking of

  • shipping everything to /etc/onionjuggler as I am the vendor, this directory will be read first
  • manual page saying for qubes-whonix users to use /usr/local/etc/onionjuggler/conf.d/50_user.conf
    • I want them to use the conf.d in all cases so there is no mess of using /usr/local/etc/onionjuggler/50_user.conf directly.

Else they would need to bind /etc/onionjuggler in the app qube.

I didn't notice this before because I use the defaults, and didn't notice of loosing a conf.d configuration because that was only used for testing.

nyxnor commented

cc2380c

The project ships /etc/onionjuggler/onionjuggler.conf.
Packages ships /etc/onionjuggler/conf.d/*.conf.
User modifies /usr/local/etc/onionjuggler/onionjuggler.conf and/or /usr/local/etc/onionjuggler/conf.d/*.conf.

Also, insluded and excluded files are shown when running with the --getconf option so user can better understand the order files are parsed and which ones where included and which ones were excluded because didn't meet the requirements of file name.

adrelanos commented

Sounds perfect!