Qubes ready to install for Journalist-Human Rights workers


1 Like

…and make them actually work properly :stuck_out_tongue:

I have to keep a computer around to use Windows 10, because, I have a few devices that the software to connect to computer is only for Windows. So, despite my frustration with the implications of Windows Operating System security - - - I understand the need.

As a workaround, consider installing a Qube of Ubuntu, and using WINE (Windows Emulator for Linux). Ubuntu because they have a large forum which has folks who have accomplished all kinds of implementations of software, and some advice in many different languages.

If the standard WINE is either difficult for what you want to do, and or you have money for your use of Windows. You might look at the CodeWeavers site. Run Microsoft Windows software on Mac, Linux and ChromeOS | CodeWeavers

Myself, I believe there exists several free software that is a “I Talk It Types.” I am guessing the versions which there is advice on how to use in different languages.

What I would consider an insecure means of trying to use Windows is to do a dual install of Qubes, and Windows. Qubes needs to be all alone on the computer to obtain . . . I think someone else can explain the how of that point better.

Just Qubes, to attain its goals of security, needs to be installed 'Bare Metal" on the computer. “Bare Metal” being the term of nothing between Qubes and the computer but the Firmware which is for that computer.

All of the salt underlying the packages available in qubes-task can be
found on GitHub

The formulas are very simple, use very few salt states,
and some of the Qubes modules.
This is deliberate - I think almost anyone can look at the source and
understand what is going to happen.

This is fine for single packages - I do not configure a full system in
this way. There it makes sense to use templating, pillar data and grains.
If you want to set up a full system it’s simpler to use more complex

@alzer89 I’m not altogether clear on what it is you are trying to do
here. As I’ve suggested I would not use these simple formulas as the
basis for configuring a full system


You can put the files anywhere where salt can find them.
This is configured in /etc/minion.d/f_defaults.conf
By default the Qubes system has /srv/salt/ as the file root for base
You should always try to structure states and formulas using a proper
directory structure.
So installing the builder package creates a directory at
/srv/salt/builder containing the source files.
Because /srv/salt is the file root, you can access these files just by
specifying (using a dot) - e.g. builder.install

The default install also has /srv/formulas - there you will find some
of the formulas for qubes - the formulas are in
/srv/formulas/base/virtual-machines-formula/qvm, and you can access
them using qvm.

These form part of the base environment - Qubes also provides a
state to create user salt and pillar directories at /srv/user_salt and
/srv/user_pillar - set this up with qubesctl state.apply qubes.user-dirs
These are for personal configurations, and wont be affected by any

You can create new environments with new directory structures, but in
Qubes I’ve never felt the need.

This may be the right approach for what you are trying to do: I don’t
salt has built in support for templating, and uses jinja as the default
templating language. It’s highly recommended on security grounds.
You can use jinja to provide control structures, access pillar data,
grains, and to deal with variables in the state file.
You can see simple jinja used here to deal with cases where there is a
cacher qube in the system.

{% if salt['qvm.exists']('cacher') %}

{% for repo in salt['file.find']('/etc/yum.repos.d/', name='*repo*') %}
{{ repo }}_baseurl:
      - name: {{ repo }}
      - pattern: 'baseurl=https://'
      - repl: 'baseurl=http://HTTPS///'
      - flags: [ 'IGNORECASE', 'MULTILINE' ]
{{ repo }}_metalink:
      - name: {{ repo }}
      - pattern: 'metalink=https://(.*)basearch'
      - repl: 'metalink=http://HTTPS///\1basearch&protocol=http'
      - flags: [ 'IGNORECASE', 'MULTILINE' ]

{% endfor %}
{% endif %}

The {% %} delimit control structures, and {{ }} variables
If there isn’t a cacher qube, then none of that code reaches the
evaluated state.

Good to see salt getting more attention in Qubes.

I’ve spent the last month on that repo, studying it religiously. You’ve done really well with it.

They’re simple once you figure it out :grin:

Qubes OS “Qube Maker”

Template Builder
Salt Script Generator
Automatic Provisioner

Imagine the “Create new Qube…” GUI dialog box, but with a few extra widgets at the bottom:

  • Something like the current “Qube Settings…” dialog box, but with a few additions
  • Users could select from a list what packages they’d like installed in their Qube
    • Standard distribution repos
    • The Qubes OS repo
  • Users could potentially put in the path to custom repos (or even DEB/RPM/ZST/eBuild packages) to add to the list
    • Any package not in the standard repos (maybe the actual maintainer’s repo is a few versions ahead of the distro repo)
    • Sysadmins/software devs could include their own bespoke packages (corporate internal software, etc.)
  • Users could specify additional things like:
    • Custom config files
    • Anything else that Salt scripts let you do (assuming a decent enough UI can be made for it, and I’ll do my best)
  • Users have the option to:
    • Build a template/Qube based on that config
    • Build Salt scripts based off Salt templates, based on that config
    • Both
Why do this?
  • It allows anyone to provision custom AppVMs (they might be based on predefined Salt templates, but that would still be enough for most people)
    • AND share them with the community! :slight_smile:
  • Would be a massive time-saver for sysadmins in provisioning work machines
  • Instead of “I created this awesome Qube, you should try it, here’s the entire 15GB template backup”, it becomes “I’ve created this awesome Qube, you should try it, here are the 400KB Salt configs”
    • Allows for more transparency when the community shares their customised AppVMs/Templates
    • Would likely be easier to use for more demographics than manually typing them out (journalists and HRDs and their bosses is a good example)
  • Could potentially even be as simple as cloning the “Qube Settings…” dialog box and reconnecting the widgets to a backend that generates Salt scripts


I’ll do up a UI and post it to show you what I’ve got in mind :slight_smile:


Here’s an example of my first try at making Salt files:

Yes, they’re probably a bit cringe, but this is likely the end result if a regular user could be bothered to give it a go….

A GUI tool to auto-generate these based on pre-made Salt templates would go a long way in making Salt in Qubes OS “accessible to the masses”.


That was what I was struggling with. Thank you!

That’s what I have been doing.

I will once I get up to speed on that actual directory structure. I’m getting there….

Thats what I’ve been basing the scripts off.

That explains a lot. Thank you!

It’s very powerful, but requires a lot of text-based config, which puts it beyond the point where a lot of regular Qubes users would go “Nah, couldn’t be bothered….No GUI tool….Too difficult….”

1 Like