Re: Qubes-MIME-Handlers final report (#9)

59 views
Skip to first unread message

Marek Marczykowski-Górecki

unread,
Sep 3, 2017, 5:46:25 PM9/3/17
to Andrew Morgan, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

I didn't got your email with the final report, probably because of
recent qubes-devel ML outage[1]. Anyway, here are my comments:

I've done review of the whole qubes-file-trust repository again.
Here are the comments:
https://github.com/marmarek/qubes-file-trust/pull/1#pullrequestreview-60296866

qubes-nautilus-trust - in practice the repository plugged into
qubes-builder should contain just spec + tarball (or a script to
download it) + patch. This will be much easier to maintain in the long
run (until the patch is included upstream). Especially rebasing on new
upstream versions. The current qubes-nautilus-trust is a good thing
during development of course.
Speaking of which - what is the status with upstreaming the patch? Looks
like that mailing list is barely alive. According to [2], trying
bugzilla may be a better choice.

Links to qubes-nautilus-python-trust and qubes-dolphin-trust-activites
repositories are broken.

Link to qubes-nautilus-python-trust should mention branch name.

Generally the whole thing looks great! There are few things before it
can be included in Qubes OS, but as noted above, those are mostly
technicalities, the main work is in a good shape.

[1] https://github.com/QubesOS/qubes-issues/issues/3065
[2] https://wiki.gnome.org/Newcomers/SubmitPatch

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJZrHgqAAoJENuP0xzK19cssuAH/RJDdnFnDNteQFWohlnWz1nP
05RNV0rqGis8Bl7ToL+u2V4qxfq9shIythsSKHvM/rqzW31pkzw5OE7QX1dEZjcd
AA+ReP/dIJhbyZcRQyZSuw6MuNw2xgZ6rEZ/AM2KI+rVt+VA71kepRvAnBmkz0d4
4Mjftcgb/v9BzGEkkDuFNa0fvHzmZmtonmTP8C9dvHa7TSM8f35JYDT+4lNRzfjX
72BpHUzanbEYlpl4QOLEpYRcD97KNgPeZF17LNLw0lKb0m86atBKf8UNPUM8sFkw
XiGI0IjsMKsplaiErjyaIgaQouh6dmwTsfy7gpS8sFyID1RF0l/2qk1GVzX68eA=
=7yIC
-----END PGP SIGNATURE-----

Andrew Morgan

unread,
Sep 4, 2017, 6:20:50 PM9/4/17
to qubes...@googlegroups.com
On 09/03/2017 02:46 PM, Marek Marczykowski-Górecki wrote:
> Hi,
>
> I didn't got your email with the final report, probably because of
> recent qubes-devel ML outage[1]. Anyway, here are my comments:
>
> I've done review of the whole qubes-file-trust repository again.
> Here are the comments:
> https://github.com/marmarek/qubes-file-trust/pull/1#pullrequestreview-60296866
>
> qubes-nautilus-trust - in practice the repository plugged into
> qubes-builder should contain just spec + tarball (or a script to
> download it) + patch. This will be much easier to maintain in the long
> run (until the patch is included upstream). Especially rebasing on new
> upstream versions. The current qubes-nautilus-trust is a good thing
> during development of course.
> Speaking of which - what is the status with upstreaming the patch? Looks
> like that mailing list is barely alive. According to [2], trying
> bugzilla may be a better choice.
>
> Links to qubes-nautilus-python-trust and qubes-dolphin-trust-activites
> repositories are broken.
>
> Link to qubes-nautilus-python-trust should mention branch name.
>
> Generally the whole thing looks great! There are few things before it
> can be included in Qubes OS, but as noted above, those are mostly
> technicalities, the main work is in a good shape.
>
> [1] https://github.com/QubesOS/qubes-issues/issues/3065
> [2] https://wiki.gnome.org/Newcomers/SubmitPatch
>
>

Thanks Marek, I've already started going through your suggestions.

For anyone else that missed it, as it looks like the report never made
it to the mailing list, the final blog post can be found here:
https://blog.amorgan.xyz/gsoc-weekly-progress-report-9---final.html

Otherwise the text-only version is below:

---

Hey everyone, another blog post coming right on the heels of the final
week of GSoC. I have to say that it's been an absolute blast
participating, and I hope to have the chance to do so again before I
graduate.

Barring that, I can say that qubes-MIME-types (now renamed to
qubes-file-trust) as a project is now in a complete and working state!
Fedora and Debian packages are currently being put together, and will
hopefully show up in the repos in the not-too-far future.

And now, on to the final report!

## Original goals

The original goals outlined in [my
proposal](https://cloud.amorgan.xyz/index.php/s/WdTP3gQSdDp1XzV) consist
of the following:

1. Implement a python context menu in Dolphin and Nautilus as well as a
minimal GUI for modifying file trust settings
2. Create a patch for Nautilus and Dolphin to follow these settings when
opening a file
3. Create a system daemon to watch and enforce file trust settings on
files create inside of untrusted folders
4. Documentation of implementation
5. Unit testing and integration

In terms of meeting these goals, most were completed on time. The only
task yet to be completed is a patch for KDE's Dolphin File Manager. The
patch for Nautilus ended up taking at least 3 weeks, and thus towards
the end of the project I decided to prioritize polish and bug fixes of
the existing code over starting an entirely new patch.

Other than that though, the rest of the goals were met, and the code is
now sitting in five separate repositories on my Github. There are, with
explanation:

1. The main repo, containing the python `qvm-file-trust` command line
tool and the C++ system daemon that watches untrusted folders:
[qubes-file-trust](https://github.com/anoadragon453/qubes-file-trust)

2. The patched version of nautilus, patched to allow extensions to react
to file-opening events and block them if necessary:
[qubes-nautilus-trust](https://github.com/anoadragon453/qubes-nautilus-trust)

3. The patch version of nautilus-python, patched to allow the same thing
as above:
[qubes-nautilus-trust-python](https://github.com/anoadragon453/qubes-nautilus-trust-python)

4. Our nautilus extension that listens for file-opening events and
blocks them if it references an untrusted file (and opens them in a
disposable VM instead):
[qubes-nautilus-trust-extension](https://github.com/anoadragon453/qubes-nautilus-trust-extension)

5. Dolphin activities that allow one to change the trusted state of a
file or folder from the right-click menu:
[qubes-dolphin-trust-activities](https://github.com/anoadragon453/qubes-dolphin-trust-activities)

## Recent updates

For those following the series, here are the main updates since the last
posting:

**Nautilus pointer truncation bug workaround**

In [the last blog
post](https://blog.amorgan.xyz/gsoc-weekly-progress-report-8.html), I
talked about a horribly hacky workaround that I was using to get around
the pointer truncation bug that kept causing nautilus to crash. Not only
was it hacky, but it also only worked inside of a running `gdb`
instance, which is pretty useless.

Working with a friend, we managed to narrow the bug down to a scope
issue. For some reason the GList\* was being returned as an integer
instead, which explains the 32-bit truncation (integers are 32-bit by
default in C). Neither the nautilus maintainer, nor my mentors really
had any clue about how to come up with a solution.

To rectify this, instead of grabbing the GList\* from
`nautilus-mime-actions.c` (which had scope issues), we sourced the
pointer from the same file as the method that generated it, then
transferred it to `nautilus-mime-actions.c` through a double-pointer.
You can see the code
[here](https://github.com/anoadragon453/qubes-nautilus-trust/blob/master/src/nautilus-mime-actions.c#L2479)
and
[here](https://github.com/anoadragon453/qubes-nautilus-trust/blob/master/src/nautilus-module.c#L288).
Admittedly, this is still a workaround for the scope issue, but it's
MUCH cleaner than before, and actually works outside of `gdb`, so that's
handy.

**Nautilus patch now supports opening multiple files at once**

Yes, originally you could only open one file at a time with the patch
(lame!). But, after learning a bit more about how extensions in nautilus
are handled, this limitation has now been removed, and things are opened
as you'd expect them to be.

**Added new commands to qvm-file-trust such as `--check-multiple` and
`--check-multiple-all-untrusted`**

In earlier iterations, you were only able to check the trust state of a
single file or folder at a time. There wasn't really a need to check
multiple at once. That was until I tested opening multiple files from
nautilus. We would have to make a separate call to `qvm-file-trust` for
*every* single file, and spinning up and down the Python runtime,
combined with extensions running in the same thread as nautilus itself,
made everything way too slow.

These commands were added in order to check a large list of files all in
one go. Both commands tell you which files are untrusted and which
aren't, however they each return different error codes based on
different situations. More explanation can be found in the [updated man
page](https://github.com/anoadragon453/qubes-file-trust/blob/master/doc/qvm-file-trust.rst)
(now written in RestructuredText!)

**RPM packages and repo separation**

As mentioned above, the `qubes-mime-types` repo has not only been
renamed, but also broken up into three separate repos! This was to keep
things clean, as well as to follow packaging, as it was decided to have
one package per repo, instead of multiple stemming from a single
codebase. Each repo now has its own `rpm_spec` folder, containing the
SPEC files used to build RPM packages. These packages build and install
successfully on my machine (minus some minor packaging issues, this is
my first time packaging for Linux, so go easy :), and they will
hopefully be available in Qubes Fedora (and debian!) repos in the
not-too-distant future.

The were *lots* of little bug fixes across all the repos, and likely
more to come once people start getting their hands on the packages. I'll
make another post when they're available to download. I'll also continue
to maintain the code even after my GSoC period to ensure there aren't
any issues for anyone, as well as extend in little ways, such as adding
support for upcoming Qubes R4.0 features (multiple DispVM templates,
anyone?).

## Thanks and closing thoughts

That's all for this week (and Summer). Thank you for taking the time to
read my ramblings over the past few months. QubesOS is currently my
all-time favorite operating system, and I can't wait to see how it
flourishes in the seasons and releases to come.

I'd also like to thank my mentors, Marek Marczykowski-Górecki and
Jean-Philippe Ouellet, as well as the rest of the Qubes team, for
putting up with my questions and issues along the way.

It was both fun and an honor to work with you, and I hope to continue to
do so in the future.

Andrew Morgan

signature.asc
Reply all
Reply to author
Forward
0 new messages