Qubes ready to install for Journalist-Human Rights workers

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:

  • extrepo and ext-repo-offline being deployed and back-ported to Qubes repo in time. Now available into bookworm unman’s debian-12 template. This will permit documentation to fill the gap of enabling custom repositories securely.
  • working caching update proxy (cacher project from unman being fascinating solution), well tested and stabilized. So that salt recipes that specialize debian-minimal templates are doing what they intend to do and nothing else, reducing liability issues into promoting one thing or the other, while minimizing download throughput required to maintain all those specialized templates (otherwise, having 6 specialized templates for multimedia, redaction, communication, etc will consume 6x the bandwidth which does not fit the bill here for precarious requirements. Nobody has time to wait for the same updates to be downloaded 6x including repository data.)
  • Have Windows Templates if needed and be able to compartmentalize usage as in any other Templates, including disposable Windows Template.

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.

3 Likes

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 :frowning:

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 :slight_smile:

Just something that can:

  • open Salt files and view them in terms of what they do
  • potentially create your own

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 :slight_smile:

1 Like

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.

1 Like

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.

2 Likes

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.

1 Like

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?

For curious

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?

Summary

[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.sls

$template_base:
  qvm.template_installed:
    - name: $template_base

clone.sls

builder_requisite:
  qvm.template_installed:
    - name: $template_base

qvm-clone-id:
  qvm.clone:
    - name: template-builder
    - source: $template_base

clone.top

base:
  dom0:
    - match: nodegroup
    - $custom_qube.clone

config.sls

/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

config.top

base:
  builder:
    - $custom_qube.config

create.sls

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

create.top

base:
  dom0:
    - match: nodegroup
    - $custom_qube.create

install.sls

# 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}

install.top

# vim: set syntax=yaml ts=2 sw=2 sts=2 et :

base:
  $template_name:
  - $custom_qube.install

$custom_qube.spec

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:

  1. Where to put the various sls and top files for it to work
  2. Create a bash script to populate the variables
  3. Maybe create a fancy GUI dialog box that does this too
3 Likes

/srv/salt?

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
structures.

@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

Anyway…

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
updates.

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
know.
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:
    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 %}

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.

1 Like

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

I hate to revive this threat, but the transition to R4.2 shows why Qubes OS is not ready to install for journalists and human rights workers. VPN no longer works. The desktop environment is different. Some applications are XFCE and different from Gnome. Where did text editor go? Oh, it’s now mousepad!? Suddenly there’s a new learning curve.

I had separate conversations in the recent weeks with human rights people working with those living in hostile environments. Everyone needs Qubes OS. And yet none of the persons who spoke to me said Qubes OS is usable. Certainly note for helping people in difficult environments to install it and use it.

For Qubes OS to be usable by journalists and human rights workers, a dedicated non-profit organizations needs to be set up to provide ongoing support / training / coaching to the end user.

Edit / addition: I have great appreciation for the work of the Qubes developers. I certainly do not want my posts to discourage them. When I post, I consider myself as a Qubes advocate. I have offered to train some hr orgs on Qubes after using it for many years now and I keep mentioning it.

4 Likes