So would anyone with ANY experience in human rights defending or “dangerous” journalism care to throw in their two cents?
You don’t have to work in it. You might have a friend or a cousin who works in it. You might have worked in it in the past. You might consider it a hobby of your.
ANY information is useful.
PLEASE… your feedback will go a long way in getting a better Qubes OS for you!
This is the point where a forum might become counter-productive. Our reach is very limited here. This part is user research. There needs to be a structured approach to doing a study like this. I mean it can be a structured interview, but it has to be designed and the goals must be scoped.
System automatically removed all of previous post.
I welcome any comment from Journalists/Human Rights Defenders. I feel that some sense of how Qubes works to obtain security is needed to create a design for a Journalists/HRD version of Qubes.
One request was for an Auto Installer of Qubes. Guessing that means, no interactions with human needed. I don’t see how that could work if computer has two drives.
I would instead be concerned with describing a group of Qubes for Journalists/Human Rights Defenders (JQubes) and, that have as a first consideration being secure. Build them by cloning off of current Qubes, install relevant software. Set whether they are online or offline.
It is from this I think I, or we, will see disagreement from Journalists/HRD saying that is not how I want it to look. Unless the Journalists have a understanding of how Qubes functions, how it obtains security. I can’t guess what they might suggest. It seems the start should be from the side of the Qubes knowledgeable forum.
I would have considered using SALT to create Jqubes until after some review. However, the current implementation of pre-installing, as much as possible, of VPN’s should be a huge improvement in Security for Journalists. Rah.
At first: I had a list of the uses of Jqubes based upon; Input. Process. Output.
Input, JQube which internet. is Online. There is a Template version, and a disp version. I would have hoped, never opens documents, or does other things which create interactions which allow information to flow from my computer to Internet.
Input: I do not see how that can work with emails, in that some emails, like many webpages, wants to download things besides text, from other places on the internet. Links. Since Thunderbird is the easy part of decrypting emails. I find the link elsewhere, problematic from a security standpoint. Describing a bunch of security, how to proceed to do both securely, hmm. I imagine one can not order an airline ticket without allowing links. So just turning off Links (Script or however) to not be the easy fix.
One thought to just download what is needed. Then “Turn off the internet connection”
Save all things to be worked on in one Directory. Then SWOOP. For which can be copied in one command to the “Jqube Process” which is never online.
Jqube process, Which is never online. What software does it need. Office software. (https://github.com/freedomofpress/dangerzone)
Split GPG, if it can be handled here. Which raises the point. If I used Input Jqube after ----“Turned off internet” Decrypted emails, using the tools with Thunderbird. There is a risk from what else might have slithered into that Jqube while online and try to capture information. One can deal with that by: 1. Making the Input Jqube disp, which means creating a template for that.
2. Creating a lock that once one has been online with this Qube, and started some software. One can not get back online (makes this more complicated than I want). Therefore must be a fresh start of the Input Jqube to get more information.
2. A warning to make sure one does not close without saving data somewhere. Or, ugh, save it for the user with a date and time somewhere. More complications.
Perhaps use a technique like is used in Deeplow DangerZone to move emails elsewhere during decryption, deliver to. Problem, use of decryption can require need to work with keys, download, verify. And so on. My limited experience, the simple, easy way to decrypt is to use Thunderbird. Simple - easy to implement and use is what we want. But with a large consideration for Security.
My original thought being how to – simply implement what is already in Qubes to create a version used by journalists, and I am suggesting creating extra software, thinks like locks, “Swoop” copies rather than use the existing, trustworthy means to copy between one Qube and another.
And, I see our Human Rights Poster who said that using Video Chat was largely used. I can understand that it must be difficult for someone to learn to touch type in a foreign language, and possibly on a keyboard meant for another language.
Truthfully, I am perplexed why I do not see offered for sale - a rubbery keyboard cover that has the letters for another language clearly on top. Might not be quite correct in terms of number of characters, but would allow someone to use a computer keyboard on a computer meant for US or some other language built in.
I feel it more secure to use a separate Jqube for Video Chat. Surely a separate one for Zoom.
I doubt the situation has changed for the security of Zoom. Zoom, Owned by a company in China, all of the product of Zoom was directed to servers inside China (PRC) before going back out. Several years ago the company announced an improvement in their encryption. Adding they would work with police, law enforcement, when asked.
To have one Qube for Zoom, should mean it has its own Template as well. I don’t like complexity.
One could put all the Video chats in the original Input Jqube, (which is a disp), which has a lock.
Software lock which allows one to do anything in this version of disp Input Jqubes, but if one has used anything Online, one can not start Zoom. After starting Zoom. One can not use other software. Now the use of the lock would require like a table to show settings of locks, ability to turn them on and off. More complexity to make up for users not learning about, or using good technique. For me, I know not to trust memory as to what I have done when and where.
Also suggests writing more software for this project. Not what I wanted. That would be a set of software locks to allow, or not allow use of some commands, using some software when other software is running, or when the computer is online. Worst part of writing a new piece of software is that someone has to maintain it.
This suggests creating a Template for a disp for Input with the nearly all the pieces of software that one might need inside. And a lock software to keep them out of using some pieces of software sequentially, and the user, spinning up several of these Qubes to do running several of these programs at the same time.
I realize I have a disp that takes a long time to spin up, and is likely to run into memory issues.
Another issue. Some time ago I installed OpenSnitch on Mint. It is an Outgoing firewall, which is to one to determine if a outgoing connection should be allowed or not. I am guessing it allows the program to check where the connection is going, Therefore, it is has an additional security possible violation. And usually having such information is of little additional value. Someone else said it was a very annoying piece of software as it keeps halting events. Still one can intuit some interesting things by timing of things. I discovered that when I saved a file in the word processor, OpenSnitch halted events because there was a connection the word processor wanted to make. I was not using any cloud backup. I use the OpenSnitch option, and deny the connection. Turn off the internet, save the file.
I don’t see a Journalist/HRD putting up with anything like OpenSnitch. And I don’t want OpenSnitch to be used to watch what internet connections I make. ???
I am thinking I should get a bunch of 5x8 inch file cards, and put the options of each Jqubes on them, and a bunch of red index cards to record the objections/risks of using that Qube. Worry about the individual points.
Yes, I am thinking of using software locks to prevent some software being used sequentially, or online, in place of the more trustworthy, create a different Qube for separate bits of software.
In the meantime, all of you should use this opportunity to point out the fallacies of any of my design.
Next step forward.
Create a clone of Template for Fedora-36-dvm
Install in this Template ----Applications----needed by Journalist/Human Rights Defender. Applications only from the Applications list that are in the Qubes Settings. Applications that are say Snap or other third party should go into another Qube. Let us focus only on this Qube for now.
Calculator
Calendar
Contacts
Files
Help
Image Viewer
KeePassXC
Maps
Open file manager
Photos
Run Terminal
System Monitor
Terminal
Text Editor
Thunderbird
Videos
Weather
Is this a good place for split-gpg?
Frankly I do not know some of these, or whether they are useful.
I do not see us building a huge number of different Qubes, that the J/HRD could keep track of which is which.
I do see this Qube could be useful, If the person using it also adhere to some observation of the principles of not starting some applications in Sequence. That is, if one has been started, then some others, must not be started in the same Qubes. Stopping Internet connection at some points. and not starting it until this dvm Qube has been stopped.
Tails has a Lock System whereby, if one has started Firefox, one can not start Tor, until Firefox is closed. Then one can start Tor, but can not again start Firefox until the Tails has been rebooted.
I had thought a similar lock - software locks to prevent some things from happening in sequence.
Problem two is making sure not information is lost from this Qube, which the user potentially wants to keep.
???Automatically save information into a directory, which gets copied somewhere on the same hard drive, with time and date stamp. ???
Someone here might have a better idea. ???
I just wanted to nudge the process along.
Wissam mentioned he did something like using one Qube and Vault for months.
This fellow is a Journalist who has made considerable effort to harden Qubes for Journalists.
I must admit that the first thought after I read someone “hardens” Qubes OS (and before diving into “solutions”) is that the key premise of Qubes is lost from the sight: Security by compartmentalization .
Especially when “hardening” includes installing Windows and Kali standalone, and installing software in dom0, like this guy did.
From experience and past communications with some journalism/freedom defenders organisms, trying to get data and help those organizations more directly myself, judgements on their use case is not recommended. Facilitating their use cases is. This is the general problem of enforcing security against needs. If people are not able to do what they intend to do, they will bypass security measures and processes, which outcome is generally worse.
What I read in the previous article is such an attempt to use Qubes to fit a certain “general” use case, which doesn’t go against the compartimentalization for security/prevention mechanisms enforced by Qubes OS.
At current state, and last time I checked, killick’s windows installer helper scripts were nearly reaching Qubes OS compartmentalization goal (Qubes’s Windows tools being last maintained for windows 7 being a limitation of that capacity). I say nearly here, since Qubes non-updated Windows tools were the reason why Windows templates are not really Templates, but more StandaloneVM which misses the compartmentalization goal. Since then, tabit-pro made a lot of progress, which deserved a Qubes News article, while newer version of Windows Tool is still not being packaged, nor distributed per Qubes OS yet (unless that changed and I missed something, which should definitely deserve another Qubes news). But when that updated tool will be distributed, I do not see any reason why Kellick’s repo would not get traction to include that work and facilitate deployment, to a testing point where that work can as well be deployed per Qubes in main repositories. I personally do not see any contradiction into using Windows Templates as a base for disposable qubes, with internet through Whonix, or without any netvm associated if a use case justifies it. But I agree with you that current state of Windows support is not in par with the compartmentalization guarantee as of now.
Hear me out here, having Windows templates, permitting to create Windows qubes with proper compartmentalization, is still desired and requested per certain use cases. Not providing for those use case or judging those needs would get in the way of filling such use cases and requirements. Being able to deploy proper Windows templates for such organizations is not to be dismissed and should still be a priority. That definitely facilitates onboarding, and a really good way to transition out of Windows.
As for your point on installing software in dom0, I did not see anything in the article (WiP as I see) that is really concerning. Installing tlp, instead of powertop, is actually better at controlling power usage since tlp is made to talk better with sensors (again, on newer hardware) from usage from past personal tests, but suggesting tlp usage is again a liability problem for anyone that would decide to deploy that. Again I agree with you that adding software under dom0 is to be made really cautiously, but better hardware control is needed if not using computer on AC adapter all the time. Again, I do not deploy powertop myself for others, but I wish I could, since I receive a lot of messages about battery draining, which would be partly mitigated by powertop --autotune, where higher gains are attained by tlp deployment. But I do not feel comfortable at all deploying patch, make and cups-client that comes with installing tlp in dom0 without further modification. But if one justifies longer battery life to be more important than the risks associated in having those risky tools into dom0, who am I to judge. Ideally, those risky tools should not be deployed under dom0. Again, the problem there is not tlp itself, but forced dependencies and automatic download of such dependencies. And the liabilities into deciding for a user which will not witness such dependencies and will be unaware of attached risks. But we must agree that having 7 hours of battery time vs 3 is impactful to say the least and might be needed in some use case. Fact to remember is always “it depends”. And this is where things are complicated.
From my experience and communication with groups that would desire to deploy such pre-packaged deployment, liability issues are the main problem as of now for anyone trying to pre-deploy anything prepackaged. Those organizations have problems endorsing the usage of some software versus the other, and prefer to let the user choose for himself, to not have any liabilities.
So I would go to precedent posts recommendations as well. The need, now, is to get data points from journalists. Some organizations are willing to have some of their employees participate in such a focus group.
As said previously, and since 2018, FPF is testing Qubes for their SecureDrop workstation Partnering with the Freedom of the Press Foundation | Qubes OS. This is to address a really defined scenario.
They are also interested into having Qubes deployed for journalist’s day to day work. But as you can imagine, the prior use case is way more easy to scope: the goal is to get SecureDrop submissions and be able to deal with those in a really confined way, permitting to deal with untrusted files and producing output that is exportable without compromising source related information in any way. An isolated workstation that never leaves a confined area, for that specific scenario. Going further and for them to suggest/propose/deploy or create deployment guides and/or salt recipes for such a vague “journalist” use case scenario comes with all those liabilities. And having experience of my own into deploying such applications and customized workflow myself leaded to many challenges to say the least, leading me to reduce the customizations and the pre-installed software myself, leading to more support time with the majority of the customers.
As said in other posts on this forum, I think the end solution might be a mix of the following:
And then, in parallel, understand and fill the gaps in upstream projects, like extrepo to have the tools required available. Have tlp not depend on make patch mailx?
And then, create salt recipes to address those needs is form of use cases. But we need use cases. And definitely not to judge them at first sight. But understand them, play with them. And come with alternatives that do not change their use cases.
I’m a little late to this, but I’ll say it anyway.
I’ve been looking online for weeks, ever since the start of this thread, for a GUI or web-based SaltStack config creator.
I have not found any, and that’s actually really surprising 
I actually want to be corrected on this, so if anyone does know of a solution that can do it (before I attempt to make my own), please please please let me know 
Just something that can:
The use case for this is so that people like @catacombs (or anyone, really…) have a GUI tool with which they can build and deploy their own custom Qubes, controlling and automating choice of installed software, network Qube, Qube parameters, and everything else
See, things like this imply that Qubes devs’ judgment isn’t good, or that they didn’t think it trough well. It is a legit implication. But if it’s true, how we could trust Qubes OS then?
This. And leading you to trust more to Qubes devs’ choices.
I just firmly believe that the default Qubes OS installation is more than enough for any use case if the concept is understood well and consequently if Qubes is properly used then.
EDIT: You didn’t mention what would Kali have to do with journalism-Human Rights workers. I’d genuinely like to know that.
I dont follow your reasoning here, but not at all. The referred article we are talking about is not about Qubes Dev team but
The Qubes dev team may be blamed to not have followed through supporting their windows tools, but following the same kind of reasoning here:
Using windows insecurely is a risk. Will always be. Getting away of proprietary code is desired. So Qubes Dev team didn’t put that as a priority, added to the departure of the Windows guy from the original Qubes team, if I remember correctly. But I am not aware of the details.
No opinion on that. Like I said in my long response already, this is not my place to judge other use cases, i’m just interested to know that it’s part of one.
Please do not interpret farther then what i’m saying:
I do not understand your reasoning here.
I got complaints by customers that didn’t want signal and element repositories deployed, and worried about some behaviors of Windows templates I once deployed. I decided to remove them and not make that choice for them. User got worried to have their machines hit signal.org for repository package information download, the software was never installed by default. Windows template was deployed though, with latest updates installed on top of killick’s script’ installed Windows 10 LTSC standalonevm. I have learned to lessen customizations over time, just tuning defaults to the bare minimum and documenting my changes through wyng-backups tags, deployed and detached signed in a seperate appvm for audits and state restoration. I’m refusing to customize now. But that is not necessary a good thing, that simply means that there is no one size fits all solution, and actually justifies Qubes devs decision:
They refuse to customize and modify upsteam decisions of implementation. Again, my prior point that you totally missed: nobody wants to be liable if something goes wrong.
Remember that pursuit against McDonald’s because coffee was hot? Well. That person wan against McDonald’s because there was no warning on the coffee cup saying that the content was hot. that means a lot on the disclosure companies have to put on their products to not be everyday in court (and also tells a lot about how crazy our world has become). But that is not my role to take a stance here.
Just saying, and restating: liability is a real thing for organizations. Unbelievable the amount of money going in liability insurances and stuff like that. Really a parallel universe there. Peacing out of this blaming game discussion here. Please listen and keep your eyes wide open when use cases are presented and shut down your judgments and just read: through those use cases are blips of persona requirements to consider.
The ones I read under tlp is: I need to optimize my battery life because I am roaming a lot in my daily job.
The ones behind Kali is information gathering having too much tools for their own goods but why not. Other than that, I repeat: suspension of judgments. Keep an open mind and listen to what they are trying to say.
Yet again, i’m no UX expert here, but those use cases are important.
Windows 7 is EOL since January 2020. Qubes developers developped their Windows Tools FOR Windows7, while it was still maintained, and the complete support of Windows 7 requires to install Qubes Windows tools on top of not latest image if no workarounds are applied. A lot of guides (and ink generally) has been spent on trying to workaround Qubes dropping support for windows for lack of internal resource to work on it. That’s the end of that story, where the community tried to pick up the task with relative success until today with tabbit-pro work, that has still not reached Qubes repo, and which carefully write news, clearly specifying that this support, as of now, comes externally of Qubes team. Qubes, not upstreaming the rpms, as of now, shows they are not ready to acknowledge nor take responsibility (liability again…) as of now until complete testing is done on their side first. That shows pretty good judgement from Qubes Devs, which are more on the careful sides of things then pushing edgy features, and I thank them for that.
So your reasoning was: blaming Qubes devs for having a correct implementation when Windows 7 was a thing for a specific version of that operating system, and then having withdrew at some point? Because you read and refer to a post of someone attempting to use Windows7 as a Template, where up-to-date Windows 7 broke things at some point compared to the moment it was developed for?! That is the reasoning I am following. As of today, without tabit-pro’s version of Windows tools, updated to work with recent versions of Windows (including Windows 11), deploying a Windows 7 is totally risky (not recommended at all) the same way you would probably not run Fedora-19 for your dispvm with old versions of everything and some too recent software not running on it, right?
The good reasoning here would be to push forward for support of ReactOS inside of Qubes, for example. But people want to use Windows to deploy software that is pushed by their corporate environment. This might not work under ReactOS. This is why having Windows current version (with updates) support cannot be completely dodged and constantly requested here, over github, everywhere, and as right now, the workaround by community members were to be able to use the Windows tools that was developed for Windows7 and make it work in a somewhat correct way, which doesn’t permit to be used as a template, but can be used as a standalone appvm. That requires the user to clone the template to specialize it and to keep an original, which is not a desired, fully efficient setup under Qubes for compartmentalization. But then the other solution is to force users to have a separate Windows PC. Those users, having that use case, decide for themselves the lesser evil and decide to use Windows under Qubes, which is still better than running Windows on bare metal.
I’m really not sure of where that call for doubting Qubes Devs come from, but it smells a bit like trolling to me. So if this is the case, that was my last feeding of the troll with my time trying to help, not to cause harm. Less judgements, more questions. Judgements normally come from a total lack of understanding. The only thing Qubes devs are responsible for is to have openly dropped official Qubes support for Windows while Windows was still maintained. And they openly justified that everywhere: not a priority, not enough resources, nobody qualified to pick up the work at the time. And then people who had interests into making this work, and doing way more, picked up where that was left and brought it further. I can only say: respect Qubes OS to have dropped the ball if following Windows internals changes was not a priority. And thanks to tabit-pro for their work; I know a lot of people will test Qubes OS when Windows support will be officially back in, with extended support like proper audio and usb support, OEM activation but their deeper internal work which will ease integration of also Android and ReactOS support through emulation support. At this point, its just to be patient and to wait for proper support and another news from Qubes team.
When users continue to use unsupported/unmaintained software, they can only blame themselves, not others.
As the author of this repository, I’m open to any and all feedback. I’ve been very intrigued by @unman and their project here: Simple set-up of new qubes and software
If I could find and tweak the salt scrips involved it might make easier the adoption of Qubes for journalists. I’d be keen to configure this for our use.
Agreed. I’m only attempting to anticipate what journalists might need and to what they are accustomed. You’ll note the dom0 upgrades are purism-specific and aren’t meant for other hardware.
Sorry, I’ve been away. Does this post refer to me? If yes, I am completely lost on it.
Thanks for your response. I’d like you to know that I wasn’t judge your approach. Questioning? Probably. But, isn’t that good actually? For example, you proposed Windows standalone, while there is a possibility to use Windows disposable, if Windows has to be used.
But my point was that once we are aware of endless possibilities of Qubes’ compartmentalization and about the need of self-discipline and changing habits at the first place, not that much hardening and additional VMs are really needed with and inside this gem.
Sorry for the extended and scattered response.
Good Windows support was something when Windows 7 was not EOL. Good windows support is in the making, finally supporting sound, usb and private volumes to get back to a state where using Windows as a template will be possible again, as expected, while not error prone nor hackish to obtain.
I just wanted to reestablish facts around Windows support, which passed from qubes supported to community based support in the past years.
Thanks for clarification. It was just that your English was too advanced for me, regardless of how hard (as always) I tried to comprehend it while it wasn’t my first language.
There is still ESU for Windows 7, and (arguably and questionably legit) workarounds to get it?
Just search for ESU patch
I will stop rephrasing in posts I do in the forum from now on and will simply post to original documentation.
Here are the known issues for QWT (Qubes Windows Tool) from amazing Killick’s script, including my notes on random issues that happen at install which might require windows reinstallation, problems with creating private volumes (to have Windows as Template) etc:
When tabit-pro’s QWT will be upstreamed to Qubes repositories, it will be possible to talk about installing Windows LTSC versions (I would not be confortable recommending Windows 7, paid support, hacked or not). This requires a bit of patience here for a News to be posted when Qubes is ready, following last article on the matter: Windows integration work in Qubes 4.1 by the tabit-pro team | Qubes OS
Aren’t they?
[user@dom0 ~]$ sudo dnf search windows
======================= Name & Summary Matched: windows ========================
kf5-kwindowsystem.x86_64 : KDE Frameworks 5 Tier 1 integration module with
: classes for windows management
qubes-windows-tools.noarch : Qubes Tools for Windows VMs
=========================== Summary Matched: windows ===========================
kf5-kxmlgui.x86_64 : KDE Frameworks 5 Tier 3 solution for user-configurable main
: windows
libwmf-lite.x86_64 : Windows Metafile parser library
Here’s what I have so far:
$template_base:
qvm.template_installed:
- name: $template_base
builder_requisite:
qvm.template_installed:
- name: $template_base
qvm-clone-id:
qvm.clone:
- name: template-builder
- source: $template_base
base:
dom0:
- match: nodegroup
- $custom_qube.clone
/path/inside/qube/to/install/file:
file.managed:
- source:
- salt://$file_pwd
- user: user/root
- group: user/root
/home/user/.rpmmacros:
file.managed:
- source:
- salt://builder/rpmmacros
- user: user/root
- group: user/root
#https://github.com/QubesOS/qubes-builder.git:
# git.latest:
# - name: <https://github.com/QubesOS/qubes-builder.git>
# - user: user
# - target: /home/user/qubes-builder
base:
builder:
- $custom_qube.config
include:
- $custom_qube.clone
qvm-present-id:
qvm.present:
- name: $custom_qube
- template: $template_name
- label: $label_colour
qvm-prefs-id:
qvm.prefs:
- name: $custom_qube
- memory: $min_ram
- maxmem: $max_ram
- vcpus: $vcpus
qvm-features-id:
qvm.features:
- name: $custom_qube
- disable:
- service.$service
"qvm-volume extend $custom_qube:private $custom_private_size" :
cmd.run
update_file:
file.prepend:
- name: /etc/qubes/policy.d/30-user.policy
- text: qubes.Gpg * builder sys-gpg allow
- makedirs: True
base:
dom0:
- match: nodegroup
- $custom_qube.create
# vim: set syntax=yaml ts=2 sw=2 sts=2 et :
{% if salt['qvm.exists']('cacher') %}
{% for repo in salt['file.find']('/etc/yum.repos.d/', name='*repo*') %}
{{ repo }}_baseurl:
file.replace:
- name: {{ repo }}
- pattern: 'baseurl=https://'
- repl: 'baseurl=http://HTTPS///'
- flags: [ 'IGNORECASE', 'MULTILINE' ]
{{ repo }}_metalink:
file.replace:
- name: {{ repo }}
- pattern: 'metalink=https://(.*)basearch'
- repl: 'metalink=http://HTTPS///\1basearch&protocol=http'
- flags: [ 'IGNORECASE', 'MULTILINE' ]
{% endfor %}
{% endif %}
install:
pkg.installed:
- pkgs:
- qubes-core-agent-networking
- qubes-core-agent-passwordless-root
- qubes-gpg-split
- aspell
- aspell-en
- createrepo_c
- createrepo_c-libs
- debootstrap
- devscripts
- dialog
- dpkg-dev
- fedora-packager
- fedora-review
- g++
- gcc
- git
- gitg
- gnupg
- m4
- make
- perl-Digest-MD5
- perl-Digest-SHA
- python3-pyyaml
- python3-sh
- re2c
- reprepro
- rpm-build
- rpm-sign
- rpmdevtools
- systemd-container
- texinfo
- wget
- vi
- zlib-devel
- ${packages}
# vim: set syntax=yaml ts=2 sw=2 sts=2 et :
base:
$template_name:
- $custom_qube.install
Name: $name
Version: $version
Release: 1%{?dist}
Summary: Salt builder template
License: GPLv3+
SOURCE0: $source0
%description
$description
%install
rm -rf %{buildroot}
mkdir -p %{buildroot}/srv/salt/build
cp -rv %{SOURCE0}/* %{buildroot}/srv/salt/build
%files
%defattr(-,root,root,-)
/srv/salt/build/*
%pos
qubesctl state.apply build.create
qubesctl --skip-dom0 --targets=template-builder state.apply build.install
qubesctl --skip-dom0 --targets=builder state.apply build.config
%changelog
$changelog
I just have to figure out: