Metapackages tweak suggestions

Development
1

Looked through Kicksecure’s metapackages to see what depends on what, and determine if some enhancements could be made. I added a rather lengthy suggestion for restructuring the metapackages to Dev/Metapackages - Kicksecure, which would be something we could consider for Trixie. While Kicksecure is still based on Bookworm however, I came up with some possibly useful changes we could apply now:

  • Add apt-transport-https to kicksecure-dependencies-cli? This will make it easier for people to use certain third-party repos, potentially.
  • Does timesanitycheck need updated? It’s “expiration date” is some time in 2023.
  • Consider adding vim-tiny or even vim to kicksecure-recommended-cli? nano is oftentimes tricky to use for me, and I spin up new VMs often enough that installing Vim later is something I have to keep redoing.
  • Does open-link-confirmation still work? If so, I notice that the Git page for it (GitHub - Kicksecure/open-link-confirmation: Asks for confirmation before opening links - For better security. - Asks before a link is (accidentally) opened in a browser to avoid linking activities.) states “On an Anonymity Gateway (when the anon-gw-base-files package is installed), it honors the $EDITOR environment variable (falls back to kwrite if unset), asks if a file should be opened in an editor before opening it and informs, that opening links on a Gateway is unsupported for security reasons.” Maybe the default text editor should be changed to Mousepad?
  • Why are the following packages part of kicksecure-default-applications-cli, shouldn’t they be part of a GUI metapackage instead, like kicksecure-desktop-applications-xfce?
    • catfish (appears to be primarily a GUI application)
    • flatpak (flatpaks are only supposed to be GUI applications)
      Why are the following applications part of kicksecure-desktop-applications-xfce, shouldn’t they be part of a CLI package like kicksecure-recommended-cli or kicksecure-default-applications-cli?
    • p7zip-full
    • unar
    • unzip
    • xz-utils
    • zip
  • CLI/TUI tools can use hunspell (nano for instance has spell checking functionality that uses it according to apt-cache rdepends), should it be moved from kicksecure-desktop-applications-recommended to kicksecure-recommended-cli or even kicksecure-dependencies-cli? (The latter has a “Do not remove.” warning similar to kicksecure-desktop-applications-recommended).
  • Hexchat is officially abandoned upstream. See 2.16.2, The Final Release – HexChat. Might be a good idea to find a different IRC client and make an apparmor-profile package for it, since Hexchat may not be secure in the long run?
  • tirdad may actually be useful under Qubes OS, assuming the VM runs its own kernel which I think it does (although there is a Qubes OS setting that makes me unsure there). If it is usable on Qubes, perhaps it should be moved from kicksecure-cli-host-packages-recommended to kicksecure-recommended-cli or even kicksecure-dependencies-cli? This needs testing.

Assuming no one brings up any objections, I’ll be submitting some changes for review that implement some or all of the above.

2 Likes
2

No need. Quote:

transitional package for https support

This is a dummy transitional package - https support has been moved into the apt package in 1.5. It can be safely removed.

Updated just now.

Yes.

Was only outdated in debian/control and readme. Now fixed.

Yes, does not fit into kicksecure-default-applications-cli.

These are not essential for a reasonably complete Xfce desktop.

But there is kicksecure-desktop-applications-recommended

(Which however isn’t installed by default in Whonix, for that there is whonix-workstation-packages-recommended-gui.)

Yeah, the package naming is inconsistent.

Right. All not fitting there.

Yes.

We’re not longer installing Hexchat by default.

AppArmor profile: We’ll probably get coverage as soon as apparmor.d - Full set of AppArmor profiles (~ 1500 profiles) - AppArmor - Whonix Forum gets implemented.

Yes.

Not by default, unfortunately. → Simplify and promote using in-vm kernel · Issue #5212 · QubesOS/qubes-issues · GitHub

Recommended vs dependencies is arguable. Not sure.

But as long as inside VM kernel isn’t the default, I think this would break.

Setting up tirdad-dkms (0.1.30-1) ...
Loading new tirdad-0.1 DKMS files...
dpkg: warning: version '6.6.36-1.qubes.fc37.x86_64' has bad syntax: invalid character in revision number
dpkg: warning: version '6.6.36-1.qubes.fc37.x86_64' has bad syntax: invalid character in revision number
Building for 6.6.36-1.qubes.fc37.x86_64
Building initial module for 6.6.36-1.qubes.fc37.x86_64
Done.

tirdad.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/6.6.36-1.qubes.fc37.x86_64/updates/dkms/
depmod....
Setting up tirdad (0.1.30-1) ...

This is working now but dependent on Qubes host kernel. In the past, tirdad broke on newer kernel versions. Since tirdad does not work without inside VM kernel inside Qubes and has the potential to brreak APT and since setting up inside VM kernel inside Qubes is difficult, I think it’s best to not install tirdad by default in Qubes.

3

related: