If any one is interested I’ve posted some templates for Qubes 4.2, and
updated the 3isec repositories with packages for Debian testing and
Ubuntu.
For Ubuntu, I’ve built packages and templates for the LTS releases -
2022.04 and 2024.04
The 2024.04 template should be considered a testing release: some things
are not quite right, although functional, eg use of list files instead
of the new sources file for repository definitions.
The trixie template is built using the latest trixie packages.
All are built using qubes builder v2, and signed with my Qubes OS signing
key.
Full details are here
I’ll be releasing Parrot and blackarch templates soon.
These are, of course, unofficial builds so you are trusting me to do the
right thing ™
Remember that you might like the look of (e.g) a Mint desktop, but you
wont get that from a template. Some people do not understand this.
Also, using any trixie based distro, or any rolling distro, is
a) insecure, b) likely to be unstable, and c) likely to generate a large
amount of update traffic.
Always happy to look at other templates or new flavours, on
request. (Please don’t suggest *BSD - it pains me as it is.)
@unman, it would be great to see a short guide from you about creating the micro-templates/qubes you use. You also mentioned in a github issue that you use Debian in dom0, which I would be interested to learn more about too.
I posted a guide some time back on customising the base template builds.
You can look in GitHub - unman/notes for guidance on builderv1.
I’m updating that for builderv2 right now. When I’ve done I may post
it here.
You’ll see from the issue you refer to that there was little point in
moving to Debian dom0, so it was a side project for me. I’m building
components for 4.2 now and then, using trixie.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
What is the reasoning behind “any rolling distro” being insecure?
I do get that for the likes of Kali Linux and Sid, it makes sense because the security team doesn’t really take care of them. I also get that Kali/Parrot/BlackArch are pen testing distros so they are filled with pen testing tools and that they are not meant for security.
I don’t see how the likes of Tumbleweed or Arch can be less secure than the likes of Debian if the templates are done properly however. At least with Tumbleweed and Arch, you are getting reasonably up-to-date packages. On Debian everything is perpetually outdated and vulnerable.
It’s not like maintainers actually check every line of the code the build. It is unfortunate that things like this happen, but it is unavoidable regardless of the distro. It is only by pure luck that it didn’t hit Debian stable.
Meanwhile, in Debian land:
Chromium frequently falls behind in updates. This is not the case right at this moment, but it is a common reoccurrence.
I’m assuming here that backdoor/malware placed inside the package won’t be very sophisticated so that nobody will be able to notice it before it’ll end up in the stable repository. If the malware is very sophisticated or nobody checked the sources of the package during the time before the new package version will end up in the stable repository and malicious maintainer waited for it to end up in stable patiently then stable distribution won’t differ from rolling distribution in this aspect.
With rolling distribution you’re forced to trust all the maintainers of all the packages that no one of them will plant the malware inside in the next release. And the rolling distribution users will be hit first when some package will turn out to be malicious.
With stable distribution you’ll have to trust the distribution security team that they will properly backport the security patches for the packages. The stable distribution users have some time span as a safeguard where they won’t be affected by the malicious package before it’ll end up in the stable repository.
When some packages needs to have fastest updates to be secure (browsers etc) then you can make your own choice and trust these specific package maintainers and install the packages provided by the maintainers themself instead of the packages provided by the distribution.
In this way users can trust just the distribution security team and the maintainers of the packages of your choice (browsers etc).
If you want to use rpm -K you will have to import the key using rpmkeys --import RPM-GPG-KEY-unman
It’s better to let qvm-template do this check for you imo.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
qvm-template --keyring /etc/qubes/repo-templates/keys/RPM-GPG-KEY-unman install qubes-template-noble-minimal-4.2.0-202405211137.noarch.rpm
Installing template 'noble-minimal'...
noble-minimal: Importing data
Traceback (most recent call last):
File "/usr/bin/qvm-template-postprocess", line 5, in <module>
sys.exit(main())
^^^^^^
File "/usr/lib/python3.11/site-packages/qubesadmin/tools/qvm_template_postprocess.py", line 449, in main
loop.run_until_complete(post_install(args))
File "/usr/lib64/python3.11/asyncio/base_events.py", line 653, in run_until_complete
return future.result()
^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/qubesadmin/tools/qvm_template_postprocess.py", line 314, in post_install
import_root_img(vm, args.dir)
File "/usr/lib/python3.11/site-packages/qubesadmin/tools/qvm_template_postprocess.py", line 102, in import_root_img
raise qubesadmin.exc.QubesException(
qubesadmin.exc.QubesException: template.rpm symlink not found for multi-part image, using up-to-date `qvm-template install ...` should help
ERROR: Command '['qvm-template-postprocess', '--really', '--no-installed-by-rpm', 'post-install', 'noble-minimal', '/var/tmp/tmp0o6ypbnx/var/lib/qubes/vm-templates/noble-minimal']' returned non-zero exit status 1.
I dont have the capacity to make these part of the “official set”.
The only official templates are the Debian and Fedora templates,
minimal, xfce and gnome.
There are community templates. Ubuntu would be one of these if it were
not for past stupidity. Otherwise, most of the templates I’ve produced
in the past are basically flavors of official templates. They are
built by adding package lists and custom scripts in to the builder-X
directories. The source is available on GitHub.
They could be added to the community template repositories: what would
be the advantage?
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I dont follow. As I said, the Ubuntu templates will never be
“accessible” in the community repo, so I provide them elsewhere.
Users who want to use the templates I provide have to copy my key and a
repository definition. That doesn’t seem a high barrier.
Using distinct repos allows me to customise and build templates and
packages pretty quickly on demand.
Templates seem to languish in the community-templates repos. I’ll
see if something can be done about this.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I had a mildly infected Q4.2.1 machine. I used the github Parrot 6 script to convert a Debian 12 template and a Standalone and it cured most of the problems.
It took 3 iterations of the script option 2 (home edition) and with Synaptic I removed the 4 offending packages (3 realtek and 1 old drivers). It saved me a lot of screen time. Thank you Doctore SuperBoss Palomino! Always a wild ride.