Hey everybody, another progress report for ya. As always, you can find the report with screenshots here: https://blog.amorgan.xyz/gsoc-weekly-progress-report-3.html
Otherwise the text-only version is reproduced below:
---
Good news everyone! The code base has been completely refactored from
multiple scripts with duplicated code into one lean python cli tool. All
the other scripts simply make use of this now.
Additionally, 90% of the bash in the project has now been replaced with
python, which should allow more portability and more maintainable code.
# New CLI Tool
This new utility is called qvm-trust, and can be used in the following
manner:
$ qvm-trust -h
usage: qvm-trust [-h] [-c] [-t] [-u] [-q] path [path ...]
Set or check file/folder trust levels.
positional arguments:
path a folder or file path
optional arguments:
-h, --help show this help message and exit
-c, --check Check whether a file or folder is trusted
-t, --trusted Set files or folders as trusted
-u, --untrusted Set files or folders as untrusted
-q, --quiet Do not print to stdout
Some example usage includes: setting a file as untrusted:
$ qvm-trust --untrusted ./leaked-documents.pdf
Checking the trusted state of a file:
$ qvm-trust --check ./leaked-documents.pdf
File is untrusted
Setting multiple files and folders as untrusted:
$ qvm-trust --untrusted ~/Downloads ./my-sketchy-file.docx ~/QubesIncoming
Checking trusted state through the return code (useful for scripting):
$ qvm-trust --check ~/Downloads --quiet
$ echo $?
2
A reference for the return codes is as follows. Additionally I plan to
write up a man page with all usage information soon:
Error codes:
Unable to read extended attributes: -2
Unable to read an input file: -1
No errors: 0
File/Folder is untrusted: 1
File/Folder is trusted: 2
# Nautilus and Dolphin integration
The Nautilus extension and Dolphin service files now make use of this
script. This cut down the file size of the Nautilus extension
considerably, as well as removed the need for the large bash script that
was dedicated specifically to checking trust in Nautilus, as well as the
two extensions for Nautilus. Now there is simply one extension that
handles both files and folders.
xattr is also no longer a dependency as we now do all the extended file
attribute checking and setting through python.
Additionally the ability to mark file-types as untrusted has been
removed, as there really wasn't a considerable use case for it and it
made implementation more complex than necessary. In the future it could
be added, but at the moment there's no real need for it.
However one benefit to its removal is no more complicated check-box UI
to navigate through! It's all simply there in the right-click menu:
[Screenshot] Nautilus context menu with right click for folders Nautilus
context menu with right click for files
There is now a single context menu item for both files and folders.
On the Dolphin side, the check-boxes have similarly been deprecated,
however I was unable to find a way to add the sleek icon next to the
service menu item as done in Nautilus. Unfortunately there doesn't seem
to be a way to change a service's icon based on a script's output, so
for now I've settled on a sub-menu which the user can choose whether to
mark a file/folder as trusted or untrusted:
[Screenshot] Dolphin with right-click sub-menu
Separate menus since Dolphin can't switch icons on the fly.
Also if you didn't already notice, 'Open in DisposableVM' now shows up
with a little Qubes logo in the right-click menu of untrusted files!
[Screenshot] Qubes logo now shows up for untrusted files
This was achieved with a .desktop file that is called upon when a
certain MIME-type is clicked. This was originally the plan for
recognizing untrusted files in the file-manager, however it was not
considered a viable option as an untrusted file could have any file-type
(i.e PDF, TXT, DOCX, etc). It wouldn't make sense to register all of
these types to be opened in DisposableVMs, so it was dropped.
That was until we started 'locking' untrusted files to disallow reading
by local applications. This had the unintended but incredibly useful
side-effect of having file managers set the MIME-type to
application/octet-stream. At that point we simply had to register that
MIME-type for our custom .desktop file and we were good!
Small bugs/issues
There are still some small roadblocks that still need to be cleared up:
While the functionality in Nautilus is all there, Nautilus doesn't
always seem to re-run the file-checking code in our extension. This can
cause the wrong icon to appear when right-clicking a file, which is
certainly confusing. The correct icon is shown if you click some empty
space, then right-click the file again. I feel this is more a Nautilus
bug than an issue with our file-checking code. I'll hit up the devs on
#nautilus soon and see if I can get some answers.
KDE's Dolphin handles MIME-type checking a bit differently than
Nautilus does. For instance, instead of solely checking for MIME-types
by reading the contents of the file, it gives the greatest priority to
the file extension.
[Screenshot] Dolphin thinks a PDF is a text file, due to its extension
This is a PDF that has been renamed with the '.txt' extension.
Dolphin thinks it is a text file.
[Screenshot] KWrite being suggested instead of qvm-trust
KWrite is suggested to edit it.
Dolphin doesn't mark untrusted files as a specific file-type,
instead it simply says 'unknown':
[Screenshot] Dolphin is confused
What could it be?!
Clicking on 'Create New File Type' does allow us to make new ones
called application/x-kdeuser, however even after doing so the file-type
is still unknown.
**Actually while writing this I just thought... we could combine 2
and 3 together and just append '.untrusted' to untrusted file types,
then register the '.untrusted' file extension with our desktop handler.
Hm... will try that right after I post this :)**
Dolphin does not allow unreadable files to be opened. It cancels the
application launch and presents an 'Access Denied' message. Not entirely
sure if there is a way around this outside of a patch. It would be great
to find a workaround.
[Screenshot] Dolphin won't let us open unreadable files
This file is unreadable, dummy!
**Update: this may not be an issue with the '.untrusted' workaround
above. Apparently if the file-type is recognizable it will send it to
the application that's registered**
The location of the untrusted-folders file. This file keeps track of
the folder paths that are untrusted, and is used by the daemon. Even
after reading the Qubes Contribution Guidelines I'm still not sure where
to put this. /usr/share/qubes seems to be the apt location but there's
not much in there already. Marek?
# Going Forward
We're currently heading into week 2 of 4 of what was supposed to be
patching the file managers, however now that it seems that's no longer
necessary, we're pretty much ahead of schedule! After Dolphin is fixed
up, I'll create a daemon to monitor untrusted folders and their
contents. If a new file is placed or created inside them, they'll
instantly be marked as untrusted.
After that is unit tests and documentation cleanup. Pretty standard stuff.
Anyways, that's about it for this week. Til next time!
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/oifna0%245go%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
