Andrew Morgan's Blog

It's a blog

GSoC Weekly Progress Report #6

July 11, 2017 — Andrew Morgan

Hello again! Few different things going on this week so let's just jump right in.


First off a basic set of tests have been written for the qvm-file-trust tool. So far these are all unit tests, and mainly test sending input to each method in qvm-file-trust, ensuring that certain methods are called with the correct parameters, and anything that is returned contains the correct data.

In the process of writing these tests I uncovered a few bugs and quirks here and there in the code, which is awesome because that's exactly what tests are designed to do. Currently I only test each method directly, however in the long run there will be tests that send varied input externally to the program. These will check the output as well as the trust status of any files that may be involved.

As was evident from my last post, I had a bit of trouble getting used to some 'pythonic' quirks, as well as the whole concept of mocking. Nevertheless, after getting a few fundamentals down on how to feed in fake inputs and data, writing the majority of the tests was mostly just time-consuming.

I also ran a few passes of pylint over qvm-file-trust to really make sure it was clean and following python's syntactical standards.

I still plan to add a few more tests for the cli tool to the suite, as well as those for the upcoming untrusted folder watching daemon.

Speaking of which...

Look out! It's a daemon!

I took a little time this week to start work on the C daemon that will watch all untrusted folders and mark any files created inside them as untrusted as well. For starters, I've switched to making it a C++ deamon instead. As far as I can tell there isn't any noticable performance difference between the two languages, and C++ comes with a few abstractions for various low-level things like file handling, meaning less room for errors and bugs. I'm also much more experienced in C++, so it seemed to the correct choice.

While following the Qubes Code Style Guidelines, I was able to implement parsing of the global and local rule lists (including functionality such as comment ignoring and override rules) as well as being able to call on qvm-file-trust and set any file as untrusted through it. I'm currently working on iterating through the rule list and setting up an inotify watch on each folder (and its subfolders) for any new files placed within them.

In a very scientific test of setting up a basic C++ program to watch /tmp and holding down tab after ls /tmp/, generating many simulataneous inotify events, the CPU usage of the program was 0%. Whether it will spike up when creating thousands of files within untrusted folders remains to be seen, but I'm trying to keep the code as efficient as possible.

One thing I wasn't entirely sure about was where to send logs. I'm not sure if I should just log to syslog (and thus journald), or /var/log/qubes/... (or both). It's simple enough to do either one.

Water-based File Managers

I've started with modifying some of Dolphin's source code. Unfortunately I've been having a little bit of trouble with their build tool, kdesrc-build. The amount of source code necessary to build Dolphin is apparently quite large. Every time I try to download the full dependencies of Dolphin it seems to stall halfway through.

This may not be the only way to work on Dolphin, but I haven't seen an alternative so far...

The other matter is that Whonix's current Dolphin version is 4.14.2, while an updated Arch system's Dolphin version is 17.04.2 (and source is 17.04.70).

According to this bug report, Whonix should be using KDE Frameworks 5 in v14 (next release), which should be included in Qubes soon following release. Due to this, I'm wondering whether I should base my patches on top of Dolphin's latest code or the legacy v4.14. If the latest, then it may be best to develop on Arch instead of Qubes, or maybe I could find a pre-release build of Whonix 14...

For Nautilus I've just been using the latest code and it's going well. Update on that in a bit!

In any case, I've outlined the required changes that need to be made to each file manager below:


1. Expose file open events to extensions

2. Respect not opening file if extension requests not to (upstream may not like this part :)


1. Work around the complete prevention of attempting to open files for which we have no read permissions for 
(instead check with our cli tool and decide what to do based on its output)

2. If the file is deemed an untrusted file, attempt to open it with our dvm-desktop handler

3. Failing that, display an error

That should about cover the functionality. Hopefully it'll be at least partially upstream-able. I'm open to suggestions if anyone has any :)

That about wraps it up for this week! As always the code is available here.

See you next time!

Tags: gsoc-2017, progress-report