Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Qubes MIME handlers #441

Open
marmarek opened this issue Mar 8, 2015 · 20 comments
Open

Qubes MIME handlers #441

marmarek opened this issue Mar 8, 2015 · 20 comments
Labels
C: other community dev This is being developed by a member of the community rather than a core Qubes developer. help wanted This issue will probably not get done in a timely fashion without help from community contributors. P: major Priority: major. Between "default" and "critical" in severity. S: partial Status: partial. Work on this issue is partially complete, but it is not actively being worked on. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality.

Comments

@marmarek
Copy link
Member

marmarek commented Mar 8, 2015

Community Dev: none (help wanted)
Partial PoC: https://github.com/kulinacs/qubes-desktop
Post: http://theinvisiblethings.blogspot.com/2013/02/converting-untrusted-pdfs-into-trusted.html
Discussion: https://groups.google.com/d/msgid/qubes-users/dc777e37-a4a2-4ea8-bb80-4b5fb5aceeac%40googlegroups.com


Reported by joanna on 6 Feb 2012 11:25 UTC
E.g. if a user manually opens a file in DispVM once, then this file will always by opened in DispVM by default.

If this is simple, it would be a great feature. If not simple, we should postpone it until after 1.0 -- TBD.

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

@marmarek marmarek added T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality. C: core P: major Priority: major. Between "default" and "critical" in severity. labels Mar 8, 2015
@marmarek
Copy link
Member Author

marmarek commented Mar 8, 2015

Comment by marmarek on 6 Feb 2012 13:14 UTC
Define "open". Double-click in nautilus?

@marmarek
Copy link
Member Author

marmarek commented Mar 8, 2015

Comment by joanna on 6 Feb 2012 13:20 UTC
Yup.

@marmarek
Copy link
Member Author

marmarek commented Mar 8, 2015

Modified by joanna on 9 Apr 2012 09:45 UTC

@marmarek marmarek added this to the Release 2 milestone Mar 8, 2015
@marmarek
Copy link
Member Author

marmarek commented Mar 8, 2015

Modified by joanna on 8 Oct 2012 09:28 UTC

@marmarek marmarek modified the milestones: Release 2 Beta 3, Release 2 Mar 8, 2015
@marmarek
Copy link
Member Author

marmarek commented Mar 8, 2015

Comment by joanna on 24 Feb 2013 15:31 UTC
This has been further discussed at the end of this post:

http://theinvisiblethings.blogspot.com/2013/02/converting-untrusted-pdfs-into-trusted.html

@marmarek
Copy link
Member Author

marmarek commented Mar 8, 2015

Modified by joanna on 1 Aug 2013 11:32 UTC

@marmarek marmarek modified the milestones: Release 3, Release 2 Beta 3 Mar 8, 2015
@marmarek
Copy link
Member Author

marmarek commented Mar 8, 2015

Modified by joanna on 5 Dec 2013 18:58 UTC

@marmarek marmarek changed the title Ability to permanently flag files for opening in DispVM Qubes MIME handlers Mar 8, 2015
@marmarek
Copy link
Member Author

marmarek commented Mar 8, 2015

Modified by joanna on 20 Apr 2014 17:03 UTC

@marmarek marmarek modified the milestones: Release 2.1 (post R2), Release 3 Mar 8, 2015
@marmarek
Copy link
Member Author

marmarek commented Mar 8, 2015

Modified by joanna on 20 Apr 2014 17:05 UTC

@marmarek
Copy link
Member Author

@bnvk bnvk mentioned this issue Feb 18, 2016
20 tasks
@andrewdavidwong
Copy link
Member

Just checking in, since the last development update on this appears to have been over a year go. Is @rootkovska actively working on this? If not, may I remove the assignment and add the help wanted label?

@marmarek marmarek added the help wanted This issue will probably not get done in a timely fashion without help from community contributors. label Apr 21, 2016
@marmarek
Copy link
Member Author

Yes, good idea.

@kulinacs
Copy link

I'm not sure how to correctly pull request this feature, but I believe I have a working solution here:
https://github.com/kulinacs/qubes-desktop
By adding the qvm-open-in-dvm.desktop file to your applications folder, it allows file managers to recognize qvm-open-in-dvm as an executable to open file types. The user can then use their respective file manager to set it as the default application.

@marmarek
Copy link
Member Author

Thanks, this is one part of this ticket. It can be included in https://github.com/qubesos/qubes-core-agent-linux repo and IMO can be so now (regardless of the other part).
The other part is a mechanism to remember user choice on file basis - for example to mark some files to always open in DispVM, while other files (possibly with the same type) - not.

andrewdavidwong added a commit that referenced this issue Jun 9, 2016
andrewdavidwong added a commit that referenced this issue Jun 12, 2016
@marmarek marmarek modified the milestones: Release 3.2, Release 4.0 Aug 5, 2016
@rootkovska
Copy link
Member

Since it's tricky to properly implement persistent-yet-not-spoofable flags on files for determining on whether a given file should be opened in DispVM or not, etc, I propose a simplified solution:

Have qubes-registered .desktop files that determines whether to open in a DispVM based on the following heuristics:

  1. If path starts with: ~/QubesIncoming/ or ~/Downloads/
  2. If the path contains the following string untrusted (case insensitive)

This should cover most of the cases, such as default treating any files downloaded from the Internet as untrusted by default, unless the user decided to move it somewhere else explicitly (and both the user's Web browser as well as the email client could be configured to save there by default).

The match for "untrusted" string in the middle of a path is meant for users who would like to explicitly insert some untrusted files into otherwise trusted directory trees (e.g. some 3rd party PDF inserted into their trusted work project tree). Also will cover ~/UntrustedPDFs case.

Of course these rules could be configurable, e.g. an env variable overridable in ~/.bashrc or /rw/config. E.g.: `QUBES_UNTRUSTED_PATH="^/home/users/Mydownloads". Note we should enforce patching always done on the canonical paths.

The above can easily be done for specif files, e.g. PDFs, JPEGs, etc, by substituting the corresponding .desktop files. Can we provide a generic .desktop files that will always be consulted first before resorting to the specific files provided by various apps (evince, etc)?

@v6ak
Copy link

v6ak commented Oct 14, 2016

Joanna, it looks mostly like a reasonable hack. The only part I am not sure about is QUBES_UNTRUSTED_PATH environment variable. Something suggests me this will be error prone, maybe someone will set it in .bashrc and it will work in some cases (when running from Bash), but not in some others (when running from qvm-run). On one hand, such power users might be aware of such behavior, on the other hand, I am not sure if this will be always the case.

andrewdavidwong added a commit that referenced this issue Nov 6, 2016
@rootkovska
Copy link
Member

Perhaps we can have the first version with hardcoded "-i untrusted" and "~/Downloads"?

@rootkovska
Copy link
Member

Here are some ready-to-use .desktop files for both URL and MIME handling:

https://micahflee.com/2016/06/qubes-tip-opening-links-in-your-preferred-appvm/
https://github.com/kulinacs/qubes-desktop

It seems like all we need is to write a simple wrapper program (which would be Exec'ed by such a .desktop file) that: 1) checks if the path ($1) matches ^~/Downloads or contains "untrusted" (case insensitive), and then, if yes, run: qvm-open-in-(d)vm $1.

@rootkovska
Copy link
Member

Also, while at at, it might be sometimes very useful to be able to set custom URI handlers for Chrome. E.g. I might want all http:// links from by work-browser VM to open automatically in work-untrusted VM. It seems like we could use e.g. this Chrome extension for this:

http://bendavis78.github.io/chrome-extension-redirector/

... but we also need a way to register Qubes qvm-open-in-(d)vm as Chrome URL handlers, e.g.: qubes-vm:// and qubes-dvm:// ?

@marmarek
Copy link
Member Author

... but we also need a way to register Qubes qvm-open-in-(d)vm as Chrome URL handlers, e.g.: qubes-vm:// and qubes-dvm:// ?

This shouldn't be a problem (if Chrome respects XDG): simply add MimeType=x-scheme-type/qubes-dvm to .desktop file, like this:

[user@testvm applications]$ pwd
/usr/share/applications
[user@testvm applications]$ cat qubes-open-dvm.desktop
[Desktop Entry]
Version=1.0
Type=Application
Exec=/bin/sh -c 'qvm-open-in-dvm $(echo %u | sed -e s:^qubes-dvm:http:)'
MimeType=x-scheme-handler/qubes-dvm
[user@testvm applications]$ sudo update-desktop-database
[user@testvm applications]$ xdg-open qubes-dvm://qubes-os.org/

And the same for https. It looks to also work in Chrome, but you get "External Protocol Request" confirmation (at least for the first time).

@mfc mfc mentioned this issue Jan 31, 2017
2 tasks
@andrewdavidwong andrewdavidwong added community dev This is being developed by a member of the community rather than a core Qubes developer. S: partial Status: partial. Work on this issue is partially complete, but it is not actively being worked on. labels Jun 9, 2019
@andrewdavidwong andrewdavidwong removed this from the Release 4.2 milestone Aug 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: other community dev This is being developed by a member of the community rather than a core Qubes developer. help wanted This issue will probably not get done in a timely fashion without help from community contributors. P: major Priority: major. Between "default" and "critical" in severity. S: partial Status: partial. Work on this issue is partially complete, but it is not actively being worked on. T: enhancement Type: enhancement. A new feature that does not yet exist or improvement of existing functionality.
Projects
None yet
Development

No branches or pull requests

5 participants