Whonix CLI Development

Development
1

VirtualBox Whonix-Gateway CLI developers-only 14.0.0.9.3 did not work “very good”. Lots of packages were missing.

Keyboard layout could not be changed since package non-qubes-vm-enhancements-cli was not installed since non-qubes-whonix-gateway-cli did not depend on non-qubes-vm-enhancements-cli.

In a series of commits, I’ve looked at non-qubes-whonix-gateway-cli and then made it as “similar as possible” to non-qubes-whonix-workstation-cli to minimize the diff. This could use some review so I didn’t break something for RPi or so.

1 Like
2

Also did not have whonixcheck, arm installed.

1 Like
3

You made non-qubes-whonix-gateway-xfce dependent on
whonix-gateway-packages-recommended-gui, however, I could not find that package.

1 Like
4

Indeed. Will fix soon.

That missing package could be considered a bug or one of the following could be considered superfluous and therefore being a bug…

Package: whonix-workstation-packages-recommended-gui
Architecture: all
Depends: whonix-workstation-packages-recommended-cli, whonix-ws-irc-chat-support,
 whonix-welcome-page, whonix-ws-start-menu-additions, ${misc:Depends}
Replaces: anon-workstation-packages-recommended, whonix-workstation-packages-recommended
Description: Recommended packages for Whonix-Workstation GUI
 A metapackage, which installs packages, which are recommended for
 graphical user interface (GUI) Whonix-Workstation, because they are
 useful for a Tor Workstation.
 .
 Feel free to remove if you know what you are doing.

Package: whonix-workstation-default-applications-gui
Architecture: all
Depends: hexchat, vlc, mixmaster, kcalc, okular, hunspell-en-us,
 gwenview, libkf5kipi31.0.0, libkf5kipi-data,
 kgpg, mat, python-hachoir-core, python-hachoir-parser,
 python-pdfrw, python-cairo, python-poppler, python-mutagen,
 libimage-exiftool-perl, gir1.2-gtk-3.0,
 pinentry-qt | pinentry-x11,
 tb-default-browser, tb-starter, tb-updater, youtube-dl,
 ricochet-im, coyim, xchat-improved-privacy, ${misc:Depends}
Replaces: anon-workstation-default-applications
Description: Recommended default applications for a graphical Anon-Workstation GUI
 A metapackage, which installs recommended GUI default applications,
 which are useful in a default installation of a graphical Tor Workstation.
 .
 Safe to remove, if you know what you are doing.

Package: whonix-gateway-default-applications-gui
Architecture: all
Pre-Depends: whonix-legacy
Depends: onioncircuits, anon-connection-wizard, tor-control-panel,
 whonix-setup-wizard,
 whonix-gw-kde-desktop-conf,
 ${misc:Depends}
Replaces: anon-gateway-default-applications, whonix-gateway-default-applications
Description: Recommended desktop packages for Whonix-Gateway GUI
 A metapackage, which installs graphical user interface (GUI) packages,
 which are recommended for a graphical Whonix-Gateway.
 .
 Safe to remove, if you know what you are doing.

Is it a good idea to merge whonix-workstation-default-applications-gui into whonix-workstation-packages-recommended-gui? Or vice versa?

Now I am wondering what I was thinking before. There seems not be much difference between packages-recommended-gui and default-applications-gui?

5
6

Currently not since it will add the kde packages like kcalc etc. to the xfce workstation.

Maybe hardened-desktop-kde-accessibility-gui and hardened-desktop-applications-kde as well as hardened-desktop-environment-essential-xfce and hardened-desktop-applications-xfce can be merged. Also maybe some of the recommended/essential/default packages. I have a feeling that no one ever removes the recommended ones so it would not make any practical differences. The control file indeed got somewhat crowded lately. But I don’t know if merging the packages would break some stuff. This requires a closer look.

1 Like
7

I would like to port Qubes to be using XFCE applications ASP. Problem is whitelisted appmenus. These cannot be upgraded. Removal of KDE applications for users who upgrade would leave existing users without whitelisted appmenu entries.

I.e. I wanted to replace hardened-desktop-applications-kde with hardened-desktop-applications-xfce in package whonix-gateway-shared-packages-shared-meta.

Then also xfce meta packages could use whonix-gateway-shared-packages-shared-meta. Then we would not have to duplicate listing Depends:.

That would also port Whonix KDE from KDE applications to XFCE applications but I think it is ok. Rather I was also considering to upgrade everyone automatically from Whonix KDE to Whonix XFCE but that may not be possible. At least not without an unclean way. Those who are now using non-qubes-whonix-workstation-kde can’t have this package removed and replaced by non-qubes-whonix-workstation-xfce unless perhaps

non-qubes-whonix-workstation-xfce Conflicts: with, and Replaces: non-qubes-whonix-workstation-kde. Maybe not a good idea. Last time these meta package migration did not go too well.

:slight_smile:

Having that sorted hopefully (otherwise please send a pull request shifting other KDE packages)., let me ask again. :slight_smile:

Is it a good idea to merge whonix-workstation-default-applications-gui into whonix-workstation-packages-recommended-gui? Or vice versa?

Yes.

Deprecated debian-vm since a non-hardened but still somewhat modified debian-vm will likely have no demand. So either no plain Debian VM ever or a plain one without any packages by Whonix installed.

Unlikely. As long as the top most dependency package that everyone is installed isn’t renamed/replaced, I am not worried.

Done. hardened-desktop-environment-essential-xfce was non-functional probably anyhow since it did not depend on lightdm.

8
9

Taking a look at the commit it seems to be too late to say no :wink:
But it looks ok to me.

imho it would not be a good idea to change the DE by upgrading. Even if everything would go well the change would probably be unexpected for most users. I don’t know if any distro ever did something like this, there are DE specific distros for a reason like the different ubuntus.
Also buster is not that far away, it will be frozen in 3-4 months so test builds could start there and we should also know at that time if the next version of Xfce will be added. Before we do a major DE change and shortly afterwards a major upgrade to the next Debian version including a new major version of Xfce, it would be better to do this at once. Sure the alternative of maybe needing to download new templates or completely new images is also not that appealing since users would then need to migrate all their stuff to the new VMs. But maybe it is the less worse option.

1 Like