-
Notifications
You must be signed in to change notification settings - Fork 47
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
Update mimetype handling for Debian Stretch #158
Comments
While testing #160, noticed that JPG images open in a DispVM in Firefox. That's not what we want (although it does display the image). Let's force an appropriate handler for that type. |
Just now verified that on Debian Stretch that file does not exists. How to test?
I even checked this:
@conorsch We are good to go :) |
Great! Now that we have #182 tracking the package implementation, and judging by @kushaldas's findings on the lack of clobbering risk, the research task identified by this ticket is satisfied. |
The submission handling logic relies on custom mimetype associations in order to ensure that submissions are never opened in the
sd-svs
AppVM (where the SecureDrop Client runs), but rather opens in a network-less DispVM. Once inside the DispVM, mimetypes are also important: the proper application must be selected to ensure a positive user experience. For example, we want to ensure that plaintext submission are opened ingedit
, notnano
orvim
.Use of
xdg-open
should be sufficient to ensure proper handling of mimetypes, but some additional dependencies may be required:gvfs-bin
andlibgnomevfs2-bin
(to ensurexdg-mime
operates correctly)nautilus
should be present in thesd-svs
VM (but isn't included by default in thedebian-9
template); we can revisit after Convert sd-journalist to sd-proxy #138 is implementedWe also want to ensure that system paths such as
/usr/share/applications/mimeapps.list
are not vulnerable to clobbering by upstream changes. It's also an option to declare the mimetype associations in~/.config/mimeapps.list
, but using a non-system path will complicate both packaging logic and the use of TemplateVMs (since AppVMs receive their own $HOME by default, not copied from the base TemplateVM).See the discussion thread in #155 (comment) for reference.
The text was updated successfully, but these errors were encountered: