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?
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.
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
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:
More information about non-meta packages (“real packages”) such as bootclockrandomization, sdwdate, etc. you’ll find here: Kicksecure repositories · GitHub
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.
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.”
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.
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.