Until Whonix switches DEs there are some packages that should be banned if not already. The geolocation module is part of base KDE.
Unrelated to DE (desktop environment) switching since one could always
install such applications.
Unwanted packages list is implemented here:
reverse-depends (which packages are depending on that
package) and outline what these would be doing.
$ sudo apt-cache rdepends libplasma-geolocation-interface4
$ sudo apt-cache rdepends libweather-ion6
libweather-ion6 seems is just an interface for plugins to use for fetching weather data. The name of the first package suggests something similar. Maybe this functionality is not used without activating the geolocation/weather widgets?
Possibly. Please try going further up by checking
reverse-depends of reverse depends.
user@host:~$ sudo apt-cache rdepends plasma-dataengines-workspace
user@host:~$ sudo apt-cache rdepends plasma-dataengines-yawp
plasma-widget-yawp = yaWP (Yet Another Weather Plasmoid) - a KDE weather widget. Since its not enabled by default its ok.
A GNOME package for managing “cloud” accounts of PRISM partners. I think this should be banned to prevent newbie users from using them by mistake.
do we need KDE wallet system (KWallet) in whonix (saw it in vbox version)?
I find this KWallet stuff very annoying outside and unrelated to Whonix. WiFi passwords are not simply stored and it no longer auto connects - each time it asks the wallet password. So I must figure out how to disable the wallet stuff. Usability issue.
2 posts were split to a new topic: How to get rid of insecure rpcbind?
@HulaHoop there r vbox guest stuff installed inside whonix-kvm , i wonder why u dont remove them.
The files are small and don’t interfere with the other hypervisor. For simplicity the build system output gives builds of both versions KVM and Vbox in one run.
For simplicity, time saving and better usability for me personally, official downloadable Non-Qubes-Whonix builds are created with --target virtualbox and --target qcow2 at the same time.
Could you process the following thread please wrt packages to be added?
Which Debian packages leak information to the network?
Thanks for getting the ball rolling Patrick. Very useful discussion
python-requests: fixed upstream
pip: leaks info about system package versions.
gnome-calculator: sets cookie. Bug open upstream for 2 years but not fixed by devs. Workaround is being done with Flatpak restrictions.
weather applications: leak location data but none enabled by default
Apparmor network filtering not supported by upstream stock kernels:
Some advocate using sandbox frameworks like flatpak for blocking leaky apps.
Debian probably needs a privacy team to audit all packages that send
data to the network and develop mitigation, configuration or patches
to counter these.
+10 I strongly support Paul’s plan to have a review team look through packages and engage upstream projects to clean up leaks. He is open to attending a brainstorm session at DebConf16 if someone organizes it.
Can you make the changes in git whonixcheck config please?
Some people may complain but no one needs a package manager (python-pip) that still doesn’t support GPG signed packages and never will. After years of arguing they implemented TLS downloads and enabled it by default but as anyone knows this is not enough.
Weather widgets I can’t touch because they are reverse dependencies of core DE packages. The good thing is the user has to go out of their way to shoot themselves in the foot.
Off-topic: Btw it has been worked on or may still be worked on [did not check the status for some time] to make PIP use TUF.
It seems TUF is production ready after all. Its been integrated in half a dozen major projects including pip and docker.
AppImage is supposed to be distro agnostic packaging format recently supported by Firejail. With TUF to secure app integrity and delivery we have a good combination.
Do we want to keep this?
If so, we should add
python3-pip as well?