[prev in list] [next in list] [prev in thread] [next in thread]
List: qubes-devel
Subject: [qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7
From: Andrew Morgan <anoa () openmailbox ! org>
Date: 2017-07-26 3:54:57
Message-ID: ol93qg$ht7$1 () blaine ! gmane ! org
[Download RAW message or body]
[Attachment #2 (multipart/mixed)]
On 07/25/2017 06:23 PM, Marek Marczykowski-Górecki wrote:
> On Tue, Jul 25, 2017 at 05:52:56PM -0700, Andrew Morgan wrote:
> > On 07/24/2017 02:33 AM, Andrew Morgan wrote:
> > > ## Nautilus
> > >
> > > The patch for Nautilus is finally getting going! After some hiccups with
> > > Nautilus' build process, I've now switched to [GNOME
> > > Builder](https://wiki.gnome.org/Apps/Builder) for the compilation and
> > > run management of Nautilus. Builder provides a much cleaner experience
> > > when building and compiling, and after only hearing about it here and
> > > there, it was exciting to finally download and try it out.
> > >
> > > After a couple hiccups with importing the Nautilus code and checking out
> > > the correct branch (gnome-3-22 in this case) with the help of some fine
> > > folks on #gnome-builder, Nautilus was building and launching as expected:
> > >
> > > 
> > > *Nautilus built and running from Builder*
> > >
> > > The other advantage GNOME Builder holds is its ability to build all
> > > projects as flatpaks. This makes it much easier to share testing builds
> > > of Nautilus without asking people to install Nautilus' [horrible list of
> > > dependencies](https://ubuntuforums.org/showthread.php?t=1678656&p=10426119#post10426119),
> > > and instead just run a single command to start it up!
> > >
> > > In addition to Nautilus, GNOME Builder is also helping me with patching
> > > [nautilus-python](https://wiki.gnome.org/Projects/NautilusPython/),
> > > which are the python bindings that allow extensions written in python to
> > > interact with Nautilus' C API.
> > >
> > > [This
> > > folder](https://git.gnome.org/browse/nautilus-python/tree/src/nautilus-python-object.c)
> > > houses the definitions of functions that can be referenced in
> > > `nautilus-python` extensions. Nautilus' maintainer, Carlos Soriano, also
> > > kindly pointed out where these methods connect to Nautilus itself, which
> > > turns out to be
> > > [here](https://git.gnome.org/browse/nautilus/tree/libnautilus-extension).
> > >
> > > The typical workflow in a `nautilus-python` extension is to define a
> > > function that corresponds to the data or action you desire, then return
> > > some data based on some logic you have in your extension. My plan is to
> > > create another function here that will be called when a file is
> > > determined to be opened. The file will then be opened depending on
> > > whether the extension returns a `True` or a `False`.
> > >
> > > A new DisposableVM with the file in question can be launched from within
> > > the extension, so there is no need for any Qubes-specific code to go
> > > into this patch.
> > >
> > To clarify on this after some digging today, Nautilus officially only
> > supports extensions written in C. There are a few extensions that are
> > included in Nautilus' source tree (such as the sendto extension), but
> > all one needs to do to install an extension is to place the extension
> > library in `/usr/lib(64)/nautilus/extensions-3.0/`, restart Nautilus and
> > it should be installed.
>
> > NautilusPython is a Nautilus C extension. It's purpose is just to read
> > python scripts that perform extension actions and translate those into
> > the C actions Nautilus is used to. It's a completely separate
> > compatibility layer.
>
> > This is all fine and dandy, and means that if needed, really only
> > Nautilus (not NautilusPython) would have to be patched to include new
> > bindings for file open events, and a C Nautilus extension could be
> > written to make use of it.
>
> > I'm going to strive to have NautilusPython be compatible with the new
> > bindings though, since writing extensions in C is a heck of a lot more
> > work and setup then their Python counterparts.
>
> +1
>
> > One blocker I'm having at the moment is getting the gnome-builder
> > version of Nautilus to recognize extensions. The 'gnome-3-22' branch
> > version, to my knowledge, does not support building with Flatpak (or at
> > least there was no manifest defined, even though it could be built and
> > ran from gnome-builder).
>
> I'm not really sure if you need to spend time on getting Flatpak build
> working. If you build the same (or similar) Nautilus version as is
> already installed in the template, all dependencies should be already in
> place, so it should be still easy.
Is it possible to build just Nautilus with qubes-builder? That may make
things much closer to what we want.
>
> > The version that was built couldn't find installed extensions however,
> > which lead me to think it was packaged as a Flatpak, with a policy that
> > prevented reading it from the extensions directory. (Though I could
> > navigate to the extensions directory in Nautilus, so presumably you can
> > access it??)
>
> > Checking out the master branch did reveal a Flatpak manifest
> > (org.gnome.Nautilus.json), however I am unable to build the latest
> > version due to a dependency on glibc v2.51.2 on Fedora 25 (v2.50.3 is
> > installed).
>
> > Also not even sure if the latest version is compatible with Qubes since
> > we use 3.22 Nautilus at the moment..
>
> > Anyways, that's where I stand with all that. IRC has been helpful with
> > some answers, but I still have a lot of questions :)
>
> Maybe, just guessing, it looks for extensions somewhere else? Like /lib
> instead of /usr/lib or such. I'd check ./configure (or equivalent)
> options. And if still nothing, use strace to check where it really looks
> (log to a file, then grep for "extensions" or some similar phrase). See
> "-s ..." and "-v" options if paths are truncated in log.
>
>
Yeah ran an strace on it though it's a little tricky as I can only start
the builder version from builder itself. Extensions are likely loaded as
soon as Nautilus starts up, thus I'm not sure how to strace the PID
before I start the program from Builder. Builder's profiling tools are
also lacking the ability to check what files are accessed.
That said, if qubes-builder can build Nautilus then we shouldn't have to
worry about any of that.
File sandboxing a File Manager seems like a silly thing to do anyways :)
Andrew Morgan
--
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+unsubscribe@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/ol93qg%24ht7%241%40blaine.gmane.org. \
For more options, visit https://groups.google.com/d/optout.
["signature.asc" (application/pgp-signature)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic