Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
whonix-ws-based VMs lack the anon-vm tag #3595
Qubes OS version:
Steps to reproduce the behavior:
VM ready for anonymous use.
Maybe whonix-ws should also have anon-vm tag too, and any VM's based on it should inherit it.
This part is a duplicate of #3561 (which also answers your parenthetical question).
I've updated the title of this issue to be about only this second part.
I'm not sure I understand how #3561 is relevant to the first issue.. #3561 says that default_dispvm of anon-whonix is correctly whonix-ws-dvm regardless of qubes-prefs setting, but I am talking about newly-created whonix-ws-based VMs.
Regardless of what default_dispvm is for either the premade anon-whonix AppVM or the whonix-ws template, new whonix-ws-based VMs get default_dispvm from qubes-prefs, which I think(?) defaults to fedora-26-dvm.
Edit: On second thought, the other issue is now about something distinct enough that it no longer makes sense to combine these two. Filed separately as #3601.
It looks like properly creating new Whonix-ws based VM require multiple steps. We can create core-admin extension that would handle all this automatically. Some thing like:
We can add more to the list above, if needed. And also create similar thing for custom whonix gateways.
This would be a python class, with just one function. I think it should be in separate package. Maybe "qubes-core-admin-addon-whonix" ?
About hardcoding names above: we could use "features" on the template to allow overriding it, for example:
Or some alternative logic - like looking for a VM based on whonix-ws with "template_for_dispvms" set to True. And taking the first one such VM.
After implementing this, the user experience would be(*): create new AppVM based on whonix-ws template, the system will take care about the rest.
(*) almost - the VM creation dialog contains "netvm" setting, which is applied after creating the VM. In theory it is possible to catch this from core-admin extension (something like "intercept the first netvm change"), but it is hacky and I'd like to avoid it.
@adrelanos what do you think?
That's the idea for #3447.
Trying to wrap my head around this. It is really complex.
My summary answer is: Generally sounds awesome!
Your question in parentheses is really difficult. For now, perhaps hardcoded to
Similar to above.
Alright with me.
That sounds ideal.
No good solution for that through qvm-features?
Besides technical issue, there is also UX issue - the setting from that dialog is going to be ignored, overridden or such. One idea is to apply netvm setting from that dialog only if was explicitly changed to something else than default. But then still - it will be listed as "default (sys-firewall)", but in reality created VM will have "sys-whonix" netvm. The problem is that the dialog have no means to know that before actually creating the VM (other than duplicating the logic from the extension we're talking about here).
README is not long, but I think it explains what it does. To test it, you need:
VMs created with
I would say rename internally to
Yes, please do.
For this it is too late.
Done. For now, named
Some testing done. Could you join the discussion please?