'[qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7'

[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-31 6:48:48
Message-ID: olmjsd$act$1 () blaine ! gmane ! org
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


On 07/30/2017 02:42 AM, Marek Marczykowski-Górecki wrote:
> On Sat, Jul 29, 2017 at 08:43:14PM -0700, Andrew Morgan wrote:
> > On 07/28/2017 08:47 PM, Andrew Morgan wrote:
> > > On 07/28/2017 01:21 AM, Marek Marczykowski-Górecki wrote:
> > > > On Thu, Jul 27, 2017 at 07:01:17PM -0700, Andrew Morgan wrote:
> > > > > On 07/26/2017 01:29 AM, Marek Marczykowski-Górecki wrote:
> > > > > > On Tue, Jul 25, 2017 at 08:54:57PM -0700, Andrew Morgan wrote:
> > > > > > > Is it possible to build just Nautilus with qubes-builder? That may make
> > > > > > > things much closer to what we want.
> > > > > > 
> > > > > > You'll need source package (.spec for rpm for example). You can start
> > > > > > with upstream source package:
> > > > > > - dnf download --source nautilus && rpmdev-extract nautilus*src.rpm
> > > > > > - apt-get source nautilus
> > > > > > 
> > > > > > Then place resulting files in a subdirectory of qubes-src and add
> > > > > > Makefile.builder with either (or both):
> > > > > > RPM_SPEC_FILES = relative/path/to/spec
> > > > > > DEBIAN_BUILD_DIRS = debian (actually, a path to a directory with \
> > > > > > "control" file) 
> > > > > > For RPM, qubes-builder will handle unpacking sources, for Debian, you
> > > > > > need to add commands to do it into Makefile.builder, something like:
> > > > > > 
> > > > > > ifneq ($(filter $(DISTRIBUTION), debian qubuntu),)
> > > > > > SOURCE_COPY_IN = debian-source-copy-in
> > > > > > endif
> > > > > > 
> > > > > > debian-source-copy-in: SRC_FILE = \
> > > > > > "$(CHROOT_DIR)/$(DIST_SRC)/nautilus-x.y.z.tar.gz" tar xf $(SRC_FILE) -C \
> > > > > > $(CHROOT_DIR)/$(DIST_SRC) --strip-components=1   
> > > > > > Some more details here:
> > > > > > https://github.com/QubesOS/qubes-builder/blob/master/doc/ComponentConfiguration.md
> > > > > >  
> > > > > > 
> > > > 
> > > > > Hey Marek,
> > > > 
> > > > > I was able to build an entire f25-minimal template. Is there any way to
> > > > > build just the app or perhaps just build a new copy of Nautilus for an
> > > > > existing template?
> > > > 
> > > > Yes, I recommend "make help" ;)
> > > > In short: "make component-name", like "make core-agent-linux". It will
> > > > print list of built packages at the end - you need to copy them into
> > > > appropriate (Template)VM and install using rpm or dnf.
> > > > 
> > > > To build nautilus (which is by default downloaded from upstream
> > > > repositories as binary package), you need to add new component,
> > > > according to instruction above.
> > > > 
> > > > Also, other builder documentation
> > > > https://www.qubes-os.org/doc/qubes-builder/
> > > > 
> > > > 
> > > 
> > > Thanks Marek, I've managed to get it working and all automated with a
> > > dom0 script.
> > > 
> > > I'll also make sure to update you guys more often on my progress going
> > > forward ;)
> > > 
> > > Thanks,
> > > Andrew Morgan
> > > 
> 
> > Quick progress update:
> 
> > I've created the following repos to hold progress of the nautilus patch:
> 
> > https://github.com/anoadragon453/nautilus
> > https://github.com/anoadragon453/nautilus-python
> 
> > The nautilus repo doesn't have commit history as checking out the
> > gnome-3-22 branch from upstream produces a tree that's slightly
> > different from the source package from Fedora repo. Mostly just build stuff.
> 
> > Commits made on there should still be applicable to the upstream branch
> > once finished.
> 
> For working directly with sources, this is the most convenient way. But
> for building and maintaining the package later, it would be better to
> have source package + patches. Then for example rebasing it later would
> be much easier, and will not mess the git history that much. See here
> for example:
> https://github.com/QubesOS/qubes-linux-scrypt
> or here:
> https://github.com/QubesOS/qubes-core-libvirt/
> 
> In fact the second example is maintained in a local git repository
> (clone of upstream), and patches.qubes directory is result of `git
> format-patch ...`. To reconstruct that local repository, you can clone
> upstream repo, then `git am patches.qubes/*`.
> 
> So, for now your repos are ok. But when finished, you'll need to extract
> those patches to:
> 1) send them upstream
> 2) create package in maintainable way
> 
> > Notes/what I've found so far:
> 
> > NautilusPython creates a Python interface to Nautilus' C extensions. It
> > is itself a Nautilus C extension. Nautilus extensions are in fact shared
> > libraries and thus are loaded in at run-time.
> 
> > There are three main areas across the different codebases to worry about:
> > 	NautilusPython: nautilus-python-object.c
> > 	Nautilus: nautilus-info-provider.c
> > 	Nautilus: Wherever a file open call is invoked
> 
> > There are a few different categories of methods that can be called by a
> > nautilus extension. nautilus-info-provider is for getting information
> > about and dealing with files and file data. There exists a method inside
> > already called update_file_info, which is called every time a file is to
> > be displayed on screen, once per file.
> 
> > If an extension subclasses this method, it will be able to alter file
> > properties (such as add an emblem) to each file based on that file's
> > information. Once finished, the extension can return an object that
> > Nautilus' extension infrastructure can use (what is returns is used for
> > determining whether Nautilus should block the main thread's execution
> > until the extension is finished or continue and wait for the extension
> > to tell it when it's finished, but that is irrelevant here).
> 
> > Essentially we also want to define a method that can return a value, in
> > this case a True/False, whenever a file is opened which will tell
> > nautilus whether to open the file or not.
> 
> > Thus I've created a new method, file_open, to do just this. All it
> > should pass to the extension is a NautilusFileInfo object (plus some
> > other boilerplate), which the extension can then use to get the file
> > path, pass that to qvm-file-trust, and return a False if the file is
> > untrusted. The extension should've already began to open the file in a
> > disposableVM, so Nautilus doing nothing at this point is desired.
> 
> > I've created some basic structures for the new method in both nautilus
> > and nautilus-python. I still need to determine where a file is opened
> > and restructure that to be blockable by an extension (I assume have a
> > method that just returns True, that can be overridden by an extension to
> > return false). I'm not sure exactly how Nautilus handles two extensions
> > updating information about the same file, but presumably it does it in
> > some sort of mergable way. This implementation will be easier as we can
> > just take a blocker by any extension to not open the file.
> 
> Sounds good.
> 
> > Documentation for both of these project is kind of lackluster, and some
> > can only be found through the Wayback Machine. Here are the relevant
> > links which I've found helpful thus far:
> 
> > Creating Nautilus extensions:
> > https://web.archive.org/web/20090418175132/http://www.campd.org/stuff/docs/extending-nautilus/NautilusExtensions.html
> > 
> 
> > Nautilus extension API:
> > https://developer.gnome.org/libnautilus-extension/stable/
> 
> > NautilusPython docs:
> > https://projects-old.gnome.org/nautilus-python/documentation/html/index.html
> 
> > Old NautilusPython docs (has better descriptions for some methods):
> > https://web.archive.org/web/*/http://projects.gnome.org:80/nautilus-python/documentation/*
> > 
> 
> > Andrew Morgan
> 

Quick update for tonight.

I've found where the most likely choke point for opening files is. [1]
Ideally one would just make a call to extensions through
libnautilus-extension through there, wait for responses, then return if
any extension returns a False. I'm unsure if anything in Nautilus on the
UX side needs to happen after that (such as showing a loading icon or
something...) but that's currently outside the scope of this patchset.

I've been talking to and getting help from people on GIMPnet/#nautilus.
After explaining the whole idea to a few people, I've been prompted to
post on the mailing list. I have now done so with a RFC of sorts on the
idea and whether or not they'd be prone to accepting it upstream once
it's ready.

The post is currently awaiting moderation approval, but I'll link it
once it goes up so people can keep up with the discussion.

Andrew Morgan

[1]:
https://github.com/GNOME/nautilus/blob/master/src/nautilus-mime-actions.c#L2421

-- 
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/olmjsd%24act%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