Some unrelated qubes packages are pre-installed

Hi,

Upgraded to 4.3 (fresh install tho), morphed into kicksecure from debian 13 min, tried to set sys-* templates(separate kicksecure template per each sys-*) and I found out that packages such as qubes-core-agent-networking and qubes-core-agent-dom0-updates are already pre-installed.

Previously with 4.2, I didn’t have this and needed to install them specifically when making a sys-firewall template for example.

Is this intentional? if yes, why?
What other packages as such are now pre-installed? Is there any page in the documentation that covers it?

1 Like

Yes. Why:

No. Such page would need to be auto-generated or would be easily out-of-date over the releases.

On Debian Packages refer to:

Which packages do Kicksecure meta packages install?

1 Like

But this wasn’t like that with 4.2
I always used debian 12 minimal morphed to kicksecure and always had to specifically install these packages for sys-firewall, just as an example.

I know you don’t have plans for maintaining minimal templates, of course if it causes issues and/or additional overhead it’s fine to keep it as is.

Thank you for your work

2 Likes

Distribution Morphing - Transforming a Linux Distribution into Another Linux Distribution remains possible. Install Kicksecure inside Debian can still be done.

Mentioned here also: Kicksecure for Qubes, Distribution Morphing.

Advanced users could start with a minimal Debian Template, then pick and choose from kicksecure-meta-packages debian/control and only install wanted packages.

1 Like

But that is exactly what I did now and did so before with 4.2 - morphing from debian minimal.
But with 4.2 these packages were not included, as I said above, and with 4.3 they are and I don’t understand what changed in that context

1 Like

Nowadays you’d need to read kicksecure-meta-packages debian/control thoroughly.

For example, see line:

Package: kicksecure-qubes-cli

See its Depends:. If that is too much, install one or multiple of these Depends:. And if that’s still to much, regress further. One dependency of kicksecure-qubes-cli is kicksecure-general-cli. So check it out. Find line:

Package: kicksecure-general-cli

Then see its Depends:. Etc. Repeat for other packages.

Too many packages? There’s not that many levels of regression. Only 2. It’s ~1000 lines but a lot of it is repetitive.

You could also read that file line by line, and then only install packages which you deem wanted. For example:

bootclockrandomization, sdwdate, security-misc-shared, security-misc-desktop, timesanitycheck, usrmerge, open-link-confirmation, …

Non-exhaustive list.

More information about non-meta packages (“real packages”) such as bootclockrandomization, sdwdate, etc. you’ll find here:
Kicksecure repositories · GitHub

1 Like

Another option might be to locally parse the debian/control, sort it and keep remove duplicates (unique package names only).

grep-dctrl -sDepends -n '' debian/control \
  | sed -E 's/^[[:space:]]+//; s/[[:space:]]+$//; s/,+$//' \
  | grep -vE '^\$\{[^}]+\}$' \
  | sort --unique

(We could provide a script to avoid having to copy/type that command.)

~ 300 lines at the time of writing and alphabetically sorted.

Then you can choose from these packages.

1 Like

I checked it right now and I see that the package that is depended on the qubes-core-agent-dom0-updates (tried that for the sake of an example) is the dist-qubes-cli. Obviously it doesn’t give me the idea if the dist-qubes-cli is necessary or not as I don’t have a clue about it, so I tried to analyze it with AI and it gave me the:

The primary role of dist-qubes-cli is to provide a hardened, minimal environment for Qubes VMs by installing essential command-line tools and Qubes integration agents.

The qubes-core-agent-dom0-updates package plays a critical role in verifying digital signatures on updates before they are applied in dom0, enhancing supply-chain security.

and so on, I won’t pollute here everything with it.

The thing is I don’t need any updates for dom0 in each and every template I use, and that’s the reason I don’t understand why this package is there - what exact purpose it serve - because if qubes-core-agent-dom0-updates is needed for a good reason and then I will remove it I’m afraid I will break something or make the system less secure, but on the other hand, if it’s not needed for general purposes and needed only for something like sys-firewall like it was with 4.2, then having it hanging for nothing introduce more code and more potential issues/security holes etc.

Or am I wrong in here?

1 Like

That’s the problem with minimal templates. qubes-core-agent-dom0-updates is just 1 of ~ 300 packages.

Quote Minimal templates — Qubes OS Documentation

This page is intended for advanced users.

My interpretation of this is “It’s too complicated for laymen. We cannot help all users with that as that would require too much time”. Or as I see it “We cannot help with this as we would be kept busy with replying to support requests and would get nothing else done.”

More more discussion on that, see links in:
Minimal Kicksecure Qubes Template

Generally more on usability versus advanced users, project philosophy:

There is no reason to focus on qubes-core-agent-dom0-updates specifically as its just 1 package among hundreds. If one wanted to benefit from a minimal Kicksecure Template, they would need to be knowledgeable on all the different parts (packages) so they can pick and choose to tailor the system for their needs. → Security versus Usability

Analogy: It’s a bit like buying a car in “minimal” form and then asking the manufacturer to help you decide, one by one, which of the roughly 300 components should be installed: airbags, ABS, seatbelts, wipers, sensors, dashboard instruments, the alternator, the starter, the cooling fan, and so on. Any single part can be debated in isolation, but the whole point of a minimal build is that you are expected to already understand how the system fits together, what each component does, which dependencies exist, and which trade-offs you are willing to accept. Otherwise, the “support question” becomes an open-ended design consultation, not a simple yes-or-no about one part.


Related:

1 Like

I’m using Qubes and Kicksecure for years now. I don’t know what each and every package do in neither of the systems. I do consider myself as advanced tho, just saying.

I’m also trusting you(hence using kicksecure in the first place) and not here to critique your work, especially that it’s public and volunteer etc.

All I was saying is that `qubes-core-agent-dom0-updates` wasn’t a must have package for Qubes 4.2 with debian 12 minimal when I was morphing to kicksecure and now it is.
It could be one of many valid reasons, I was trying to figure that part here tho, as it doesn’t seem logical for me.

1 Like