Simplifying Third-Party Installations in Qubes with a New Management Tool

The post contradicts with Qubes Security Model . I understand it. - This post is more for “Qubes Enthusiasts.”

I embarked on this project at the beginning of March and have since spent over 50 hours exploring this manager. Now, I’m seeking motivation to continue. I welcome all feedback, and if you appreciate the concept, please consider giving the repo a star.

As a Qubes Enthusiast, I evaluate my risk of serious cyber threats as considerably low. However, I enjoy using Qubes, and I find that its usage motivates and energizes developers to enhance it further. This, in turn, helps those who genuinely need Qubes, unlike me. On the flip side, I feel a certain lack of flexibility for my regular use, and I see immense potential that is currently underutilized due to its complexity.

Another driving force for me is the realization that, with the current lack of certain software, I risk discontinuing the use of Qubes in the future. As of now, I am highly motivated, but I’m not confident that I’ll maintain the same enthusiasm to debug the unikernel installation on dom0 five years from now.

Here are some specifics:

  • Mirage-firewall installation
  • Windows installation (currently, only Windows 10)
  • Unmanaged template installations ()


Future Plans:

  • Trust growth: This is the most important and singular task. The aim is to simplify it for easy revision, sign it, and improve connections with other Qubes projects.
  • Bug fixes

Your understanding and support are appreciated as we aim to make Qubes more user-friendly while maintaining its robust security.


Thanks a lot for your effort.

Can you ellaborate what exactly this thing does? I checked screenshots on github, but still what exactly happens when user wants to install “Windows installation (currently, only Windows 10)”? Because installation of Win10 is not that easy process after all.

On github, choose the fancy branch and watch the commit.

For windows specifically see the function def windows_installation at line 285.

Yes! Thank you for response!

I will now upload video with windows installation and all steps with github links.

I was doing this project so long so I was thinking if I will not public it right now then I will just get out of motivation

@szz9pza Thank you for link. Yes you found correct place. qubes-fancy-manager/ at fancy · qubes-fancy-manager/qubes-fancy-manager · GitHub

Cool idea. I think anything that simplifies the Qubes installation would attract users who might otherwise not take the plunge.

1 Like

There is the video demonstration of Windows 10 installation. All credits for so streamline installation go to elliotkillick with his qvm-create-windows-qube tool.

1 Like


I’m somewhat unhappy with this being incorporated in to Qube Manager
-it feels like the wrong place. But the principle is right -
that’s why I demoed the “Simple tool” last year, which also includes a
mirage-firewall install.

It seems wrong to me to automatically install a new key in to dom0
without any warning - even when it belongs to as obviously trustworthy a
person as me.
I’m not sure that I agree with making it easier to install 3rd party
templates than official templates, and to use a different GUI tool to do
At the moment, anyone wanting to install one of the templates I build
can either download the template, as explained here, or add
the repository to the qvm-template tool, so 3rd party and official
templates are managed together. This feels right, and either approach
puts the user in control.

But the aim of making Qubes more user-friendly is absolutely right. I’ll
be interested to see how this develops.

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

Thank you for your feedback :smiling_face:!

Your tool was certainly a key reference for my project, and I had intended to mention it in my post but couldn’t locate it immediately.

Qubes-manager served as an ideal starting point for me because it already provides a frame that works flawlessly within QubesOS. I was able to easily replicate the qubes-admin logic from existing functions and redesign UIs as needed in QTEditor. That’s the main reason why it’s incorporated there for now.

Regarding certificate installation, I initially aimed to prompt a pop-up on the first run to explicitly inform the user about the necessity of increasing the size of QubesOS volumes and installing certificates. However, I decided release what I had at a moment as I started to lose motivation.

Your instructions were immensely helpful! If you examine the code, you’ll notice that your instructions are essentially encapsulated within a Python wrapper. I greatly appreciate your work!

Here’s why I designed Qubes-fancy-manager this way:

  1. Ease of Installation: PyInstaller allows for a simple executable file. (Appimage didn’t work as I wanted) It doesn’t add anything to dom0, maintaining minimal presence in the domain. The only change I made was adding it to the system-tools menu. My goal is to achieve following level of simplicity in installation:

qvm-run --disposable “curl {{URL}}” > manager && ./manager

Afterwards, it should request permission to add itself to system-tools. If users want to install your templates, it will separately ask for certificate approval.

  1. Ease of Use: I’ve amalgamated your scripts, mirage-firewall, and elliotkillick/qvm-create-windows-qube under a Python wrapper for simplicity. If you’ve seen the YouTube video on Windows installation, it’s as easy as choosing a name for the qube and clicking “ok”. The same applies to mirage-firewall and your templates.

  2. Cleanliness: I’m striving to perform all operations in disposable VMs. My preference would even be to create temporary volumes on dom0 for downloading debs, all while maintaining air-gapped security.

  3. ONLY_IN_DREAMS_FOR_NOW: I imagine to have a simple repository system, somewhat akin to helm in k8s (I am devop). The vision is for anyone to be able to create a package, host it on a git repo, and users can then install it effortlessly by importing this git repo url. However, I acknowledge that this is huge contradiction to QubesOS’s isolation principles. Hence, my idea is to introduce a system to differentiate between the sources of these packages.

    Incorparated in installation tool

  • :green_square: Green would be reserved for instructions from the QubesOS team official docs.
  • :yellow_square: Yellow would indicate contributions from very trustworthy users such as you or elliotclick.
  • :orange_square: Orange would be for current installations from enthusiasts that are deemed to be reasonably trustworthy.
    Require user explicitly import the installation
  • :red_square: Red would be a zone where the user can add a link to a git repo, representing the highest level of user discretion and potential risk.

These principles I was thinking to make the tool user-friendly, maintain integrity in QubesOS, and to respect the great work done by those who support 3rd party images, making installations more accessible on QubesOS.

Hi ! I added some updates to the qubes-task.

So far I didn’t port yet anything from qubes-fancy-manager. I mostly prepared frame for it. Next will be porting Windows 10 installation.

From tasks: I would like to set names for created qubes from UI. For example it can be not flexible that mirage-firewall has static name.

Sorry I didn’t realise you was QubesOS team member! You are doing great thing! Thank you!

What did I do wrong?

[user@dom0~]$qvm-create-windows-qube -n sys-whonix -oyw -i win10x64-enterprise-eval.iso -a win10x64-enterprise-eval.xml anon-win10
[!] ISO not specified
[i] Available ISOs (Make sure to download them with Mido as instructed in the README):
[user@dom0 ~]$

i dont have github because its javascript and microsoft and no account with tor