qubes-issues
qubes-issues copied to clipboard
QubesOS
[Contribution] qvm-screenshot-tool
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
Some details here: https://groups.google.com/d/msgid/qubes-devel/20150708022217.GH900%40mail-itl
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.
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?
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.
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?
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.
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?
On which KDE version will Qubes R3.2 or 4.0 be based on?
The plan is to use KDE 5.
Is there any usable Qubes R4.0 or R3.2 available to develop the screenshot tool?
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
@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.
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).
Looks good, but what should be developed or created to be able to close this issue?
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?
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.
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?
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 it isn't done yet - "Other application" option you see there is not what is meant to be used here.
I think it would be a good idea to schedule this task till Qubes OS uses KDE 5 and Python 3.
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.
@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?
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
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
@marmarek What is the right way to store some temp.config values? Create some file with value or keys? Or use something other? Thanks
It depends on exact purpose and use case, but temp file seems to be a good solution.
I'm not sure if I understand your question correctly, can you elaborate? @evadogstar
@marmarek
-
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)
-
Maybe, I want to implement some log of all uploaded urls. Estimated solution: file "~/.config/qvmscreenshot/log.txt" with full log.
-
"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)
- 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)
- 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.
- "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?
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.
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?