[Contribution] qvm-screenshot-tool

marmarek commented 9 years ago

Community Dev: @ben-grande (originally @evadogstar) Repo: https://github.com/ben-grande/qubes-qvm-screenshot-tool

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 commented 9 years ago

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

ptitdoc commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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

Press Print Screen to start the tool
Select capture mode
Click "Take a New Snapshot"
Select region/window/whatever
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 commented 9 years ago

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 commented 8 years ago

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 commented 8 years ago

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

The plan is to use KDE 5.

Jeeppler commented 8 years ago

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

marmarek commented 8 years ago

I'm going to upload some preliminary R3.2 image somehow today/tomorrow. Anyway this isn't much different than R3.1 - see: https://github.com/QubesOS/qubes-issues/issues/1324#issuecomment-155655636

Jeeppler commented 8 years ago

@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 commented 8 years ago

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

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

Jeeppler commented 8 years ago

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

marmarek commented 8 years ago

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

Jeeppler commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

marmarek commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

Jeeppler commented 8 years ago

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

ghost commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

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

marmarek commented 8 years ago

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

marmarek commented 8 years ago

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

marmarek commented 8 years ago

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?

v6ak commented 8 years ago

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

Do I trust it? (Do I trust there are no intentional backdoors?)
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 commented 8 years ago

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 commented 8 years ago

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

ptitdoc commented 7 years ago

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 commented 7 years ago

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

ptitdoc commented 7 years ago

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

marmarek commented 7 years ago

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 commented 7 years ago

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.

jpouellet commented 7 years ago

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: screenshot_2017-06-27_04-18-58

Then you get a list of running VMs, and select where to save the image: screenshot_2017-06-27_04-19-58

And then it saves the screenshot there and opens the location where it saved it (~/QubesIncoming/dom0) in a file manager: screenshot_2017-06-27_04-21-03 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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@marmarek: Will do.

jpouellet commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

On Thu, Mar 22, 2018 at 04:40:01PM -0700, Jean-Philippe Ouellet wrote:

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.

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

jpouellet commented 6 years ago

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 commented 6 years ago

Pinging @marmarek

jpouellet commented 6 years ago

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.

mike4420 commented 6 years ago

I use i3 and wrote this simple script I invoke with a shortcut after taking a screenshot with xfce4-screenshooter. It simply copies all files newer than 5 minutes from dom0:~/Pictures to the current qube. Gets job done even though it's dumb simple. Don't know how it can be done in other WMs and/or if it makes sense there, but it really fits well into i3 flow.

#!/bin/bash

. /usr/local/bin/qubes-inc

main() {
    local vm=$(get_vm)
    if [[ -n "$vm" ]]; then
        find ~/Pictures -type f -maxdepth 1 -mmin -5 | xargs qvm-copy-screenshot "$vm"
    fi
}

main

get_vm is a function defined in qubes-inc returning the VM which the current window is running on. qvm-copy just runs qvm-copy-to-vm for a given file from ~/Pictures and then moves that file to ~/Pictures/copied/.

mryellow commented 5 years ago

Thanks for the work formalising something @jpouellet. Works well.

For some reason the approach from @marmarek of Exec=qvm-move-to-vm testvm %F didn't work. Couldn't find a log to help debug exactly why.

https://github.com/QubesOS/qubes-issues/issues/953#issuecomment-286129671

One minor suggestion would be to use the envvar $USER here just in-case they've changed it from default:

qvm-run -p "$vm" 'xdg-open /home/$USER/QubesIncoming/dom0' </dev/null

Thovthe commented 5 years ago

What's the status of this? Are any of these solutions included in the repos yet? Is the contributor's repo set up yet?

andrewdavidwong commented 5 years ago

What's the status of this? Are any of these solutions included in the repos yet? Is the contributor's repo set up yet?

I believe the current status is for @marmarek to review the code contributed by @evadogstar in https://github.com/evadogstar/qvm-screenshot-tool.

ninavizz commented 4 years ago

Pinging @marmarta... any chance I could see how this is currently invoked by the user, and how it works? Would there be time for me to make any text, icon, or interaction reccs/improvments, if I have any?

QubesOS / qubes-issues

[Contribution] qvm-screenshot-tool #953