Remove non-essential packages from debian-12-minimal template

[emanruse]

The problem you're addressing (if any)

debian-12-minimal template includes non-essential packages:

• nftables

Since minimal templates provide no network functionality to AppVMs, this is not necessary.

• 3 text editor packages: nano, vim-tiny, vim-common

For a minimal system, one should suffice.

• tasksel

Non-essential. The target users of minimal templates are supposedly experienced enough to use apt-get to install packages (or to install tasksel additionally, if required).

The solution you'd like

No non-essential packages or packages duplicating functionality in minimal templates.

The value to a user, and who that user might be

The same which minimal templates aim to provide.

[andrewdavidwong]

• 3 text editor packages: nano, vim-tiny, vim-common

For a minimal system, one should suffice.

Or even zero. Let users install their own preferred text editor, if they even want one. I have to manually uninstall nano when I configure a fresh Debian minimal template for myself, or else it defaults to Nano instead of Vim. Having to manually uninstall a package from a minimal template for a reason like that should never happen. That just means the template isn't minimal enough.

[h01ger]

I do think that having both vim-tiny and nano installed on a minimal template is a sensible default. I don't think that the minimal template should have no editor installed. I do agree that having tasksel installed is useless.

…

-- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ "Any fool can know. The point is to understand." - A. Einstein

[unman]

On Tue, Feb 27, 2024 at 03:57:05AM -0800, Holger Levsen wrote: I do think that having both vim-tiny and nano installed on a minimal template is a sensible default. I don't think that the minimal template should have no editor installed. I do agree that having tasksel installed is useless.

I agree with the first two points - not tasksel. If one downloads only the minimal version of a new template, it can be useful to clone and tasksel. (I have never done this, but I know people who do.)

[h01ger]

Can't those (very?) few who use tasksel not apt install it?

…

-- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ 40% of homeless people in the United States have full-time jobs.

[emanruse]

If one downloads only the minimal version of a new template, it can be useful to clone and tasksel.

According to the documentation minimal templates "have only the most vital packages installed". Assuming that is correct and the dictionary meaning of vital: https://www.merriam-webster.com/dictionary/vital doesn't that make tasksel non-vital? Its absence definitely doesn't influence the work of the system and it is not a dependency.

but I know people who do.

Doesn't that belong to the category of "Do not ask for your favorite package to be added to the minimal template by default"?

[marmarek]

FWIW tasksel is installed because it's used to select packages for non-minimal templates. I think it's an oversight to have it installed in the minimal template too.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab

[emanruse]

A few others perhaps worth considering: - cpio (nothing depends on it, as per 'apt-get autopurge cpio') - cron (same) - debconf-i18n (Recommended by debconf, i.e. not required) - eatmydata (not a dependency) - fdisk (not a dependency) - ifupdown (not a dependency, implies networking) - iproute2 (networking) - iputils-ping (implies networking) - isc-dhcp-client (same) - isc-dhcp-common (same) - kmod (not a dependency) - less (just like editors) - installed as Suggested by gzip - libbpf1 (not a dependency) - libcap2-bin (not a dependency) - libglib2.0-bin (not a dependency) - libglib2.0-data (not a dependency) - libjansson4 (removes also libnftables1 during autopurge) - libmnl0 (removes also libnftables1 libnftnl11 nftables during autopurge) - libnewt0.52 (removes whiptail) - libnftables1 (removes nftables) - libxtables12 - libnftnl11 (removes nftables) - logrotate (non-essential) - netbase (networking) [Strangely, autopurging nftables does not remove the above libraries which remove it] - libregexp-ipv6-perl (implies networking, part of perl, mentioned below) - libtext-charwidth-perl - mawk (not a dependency, duplicates gawk which is a reverse dependency) - tzdata (not a dependency) - perl (no qubes packages depend on it) - whiptail (Suggested by debconf) - haveged (only libhavege2 depends on it) - might need special attention Also, according to https://wiki.debian.org/ReduceDebian the following are non-essential - aptitude (removes 6 non-qubes packages) - ca-certificates - gnupg ('apt-get autopurge gnupg' removes 17 non-qubes packages) - openssl - tasksel (discussed) - vim-common (discussed) - vim-tiny (discussed) Also: https://wiki.debian.org/ReduceDebian#Remove_foreign_language_man_files I see de, es, fr, pl exist.

[emanruse]

Additional info about haveged: it seems obsolete. jirka-h/haveged#57 (comment)

[emanruse]

Testing all this, I found: - kmod is necessary for proper boot-time mounting procedures. - tzdata is necessary too. I don't know why but removing it results in a non-bootable system. All the others can be removed and the system boots normally. The result is: 'free -m' shows 249M used memory (compared to 355M without the extra minification). icon-sender is the second most memory-consuming process.

[emanruse]

ca-certificates and openssl seem necessary for package management. Other candidates for removal: cron-daemon-common gpgv perl-modules-5.36 Even xterm can be removed and the template can be managed through qvm-console-dispvm. I don't know why xen packages depend on X11 (and if that is possible to change) but if one runs a headless service VM (with no guivm) even further minimization would be useful.

[emanruse]

If netbase is removed and qubes-core-agent-networking is installed, AppVMs can't connect to the network, i.e. the former should be a dependency to the latter.

[unman]

I dont know what it is about Debian templates that single them out for this sort of issue. AFAIK this is a duplicate of other existing issues relating to Debian templates. I dont recall *ever* seeing the same suggestions re Fedora minimal templates. What does "vital" mean? Are eyes vital? No - why not take them out. Are two kidneys vital? No - whip one out. Are legs vital? No - remove them. Vital in this usage is completely dependent on having an answer to the question, "vital for what?" So we should at least consider the question what minimal templates are to be used for, and how they fit in the context of "honoring the distro", before hacking out packages. Debian has the concepts of minbase and base systems. Minbase is a variant in debootstrap - it installs only essential packages and apt. The base system, or core installation, consists of essential packages, and those tagged as required or important. Almost all the proposed packages form part of the base system. Some of them, like mawk, are essential. Tasksel isnt installed because Qubes CHOOSES it - its installed because it's part of the base Debian system. The same for nftables. These are standard packages in the core Debian install, which any user would expect to be present - we should not remove them without good reason. Of course, it could be that there IS a good reason for doing this, but it hasnt yet been explained. It could also be that Qubes decides to create micro templates that contain only packages that Qubes chooses - these would not "honor the distro", but would serve some function in Qubes. I use such micro templates myself, but I dont consider them useful for distribution. Given the support questions that MINIMAL templates throw up, despite the prominent health warning in the docs, providing such micro templates would just create yet more support issues. There should be a careful assessment of the benefits and costs before going down this path. If we do, then it should apply to all official templates.

[emanruse]

I dont know what it is about Debian templates that single them out for this sort of issue.

Nothing. Just trying to follow the principle of single actionable issue.

AFAIK this is a duplicate of other existing issues relating to Debian templates.

I searched and did not find any. Maybe I searched wrong.

I dont recall *ever* seeing the same suggestions re Fedora minimal templates.

I still have not explored Fedora's minimal templates in depth. All I have seen so far is that they are much bigger, contain many more packages and their shell scripts are not as clean as those of Debian, i.e. the work on them is probably considerably more. So, that probably explains why there are no such suggestions for them - perhaps people simply see that Debian templates are much smaller and more suitable for a minimalist approach. FWIW, I have opened at least one issue related to dom0 minimization (as dom0 also contains removable stuff) and it was closed. If dom0 starts from a minimal Fedora template, then that issue might be related.

What does "vital" mean? Are eyes vital? No - why not take them out. Are two kidneys vital? No - whip one out. Are legs vital? No - remove them. Vital in this usage is completely dependent on having an answer to the question, "vital for what?"

These are logical questions to the the author of the documentation. I just mentioned what it says. Creative metaphors/analogies are not the best rhetorical device for technical documentation, as they stimulate interpretation rather than clarification. In the particular case, something like "essential for running a system with minimal resources" would have been better. IIUC, the reason of a template being minimal is attack surface and resource usage. My personal definition (which may or may not be applicable here) of a minimal system is one from which nothing can be removed without breaking anything else.

So we should at least consider the question what minimal templates are to be used for, and how they fit in the context of "honoring the distro", before hacking out packages.

Perhaps also how honoring fits the Qubes OS goal. E.g, Debian automatically starts newly installed services. In Qubes template system that may not be quite appropriate, regardless of expectations of stock Debian users. I suppose that is a separate issue though.

Almost all the proposed packages form part of the base system. Some of them, like mawk, are essential.

Essential for what? gawk is a dependency. mawk is not.

Of course, it could be that there IS a good reason for doing this, but it hasnt yet been explained.

The reason is the same as the one for having minimal templates.

It could also be that Qubes decides to create micro templates that contain only packages that Qubes chooses - these would not "honor the distro", but would serve some function in Qubes. I use such micro templates myself, but I dont consider them useful for distribution.

Others may consider them though.

Given the support questions that MINIMAL templates throw up, despite the prominent health warning in the docs, providing such micro templates would just create yet more support issues.

This: "Caution: This page is intended for advanced users." is like "vital". I have mentioned that many times on the forums on different occasions: what does "advanced user" mean? Many would read this as "Awesome! If I do this, I will be advanced and much more secure!" which is surely not what it says. So, this is a documentation issue, not a problem with the feature itself. Consider an alternative message, e.g. "Minimal templates of for users who know A, B, C and are comfortable working with D" + links to proper learning resources for A-D. Given enough clarity, any feature (mini, micro, nano templates) can be useful.

There should be a careful assessment of the benefits and costs before going down this path. If we do, then it should apply to all official templates.

It costed me a single 'apt-get autopurge <packages>'. For automation I use this simple script: https://paste.opensuse.org/pastes/112070eeafbf

[unman]

I dont think that this is the right place for these discussions. Take it over to qubes-devel - thrash out arguments about what minimal templates should be, what they are for, and what packages they should contain. Then come back here with a concrete proposal.

[emanruse]

I dont think that this is the right place for these discussions.

I simply replied to your discussion, as it is a sort of contemplation about the validity of the current issue. I did that because the counterarguments, through which you approach the proposal, are separate issues on their own and have to be resolved outside of it, rather than be weighed against it.

Take it over to qubes-devel

No idea what this means.

Then come back here with a concrete proposal.

The current proposal is as concrete as it can be. I don't understand why I should go somewhere else, then come back with something else.

[emanruse]

I found this: https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#install-gpgv I don't know if it relates to the upgrade process from 11 to 12. My tests show that apt works without gpgv.

[ben-grande]

I disagree with the proposal. Minimal templates are not a custom build of Qubes that debian created, it is, as unman has alreay explained, a Debian variant.

Removing packages from a minimal template is not what Qubes has done till this point, it has only used a Debian variant and built up from there.

This is a change to guest distros.

No idea what this means.

The developer's discussion mailing list.

There should be a careful assessment of the benefits and costs before
going down this path. If we do, then it should apply to all official
templates.

I agree with @unman, the user may only use or favor Debian, but why Qubes OS should favor a specific template? Qubes OS shouldn't and doing all of this for every available template is a lot of work.

Also, removing packages is not a good idea, starting from a more minimal base is much better to avoid conflicts removing desired packages.

If there are packages that can be removed from a Debian minimal build, it is on the minimal package list, does not mean that all that packages should be purged.

Anything that is not on that list, was brought up as a dependency of the Debian minbase build and has nothing to do with Qubes OS choices of packages, but the guest distro policy.

[emanruse]

@ben-grande Thank you for explaining. I do understand what you said. I made the proposal assuming that security is more important than conformity. Another thing is:

Minimal templates are not a custom build of Qubes that debian created, it is [...] a Debian variant.

Templates (not only minimal) already change the default Debian package set - they add packages (and AFAIK qubes packages don't come from official Debian repos). I may be misinformed but I don't understand why adding does not constitute a derivative but removal does. Also, IIUC, templates exclude kernel by default and use dom0 supplied one - this is a form of removal, no? I don't know what is the right formal term for this but the fact is - the Qubes user receives a modified Debian even today.

why Qubes OS should favor a specific template?

Favoring is not proposed here. Minimal templates just declare a specific goal. The proposal aligns with that goal for one of the two official minimal templates.

Also, removing packages is not a good idea, starting from a more minimal base is much better to avoid conflicts removing desired packages.

I agree starting from more minimal is better (if possible). However, even Debian suggests removal, as mentioned: https://wiki.debian.org/ReduceDebian Quote from the same URL: "Minimal systems in general also carry security benefits because fewer packages means that there are fewer security exploits available." This aligns too.

Anything that is not on that list, was brought up as a dependency of the Debian minbase build and has nothing to do with Qubes OS choices of packages, but the guest distro policy.

This does not seem to be the universal principle applying to all packages mentioned here. Example: # apt-cache rdepends --installed nftables nftables Reverse Depends: # Same for fdisk. Another example: netbase reverse depends on perl and nftables. perl reverse depends on a few packages. Following the 'aptitude why' chain of each one shows that: # aptitude why libfile-mimeinfo-perl Warning: Invalid locale (please review locale settings, this might lead to problems later): locale::facet::_S_create_c_locale name not valid i qubes-vm-dependencies Depends qubes-core-agent i A qubes-core-agent Depends xdg-utils i A xdg-utils Recommends libfile-mimeinfo-perl As you see - "Recommends", not "Depends". IOW, perl and its dependencies seems installed just because there is a chain of dependencies started through a recommendation, not through inevitable requirement. I have not investigated how this happened - whether during the build of the template or if it is due to an upstream issue in Debian itself. There are also packages which are installed as "suggested" (again - not required), as mentioned in an earlier reply. As it seems, there are whole groups of packages with strong dependencies _within_ the group, but no package of the group is a strong dependency of anything essential outside that group. The point is - a more careful look might be necessary.

[adrelanos]

Please fork Debian so we can avoid the "honor distribution culture" discussion. If Qubes forked Debian, then we could:

• A) Get a standard, security hardened Debian based Template that Qubes can customize without having to consider Debian distribution culture.
• B) Get a minimal, securitry hardened Debian based Template that can be as minimal as possible while still being useful for Qubes. Again without needing to consider what Debian distribution culture is.

I previously elaborated on that proposal here:

• rename/fork base distributions such as Debian, Fedora for trademark compliance and to avoid confusion #8730
• EDIT: create or fork a Linux distribution for default use by App Qubes for better security #9332

related:

• (Re)move Debian packages in packages.list and packages_minimal.list #6566
• Remove haveged and dbus-x11 qubes-builder-debian#77