There are a number of Qubes community guides I’d like to implement. It’s very time-consuming to do this, however.
Is there any tool that would allow automation of such guides?
How do you imagine such implementation/automation?
I thought this is what Salt is for? Combined with a more elaborate version of Qubes OS Helper, we could make this nice.
I imagine that someone creates a community guide and then also creates a version that has commands to be run in dom0 with a script for waiting before applying certain steps if necessary.
Running such a script at first might not be safe, but over time if the community said it was good, then someone could just run it.
This would be something like a community guides tool. For example, I would like it if Qubes had a distress password at boot at at the screensaver. There are two community guides on how to do this. I realize that if I want to implement those, it may take 2-3 hours for each one for me to figure it out.
I really just wish I could copy a chunk of text to dom0 (it looks like QubesOS Helper could help with that) and just apply the community guide. This would especially help for setting up VPNs and setting up other things.
Qubes is just so time consuming and a lot of times I can look at the code and go “this doesn’t look malicious” and still know that it’s probably going to take a long time to utilize.
I thought about this too, like if there were another tab for Qubes OS Helper and Guides could just be changed to some sort of format. But some guides require manual steps or verification or creations of password, so it would need to be semi-automated.
I’d really like to be able to just cut a block of code from this website, paste it into dom0, and then apply it, but mostly guides are posted without needed code for pausing or rebooting or doing other things, at least I think so? For example, the RAM-only guide is probably I can’t implement just by copying code to dom0 and running it all I am guessing. This may be a bad example, but I just don’t think most guides are in “cut paste and run” mode… but they could be?
There are security risks, but the code would be posted here.
So, you want to copy code from distrusted infrastructure and paste it in dom0, so you can run it easily.
Even if we ignore the anti-security of all that, that is not learning (what a guide is supposed to help). That is blind copying.
I would recommend against that. I wouldn’t copy and paste code from forum even for my own guides.
The community guides have no guarantees about their quality. In fact, I’ve seen numerous guides being praised while being very dubious. That’s not something you would like to copy-paste.
There is no way to authenticate their content, and it wouldn’t be difficult for an attacker to create an account and edit a community guide (the guides are wiki posts) with a lot of good comments from members with a high “trust level” (that’s a discourse term).
For something convenient while serious, you can take a look at:
https://qubes.3isec.org/tasks.html
There are many more essential improvements to learn and achieve with the official documentation. The first step would be to understand Qubes architecture (or, like me, not really understanding it but having a vague idea of the mindset):
As long as the community guide creator or a community member creates a salt for it yeah its easy as pie, otherwise no
On the other hand this is a slippery slope which can lead to backdoors the same way the AUR is always getting infected and even if we get enough mods to vet the salts then who is going to vet the mods?
Remember vigilance is always the most important rule so even IF we had a community repo with salts you would still have to vet the salt yourself
It’s one of the reasons I haven’t shared my gentoo qubesos setup yet because its TOO COMPLICATED
Then you are trusting opinions instead of auditing source code, the Privacy Guides Community is structured exactly for the former:
The process I take is to hand-translate the guide to private scripting in my own style. That way every line gets audited (at my capability, anyway) and I learn a bit. But the drawback is what you said, it’s laborious. I haven’t done half the stuff I’d like to. And a further drawback is my scripts will bit-rot, they have an unknown expiry date.
It’s the point of compromise I’ve found between ultimate trust and from-scratch.
In my defense, you’re probably smarter than me.
can i see your gentoo qubes os setup or salts?
Stay on topic, you may be interested in this guide:
Look at my profile on other posts, I have described the whole process and why every setting is the way it is, I am trying to minimize compilation time, outside forces affecting my compilation, storage usage, ram usage and the storage of locally compiled packages, as well as having the same portage db between qubes
Edit: oops off topic
Related:
Like others, I’m against any dom0 configuration un-reviewed by dom0 admin. Even if it is reviewed by the core team there is no guarantee that a good package is compatible with your customizations.
For the guest side, however, there are solutions native to the configuration management systems commonly used on Qubes. Salt has gitfs, and ansible has ansible-pull. Getting gitfs working on qubes is one of the things I’m working on. ansible-pull should work out of the box since you run it in the target system, not dom0.