Consider Qubes Screenshot Tool

[marmarek]

Reported by axon on 16 Feb 2015 11:02 UTC
The ability send dom0 screenshots directly to an AppVM/DispVM from the screenshot app is an oft-requested feature (see below). The ability to transfer saved screenshot files from dom0 to other VMs is already available, but it is neither obvious nor easy for most users to do this.

User requests/queries about this:
https://groups.google.com/d/topic/qubes-devel/m8TfyvSqvf4/discussion
https://groups.google.com/d/topic/qubes-devel/CwSPqtPYTRQ/discussion
https://groups.google.com/d/topic/qubes-devel/_a7KxHbkSJo/discussion
https://groups.google.com/d/topic/qubes-users/l6vOqhsd7ss/discussion
https://groups.google.com/d/topic/qubes-users/etxwrc6rsIM/discussion
https://groups.google.com/d/topic/qubes-users/_7FzKv6eJqA/discussion

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

[marmarek]

Some details here: https://groups.google.com/d/msgid/qubes-devel/20150708022217.GH900%40mail-itl

[marmarek]

Some details here: https://groups.google.com/d/msgid/qubes-devel/20150708022217.GH900%40mail-itl

[ptitdoc]

What about a tool in dom0 that scan changes in ~/QubesOutgoing/[VMname]/ folder and send it to the AppVM ~/QubesIncoming/dom0 when available ?

For instance, when you take screenshots, you just have to save it to the right folder.

[ptitdoc]

What about a tool in dom0 that scan changes in ~/QubesOutgoing/[VMname]/ folder and send it to the AppVM ~/QubesIncoming/dom0 when available ?

For instance, when you take screenshots, you just have to save it to the right folder.

[marmarek]

I think the best solution is to use #1324 (qvm-copy-to-vm tool for dom0)
and make it a handler for screenshooting tool.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

I think the best solution is to use #1324 (qvm-copy-to-vm tool for dom0)
and make it a handler for screenshooting tool.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[mfc]

fyi with KSnapshot (the current screenshot tool) one cannot screenshot a specific window, freehand region, etc., even when selected. Such functionality would be quite helpful for creating Qubes documentation.

[mfc]

fyi with KSnapshot (the current screenshot tool) one cannot screenshot a specific window, freehand region, etc., even when selected. Such functionality would be quite helpful for creating Qubes documentation.

[marmarek]

Are you sure? I've just tried and it seems to work well:

1. Press Print Screen to start the tool
2. Select capture mode
3. Click "Take a New Snapshot"
4. Select region/window/whatever
5. Confirm with Enter (or double-click) - instructions are on the
   screen.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

Are you sure? I've just tried and it seems to work well:

1. Press Print Screen to start the tool
2. Select capture mode
3. Click "Take a New Snapshot"
4. Select region/window/whatever
5. Confirm with Enter (or double-click) - instructions are on the
   screen.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[mfc]

never mind! worked great, thanks for the steps.

I misunderstood how it worked, I thought changing the settings would change the default of pressing Print Screen. Instead one has to select Take a New Snapshot.

[mfc]

never mind! worked great, thanks for the steps.

I misunderstood how it worked, I thought changing the settings would change the default of pressing Print Screen. Instead one has to select Take a New Snapshot.

[Jeeppler]

Ksnapshot is getting a new version for KDE 5 based on KScreenGenie. On which KDE version will Qubes R3.2 or 4.0 be based on?

[Jeeppler]

Ksnapshot is getting a new version for KDE 5 based on KScreenGenie. On which KDE version will Qubes R3.2 or 4.0 be based on?

[andrewdavidwong]

On which KDE version will Qubes R3.2 or 4.0 be based on?

The plan is to use KDE 5.

[andrewdavidwong]

On which KDE version will Qubes R3.2 or 4.0 be based on?

The plan is to use KDE 5.

[Jeeppler]

Is there any usable Qubes R4.0 or R3.2 available to develop the screenshot tool?

[Jeeppler]

Is there any usable Qubes R4.0 or R3.2 available to develop the screenshot tool?

[marmarek]

I'm going to upload some preliminary R3.2 image somehow today/tomorrow.
Anyway this isn't much different than R3.1 - see: #1324 (comment)

[marmarek]

I'm going to upload some preliminary R3.2 image somehow today/tomorrow.
Anyway this isn't much different than R3.1 - see: #1324 (comment)

[Jeeppler]

@marmarek I think the Desktop Entry solution, you mentioned in the comment, has several draw backs. First it does not work on all desktop environments and secondly you have to open the PNG file, as far as I understand it.

For my understanding it would be better to have a screen shoot tool which invokes the qvm-move-to-vm command. The tools should move the screenshot directly to a qube and only ask to start the destination qube if the destination qube is not running.

I think KSnapshot is a really nice tool to take snapshots with, but I don't know if it works reliable on XCFE or other desktop environments.

[Jeeppler]

@marmarek I think the Desktop Entry solution, you mentioned in the comment, has several draw backs. First it does not work on all desktop environments and secondly you have to open the PNG file, as far as I understand it.

For my understanding it would be better to have a screen shoot tool which invokes the qvm-move-to-vm command. The tools should move the screenshot directly to a qube and only ask to start the destination qube if the destination qube is not running.

I think KSnapshot is a really nice tool to take snapshots with, but I don't know if it works reliable on XCFE or other desktop environments.

[marmarek]

It is simply available as one of applications to open screenshot with, see here:

This one is from Xfce4. In KDE it lands under "Open with" menu (or "Send to" in KDE4).

[marmarek]

It is simply available as one of applications to open screenshot with, see here:

This one is from Xfce4. In KDE it lands under "Open with" menu (or "Send to" in KDE4).

[Jeeppler]

Looks good, but what should be developed or created to be able to close this issue?

[Jeeppler]

Looks good, but what should be developed or created to be able to close this issue?

[marmarek]

A tool to ask for target VM name - qvm-move-to-vm-prompt

[marmarek]

A tool to ask for target VM name - qvm-move-to-vm-prompt

[Jeeppler]

What would be the preferred programming language and graphical toolkit to develop such a prompt? Should it look like the prompts Qubes OS already has to copy files from one VM to another?

[Jeeppler]

What would be the preferred programming language and graphical toolkit to develop such a prompt? Should it look like the prompts Qubes OS already has to copy files from one VM to another?

[marmarek]

As usual - python. As for toolkit - currently it is mostly in Qt (especially the current qrexec confirmations). But since the long term goal is to implement new Qubes Manager in GTK and to add GNOME support, GTK is also ok. If it doesn't matter for you, I'd choose GTK.

[marmarek]

As usual - python. As for toolkit - currently it is mostly in Qt (especially the current qrexec confirmations). But since the long term goal is to implement new Qubes Manager in GTK and to add GNOME support, GTK is also ok. If it doesn't matter for you, I'd choose GTK.

[Jeeppler]

Is it possible to have access to the Qubes API via Python3?

[Jeeppler]

Is it possible to have access to the Qubes API via Python3?

[marmarek]

On Thu, May 19, 2016 at 01:57:54AM -0700, Jeppler wrote:

Is it possible to have access to the Qubes API via Python3?

Not yet, unfortunately...

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Thu, May 19, 2016 at 01:57:54AM -0700, Jeppler wrote:

Is it possible to have access to the Qubes API via Python3?

Not yet, unfortunately...

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[greenrd]

Unfortunately "send to" in KSnapshot does not currently work - it says "qvm-run: error: To many arguments" [sic]. Should I file another bug for that?

[greenrd]

Unfortunately "send to" in KSnapshot does not currently work - it says "qvm-run: error: To many arguments" [sic]. Should I file another bug for that?

[marmarek]

@greenrd it isn't done yet - "Other application" option you see there is not what is meant to be used here.

[marmarek]

@greenrd it isn't done yet - "Other application" option you see there is not what is meant to be used here.

[Jeeppler]

I think it would be a good idea to schedule this task till Qubes OS uses KDE 5 and Python 3.

[Jeeppler]

I think it would be a good idea to schedule this task till Qubes OS uses KDE 5 and Python 3.

[ghost]

Jeppler:

I think it would be a good idea to schedule this task till Qubes OS uses KDE 5 and especially Python 3.

I would like to expand on this as propose an application for video
capturing. This for future educational material for new users, and video
is easier to digest than long pages of text with screenshots.

[ghost]

Jeppler:

I think it would be a good idea to schedule this task till Qubes OS uses KDE 5 and especially Python 3.

I would like to expand on this as propose an application for video
capturing. This for future educational material for new users, and video
is easier to digest than long pages of text with screenshots.

[Jeeppler]

@dumbl3d0re your idea should be in a new issue. In general the idea of having a video capture tool in Qubes OS is a good idea.

This issue is primarily talking about using KSnapshots 'send to' function. The question is which video capturing tool does KDE or linux in general provide for capturing videos?

[Jeeppler]

@dumbl3d0re your idea should be in a new issue. In general the idea of having a video capture tool in Qubes OS is a good idea.

This issue is primarily talking about using KSnapshots 'send to' function. The question is which video capturing tool does KDE or linux in general provide for capturing videos?

[andrewdavidwong]

On 2016-07-02 13:57, Eva Star wrote:

Okey. I released tool that can automatically capture
fullscreen/windows/regions and upload it to AppVM and imgurl automaticaly.

Now it is in beta state and tested only with Qubes 3.2rc1, but I think it
will work with other Qubes starting from R3.0 or R3.1 (where qvm-run is
available)

Full description and download you can find here:

https://github.com/evadogstar/qvm-screenshot-tool

Test it and I hope you will be happy with it as I am :) Because screenshots
is one weak side of Qubes (before this tool done ;)

Plans:

• add editor for images at AppVM to blur some arias on image... (suggest
  are welcome)
• multiple selections -> one screenshots -> upload it
• delayed screenshots
• maybe uploading any existed image from dom0 to imgurl after selecting it
  on dialog

Enjoy but remember that is only beta

Other notes:

• It is ready for GNOME and it's developed and tested under XFCE

[andrewdavidwong]

On 2016-07-02 13:57, Eva Star wrote:

Okey. I released tool that can automatically capture
fullscreen/windows/regions and upload it to AppVM and imgurl automaticaly.

Now it is in beta state and tested only with Qubes 3.2rc1, but I think it
will work with other Qubes starting from R3.0 or R3.1 (where qvm-run is
available)

Full description and download you can find here:

https://github.com/evadogstar/qvm-screenshot-tool

Test it and I hope you will be happy with it as I am :) Because screenshots
is one weak side of Qubes (before this tool done ;)

Plans:

• add editor for images at AppVM to blur some arias on image... (suggest
  are welcome)
• multiple selections -> one screenshots -> upload it
• delayed screenshots
• maybe uploading any existed image from dom0 to imgurl after selecting it
  on dialog

Enjoy but remember that is only beta

Other notes:

• It is ready for GNOME and it's developed and tested under XFCE

[evadogstar]

qvm-screenshot-tool updates and now support editing of image at dom0 before uploading it to AppVM and/or Imgurl

https://i.imgur.com/BZHFvJq.png

[evadogstar]

qvm-screenshot-tool updates and now support editing of image at dom0 before uploading it to AppVM and/or Imgurl

https://i.imgur.com/BZHFvJq.png

[evadogstar]

@marmarek What is the right way to store some temp.config values? Create some file with value or keys? Or use something other? Thanks

[evadogstar]

@marmarek What is the right way to store some temp.config values? Create some file with value or keys? Or use something other? Thanks

[marmarek]

It depends on exact purpose and use case, but temp file seems to be a good solution.

[marmarek]

It depends on exact purpose and use case, but temp file seems to be a good solution.

[marmarek]

I'm not sure if I understand your question correctly, can you elaborate? @evadogstar

[marmarek]

I'm not sure if I understand your question correctly, can you elaborate? @evadogstar

[evadogstar]

@marmarek

1. I want to store setting: i.e. last "VM name" from where image was uploaded to imgurl service. This need to reopen last closed dialog with results again by simply choose "Open last" from dom0 menu. I found that this will be useful feature.
   Estimated solution: file "~/.config/qvmscreenshot/lastvm.cfg" with content "personal" (to read it later)

2. Maybe, I want to implement some log of all uploaded urls.
   Estimated solution: file "~/.config/qvmscreenshot/log.txt" with full log.

3. "Config" for some script settings (available to change by user). Now, settings stored at the source. How to store/read them from separate file/QubesDB? What is better?

I do not want to reinvent the wheel with config)

[evadogstar]

@marmarek

1. I want to store setting: i.e. last "VM name" from where image was uploaded to imgurl service. This need to reopen last closed dialog with results again by simply choose "Open last" from dom0 menu. I found that this will be useful feature.
   Estimated solution: file "~/.config/qvmscreenshot/lastvm.cfg" with content "personal" (to read it later)

2. Maybe, I want to implement some log of all uploaded urls.
   Estimated solution: file "~/.config/qvmscreenshot/log.txt" with full log.

3. "Config" for some script settings (available to change by user). Now, settings stored at the source. How to store/read them from separate file/QubesDB? What is better?

I do not want to reinvent the wheel with config)

[marmarek]

1. I want to store setting: i.e. last "VM name" from where image was uploaded to imgurl service. This need to reopen last closed dialog with results again by simply choose "Open last" from dom0 menu. I found that this will be useful feature.
   Estimated solution: file "~/.config/qvmscreenshot/lastvm.cfg" with content "personal" (to read it later)

Yes, this seems like a good idea. Take a look here for more robust config handling from scripts (have one file, instead of one-per-value)

2. Maybe, I want to implement some log of all uploaded urls.
   Estimated solution: file "~/.config/qvmscreenshot/log.txt" with full log.

I think logs belong to ~/.local/share/..., at least X server store its log in ~/.local/share/xorg/Xorg.0.log.

3. "Config" for some script settings (available to change by user). Now, settings stored at the source. How to store/read them from separate file/QubesDB? What is better?

See "1". Maybe have two files - one with user changeable settings, the other with state from previous run?

[marmarek]

1. I want to store setting: i.e. last "VM name" from where image was uploaded to imgurl service. This need to reopen last closed dialog with results again by simply choose "Open last" from dom0 menu. I found that this will be useful feature.
   Estimated solution: file "~/.config/qvmscreenshot/lastvm.cfg" with content "personal" (to read it later)

Yes, this seems like a good idea. Take a look here for more robust config handling from scripts (have one file, instead of one-per-value)

2. Maybe, I want to implement some log of all uploaded urls.
   Estimated solution: file "~/.config/qvmscreenshot/log.txt" with full log.

I think logs belong to ~/.local/share/..., at least X server store its log in ~/.local/share/xorg/Xorg.0.log.

3. "Config" for some script settings (available to change by user). Now, settings stored at the source. How to store/read them from separate file/QubesDB? What is better?

See "1". Maybe have two files - one with user changeable settings, the other with state from previous run?

[evadogstar]

@marmarek About screencasts. All of such tools have a lot of dependencies (i.e. ffmpeg and other).
Is it possible/reasonable to add them to dom0? What you can say about screencasting ?
I found good tool for screencasting (it's open source):
https://github.com/colinkeenan/silentcast

[evadogstar]

@marmarek About screencasts. All of such tools have a lot of dependencies (i.e. ffmpeg and other).
Is it possible/reasonable to add them to dom0? What you can say about screencasting ?
I found good tool for screencasting (it's open source):
https://github.com/colinkeenan/silentcast

[v6ak]

In my opinion, there are generally two concerns when you are considering adding a 3rd party SW to dom0:

1. Do I trust it? (Do I trust there are no intentional backdoors?)
2. Is it secure enough?

The first one is rather a matter of choice than a technical question.

The security concern is the interesting one. While level of acceptable risk is not a technical question, the risk itself (at least partially) is. I believe there are not-yet-known vulnerabilities related to complex formats processing in ffmpeg and some other software you are considering. Exposing dom0 to those vulnerabilities can be considered at least strongly against Qubes philosophy. (If it is acceptable or not, it is up to you.) However, the key question is: Are those potential vulnerabilities likely to be exploitable? I don't think so. I expect the screenshots (in a simple bitmap format) and potentially a sound (in similarly simple raw format) to be the only untrusted inputs.

In short, after rather brief review, it looks OK to me provided that you trust the software not to be intentionally malicious.

[v6ak]

In my opinion, there are generally two concerns when you are considering adding a 3rd party SW to dom0:

1. Do I trust it? (Do I trust there are no intentional backdoors?)
2. Is it secure enough?

The first one is rather a matter of choice than a technical question.

The security concern is the interesting one. While level of acceptable risk is not a technical question, the risk itself (at least partially) is. I believe there are not-yet-known vulnerabilities related to complex formats processing in ffmpeg and some other software you are considering. Exposing dom0 to those vulnerabilities can be considered at least strongly against Qubes philosophy. (If it is acceptable or not, it is up to you.) However, the key question is: Are those potential vulnerabilities likely to be exploitable? I don't think so. I expect the screenshots (in a simple bitmap format) and potentially a sound (in similarly simple raw format) to be the only untrusted inputs.

In short, after rather brief review, it looks OK to me provided that you trust the software not to be intentionally malicious.

[marmarek]

Generally, if input is trusted, even complex tools are not a big problem.
The question is whether screen content (as a bitmap) can be treated as
trusted input. I find it very unlikely to crash/exploit some image/video
processor by just a bitmap (without control over its metadata). So,
should be safe.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

Generally, if input is trusted, even complex tools are not a big problem.
The question is whether screen content (as a bitmap) can be treated as
trusted input. I find it very unlikely to crash/exploit some image/video
processor by just a bitmap (without control over its metadata). So,
should be safe.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[andrewdavidwong]

@marmarek: Is this feature slated for inclusion in 4.0?

[andrewdavidwong]

@marmarek: Is this feature slated for inclusion in 4.0?

[evadogstar]

@andrewdavidwong my tool work well and do more than requested at first post

[evadogstar]

@andrewdavidwong my tool work well and do more than requested at first post

[ptitdoc]

Is there any work in progress on this topic ? Can we try contributing ?

If I followed the discussion properly there are two approaches:

• @evadogstar already wrote a screenshot client that allows editing screenshots, uploading to cloud services, sending it to specific VM, eventually edit the screenshot (in dom0?) and keep the history of where the screenshot is being sent.

  • PROs are features
  • CONs are dependencies, specific code for file upload and edition needs to be added to dom0, screenshot feature is not properly integrated into the panel (except if we create a specific action button into the panel)

• @marmarek is proposing to integrate into existing screenshot tools by using qvm-copy-to-vm the same way you can open a file with qvm-open-in-dvm in an AppVM (by calling a wrapper script). This requires writing a .desktop file and a script that wraps qvm-copy-to-vm with a widget that asks which AppVM the screenshot will be sent to.

  • PROs are flexibility of this approach, and the inocuity of code that needs to be written for dom0.
  • CONs are missing features such as screenshot edition (which could be delivered directly by the screen shot tool) or file upload to specific web services. Code is also still missing (however the script qvm-mru-entry available in AppVMs can probably be used).

To summarize, the second solution allows keeping dom0 clean but is missing automated features requested by end-users such as "share my screenshot" or "annotate my screenshot". This would require writing specific Qubes RPCs to "do something with my data coming from dom0 inside my AppVM", and I fear that it could cause incidents such as "oops I uploaded sensitive dom0 data by error".

[ptitdoc]

Is there any work in progress on this topic ? Can we try contributing ?

If I followed the discussion properly there are two approaches:

• @evadogstar already wrote a screenshot client that allows editing screenshots, uploading to cloud services, sending it to specific VM, eventually edit the screenshot (in dom0?) and keep the history of where the screenshot is being sent.

  • PROs are features
  • CONs are dependencies, specific code for file upload and edition needs to be added to dom0, screenshot feature is not properly integrated into the panel (except if we create a specific action button into the panel)

• @marmarek is proposing to integrate into existing screenshot tools by using qvm-copy-to-vm the same way you can open a file with qvm-open-in-dvm in an AppVM (by calling a wrapper script). This requires writing a .desktop file and a script that wraps qvm-copy-to-vm with a widget that asks which AppVM the screenshot will be sent to.

  • PROs are flexibility of this approach, and the inocuity of code that needs to be written for dom0.
  • CONs are missing features such as screenshot edition (which could be delivered directly by the screen shot tool) or file upload to specific web services. Code is also still missing (however the script qvm-mru-entry available in AppVMs can probably be used).

To summarize, the second solution allows keeping dom0 clean but is missing automated features requested by end-users such as "share my screenshot" or "annotate my screenshot". This would require writing specific Qubes RPCs to "do something with my data coming from dom0 inside my AppVM", and I fear that it could cause incidents such as "oops I uploaded sensitive dom0 data by error".

[ptitdoc]

I can confirm that qvm-mru-entry works in dom0 without any change.

[ptitdoc]

I can confirm that qvm-mru-entry works in dom0 without any change.

[ptitdoc]

@marmarek: can you provide your desktop entry somewhere ? I did not managed to create a desktop file that works properly with xfce4-screenshot.

[ptitdoc]

@marmarek: can you provide your desktop entry somewhere ? I did not managed to create a desktop file that works properly with xfce4-screenshot.

[marmarek]

Sure, it looks like this:

[Desktop Entry]
Type=Application
Name=Save image to testvm
Exec=qvm-move-to-vm testvm %F
MimeType=image/png;
NoDisplay=true

[marmarek]

Sure, it looks like this:

[Desktop Entry]
Type=Application
Name=Save image to testvm
Exec=qvm-move-to-vm testvm %F
MimeType=image/png;
NoDisplay=true

[ptitdoc]

After importing qvm-mru-entry in dom0 (in /usr/bin), the following two files are sufficient to make this working:

/usr/share/applications/qubes-movetovm.desktop:
[Desktop Entry]
Name=SaveToAppVM
GenericName=Save image to AppVM
Comment=Open an AppVM selector and save image in the selected AppVM
Exec=/usr/lib/qubes/qvm-move-to-vm.gnome
Icon=qubes-appmenu-select
Type=Application
Terminal=false
NoDisplay=true
Categories=Graphics;Viewer;
MimeType=application/x-navi-animation;image/bmp;image/x-bmp;image/x-MS-bmp;image/gif;image/x-icon;image/jpeg;image/png;image/x-portable-anymap;image/x-portable-bitmap;image/x-portable-graymap;image/x-portable-pixmap;image/x-cmu-raster;image/x-sun-raster;image/x-tga;image/tiff;image/vnd.wap.wbmp;image/x-xbitmap;image/x-xpixmap;image/svg;image/svg+xml;image/x-png;image/xpm;image/x-ico;image/x-pcx;
X-Desktop-File-Install-Version=0.22

/usr/lib/qubes/qvm-move-to-vm.gnome:
#!/bin/sh
VM=$(qvm-mru-entry --title="File Copy" --text="Enter the destination domain name:" --mrufile "qvm-mru-filecopy")
if [ X$VM = X ] ; then exit 0 ; fi

qvm-move-to-vm $VM "$@"

There are of course room for improvement such as:

• providing a drop-down list in qvm-mru-entry, but as qvm-mru-entry remembers the last entered vm, it is not a big improvement.
• providing some feedback to say that the file has been copied successfully, but again, I thing there is a popup if the copy failed, and a success message is just another spam popup for me.

[ptitdoc]

After importing qvm-mru-entry in dom0 (in /usr/bin), the following two files are sufficient to make this working:

/usr/share/applications/qubes-movetovm.desktop:
[Desktop Entry]
Name=SaveToAppVM
GenericName=Save image to AppVM
Comment=Open an AppVM selector and save image in the selected AppVM
Exec=/usr/lib/qubes/qvm-move-to-vm.gnome
Icon=qubes-appmenu-select
Type=Application
Terminal=false
NoDisplay=true
Categories=Graphics;Viewer;
MimeType=application/x-navi-animation;image/bmp;image/x-bmp;image/x-MS-bmp;image/gif;image/x-icon;image/jpeg;image/png;image/x-portable-anymap;image/x-portable-bitmap;image/x-portable-graymap;image/x-portable-pixmap;image/x-cmu-raster;image/x-sun-raster;image/x-tga;image/tiff;image/vnd.wap.wbmp;image/x-xbitmap;image/x-xpixmap;image/svg;image/svg+xml;image/x-png;image/xpm;image/x-ico;image/x-pcx;
X-Desktop-File-Install-Version=0.22

/usr/lib/qubes/qvm-move-to-vm.gnome:
#!/bin/sh
VM=$(qvm-mru-entry --title="File Copy" --text="Enter the destination domain name:" --mrufile "qvm-mru-filecopy")
if [ X$VM = X ] ; then exit 0 ; fi

qvm-move-to-vm $VM "$@"

There are of course room for improvement such as:

• providing a drop-down list in qvm-mru-entry, but as qvm-mru-entry remembers the last entered vm, it is not a big improvement.
• providing some feedback to say that the file has been copied successfully, but again, I thing there is a popup if the copy failed, and a success message is just another spam popup for me.

[evadogstar]

@ptitdoc It's not a lot of dependencies, because almost all tools already preinstalleted at the dom0. What do you mean with "integration into the panel" ? I use my tool every day and do not know why it's need any integration to the panel, because it's very simple to use key binding to run the script and it's traditional way to make screenshots and manipulate them.

About "special code to upload screenshots". It can be separated from the tool and pre-installeted at the template, then the script will use available code from selected appvm. I do not separate the code already, because it's a lot of additional actions to add 'upload script' to every template manually if the script can do it for you from dom0 for any unix-based appvm after selecting it from the list. It's user-friendly.

p.s. About editing screenshot: Is there any reasons to edit them at the destination VMs? Screenshot made at the dom0 and it's already safe (because it come from dom0). We have the tool to edit screenshoots at the dom0 by instated default. So, I think we can trust this tool, because we are already have it there, yes? Why not to edit taken screenshot at the dom0? Any reasons?

[evadogstar]

@ptitdoc It's not a lot of dependencies, because almost all tools already preinstalleted at the dom0. What do you mean with "integration into the panel" ? I use my tool every day and do not know why it's need any integration to the panel, because it's very simple to use key binding to run the script and it's traditional way to make screenshots and manipulate them.

About "special code to upload screenshots". It can be separated from the tool and pre-installeted at the template, then the script will use available code from selected appvm. I do not separate the code already, because it's a lot of additional actions to add 'upload script' to every template manually if the script can do it for you from dom0 for any unix-based appvm after selecting it from the list. It's user-friendly.

p.s. About editing screenshot: Is there any reasons to edit them at the destination VMs? Screenshot made at the dom0 and it's already safe (because it come from dom0). We have the tool to edit screenshoots at the dom0 by instated default. So, I think we can trust this tool, because we are already have it there, yes? Why not to edit taken screenshot at the dom0? Any reasons?

[jpouellet]

There seems to be some resistance to the upstreaming of @evadogstar's implementation due to its size and the question of whether editing screenshots should be done in dom0 in the first place.

In the interest of having something useful available, I've made a minimal alternative. It's quite simple, and perhaps best explained by screenshots ;)

You press the Print Screen key (or in some way invoke xfce4-screenshooter) and get SaveImageInVM as an option:

Then you get a list of running VMs, and select where to save the image:

And then it saves the screenshot there and opens the location where it saved it (~/QubesIncoming/dom0) in a file manager:

so you can then do whatever with it (like open it in gimp or whatever you prefer in an AppVM, instead of solidifying a dependency on ImageMagick in dom0 and asking people to actually learn to use the (IMO ugly and unfriendly) ImageMagick GUI)

Source here: https://github.com/jpouellet/qubes-screenshot-helper (qubes-builder friendly)

I'm happy to change the name of the repo or propose this as a PR against qubes-desktop-linux-common if preferred.

It could of course be improved, but lets start somewhere. This is small and probably does all of what most users really need. Right now everybody needs to qvm-copy-to-vm their screenshots from the command line, and that's not a friendly workflow.

[jpouellet]

There seems to be some resistance to the upstreaming of @evadogstar's implementation due to its size and the question of whether editing screenshots should be done in dom0 in the first place.

In the interest of having something useful available, I've made a minimal alternative. It's quite simple, and perhaps best explained by screenshots ;)

You press the Print Screen key (or in some way invoke xfce4-screenshooter) and get SaveImageInVM as an option:

Then you get a list of running VMs, and select where to save the image:

And then it saves the screenshot there and opens the location where it saved it (~/QubesIncoming/dom0) in a file manager:

so you can then do whatever with it (like open it in gimp or whatever you prefer in an AppVM, instead of solidifying a dependency on ImageMagick in dom0 and asking people to actually learn to use the (IMO ugly and unfriendly) ImageMagick GUI)

Source here: https://github.com/jpouellet/qubes-screenshot-helper (qubes-builder friendly)

I'm happy to change the name of the repo or propose this as a PR against qubes-desktop-linux-common if preferred.

It could of course be improved, but lets start somewhere. This is small and probably does all of what most users really need. Right now everybody needs to qvm-copy-to-vm their screenshots from the command line, and that's not a friendly workflow.

[jpouellet]

@evadogstar I don't mean to detract from your work. You've made a useful thing, and I thank you for contributing. I'm just trying to move things along, and I also prefer to do as little as we can in dom0.

[jpouellet]

@evadogstar I don't mean to detract from your work. You've made a useful thing, and I thank you for contributing. I'm just trying to move things along, and I also prefer to do as little as we can in dom0.

[marmarek]

This, and others, is blocked on setting up @QubesOS-contrib finally. To be honest, most of technical stuff is done - there are even package repository definitions. What is missing is a procedure to handle it:

• how to request package being added there
• what are inclusion criteria
• how to handle updates
  etc

Some of this was already discussed on qubes-devel, but not all. And we need to clarify all that and document it somewhere. @andrewdavidwong do you want to draft it? Anyway probably worth a separate ticket.

[marmarek]

This, and others, is blocked on setting up @QubesOS-contrib finally. To be honest, most of technical stuff is done - there are even package repository definitions. What is missing is a procedure to handle it:

• how to request package being added there
• what are inclusion criteria
• how to handle updates
  etc

Some of this was already discussed on qubes-devel, but not all. And we need to clarify all that and document it somewhere. @andrewdavidwong do you want to draft it? Anyway probably worth a separate ticket.

[andrewdavidwong]

@marmarek: Will do.

[andrewdavidwong]

@marmarek: Will do.

[evadogstar]

@jpouellet No problem, but with my tool it's also possible to easy save&move screenshot to AppVM then edit it with GIMP. ImageMagick is already there at dom0, but I'm also think that it's very ugly. If we will have some other pre-installeted image editor at the fedora template, then we can open screenshot with it, edit, then upload (or what user want).

P.S. Personally, I do NOT like the way to use default Qubes screenshot tool and "Open With" menu from it, because this tool can be changed (and it already changed on my mind from kde screenshot tool to current one. And it will changed on the future) and "Open With" will totally broken, while my implementation as separated will continue working and it can work at kde, xfce and at future gnome (not only at xfce).

[evadogstar]

@jpouellet No problem, but with my tool it's also possible to easy save&move screenshot to AppVM then edit it with GIMP. ImageMagick is already there at dom0, but I'm also think that it's very ugly. If we will have some other pre-installeted image editor at the fedora template, then we can open screenshot with it, edit, then upload (or what user want).

P.S. Personally, I do NOT like the way to use default Qubes screenshot tool and "Open With" menu from it, because this tool can be changed (and it already changed on my mind from kde screenshot tool to current one. And it will changed on the future) and "Open With" will totally broken, while my implementation as separated will continue working and it can work at kde, xfce and at future gnome (not only at xfce).

[jpouellet]

This came up on the mailing lists again: https://groups.google.com/d/topic/qubes-users/q1fizu46Pbs/discussion

What's this still blocking on?

If it's still waiting on @QubesOS-contrib, can we at least upstream at least my minimalist implementation in the mean time? It might not be the long-term ideal solution, but it provides a usable solution today to a real user issue which keeps coming back up.

[jpouellet]

This came up on the mailing lists again: https://groups.google.com/d/topic/qubes-users/q1fizu46Pbs/discussion

What's this still blocking on?

If it's still waiting on @QubesOS-contrib, can we at least upstream at least my minimalist implementation in the mean time? It might not be the long-term ideal solution, but it provides a usable solution today to a real user issue which keeps coming back up.

[jpouellet]

I've updated my minimal screenshot tool for R4. Any chance at getting it (or anything equivalent) merged? Users still have no easy way to get screenshots out of dom0.

[jpouellet]

I've updated my minimal screenshot tool for R4. Any chance at getting it (or anything equivalent) merged? Users still have no easy way to get screenshots out of dom0.

[unman]

On Thu, Mar 22, 2018 at 04:40:01PM -0700, Jean-Philippe Ouellet wrote: I've updated [my minimal screenshot tool](https://github.com/jpouellet/qubes-screenshot-helper) for R4. Any chance at getting it (or anything equivalent) merged? Users *still* have no easy way to get screenshots out of dom0.

I use KSnapshot. What's wrong with qvm-copy-to-vm run in dom0? Easy enough

[unman]

On Thu, Mar 22, 2018 at 04:40:01PM -0700, Jean-Philippe Ouellet wrote: I've updated [my minimal screenshot tool](https://github.com/jpouellet/qubes-screenshot-helper) for R4. Any chance at getting it (or anything equivalent) merged? Users *still* have no easy way to get screenshots out of dom0.

I use KSnapshot. What's wrong with qvm-copy-to-vm run in dom0? Easy enough

[jpouellet]

Easy enough for you and me, sure, but not everyone. I only developed the tool I did because I was asked to by someone for whom the command line was not a good solution.

Given that questions about getting screenshots out of dom0 keep coming up ([1] [2] [3] [4] & more that I don't feel like searching for), and how many people have independently rolled their own screenshot scripts at this point ([1] [2] [3] [4] [5] [6], etc.), I think the case for having something easier to use out of the box has already been well proven.

[jpouellet]

Easy enough for you and me, sure, but not everyone. I only developed the tool I did because I was asked to by someone for whom the command line was not a good solution.

Given that questions about getting screenshots out of dom0 keep coming up ([1] [2] [3] [4] & more that I don't feel like searching for), and how many people have independently rolled their own screenshot scripts at this point ([1] [2] [3] [4] [5] [6], etc.), I think the case for having something easier to use out of the box has already been well proven.

[andrewdavidwong]

Pinging @marmarek

[andrewdavidwong]

Pinging @marmarek

[jpouellet]

I'm not lobbying for my particular implementation here, I just want users to have something that works for them.

Personally, I think the criteria here should be:

• easy to use
• no additional attack surface
• no new dependencies
• supports R3.2 and R4
• minimal complexity

I believe mine fits all of the above, and it's already a component you can just drop into qubes-builder, but anything else is welcome too.

I don't like the way mine chooses the destination VM, and I think it'd be better to implement screenshot delivery to a VM as a qubes-rpc service instead. That would allow re-use of the the nice (and familiar) dom0 qrexec target selection GUI, as well as give the user the flexibility to use ,target=some-screenshot-recipient-vm in policy. Users could also override the hypothetical qubes.ReceiveScreenshot implementation on a per-VM basis. Additionally, this would "just work" when switching to GUI outside dom0. I didn't implement it this way only because I couldn't find an easy way to force qrexec calls originating from dom0 to observe ask behavior and not require a specific destination vm, rather it appears any dest is always immediately approved and used in the implicit assumption that dom0 is always trusted and always knows what it wants to target.

Also, I think [799] had a good idea here with copying the screenshot into the clipboard of the frontmost VM, but that introduces a VM-side dependency on xclip. Honestly I think adding xclip to templates by default is not a bad idea (and I invariably end up installing an equivalent anyway) but idk if that's just a personal preference or if it's actually justified.

[jpouellet]

I'm not lobbying for my particular implementation here, I just want users to have something that works for them.

Personally, I think the criteria here should be:

• easy to use
• no additional attack surface
• no new dependencies
• supports R3.2 and R4
• minimal complexity

I believe mine fits all of the above, and it's already a component you can just drop into qubes-builder, but anything else is welcome too.

I don't like the way mine chooses the destination VM, and I think it'd be better to implement screenshot delivery to a VM as a qubes-rpc service instead. That would allow re-use of the the nice (and familiar) dom0 qrexec target selection GUI, as well as give the user the flexibility to use ,target=some-screenshot-recipient-vm in policy. Users could also override the hypothetical qubes.ReceiveScreenshot implementation on a per-VM basis. Additionally, this would "just work" when switching to GUI outside dom0. I didn't implement it this way only because I couldn't find an easy way to force qrexec calls originating from dom0 to observe ask behavior and not require a specific destination vm, rather it appears any dest is always immediately approved and used in the implicit assumption that dom0 is always trusted and always knows what it wants to target.

Also, I think [799] had a good idea here with copying the screenshot into the clipboard of the frontmost VM, but that introduces a VM-side dependency on xclip. Honestly I think adding xclip to templates by default is not a bad idea (and I invariably end up installing an equivalent anyway) but idk if that's just a personal preference or if it's actually justified.