Minimal minimal templates?

[unman]

There's a recent issues on GitHub (#8980) about removing "non-essential"
packages from the Debian minimal template.

The argument is that minimal templates should contain only "vital packages".
OP argues that a minimal system is one from which nothing can be removed
without breaking anything else, and therefore the minimal templates
should be trimmed accordingly.

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.

The Debian minimal template is a core system, with some Qubes packages
installed.
In my view the minimal template contains a base system - it contains
packages that any user of Debian would expect to find installed.

The docs say that "The minimal templates are lightweight versions of
their standard template counterparts. They have only the most vital
packages installed, including a minimal X and xterm installation."

It may be that Qubes wants to ship a micro template, with only selected
packages installed, as well as the existing minimal templates. Or trim
down minimal templates to minbase, or smaller.
In either case, we would need to decide what packages should be included.
Any decision should be applied for all official templates.

(I should say that building with minbase in debootstrap makes very
little difference once Qubes packages are installed, and that not all
packages correctly set out dependencies on packages that are assumed o
be present.)

Thoughts would be appreciated.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Generally, I think minimal template should be as minimal as possible,
while still allowing reasonable easy customization. The latter
especially means:
- - working package manager (thanks to updates proxy, it doesn't require
all kind of networking packages)
- - some terminal emulator
- - being able to target with salt (or ansible in the future)

The last two are debatable. Terminal emulator may not be strictly
required since there is qvm-console-dispvm. And also salt is rather
arbitrary choice here, but IMO since minimal templates in practice must
be customized to be useful, being friendly to automating this
customization makes sense (BTW, this is currently broken in Fedora
minimal templates).

If there is some smaller base Debian variant to start from, IMHO it's
worth a try. Currently the main difference is that minimal template
skips installing "standard" task:
https://github.com/QubesOS/qubes-builder-debian/blob/main/template_debian/02_install_groups.sh#L45-L54
and also there is a smaller list of packages to be installed:
https://github.com/QubesOS/qubes-builder-debian/blob/main/template_debian/packages_minimal.list
many of the latter list probably can be removed. If some of those are
actually required by other packages, it should be set in package
dependencies. And if that's isn't the case, it's a bug to be fixed.

Whether to actively remove packages that were installed automatically
but aren't "vital" is another question. I suspect it might be quite
fragile (something that wasn't essential before may become essential at
some point, and thus removing will break stuff). I'd prefer the approach
that prevents installing non-essential packages in the first place, so
dependencies still can do their job. Minimal templates are built with
"no-recommends" option[2] already. But maybe there is some place that
doesn't use that properly and some "recommends" (not "depends") packages
are installed anyway?

[2] https://github.com/QubesOS/qubes-release-configs/blob/main/R4.2/qubes-os-r4.2-templates-itl.yml#L131

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXocJAACgkQ24/THMrX
1yzREAf+K3SnbpqCuQx8zyVyVZP1GqYpcvZ4yAn1+KMisiinpI1/x+3/wmOdP3f7
9AyuNBJ3wVBMgliYWAtQMLdZ2sqyS41KTEQd6BwVvuK9qjYp6cO72GdUdvK1WWbK
1cw6nq0gux+livKIbXjxgyjloABrGmzfG6F5/4QAi/Ce7TrED1DqlTW5RSjqORRj
N8LWY0wZ+oyPn/fTNnNGh4KxZb5Ps+T8fHloK1E2A+N6mcBPkDaAsqvZ0+x2lqCR
FxVgygFjoEo3LJBtjNamzg7ELjwWGDDXoKaYO0AfqIt93i04YNE3TtXh/YTH/QA+
1omKuMoRjIj/0vJV+ACI/mnTYVyvfw==
=tZfX
-----END PGP SIGNATURE-----

[qubist]

Just a little clarification to avoid potential misunderstanding:

> OP argues that a minimal system is one from which nothing can be
> removed without breaking anything else, and therefore the minimal
> templates should be trimmed accordingly.

There is no such argumentation in the opening post. I just said in a
comment that this was my personal definition of a minimal system, which
may apply to the issue or not, i.e. I don't claim it is universal or
that it must be enforced as a principle in resolving the issue.

The actual argument in the GitHub issue is based on the goal of minimal
templates, as described in documentation - reduced resource usage and
attack surface.

> Thoughts would be appreciated.

If it is not too much effort, it would be good to decouple X packages
from qubes/xen, which are dependencies now. This would allow an even
smaller system, which is useful for headless service qubes, which are
more exposed to potential attacks. Additionally, if applied to all
templates, as you suggest, it may turn out beneficial even for dom0 at
certain point in time.

[unman]

On Wed, Mar 06, 2024 at 01:06:50PM -0000, qubist wrote:
> Just a little clarification to avoid potential misunderstanding:
>
> > OP argues that a minimal system is one from which nothing can be
> > removed without breaking anything else, and therefore the minimal
> > templates should be trimmed accordingly.
>
> There is no such argumentation in the opening post. I just said in a
> comment that this was my personal definition of a minimal system, which
> may apply to the issue or not, i.e. I don't claim it is universal or
> that it must be enforced as a principle in resolving the issue.
>
> The actual argument in the GitHub issue is based on the goal of minimal
> templates, as described in documentation - reduced resource usage and
> attack surface.

This is a misunderstanding.
We should *start* by deciding what minimal templates are for,
and what the use case is, and then produce those things. As I read it,
the "goal" is to have lightweight versions of the standard templates -
reduced resource usage and attack surface is a potential effect of this,
not the primary aim. ( I note that that is a fairly recent addition to
the page and is dependent on the clause "When properly configured and
used.." )

>
> > Thoughts would be appreciated.
>
> If it is not too much effort, it would be good to decouple X packages
> from qubes/xen, which are dependencies now. This would allow an even
> smaller system, which is useful for headless service qubes, which are
> more exposed to potential attacks. Additionally, if applied to all
> templates, as you suggest, it may turn out beneficial even for dom0 at
> certain point in time.

That's a separate issue and has definitely been raised before.
Can you spell out which service qubes you see this as being useful for,
(for most users), and how the current GUI interactions , like
NetworkManager, GPG user prompts, etc, would be replaced in those qubes?
Qubes is a constant balance between usability and security - I suspect
that for most users, this would tip the wrong way.

[qubist]

On Thu, 7 Mar 2024 09:16:35 +0000 unman wrote:

> This is a misunderstanding.
> We should *start* by deciding what minimal templates are for,
> and what the use case is, and then produce those things.

OK. That is an important clarification.

Considering the mentioned text in the docs, I have assumed this has
been decided. Now, I understand from you that is yet to be done.

> As I read it, the "goal" is to have lightweight versions of the
> standard templates - reduced resource usage and attack surface is a
> potential effect of this, not the primary aim.

If those are a side effect and not the primary aim, it makes sense to
ask:

- What is the actual aim?
- What does "lightweight" really mean? What purpose does it serve?
- How will users, who have assumed the potential effect is the goal,
react to the goal being swapped with a new one?

Currently, "lightweight" is an abstraction, because it needs to be
evaluated in relation to something else, which is unknown, i.e. there
is no objective measure and without a clear goal that makes the whole
thing sound confusing.

> Can you spell out which service qubes you see this as being useful
> for, (for most users),

Disclaimer: I cannot speak for most users, as I neither represent
anyone, nor I have any data about who uses what and how. Also (as
currently stated), minimal templates are not aimed to be used by most
users but rather by qualifies ones (who know A, B, C and are
comfortable with D).

That said, and considering the important initial clarification, whether
it is useful or not, and for which particular qubes, would depend on the
re/defined goal. My previous reply was based on the assumption of
minimal resource/attack surface, i.e. applicable to all service qubes in
general.

> and how the current GUI interactions , like NetworkManager, GPG user
> prompts, etc, would be replaced in those qubes? Qubes is a constant
> balance between usability and security - I suspect that for most
> users, this would tip the wrong way.

I understand your point. Is it not possible to have the GUI in guivm
(dom0 currently) and get the messages exchanged between the service
qube and the user input in the guivm? For example, I have some shell
scripts in dom0 which accept text as user input, then call qvm-run
based on that input and check error code. Is it not possible to have
similar functionality through GUI with policies?

BTW, another related example, which you might want to consider along
the lines of minimalism and efficiency:

Currently, qubes-core-agent networking installs nftables and iproute2
(and others) as dependencies. Practically, this makes any network
connected qube have the full functionality of a firewall, a router and
a gateway. If more fine-grained compartmentalization ("the qubes way")
should be possible, one may want to separate these 3 functionalities in
separate qubes without having to install unnecessary software.

I am mentioning this, because there may be other similar cases. I have
not investigated all qubes-* packages.

[qubist]

Someone shared interesting info on the forum which might be related:

https://forum.qubes-os.org/t/nanos-unikernel-and-qubes/25496/

[qubist]

This is a reply to:

https://github.com/QubesOS/qubes-issues/issues/8980#issuecomment-3938950365

On Sat, 21 Feb 2026 07:22:35 -0800 unman wrote:

> No doubt there is a place for mini templates. But the CURRENT minimal
> templates give rise to repeated user errors and confusions - the
> proposal here would multiply that.

Are any of those related to the lack of particular package (which one)?

> I completely agree that having two templates would have a similar
> effect. That's why I'm opposed to the idea.

You said:

https://github.com/QubesOS/qubes-issues/issues/8980#issuecomment-3937767597

> If the aim is to provide an additional mini template for the project,
> OK. I've done that myself. But the aim should not be to REPLACE the
> current minimal template.

which I am reading as "I am OK with additional mini template, just
don't replace the current one". Now I understand you are against both
but it is still not immediately clear why.

> You should read "most vital" within the context of what Debian
> considers core.

I can't find any definition of Debian "core" package although I
searched a lot. What I find is:

https://www.debian.org/doc/debian-policy/ch-binary.html#s3.7
https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities

Here:

https://forum.qubes-os.org/t/how-are-minimal-templates-and-dom0-created/22544/18

you explained that minimal templates "bootstrap a basic system, and
install packages on it" to "make a usable system, providing (most of)
expected programs", by "follow[ing] the culture of the distro, while
attempting to make templates cohere". You also said that decisions
about all that were made by "the core team - although reasoned arguments
for inclusion/changes are welcome."

I don't know what expected programs means (by whom?). How does it align
with:

https://doc.qubes-os.org/en/latest/introduction/faq.html#could-you-please-make-my-preference-the-default

Speaking of core/vital, if you look at what I also linked on GitHub:

https://forum.qubes-os.org/t/minifying-debian-12-minimal-and-debian-13-minimal/24778/40

that procedure explicitly avoids "required" and "essential" packages.


> Of course, you can strip out what you like, but the aim is to provide
> templates that provide what Debian considers core/base and are USABLE
> by users.

I already explained on GitHub that removing the suggested packages does
not create dependency issues and pointed out possible solutions to
potential usage difficulties. Marek also explained that fdisk might be
necessary and a potential future dependency. That leaves for
consideration:

- fdisk
- xterm
- probably some minimal text editor

Fair enough.

But if you insist that it is better to leave all 42 packages (including
3 editors, network tools and what not) even though even Debian wiki
suggest they can be removed, please provide objective reasons.

> By all means, publish a guide on how to reduce the minimal template,

Linked above.

> or propose specific packages that should be removed from the minimal
> template, but what you are doing here is not that.

What do you mean? I have provided a list of packages, the procedure for
finding them and the reasons why they can be removed.

[unman]

Thanks. Let me try to clarify my position.

On Sat, Feb 21, 2026 at 07:23:28PM -0000, qubist wrote:
<snip>>

> which I am reading as "I am OK with additional mini template, just
> don't replace the current one". Now I understand you are against both
> but it is still not immediately clear why.

I am against providing TWO official minimal templates, and I am against
minimising the current minimal template. I think it will lead to
confusion and an increased number of support calls. You know that users
adopt the minimal templates, when they are frankly unfit, despite best
warnings: with stripped down templates, the situation would be worse.

To repeat myself, I see no problem in your guide in the Forum. The issue
here is whether we should provide such templates as part of official
release. I do not think so, and I think it would be a mistake for the
project to do this.

>
> > You should read "most vital" within the context of what Debian
> > considers core.
>
> I can't find any definition of Debian "core" package although I
> searched a lot. What I find is:

Using a stock netinst iso, at the end of the install but BEFORE tasksel,
users are told "Only the Core of the system is installed". This
comprises some 190 Packages.
Base includes 67 Packages.

<snip>

> I don't know what expected programs means (by whom?). How does it align
> with:
>
> https://doc.qubes-os.org/en/latest/introduction/faq.html#could-you-please-make-my-preference-the-default

Expected by any user who is familiar with a Debian system. There is no
way for ordinary users in official Debian releases to install only Base.
The smallest they achieve is "Core", and that sets minimal
expectations.

This is not a user choice - this is the choice of the Debian project. It's
a principle that we follow them. You may not like this, but it has been
longstanding practice.

<snip>

> that procedure explicitly avoids "required" and "essential" packages.

Understood but I see on GitHub proposals to remove editors and so on.
That is what I object to.

<snip>

> What do you mean? I have provided a list of packages, the procedure for
> finding them and the reasons why they can be removed.

With the greatest respect you have not done this. You have identified
packages that *can* be removed, but you have not given reasons for their
removal.

Some years ago, I said : "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 do not see that this has happened, and
I do not see a reasoned proposal for removing individual packages.

I think that this issue has run its course and should be closed. Keep
the guide in the Forum, which will have the same status as the Debian
guide - unofficial, but in official Forum. If there are individual
packages, or groups of packages that can be removed, then a separate
issue should be opened in that case.

[qubist]

Thank you for the detailed response.

I am confused by your earlier welcoming of reasoned arguments for
changes vs. your total rejection of any changes and any reasoning.

> I think it will lead to confusion and an increased number of support
> calls.

That rather sounds like "I am afraid I will have more work" than "the
suggested change creates a worse product". I have never read that the
goal of minimal templates is keeping a low support call number.

> You know that users adopt the minimal templates, when they are
> frankly unfit, despite best warnings: with stripped down templates,
> the situation would be worse.

If someone refuses to read the warning, they won't read it better with
more packages in template. Prove me wrong.

> To repeat myself, I see no problem in your guide in the Forum. The
> issue here is whether we should provide such templates as part of
> official release. I do not think so, and I think it would be a
> mistake for the project to do this.

If you are afraid you will have too much work to help people on the
forum, that can be easily solved with simple examples in docs, e.g. how
to create a minimal sys-* qubes. We have done this in guides e.g. for
DNSCrypt and people actually liked it.

> Using a stock netinst iso, at the end of the install but BEFORE
> tasksel, users are told "Only the Core of the system is installed".
> This comprises some 190 Packages.
> Base includes 67 Packages.

I don't know where to find a list of those (without having to install
an ISO). In any case, the minimal template currently contains more than
300 packages.

> [...] but I see on GitHub proposals to remove editors and so on.

> That is what I object to.

Well, you are in a position to object to anything but having editorS is
not minimalism.

> With the greatest respect you have not done this. You have identified
> packages that *can* be removed, but you have not given reasons for
> their removal.

The reasons are the same as the reasons for having minimal templates in
the first place. I referred to the docs and to "Reduce Debian" on
GitHub. There is also the note about "as minimal as possible" here
which the current minimal template is not.

You are asking me to explain why 3 text editors and 42 packages should
be removed. Please explain why a minimal system needs 3 text editors,
and why a non-networked system needs networking packages.

I highly doubt the Debian team made their core-system choices
considering a Qubes environment, so conforming to those choices as an
essential principle may be worth reconsideration.

/I rest my case

[Steve Coleman]

On 2/22/26 14:32, qubist wrote:

Thank you for the detailed response.

I am confused by your earlier welcoming of reasoned arguments for
changes vs. your total rejection of any changes and any reasoning.

Philosophically speaking, the more you take out, the less useful it is for the majority of people. 

Reducing the functionality down to the absolute bare minimum that can just barely run makes it that much more unusable for the vast majority of people. By the time you get down to the bare bones of a truly minimalist system there would be too many permutations of what is needed to make it become useful to others, because each persons use-case will be different.  

Here is an idea, create your ideal minimalist Template and put it out in the Community Template directory. If someone wants such a highly constrained template then they can download it from there. Doing this would be a community service. Collaborate with others if they find it useful. 

Personally I don't want such a tightly constrained Template because it doesn't actually provide any benefit to me beyond the current minimal Template that is already available. The size of the footprint on disk is not that concerning, and security wise if something isn't running and in memory then it doesn't add anything to the attack surface. Perhaps if you are concerned with the speed of loading a VM into memory? Bbut that speed up difference won't be that all much. A few nanoseconds? A faster machine would help even more. 

If someone does break into your super-minimalist template or its associated AppVM somehow, and then they subsequently discover *three whole editors*, sorry, the game is already over. You loose. It didn't matter that you have a few extra binaries sitting around on that drive volume or not. You are already toast. If there is no editor at all they will just import one. You see, if your adversary is smart enough to get into that runtime environment in the first place then they are certainly smart enough to import whatever binaries they like as long as the disk volume space allows for it. Maybe not Emacs, but Vim, pico, or micro will likely fit unless its on a read-only volume with no CoW. 

If you want a template without any network interface at all, then have at it. Without at least a loopback interface it will be pretty much useless for most people. Publish your Template and wait for the questions to come on how to use it with zero editors installed. Or install just one editor, and wait for the questions on why you chose *THAT* editor. 

Bottom line. You can't please everyone. You have to make choices, and your choices are not going to be the equivalent choices of everyone else. If you do include enough choices then you please more people, so its a balance. The Qubes team is just trying to strike that magic balance by catering to what the most users really need. 

[qubist]

A minimal template is not a usability tool. Marek nailed it earlier:

On Wed, 6 Mar 2024 14:33:04 +0100 Marek Marczykowski-Górecki wrote:

> as minimal as possible, while still allowing reasonable easy
> customization

So far, nobody has explained how exactly removing all the listed
packages (optionally keeping xterm and e.g. nano) will make the minimal
template worse or harder to customize.

[Zaz Brown]

> So far, nobody has explained how exactly removing all the listed
> packages (optionally keeping xterm and e.g. nano) will make the minimal
> template worse or harder to customize.

One thing I have found that can be annoying is if you have an offline VM
and need to debug something on it, but don't have the required package
to do so. I certainly agree we should keep *running* software to a
minimum, but I'm not sure how much harm having installed software does.

--

[unman]

If you do not understand how this will make the minimal template even
LESS usable, then I do not know what more to say.

It has nothing to do with my time - that was an unworthy slur. It's to
do with the project. You are proposing changes that will leave users
confused and uncertain of what to do, and it will lead to greater
support calls in qubes-issues and in lists and the Forum.

--
I never presume to speak for the Qubes team.
When I comment in the mailing lists I speak for myself.

[qubist]

On Mon, 23 Feb 2026 14:59:12 +0000 'unman' via qubes-devel wrote:

> If you do not understand how this will make the minimal template even
> LESS usable, then I do not know what more to say.

For instance, you can explain how removing the packages while keeping
xterm and e.g. nano will do that.

> You are proposing changes that will leave users confused and
> uncertain of what to do, and it will lead to greater support calls in
> qubes-issues and in lists and the Forum.

This is a speculation, not a fact. My speculation is nothing will
change.

This did not receive an answer either:

On Sun, 22 Feb 2026 19:32:54 -0000 qubist wrote:

> Please explain why a minimal system needs 3 text editors,
> and why a non-networked system needs networking packages.

I have been reading generalizations, abstractions, and argumentum ad
populum. It does not answer why a particular package of the list must
stay and for what exact purpose, or how it improves/maintains usability
or anything else specific to Qubes.

Example of the opposite:

Marek mentioned that fdisk might be necessary and explained how. - I
checked how it is called, so indeed it may become a dependency. There
is a valid reason to keep it.

> It has nothing to do with my time - that was an unworthy slur.

It was never intended to be that. I apologize if my interpretation of
your words was inappropriate.

[Ben Grande]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I agree with the proposal of having a very minimal OS. I do not agree
with removing packages from existing systems. I understand unman's point
that it will increase support calls, I think that supporters should
point out that it is for advanced users, rather than trying to help
others. I believe minimal templates are best leveraged with
orchestration tools.

Now back to the point of defining how minimal it is, I agree with
Marek's point of a minimal system:

- - being as minimal as it can be
- - having orchestration tools installed by default

I don't think xterm is necessary give qvm-console-dispvm. It is not the
perfect solution yet as the management console window does not inform
which qube it is connected to [0].

[0] https://github.com/qubesos/qubes-issues/issues/9810

- --
Benjamin Grande
-----BEGIN PGP SIGNATURE-----

iHUEARYIAB0WIQRklnEdsUUe50UmvUUbcxS/DMyWhwUCaZ8tMQAKCRAbcxS/DMyW
h/KDAQCTRAJPNiElEX/WtzgAynWjsTyf8SBTc7jOX1SZqBsVjwEAukaZlrZReKkR
I4NRfppRGmyWhkGATvAGQFsBEdG0owA=
=WZcm
-----END PGP SIGNATURE-----

[qubist]

On Wed, 25 Feb 2026 18:11:14 +0100 Ben Grande wrote:

> I do not agree with removing packages from existing systems.

Just to make clear: My proposal is NOT to have the extra packages in
the template in the first place. That is what I mean by removing of
packages from template. It does NOT mean removal from installed
systems e.g. through the updates mechanism. The latter would be a
nightmare for users.

My suggestion is to have a new version of the minimal template, not an
upgrade of the current one. Users would need to explicitly install that
new version to use it. The old version can simply be discontinued after
a short transitional period.


* What is discussed in the forum thread is how to uninstall packages
from existing system because it is the only possibility given the
status quo, or one has to build a template oneself.