Gracefully fail when sd-viewer does not support a file format

[philmcmahon]

The securedrop workstation viewer does not support all file formats - and realistically probably never will.

In a situation where sd-viewer cannot open a file, it would be helpful to make clear to the user what the problem is. In our experience we have noticed two behaviours:

• html - Qubes VM opens then a "Denied: qubes.OpenInVM" message is shown
• webp/eml - VM starts up and shuts down with no warning

In all of these cases it would be helpful to explain that the format is not supported to the user.

Longer term, it might be useful to be able to interrogate the file in a sandboxed VM. Typically in my organisation we might try run ExifTool or less on a suspicious looking file to get some idea of what it is. It's probably safer doing this within a qubes VM rather than exported to a different machine.

[eaon]

Generally agreed, the client should be aware of the supported file formats, and only even give the option to open or print if that is supported for the respective file type.

[gonzalo-bulnes]

It seems to me that he problem described here is conceptually related to the one described in https://github.com/freedomofpress/securedrop-client/issues/918, namely, that the GUI allows to request printing files that it makes little sense to print (e.g. compressed archives).

With that in mind, I think I'd be inclined to suggest addressing the primary issue in the SecureDrop Client.

---

The second aspect, while related, seems like a distinct problem to me, that we could track along "Allowing files to be exported to a different VM" https://github.com/freedomofpress/securedrop-client/issues/1349.

Longer term, it might be useful to be able to interrogate the file in a sandboxed VM. Typically in my organisation we might try run ExifTool or less on a suspicious looking file to get some idea of what it is. It's probably safer doing this within a qubes VM rather than exported to a different machine.

[gonzalo-bulnes]

To clarify: I think @philmcmahon is right in that the Workstation will never support viewing all the formats. And I think that from there we should make sure that:

1. The SecureDrop Client is aware of the supported formats so that it doesn't misleadingly offers to "View" a file that is known to be of an unsupported format. (Note on known: confidently asserting on a file format can be tricky, but I think we can address the most obvious source of confusion without nitpicking.)
2. When the "View" option is not available, an option along the lines of "Export to VM" would provide a way forward to further inspect the file.

---

Edited to add for cross-referencing purposes that https://github.com/freedomofpress/securedrop-workstation/issues/842 is relevant to the first item.

[cfm]

In the course of freedomofpress/securedrop-workstation#1138, I think this can be accomplished by:

1. linting to determine which files assigned to open-in-vm.desktop in mimeapps.list.sd-{app,devices} are not actually handled by mimeapps.list.sd-viewer;
2. querying mimeapps.list.sd-app in the Client to determine whether a given file's MIME type is assigned; and
3. assigning (in either sd-{app,viewer} or sd-devices) the default MIME type of application/octet-stream to some trivial program that displays a graphical error to the effect of: "Can't open that; sorry!"

[kennethrrosen]

In the course of freedomofpress/securedrop-workstation#1138, I think this can be accomplished by:

1. **linting** to determine which files assigned to `open-in-vm.desktop` in `mimeapps.list.sd-{app,devices}` are not actually handled by `mimeapps.list.sd-viewer`;

2. **querying** `mimeapps.list.sd-app` in the Client to determine whether a given file's MIME type is assigned; and

3. **assigning** (in either `sd-{app,viewer}` or `sd-devices`) the [default MIME type of `application/octet-stream`](https://askubuntu.com/questions/65009/how-do-i-change-the-default-application-for-unknown-file-types) to some trivial program that displays a graphical error to the effect of: "Can't open that; sorry!"

Wondering if there's a 4th/5th option here, piggybacking off of @philmcmahon's idea to instead offer a VM for inspection/interrogation/metadata analysis.

If sd-viewer is a non-networked disposable, couldn't it conceivably open any file even if not defined in the current mimeapps.list? Unless sd-viewer eventually opens files in dangerzone by default, meaning sd-viewer formats are limited to what dangerzone can sanitize, shouldn't sd-viewer handle any file format and offer tools like ExifTool and less?

Alternatively, there could be a mimeapps list for an sd-dangerzone (supported file formats), sd-viewer (everything else), and/or sd-inspect.

[eloquence]

webp support landed in https://github.com/freedomofpress/securedrop-workstation/pull/1147; otherwise this is still applicable to the current codebase.

Keeping this one open as the current behavior is very buggy and confusing (HTML files also result in an additional Qubes permission prompt), regardless of what we do with the rewrite - a good candidate for "issues to still fix in current codebase alongside rewrite".