[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qubes-devel
Subject:    Re: [qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #7
From:       Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek () invisiblethingslab ! com>
Date:       2017-07-30 9:42:51
Message-ID: 20170730094251.GJ13907 () mail-itl
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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
> 




- -- 
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

iQEcBAEBCAAGBQJZfaocAAoJENuP0xzK19csbI4H/RBAsaSJUXyYJI0fhmY5qjB8
qLGLSSn9Y+D2wotwlgxYsOhB5Se+gkQxwoomOaXdr+9QTEDQH3EO7uayBgGDrUv8
9zmv1ePSDWfl/wJ8JkYOhPA6fEsnIYG2Ul9VN7gI7ZDxcIjwyWQt6D7dF2Y9a29a
orNBhoJnGwWWZxTsD0UxZ9tfIJuwHlS+OuOCAvpO9qKN5M4k8Ve5vFlD3HnyJQNF
RRRccDsjFTa5x6mmZUlSPgZn01mQCpXKVbTSGd5hOjyZlUiZzCynGgRRRKfmnNl/
SvBmNuOWMZzhB7thEu5DA0wWIVZEEbgBFejcKr/z4/En+X88G/Q84cPdrMJQCdQ=
=ImZW
-----END PGP SIGNATURE-----

-- 
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/20170730094251.GJ13907%40mail-itl. For \
more options, visit https://groups.google.com/d/optout.


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic