Consider an option to ask for RPC target VM in dom0

[marmarek]

Reported by marmarek on 28 Oct 2014 13:49 UTC
This would allow for example copy some files out of VM, without telling the VM name of target VM.

In case of filecopy, it would not change user experience - user will still get a single prompt for VM name. In fact it will even simplify some things:

• can get rid of ugly VM name prompt on Windows
• can use the same script for nautilus and dolphin (no need to use zenity/kdialog to match the interface there)
• finally - can use the same prompt for VM name and service confirmation (when policy says "ask")

Technically, when source VM sends empty target VM field in service request, qrexec-policy would handle this case and show the prompt, instead of failing the request.

Migrated-From: https://wiki.qubes-os.org/ticket/910

[marmarek]

Comment by marmarek on 28 Oct 2014 13:52 UTC
Additionally dom0 know full VM list, so it can be drop-down list, without a risk of information leak.

Discussion:
https://groups.google.com/d/msg/qubes-users/0lIEQ01gtDA/ajxcuT_GqmsJ

[marmarek]

Comment by marmarek on 28 Oct 2014 13:52 UTC
Additionally dom0 know full VM list, so it can be drop-down list, without a risk of information leak.

Discussion:
https://groups.google.com/d/msg/qubes-users/0lIEQ01gtDA/ajxcuT_GqmsJ

[marmarek]

Comment by joanna on 31 Oct 2014 12:07 UTC
Yes. But I think in R3.

[marmarek]

Comment by joanna on 31 Oct 2014 12:07 UTC
Yes. But I think in R3.

[rootkovska]

See: https://groups.google.com/forum/#!msg/qubes-devel/xLZU0R5ijCg/_Lk1tXp9BwAJ

[rootkovska]

See: https://groups.google.com/forum/#!msg/qubes-devel/xLZU0R5ijCg/_Lk1tXp9BwAJ

[marmarek]

Moving discussion from #2436:

I think the target VM argument should be preserved. There are multiple cases when you want to simply allow action for specific target VM without bothering user with confirmation. For example in 'devel' VM you may want to copy the outcome to some 'testing' VM where you run various tests. You don't want to select 'testing' VM hundreds times a day (you have a script to call qvm-copy-to-vm, or simply call it from shell history), but on the other hand you still may want to occasionally copy some files to a different VM.

This means I wouldn't touch the cases when policy explicitly says 'allow'. If you have policy some-vm $anyvm allow, it means that 'some-vm' VM will be able to learn list of VMs. If you don't want that, do not add such line to the policy.

The case of 'deny' action for existing vs non-existing target VM is easy - error message (if any) should not be blocking.

I should note that policy right now allow also to override target VM choice. You may specify something like:

some-vm $anyvm allow,target=another-vm

Currently it means "whatever existing target VM name (if any) was provided, redirect service to another-vm". Should be: "whaveter target VM name is, redirect service to another-vm". Of course unless earlier rule says otherwise.

The thing to reconsider is what about 'ask' action. There are few cases:

• calling VM provided target VM and it exists (and policy says 'ask')
• calling VM provided target VM and it does not exist (but default action says 'ask')
• calling VM did not provided target VM at all (and default action says 'ask')

Currently each of those cases are handled differently:

• if target VM is provided and it exists you get the confirmation prompt, if it does not exists, you get (blocking) error message
• if target VM is not provided, it is this ticket - user should be prompted to select one

I think non-existing target VM should be treated as no target VM provided at all (still - if the default action is 'ask').

So, we have two things to design:

• what VMs should be listed in the prompt - initial idea was: all whose policy action would be "allow" or "ask".
• (related to above) how to differentiate - if desired at all - between target VM selected in service call and target VM selected by the user in policy prompt - this IMO applies only to 'ask' action - should the policy prompt for specific target differ from prompt without target VM specified? Or maybe both should allow to select target VM, even if caller provided one?

And some UX issue: what should be the default target in that dialog (if any). If called provided one - I think it should be used), but otherwise - anything at all?
/cc @jpouellet

[marmarek]

Moving discussion from #2436:

I think the target VM argument should be preserved. There are multiple cases when you want to simply allow action for specific target VM without bothering user with confirmation. For example in 'devel' VM you may want to copy the outcome to some 'testing' VM where you run various tests. You don't want to select 'testing' VM hundreds times a day (you have a script to call qvm-copy-to-vm, or simply call it from shell history), but on the other hand you still may want to occasionally copy some files to a different VM.

This means I wouldn't touch the cases when policy explicitly says 'allow'. If you have policy some-vm $anyvm allow, it means that 'some-vm' VM will be able to learn list of VMs. If you don't want that, do not add such line to the policy.

The case of 'deny' action for existing vs non-existing target VM is easy - error message (if any) should not be blocking.

I should note that policy right now allow also to override target VM choice. You may specify something like:

some-vm $anyvm allow,target=another-vm

Currently it means "whatever existing target VM name (if any) was provided, redirect service to another-vm". Should be: "whaveter target VM name is, redirect service to another-vm". Of course unless earlier rule says otherwise.

The thing to reconsider is what about 'ask' action. There are few cases:

• calling VM provided target VM and it exists (and policy says 'ask')
• calling VM provided target VM and it does not exist (but default action says 'ask')
• calling VM did not provided target VM at all (and default action says 'ask')

Currently each of those cases are handled differently:

• if target VM is provided and it exists you get the confirmation prompt, if it does not exists, you get (blocking) error message
• if target VM is not provided, it is this ticket - user should be prompted to select one

I think non-existing target VM should be treated as no target VM provided at all (still - if the default action is 'ask').

So, we have two things to design:

• what VMs should be listed in the prompt - initial idea was: all whose policy action would be "allow" or "ask".
• (related to above) how to differentiate - if desired at all - between target VM selected in service call and target VM selected by the user in policy prompt - this IMO applies only to 'ask' action - should the policy prompt for specific target differ from prompt without target VM specified? Or maybe both should allow to select target VM, even if caller provided one?

And some UX issue: what should be the default target in that dialog (if any). If called provided one - I think it should be used), but otherwise - anything at all?
/cc @jpouellet

[jpouellet]

A first thought is to have the list of VMs always displayed, and the source-specified intended-target be the initial selection of that dropdown (or in case of text box: have it pre-populated with name of intended target). I don't know how I feel about that though, since I feel like it leads to building a user habit of simply pressing enter whenever source-suggested target exists, and what happens when one day the source is malicious and suggests a different target? User habit is still to press enter! Would they even notice the difference? Likely not...

Therefore, I think handling both "ask" cases (with and without suggested target) as if there were never a suggested target would be a good thing.

Another case we need to consider is an ... ... ask,target=foo rule. Is this even meaningful anymore? If so, which target should win (user specified vs. target=)?

[jpouellet]

A first thought is to have the list of VMs always displayed, and the source-specified intended-target be the initial selection of that dropdown (or in case of text box: have it pre-populated with name of intended target). I don't know how I feel about that though, since I feel like it leads to building a user habit of simply pressing enter whenever source-suggested target exists, and what happens when one day the source is malicious and suggests a different target? User habit is still to press enter! Would they even notice the difference? Likely not...

Therefore, I think handling both "ask" cases (with and without suggested target) as if there were never a suggested target would be a good thing.

Another case we need to consider is an ... ... ask,target=foo rule. Is this even meaningful anymore? If so, which target should win (user specified vs. target=)?

[marmarek]

and what happens when one day the source is malicious and suggests a different target? User habit is still to press enter! Would they even notice the difference? Likely not...

The point is to have only subset of VMs there - so it should be impossible to execute "dangerous" operation. Of course for that, someone would need to select which VMs should be there (set policy to 'deny' for others - or even 'deny' by default and 'ask' for a few). And the case you've described is exactly what we currently have - only a confirmation of what calling VM requested. I'm not saying it's the best possible, but not bad either. I think much bigger problem with it is focus stealing (#1166) - it's simple enough to guess when user will press enter and execute some qrexec operation just before...

Another case we need to consider is an ... ... ask,target=foo rule. Is this even meaningful anymore? If so, which target should win (user specified vs. target=)?

That's a good question. I'd say in that case, target= means what should be suggested, but the final decision is up to the user. Maybe this is the way to go: have target VM prefilled only when defined as such in policy, otherwise empty by default (even when specified by source VM)?

[marmarek]

and what happens when one day the source is malicious and suggests a different target? User habit is still to press enter! Would they even notice the difference? Likely not...

The point is to have only subset of VMs there - so it should be impossible to execute "dangerous" operation. Of course for that, someone would need to select which VMs should be there (set policy to 'deny' for others - or even 'deny' by default and 'ask' for a few). And the case you've described is exactly what we currently have - only a confirmation of what calling VM requested. I'm not saying it's the best possible, but not bad either. I think much bigger problem with it is focus stealing (#1166) - it's simple enough to guess when user will press enter and execute some qrexec operation just before...

Another case we need to consider is an ... ... ask,target=foo rule. Is this even meaningful anymore? If so, which target should win (user specified vs. target=)?

That's a good question. I'd say in that case, target= means what should be suggested, but the final decision is up to the user. Maybe this is the way to go: have target VM prefilled only when defined as such in policy, otherwise empty by default (even when specified by source VM)?

[jpouellet]

I think much bigger problem with it is focus stealing

I agree, but my point was that even with perfect focus stealing prevention, pre-populating target in UI according to suggestion from (un-trusted!) rpc source seems to me a bad idea. It conditions users to accept the default, where the default is attacker-controlled.

That's a good question. I'd say in that case, target= means what should be suggested, but the final decision is up to the user.

Sounds reasonable to me.

Maybe this is the way to go: have target VM prefilled only when defined as such [target=] in policy, otherwise empty by default (even when specified by source VM)?

Yes. This sounds to me like the best option.

[jpouellet]

I think much bigger problem with it is focus stealing

I agree, but my point was that even with perfect focus stealing prevention, pre-populating target in UI according to suggestion from (un-trusted!) rpc source seems to me a bad idea. It conditions users to accept the default, where the default is attacker-controlled.

That's a good question. I'd say in that case, target= means what should be suggested, but the final decision is up to the user.

Sounds reasonable to me.

Maybe this is the way to go: have target VM prefilled only when defined as such [target=] in policy, otherwise empty by default (even when specified by source VM)?

Yes. This sounds to me like the best option.

[boring-stuff]

Hi, I'd like to start on this.
Should I begin with implementing the Qt dialog first, the best place for this looks like guihelpers.py? I'd then integrate it in qrexec-policy and allow an empty target.

Also, should I follow any particular Qt guidelines at all?

[boring-stuff]

Hi, I'd like to start on this.
Should I begin with implementing the Qt dialog first, the best place for this looks like guihelpers.py? I'd then integrate it in qrexec-policy and allow an empty target.

Also, should I follow any particular Qt guidelines at all?

[marmarek]

Actually, GTK would be better, as new Qubes Manager would be in GTK, and also it will be more consistent with now default Xfce environment. I think it's better to create separate python file this GUI dialog.
Anyway the overall plan looks ok :)

[marmarek]

Actually, GTK would be better, as new Qubes Manager would be in GTK, and also it will be more consistent with now default Xfce environment. I think it's better to create separate python file this GUI dialog.
Anyway the overall plan looks ok :)

[boring-stuff]

Noted.
I've prototyped the window in glade and am hooking onto the elements via IDs, so that designers can later on change the .glade file without touching the code.
I'd also shoot for a re-usable python class that leverages a gtk combobox listing a subset of the domains, including colored icons.

Question: how's the test strategy here? Are they all integration tests, or are there unit tests as well? How can I add testcases, and run them in a local environment? Are they all in tests, or somewhere else?

[boring-stuff]

Noted.
I've prototyped the window in glade and am hooking onto the elements via IDs, so that designers can later on change the .glade file without touching the code.
I'd also shoot for a re-usable python class that leverages a gtk combobox listing a subset of the domains, including colored icons.

Question: how's the test strategy here? Are they all integration tests, or are there unit tests as well? How can I add testcases, and run them in a local environment? Are they all in tests, or somewhere else?

[andrewdavidwong]

Thanks for taking this on, @boring-stuff! I've added this to the community-developed feature tracker.

[andrewdavidwong]

Thanks for taking this on, @boring-stuff! I've added this to the community-developed feature tracker.

[marmarek]

Question: how's the test strategy here? Are they all integration tests, or are there unit tests as well? How can I add testcases, and run them in a local environment? Are they all in tests, or somewhere else?

Yes, most tests are there. In Qubes 3.x we have only integration tests, but for Qubes 4.x (for which this feature is targeted), we also have unit tests. Take a look at core3-devel branch, especially here:
https://github.com/QubesOS/qubes-core-admin/tree/core3-devel/qubes/tests
There is also an API to have tests in other repositories (here - basically expose an endpoint for qubes.tests.extra.for_template), but I think it would be an overkill for this case.

I think at minimum we should have few tests calling qrexec-policy (directly) with various arguments:

• valid source and destination domains, policy action deny, ask, allow
• policy overriding target domain
• various invalid values (service name, destination domain, invalid domain entered by the user etc)

Some existing integration tests (calling this through the whole stack - so from one VM to another):

• https://github.com/QubesOS/qubes-core-admin/blob/core3-devel/qubes/tests/int/vm_qrexec_gui.py#L322-L367
• https://github.com/QubesOS/qubes-core-admin/blob/core3-devel/qubes/tests/int/vm_qrexec_gui.py#L537-L644

Also, IMO qrexec-policy tool should really belong to qubes-core-admin, not qubes-core-admin-linux repository. I'm going to move it there, but for your convenience you can continue to work on it in the old place.
Also, it's not so easy to have working working Qubes 4.0 installation to test stuff there ;) so you can work on this in Qubes 3.2 - while there are some API changes, should be minimal in this code.

[marmarek]

Question: how's the test strategy here? Are they all integration tests, or are there unit tests as well? How can I add testcases, and run them in a local environment? Are they all in tests, or somewhere else?

Yes, most tests are there. In Qubes 3.x we have only integration tests, but for Qubes 4.x (for which this feature is targeted), we also have unit tests. Take a look at core3-devel branch, especially here:
https://github.com/QubesOS/qubes-core-admin/tree/core3-devel/qubes/tests
There is also an API to have tests in other repositories (here - basically expose an endpoint for qubes.tests.extra.for_template), but I think it would be an overkill for this case.

I think at minimum we should have few tests calling qrexec-policy (directly) with various arguments:

• valid source and destination domains, policy action deny, ask, allow
• policy overriding target domain
• various invalid values (service name, destination domain, invalid domain entered by the user etc)

Some existing integration tests (calling this through the whole stack - so from one VM to another):

• https://github.com/QubesOS/qubes-core-admin/blob/core3-devel/qubes/tests/int/vm_qrexec_gui.py#L322-L367
• https://github.com/QubesOS/qubes-core-admin/blob/core3-devel/qubes/tests/int/vm_qrexec_gui.py#L537-L644

Also, IMO qrexec-policy tool should really belong to qubes-core-admin, not qubes-core-admin-linux repository. I'm going to move it there, but for your convenience you can continue to work on it in the old place.
Also, it's not so easy to have working working Qubes 4.0 installation to test stuff there ;) so you can work on this in Qubes 3.2 - while there are some API changes, should be minimal in this code.

[boring-stuff]

I understand, thanks for the hints! Is there a way of getting into a simulated environment without using an extra physical machine for this?

As an example, I'd like to use the Gtk equivalent of getting a VM's icon (See this as an example), but when I run it in a VM it fails, since no such icons are installed in the templates. The icons are not even in the same repository, so there's no way to reference them directly.
Another example is trying to import qubes.qubes which fails, since the main python files are under "core" until they get installed at the proper location.

Am I missing some way of setting up a testing environment? This is no blocker btw as I do use stubs for as long as I need to, but it would help...

[boring-stuff]

I understand, thanks for the hints! Is there a way of getting into a simulated environment without using an extra physical machine for this?

As an example, I'd like to use the Gtk equivalent of getting a VM's icon (See this as an example), but when I run it in a VM it fails, since no such icons are installed in the templates. The icons are not even in the same repository, so there's no way to reference them directly.
Another example is trying to import qubes.qubes which fails, since the main python files are under "core" until they get installed at the proper location.

Am I missing some way of setting up a testing environment? This is no blocker btw as I do use stubs for as long as I need to, but it would help...

[marmarek]

I understand, thanks for the hints! Is there a way of getting into a simulated environment without using an extra physical machine for this?

Generally it's tricky... I haven't tried this for a long time. In theory it's easier for Qubes 4.0 (some unit tests can be run directly from git, so it works). See run-tests script in core3-devel branch.
Some approximation of separate physical machine may be a system started from separate partition or USB disk. Not very convenient, but for some development stage should be ok.

As an example, I'd like to use the Gtk equivalent of getting a VM's icon (See this as an example), but when I run it in a VM it fails, since no such icons are installed in the templates. The icons are not even in the same repository, so there's no way to reference them directly.

You can add appropriate repository, then download artwork and other packages, then install them with rpm -i --nodeps. It's major hack, but for this particular case should work.

Another example is trying to import qubes.qubes which fails, since the main python files are under "core" until they get installed at the proper location.

Similar here. You can do the same with locally built package. But import qubes.qubes, or try to loading qubes.xml will probably try to connect to libvirt, enumerate VMs etc, which will fail in VM. You can try setting dry_run at the beginning of qubes.py, but this mode isn't maintained for a long time...

[marmarek]

I understand, thanks for the hints! Is there a way of getting into a simulated environment without using an extra physical machine for this?

Generally it's tricky... I haven't tried this for a long time. In theory it's easier for Qubes 4.0 (some unit tests can be run directly from git, so it works). See run-tests script in core3-devel branch.
Some approximation of separate physical machine may be a system started from separate partition or USB disk. Not very convenient, but for some development stage should be ok.

As an example, I'd like to use the Gtk equivalent of getting a VM's icon (See this as an example), but when I run it in a VM it fails, since no such icons are installed in the templates. The icons are not even in the same repository, so there's no way to reference them directly.

You can add appropriate repository, then download artwork and other packages, then install them with rpm -i --nodeps. It's major hack, but for this particular case should work.

Another example is trying to import qubes.qubes which fails, since the main python files are under "core" until they get installed at the proper location.

Similar here. You can do the same with locally built package. But import qubes.qubes, or try to loading qubes.xml will probably try to connect to libvirt, enumerate VMs etc, which will fail in VM. You can try setting dry_run at the beginning of qubes.py, but this mode isn't maintained for a long time...

[jpouellet]

@boring-stuff Thanks for tackling this. One less item on my personal to-do list :)

Is there a way of getting into a simulated environment without using an extra physical machine for this?

So... partially. I wanted this too for various reasons. I had some success with running Qubes inside Qubes:

• In the outer Qubes, create an HVM vm, and install Qubes on it (advanced tab lets you attach an installer CD ISO).
• You can run only PV VMs inside that inner Qubes instance.

I did not get networking working (because sys-net requires working PCI passthrough of the emulated network device, and AFAIK qemu can't). It was annoying, but still enough for testing things requiring proper inter-VM communication.

[jpouellet]

@boring-stuff Thanks for tackling this. One less item on my personal to-do list :)

Is there a way of getting into a simulated environment without using an extra physical machine for this?

So... partially. I wanted this too for various reasons. I had some success with running Qubes inside Qubes:

• In the outer Qubes, create an HVM vm, and install Qubes on it (advanced tab lets you attach an installer CD ISO).
• You can run only PV VMs inside that inner Qubes instance.

I did not get networking working (because sys-net requires working PCI passthrough of the emulated network device, and AFAIK qemu can't). It was annoying, but still enough for testing things requiring proper inter-VM communication.

[boring-stuff]

Thanks for the support and answers! I might try the HVM because from now on I'll be mostly blindly coding without it, but it might take some time.

First, a status report: the gtkhelpers.py utility (tests here) now can show a Gtk confirmation window, depending on the parameters source and target (which is None by default).

The core/gtkhelpers.py along with the gtk folder can be copied in the qubes module directly, and plug into it.

Simulated test (in any VM):

1. checkout https://github.com/boring-stuff/qubes-core-admin.git
2. first comment out import qubes from core/gtkhelpers.py
3. run python tests/gtkhelpers.py -w to show a window with dummy entries (icons will default to gnome-foot if not found)
4. run python tests/gtkhelpers.py -t to run it as a unittest

Note: the unit tests are quite extensive, but they're not yet integrated in the build process. They don't perform any edit to the configuration whatsoever, but instead mostly use mock classes exactly to avoid that. Also the import should be fixed, depending on the environment in which they're run.

Usage (in a dom0):

from qubes.rpcconfirmation import RPCConfirmationWindow

print RPCConfirmationWindow.confirm_rpc("sys-net", "qubes.Filecopy")
print RPCConfirmationWindow.confirm_rpc("sys-net", "qubes.Filecopy", "sys-firewall")
print RPCConfirmationWindow.confirm_rpc("sys-net", "qubes.Filecopy", "non-existing")
print RPCConfirmationWindow.confirm_rpc("sys-net", "qubes.Filecopy", "sys-net")

The user must/can then select (and eventually override, if target != None) a destination domain and confirm with ok. The function then returns e.g. {'target_name': 'my-vm-name', 'target_id': 5} with a confirmation, and False if cancel is pressed, or the window is closed.

Activities and ToDos

• Create main confirmation window
• Make selection combo searchable
• Display source domain and service name in table-like view
• Render source domain with the colored lock
• The ESC key cancels the dialog
• Fix the Gtk Warning because of ComboBox column hack
• Separate the RPC window in a dedicated module
• Add OK button sensitivity delay after window focus
• Exclude additional VMs from the list, as specified by the qrexec-policy call (the "deny" case)
• Create integration tests for the file transfer
• Integrate the unit tests in the build process
• Integrate in qrexec-policy (handling the target= case as the only case for a prefill)

[boring-stuff]

Thanks for the support and answers! I might try the HVM because from now on I'll be mostly blindly coding without it, but it might take some time.

First, a status report: the gtkhelpers.py utility (tests here) now can show a Gtk confirmation window, depending on the parameters source and target (which is None by default).

The core/gtkhelpers.py along with the gtk folder can be copied in the qubes module directly, and plug into it.

Simulated test (in any VM):

1. checkout https://github.com/boring-stuff/qubes-core-admin.git
2. first comment out import qubes from core/gtkhelpers.py
3. run python tests/gtkhelpers.py -w to show a window with dummy entries (icons will default to gnome-foot if not found)
4. run python tests/gtkhelpers.py -t to run it as a unittest

Note: the unit tests are quite extensive, but they're not yet integrated in the build process. They don't perform any edit to the configuration whatsoever, but instead mostly use mock classes exactly to avoid that. Also the import should be fixed, depending on the environment in which they're run.

Usage (in a dom0):

from qubes.rpcconfirmation import RPCConfirmationWindow

print RPCConfirmationWindow.confirm_rpc("sys-net", "qubes.Filecopy")
print RPCConfirmationWindow.confirm_rpc("sys-net", "qubes.Filecopy", "sys-firewall")
print RPCConfirmationWindow.confirm_rpc("sys-net", "qubes.Filecopy", "non-existing")
print RPCConfirmationWindow.confirm_rpc("sys-net", "qubes.Filecopy", "sys-net")

The user must/can then select (and eventually override, if target != None) a destination domain and confirm with ok. The function then returns e.g. {'target_name': 'my-vm-name', 'target_id': 5} with a confirmation, and False if cancel is pressed, or the window is closed.

Activities and ToDos

• Create main confirmation window
• Make selection combo searchable
• Display source domain and service name in table-like view
• Render source domain with the colored lock
• The ESC key cancels the dialog
• Fix the Gtk Warning because of ComboBox column hack
• Separate the RPC window in a dedicated module
• Add OK button sensitivity delay after window focus
• Exclude additional VMs from the list, as specified by the qrexec-policy call (the "deny" case)
• Create integration tests for the file transfer
• Integrate the unit tests in the build process
• Integrate in qrexec-policy (handling the target= case as the only case for a prefill)

[boring-stuff]

Wait, this should actually affect all of the RPC actions, not just the filecopy, right? Then I'll first change the template and names to be a generic one, before starting with further integration...

[boring-stuff]

Wait, this should actually affect all of the RPC actions, not just the filecopy, right? Then I'll first change the template and names to be a generic one, before starting with further integration...

[marmarek]

Wait, this should actually affect all of the RPC actions, not just the filecopy, right?

Yes...

[marmarek]

Wait, this should actually affect all of the RPC actions, not just the filecopy, right?

Yes...

[boring-stuff]

Updated my previous comment, names and semantic fixed.

[boring-stuff]

Updated my previous comment, names and semantic fixed.

[marmarek]

Generally looks good!
Minor comments:

• can we have more structured message, like source domain and service name in table-like view, for example:

Source qube: <b>%s</b>\n
Action: <b>%s</b>\n

IMO that would make easier to quickly read the important parts.

• target VM name selection should be search-able/filterable - to allow entering VM name by keyboard (or enter few characters, then select from list). You know, some of us have a lot of qubes ;)

[marmarek]

Generally looks good!
Minor comments:

• can we have more structured message, like source domain and service name in table-like view, for example:

Source qube: <b>%s</b>\n
Action: <b>%s</b>\n

IMO that would make easier to quickly read the important parts.

• target VM name selection should be search-able/filterable - to allow entering VM name by keyboard (or enter few characters, then select from list). You know, some of us have a lot of qubes ;)

[marmarek]

later: launch GUI part as separate process, inside user session (through d-bus?) - this will be required for GUI domain, where mere setting DISPLAY is not enough

Chosen this option right now - it was just few lines of code.

[marmarek]

later: launch GUI part as separate process, inside user session (through d-bus?) - this will be required for GUI domain, where mere setting DISPLAY is not enough

Chosen this option right now - it was just few lines of code.

[qubesos-bot]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-4.0.0-1.fc24 has been pushed to the r4.0 testing repository for the Fedora fc24 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-4.0.0-1.fc24 has been pushed to the r4.0 testing repository for the Fedora fc24 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-4.0.0-1.fc25 has been pushed to the r4.0 testing repository for the Fedora fc25 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-4.0.0-1.fc25 has been pushed to the r4.0 testing repository for the Fedora fc25 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.0-1+deb8u1 has been pushed to the r4.0 testing repository for the Debian jessie template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing jessie-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.0-1+deb8u1 has been pushed to the r4.0 testing repository for the Debian jessie template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing jessie-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.0-1+deb9u1 has been pushed to the r4.0 testing repository for the Debian stretch template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-agent_4.0.0-1+deb9u1 has been pushed to the r4.0 testing repository for the Debian stretch template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update