qubes-issues
qubes-issues copied to clipboard
QubesOS
Graphical Package Manager Support
The problem you're addressing (if any)
The fedora template "Software" graphical installer does not work out of the box, despite being one of the default template shortcuts. This leads to terrible advice like enabling internet access to the TemplateVM.
The current way of installing software is through the terminal, which constitutes a terrible user experience, especially for someone just coming from a windows background.
Describe the solution you'd like
To solve this problem, a graphical software installer like fedora's "software" or debian's synapse or other alternative ones and allow them to connect to the internet through the updates proxy, for exmaple.
Where is the value to a user, and who might that user be?
Software installation is something users can't do without. And for people without IT or linux background it's a big usability challenge they will have to overcome. Even if later on they end up learning to use the terminal, it is important that they can do basic stuff like installing software, without having to learn to use the terminal.
Describe alternatives you've considered
Fedora's software, debian's synapse. But there are probably many other software "stores". But there is a problem with fedora's "software" program in the sense that is is not just a wrapper to DNF. It gets things like images and software description probably from redhat's servers, I would imagine.
Additional context
Discussion stemmed from the forum: GUI-only software installation: Thoughts? (fedora)
The following picture is what the user sees if they open the default "software" application on the fedora template. As you can see, it fails to fetch software because it can't reach the internet.
On the picture bellow you can see what the user sees after enabling internet connection on the TemplateVM
Contrast this with the daunting experience of opening a terminal for the first time and typing commands.
Relevant documentation you've consulted
- removal of mention of software installer from the docs: https://github.com/QubesOS/qubes-doc/commit/4202598824031b9ff3e025bc5ed6113dcaf8f98c
Related, non-duplicate issues
Crossposting here a preliminary "investigation" I did for the implications of enabling internet access to the fedora graphical software installer. And I'm sure this extends to other distro's installers that are more usable a than simple package manager command wrapper.
Potential user-related dangers
Updating to fedora-33 via "Software application"
As you can see on the picture bellow, there is an option to upgrade from fedora-32.
After testing a bit it seems the "restart and update" button gets stuck which prevents the user from completing the potentially problematic action. But this can lead to user confusion as the software didn't perform what was expected by the user.
User starts doing internet-related tasks on TemplateVM
note: as suggested by @unman, this would be solved by making the "Software" application go through the updates proxy by default.
Because in order to make this work, one has to enable internet access, it may be possible the user starts using stuff like a web browser on the template VM, which defaults their entire purpose.
Opening the browser by mistake
On the templateVMs we want to minimise as much as possible running software. And the browser is probably the most complex software that could be ran.
When visiting a particular piece of software's installation page, the interface present two buttons [website] and [Donate] which when clicked will open the browser.
Making it simple to enable third-party repos
The software center makes it extremely easy to enable third-party repositories. Which may not be desireable for the user from the security standpoint.
Potential technical risks
Increase attack surface (complex code)
Running a complex GUI application, can increase the attack surface.
Increase attack surface (internet access)
I don't know exactly how the software center for fedora works under the hood, but I can imagine there is much less scrutiny as to how the protocol works. For typical package mangers, the protocol is probably well defined and it can even work with mirrors, but with the software center, I can imagine it only fetches the images from one source, for example
Technical reason why it doesn't work is https://github.com/QubesOS/qubes-issues/issues/3815
dnfdragora offers a built-in support into TemplateVM. As it uses dnf as backend, you can graphically manage your packages with it. I've posted a screenshot of it. It's clear and simple.
I can confirm dnfdragora works without any extra modifications (it is likely a true wrapper for dnf). I can also confirm that for debian-based distros synaptic works as well (since it's just an aptitude wrapper)
For both of these, the user experience in not great, but I believe it's better than a terminal for novice users.
Ideally, there would be a program that is package manager agnostic so that some consistency across different distributions. Does anyone know of such a package manager?
@ninavizz you may have some thoughts on this.
If this happens at all, I strongly recommend starting with one of these simple dnf/apt wrappers. In case the rationale is not already obvious, I'll make it explicit:
- The more complex the solution, the higher the security risk.
- The more complex the solution, the more time and work required, hence the less likely it is to get done and into users' hands any time soon.
- The perfect is the enemy of the good.
- Implementing something that is "good enough" for now does not prevent doing something better later. In the mean time, users can actually benefit from it.
Just linking here to a user detailing this exact issue/frustration: https://qubes-os.discourse.group/t/new-user-feedback-running-into-walls/2784/3
Implementing something that is "good enough" for now does not prevent doing something better later. In the mean time, users can actually benefit from it.
If it is not a significant effort to implement something that is "good enough" that can give us a baseline to begin user research from, while also unblocking less technical users, I would also see this as a total win.
FYI, @micahflee has just published "Qube Apps: a Flatpak-based app store for each qube", which looks very cool and might be of interest to folks here.
I got GNOME software to work, it's a bit hacky though but I let you decide if it's something that could be shipped by default.
GNOME Software needs to have a default route to be happy -_-
#!/bin/sh
sudo ip link add dummy0 type dummy
sudo ip link set dummy0 up
sudo ip addr add 192.168.0.1/24 dev dummy0
sudo ip route add default via 192.168.0.2 dev dummy0
Attaching a network interface to the template but denying everything in the firewall also works, but this is bad compared to this solution.
I opened an issue upstream https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2336
Does it use the updates proxy then? In the past it did not: https://github.com/QubesOS/qubes-issues/issues/3815#issuecomment-381128917
Does it use the updates proxy then? In the past it did not: #3815 (comment)
Yes, of course. Packages are downloaded on lo0 by reaching http://127.0.0.1:8082
And anyway, the packages are pulled without the template being connected to the internet, so it can't get them by any mean but the proxy
The dummy interface is just thin air, it doesn't lead anywhere, doesn't connect to anything. I wonder if I can make a default route using 127.0.0.1, that would be even "better".
Using
ip route add default via 127.0.0.1works!
Incredible find. If this doesn't have unintended consequences, I would advocate for this to be put on 4.2. @marmarta tagging you so this is on your radar.
Having gnome software working would be such a quality-of-life improvement, especially with such a simple fix. Currently the docs instruct the users to temporarily connect the template to the internet.
A cleaner fix was provided in this gnome-software issue https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2330#note_1842682
mkdir -p /home/user/.config/environment.d/
echo "GIO_USE_NETWORK_MONITOR=base" > /home/user/.config/environment.d/fix.conf
This indeed helps a bit, application gets installed. But at the end I got Unable to install "(null)" as not supported message.
And also, "updates" tab flashes every second, and in the background I see it queries PackageKit for available updates (this works), but also it complains about "Failed to get cache filename for emacs-filesystem". And updates-shell: failed to get upgrades: [*/*/*/fedora-pkgdb-collections/*] Failed to download https://admin.fedoraproject.org/pkgdb/api/collections/: Cannot resolve hostname: Error resolving "admin.fedoraproject.org": Temporary failure in network resolution.
I mean, it's expected it won't reach it, but it would be better if it either try once, or maybe disable this part?
The "Update" button doesn't seem to work - it changes to "Restart & Update...", but clicking it doesn't do anything either. Not even any error message.
Anyway, since this is clearly an improvement, I'll add setting this variable.
thank you all for your efforts on this topic, i think it is very important & maybe the final missing piece to users being able to use Qubes OS without needing immediate familiarity with the command line.
it would be great to have functional GUI package managers for users going forward: R4.3 and any future updated official templates.
from the discussion here, it seems like synaptic for default debian and whonix templates, and dnfdragora for default fedora template. i have also tested and confirmed they work fine -- honestly they have pretty similar workflows which is great.
i'm including @adrelanos since this touches upon whonix templates as well.
Even though I think they are a bit of a UX tragedy compared to more graphical stores, you're right in that this is possibly the best compromise within the available solutions. Specifically because we're talking about software that would run in a template. I have an alternative proposal for running stuff in non-templates, but it is more complex. So I think this one is preferable in the short-term.
Improved Discoverability
But I think one crucial aspect is the discoverability aspect. Even if these GUI package managers are made available in the template's menu by default, user's don't necessarily know that "Dnfdragora" is "the software install tool" (same for the synaptic).
So I would advocate for factoring in discoverability.
Naive solution: change .desktop name
Renaming the desktop entries to "software store (synaptic)" would be the most pragmatic implementation for improved discoverability.
"Install Software" dedicated menu entry
or, alternatively (and preferably), adding a qubes-feature that stores the .desktop entry for the default software store.
When said template has such a feature enabled, the menu could show a button like this:
The image above suggests that this would also be available on regular app qubes. That's because I took it from my other feature suggestion. But the simplest implementation would be to just add the "install software" to the templates and nothing else.
Lastly, by going down this "install software" menu button path, it not only makes it more obvious how to install software, but has the potential not confuse users as much if it's ever moved to a different piece of software by default.
yes you are right, while synaptic lists itself as Synaptic Package Manager dnfdragora lists itself as dnfdragora which is not helpful. having a shared reference for them both would be valuable for the user.
the dedicated / emphasized menu item would be very nice, and yes it depends on the time/capacity we have. looping in @marmarta for their thoughts/consideration.
i think one aspect that would need UX consideration (maybe as a further/future effort) is users dont initially understand that the software listed in the qube menu is not the only software installed, it is just the software added to the menu. so there are situations where software is actually installed but they do not understand how to surface it.
or put another way, the user has just used the Install Software button to install some software, but it does not show up on their app menu -- there is some missing guidance to the user to complete the circle of user intention. like maybe if the Install Software is selected within a qube, then that new software entry is added automatically to that qube's menu.
You're right. This has extra UX implications. But implementation-wise (were it not for UX considerations) I don't think it would be complicated:
- Official templates could already have " default-software-menu-item" by default
- Adding another widget to the menu which simply starts starts said application in the template
to be fair/clear tho, those issues already exist with the current software installation workflows, so your suggestion is not adding these implications, just further surfacing them (with the hope we address them :).
i like your suggestion a lot and it would be a big improvement for us to include it.
I generally agree with the idea of putting an "Add Software" button in the menu, but I think it might better communicate what it does if it opened the Applications page of VM Settings, or, to be more precise, a redesigned page which would have:
- more explanation about when the programs come from
- a way to run the discussed-above installer in the template/qube (depending on whether we're running it for an appvm or a template/standalone)
Something I would really like, and I suppose a lot of people would appreciate, would be to have some text area in template's settings where you list packages to install, this would be used as a package list for salt. There would be a "Install packages" button on that GUI. It would also refresh all qubes application list using this template.
This would allow people to easily copy/paste the list from one template to another, without having to figure how to run salt manually or how to write states as root in dom0.
The UX appearance would be raw, but should be effective.
I know there is no interest into this, I remember suggesting it a while ago on matrix, but I wanted to share it publicly here anyway.
Something I would really like, and I suppose a lot of people would appreciate, would be to have some text area in template's settings where you list packages to install, this would be used as a package list for salt. There would be a "Install packages" button on that GUI. It would also refresh all qubes application list using this template.
This would allow people to easily copy/paste the list from one template to another, without having to figure how to run salt manually or how to write states as root in dom0.
The UX appearance would be raw, but should be effective.
I know there is no interest into this, I remember suggesting it a while ago on matrix, but I wanted to share it publicly here anyway.
I suggest opening a separate issue for this. It sounds a bit off topic for this issue.