See this thread.
1 Like
I’d like to see better changelogs, it’s currently hard to guess what changed between 4.1 and 4.2, and the item list in the RC announcements are really vague.
1 Like
- I will find it nice that the default’s icons of the XFCE templates will be the same as those of Dom0. Like that, we’ll find a similar desktop in the sys-gui and sys-gui-gpu sessions.
- Have the Documentation available in other languages
(I’m from France and sometimes, it was difficult to understand it even with translation’s sites. I can help for that if you want. 
I think a lot of people miss it! lol But from what I could understand, it seems quite difficult
Unfortunately, it seem very difficult for these reason:
1 Like
for hardened sys-usb and sys-net check liteqube.
1 Like
here is my wishlist. qubes is awesome btw , thanks for working on it
in order of importance
1- full support for machine sleep / standy using s0x sleep state (i believe this has upstream dependency on xen to support fully). many modern laptops don’t support s3 sleep so this is a must have.
2-fido support for login (hardware key)
3-improved change management for dom0 - snapshots, rollbacks, etc.
4-optimize backups (incremental vs full backup).
thanks
1 Like
suspend/resume compatibility improved a lot in the incoming 4.2 release 
1 Like
thank you @solene
i have tested latest rc3 on my dell XPS, the machine doesn’t suspend properly. i am keeping an eye on this issue scheduled for 4.3 milestone
4.2 isn’t out yet, so 4.3 is far far away
yep , I will need to wait for 4.3 
more info on XPS sleep issue on this thread
1 Like
I managed to get it working. It took me quite a bit of time and it’s not perfect. I can’t where I posted my setup right now but ping me if I forget to post some more context.
But in the very least it requires a discrete GPU
1 Like
I think this is a great feature, which could be added in version 4.2
6 Likes
Controllable intrusion monitoring based on selinux in non-enforceing mode, with a daemon that offboards the triggered avc alerts to a central monitoring VM “sys-mon” or “sys-avc”. Once configured properly, if any system file is accessed or modified in an unexpected manner that would trigger an alert upstream in the sys-mon VM before it can have any real affect on that monitored VM. Doing this will not prevent the cow writes to the system files but it will send an alert as to what application triggered the alert so that the offending app or process session can be more closely monitored by the user.
Example: Should for any reason there be a breach in sys-net due to some exploit in a protocol or vulnerability in the network adaptor any subsequent searching and probing of that VM would trigger a cascade of avc events while That intruder is identifying the environment to decide how to exploit the OS and install their toolkit. The sys-mon would detect this before the malware has even dropped and installed.
Same deal with user apps and rogue plug-ins. Any plug in that reaches outside the configured bounds of the parent app would trigger avc alerts by those actions and sys-mon would alert the user of the nefarious operations currently underway.
The deal is to give warnings to the user/system before the VM is completely compromised. Selinux has many capabilities that could be tapped into and a complete rule set that can be modified and updated as necessary to customize the user’s system. We just need to trap the avc errors and forward them before the intruder has a chance to completely take over the VM. You may not be able to prevent an unknown adversary using unknown tools to circumvent your system but you can detect the tampering they are doing to set that up. Even doing a find or an ls in the wrong part of the file system from the wrong process context would be enough to trigger such an alert. Doing it from the proper context would not. The rules are configurable, and this capability is already there in the OS kernel software, it’s just not being compiled into the current distribution.
One lightweight service to propagate those alerts is a small price to pay for peace of mind. In the net-mon VM you could have processing that triggers rules for snapshots or automatically taking a VM offline in response to certain actions giving it the possibility for unattended mitigation where certain exploits may not be patched yet. Rules could be shared and updated across platforms. You would finally have a high level view of any unexpected tampering of your system and rules that can mitigate a real-time attack.
Qubes is designed for security, but it is completely blind to the common threats out in the wild. This model could change all that. It would also be adjustable based on your personal threat model, and using salt could even be managed across an enterprise.
9 Likes
My top favorites:
- lan/smb share connection speed improvements
- progress in qubes backup and restore
- disabled focus stealing by default (this is a minor security/privacy issue)
1 Like
I’m happy with Qubes if I had to put out a wishlist I guess it would be:
-
More official support and up to date documentation for setting up an audio domain for the coming 4.2 including pipewire. Existing doc on qubes-os.org is just a developer guide. I’ve found plenty of unofficial guides and I haven’t tried them all but I haven’t had any luck with a working audio domain since early 4.0 and maybe early 4.1. And maybe a UI with granular control over both Speaker and Mic access.
-
I haven’t tried it yet but I seen an interesting split webcam solution on the forum that would definitely be a security improvement from a personal security perspective in my opinion. Given all the endless video conf calls these days seems like a good idea. a UI controlling cam access would be nice too, possibly with an option to grant temp access that is revoked after the Qube shuts down? Maybe similiar for at least the Mic side for sys-audio.
-
If at all possible (I understand it’s not easy of course) some expanded hardware compatibility for sys-gui-gpu.
-
I haven’t tried KDE in a while so this comment may be inaccurate. However the last time I did in 4.1.2 it was kinda mostly functional, but a little smoothing of the rough edges functionally in relation to Qubes functionality might be nice. If that’s already been done I apolagize for mentioning it.
Although I have to say the changes to XFCE in 4.2 are a GREAT improvement and much appreciated! I may just stick with XFCE at this point, although I think I will install KDE anyway just to take a look at any possible changes -
Oh sorry one more. A real annoyance the shutdown or restart (it seems to just be restart at the moment). But just sitting there on a black screen still powered on forcing me to hold the power button. That seems to have come and go over time as Qubes updates are applied on my Dell machines, not a new one for 4.2 but really annoying
-
I can think of 1 or 2 things Windows related but honestly I don’t know if I care any more. As long as I continue to have the ability to keep a Windows VM functional I’m happy. A functional Windows VM or two was a requirement for me for certain professional tasks and it’s there. Without that I could never have made this a full time OS. I keep my use to a bare minimum and the VM’s are restricted to outbound communication to specific internal IP’s. So improvements may be nice but not of a priority anymore as long as the VM’s are severely locked down communication wise for me. I just ask that they keep functioning
However I have no doubt others certainly have different feelings of course.
3 Likes
I would like to be able to “restart” a sys-net service template from qubes tray icon, even when sys-firewall is running, without having to open Terminal in sys-net and run “sudo reboot”, which shuts the template down and then having to manually start sys-net again.
Update: that apparently possible from the “Qubes Manager” window. Thanks @solene for pointing out
4 Likes
And that should be possible, when updating a template in Qubes OS 4.2 it asks if it should reboot VMs, this includes sys-net, and will do a full reboot by itself properly.
Yet, using the GUI or CLI, the best I came with is qvm-kill sys-net && qvm-start sys-net 
2 Likes
wondering if there is a way to configure 4.2 Q menu and sort my AppVMs (APPS) to subgroups, otherwise this remains a wish 
1 Like