Won’t these salt scripts be problematic for users with non-standard Whonix VM names? whonix-gw, sys-whonix, whonix-ws, anon-whonix seem to be hardcoded?
I see instructions have steps for updating qubes.UpdatesProxy for differently named VMs. Not sure what anon-whonix.sls does but sys-whonix and whonix-ws-dvm may not exist on existing 3.2 systems.
Simple GUI would be useful for managing qubes.UpdatesProxy. @iry Would go in Dom0 / System Tools: Whonix Update Manager
Which templates would you like to update through Whonix?
Which whonix gateway VM would you like to use to update?
Use clearnet or onion repos? (currently both are used)
Not a fan of GUI everything but this is something most users will probably have to deal with. Lots of syntax errors bound to happen.
Can’t qubes.UpdatesProxy be set automatically by Global UpdateVM settings? (maybe that setting doesn’t exist in R4?)
Yes, so it will be an issue documenting. When you create a VM based on whonix-ws, then it will probably inherit the tag anon-vm. Could you verify please?
But what when cloning a Whonix TemplateVM?
When you upgrade a pre-R4 released Whonix template, it might not have the tag anon-vm. So the cloned would not have either. So it needs to be manually set.
And when you start with a new R4 installation and clone it, gets to tag anon-vm inherited? Could you verify please?
Yes, currently not easy.
Not that I know. NetVM is set to none which will certainly confuse lots of users. That looks strange in qubes-vm-settings. Next to NetVM perhaps there should be a field UpdateVM next to the NetVM setting in qubes-vm-settings, which would define i.e. configure /etc/qubes-rpc/policy/qubes.UpdatesProxy?
Global Qubes VM setting UpdateVM as far as I know only configures what dom0 shall use.
I would like to confirm if you are proposing a potentially useful GUI application called Whonix Update Manager which will work in dom0 for Qubes 4 and/or later?
I can definitely look into the problem but could you and @Patrick share some insights on these two questions first:
Can this problem be solved alternatively than using a GUI application nicely?
How long will this GUI application be useful aproximately?
It’s not clear to me users would notice there is a Qubes-Whonix Update GUI so we could still have this issue, even if an Qubes-Whonix Update GUI could make it easier to change the settings.
@iry Thanks for checking in. I think @Patrick’s ideas would address my usability concerns and at the same time, be more consistent with the Qubes’ UX. We should save your talents for more important projects.
BTW, can anon-connection-wizard configure apt.sources to only use onion repos or clearnet repos? What’s the point of using onion repos if we’re downloading clearnet versions anyway? other than redundancy?
@iry Thanks for checking in. I think @Patrick’s ideas would address my usability concerns and at the same time, be more consistent with the Qubes’ UX. We should save your talents for more important projects.
Great!
BTW, can anon-connection-wizard configure apt.sources to only use onion repos or clearnet repos?
No, that’s not the right tool for it. anon-connection-wizard is more
like tor-connection-wizard (did you ask about the name change @iry?) so
no unrelated features should be mixed into it.
What’s the point of using onion repos if we’re downloading clearnet versions anyway? other than redundancy?
It’s a big change. With Whonix 14 we’re doing a big scale test if these
are working stable. If it is working stable, it will be onion only for
Whonix 15.
I have several applications that had been failing to start in Whonix 14. Unsetting environmental variable XDG_CONFIG_DIRS seems to fix most of them.
TorMessenger is one such application.
CoyIM may have been another.
I am testing several communications applications in Qubes 3.2/Whonix 14. Including RetroShare, CoyIM, Ricochet, Riot.im, CoyIM, TorMessenger, etc etc
Several of these would not start, and I noticed that some were throwing segmentation fault errors. So, I found the posts about torbrowser crashing, and was able to apply the same advice.
I assume there are no security risks with unsetting this variable? It will just default to some order of searching config directories?
Any idea what is causing the crash? Directories listed that do not exist perhaps?
I am on testers, and just upgraded (several whonix packages including whonixcheck and whonix-legacy), but after rebooting all of Qubes, I am still Seg Faulting.
I still need to unset the variable in order to run.
user@host:~$ riot-web
Segmentation fault
user@host:~$ unset XDG_CONFIG_DIRS && riot-web
Starting auto update with base URL: https://riot.im/download/desktop/update/
Auto update not supported on this platform
Upgraded whonix-legacy package should be uploaded soon. When that happens, please upgrade. Then shutdown all Whonix VMs. Then restart the TemplateBasedVMs. (The usual process to make ṕackage upgrades take effect in TemplateBasedVMs.) Should be fixed by then.
Good question.