Re: How do you hack on GNOME? How can we do better?

[Owen Taylor <otaylor redhat com>]

On Tue, 2015-07-21 at 12:22 +0100, Simon McVittie wrote:
> On 21/07/15 00:11, Owen Taylor wrote:
> > We could theoretically address 2 by having our standard test setup
> > to run in a VM, but a lot of aspects of the system don't test well
> > in a VM - touchscreen input, multimonitor, networking UI, sound, 
> > etc.
>
> VMs do have the advantage that they are definitely a trust boundary:
> running a branch of some component in a VM does not require you to 
> trust that branch with all your data, credentials and so on. Test 
> uids and VT-switching have the same advantages, but only work for the 
> user session, not for system components like NetworkManager.

This only works, of course, if your *builds* are also inside the
virtual machine, or are effectively sandboxed.

> Containers are not (in general) an answer to this, because my
> understanding of the state of the art is that containers don't really
> contain: root in a container can usually escape. So they're OK for 
> the same use-cases where test uids work, and additionally they can
> virtualize system-level libraries like a chroot would (e.g. to have a
> newer GLib in your container without playing with LD_LIBRARY_PATH), 
> but they don't help for the NetworkManager use-case.

I think we're pretty good with LD_LIBRARY_PATH these days. The main
advantage of a container over a separate UID is that it potentially
allows testing new versions system-level services. But you have to make
the services work inside a container, which is non-trivial.

> I personally try to stick to VMs or test uids for anything that isn't
> either something I can reasonably audit myself, or a supported 
> release of my preferred OS distribution (in my case Debian, where the
> responsibilities of a package maintainer are meant to include 
> checking new versions for malicious changes).

Hmm, I have some strong doubts about packagers as a reliable line of
defense against malicious code - especially since malicious code could
be very subtle. But yes, there is an advantage not having everything
that is committed to git immediately having full access to developer's
user accounts. A goal to shoot for.

> Throwaway virtual machines (qemu with kvm, running from an image on a
> tmpfs), on a laptop with all the RAM, are a wonderful thing.
> Accidentally broke the whole system with an ill-considered packaging
> change? Delete it, copy your clean vmdebootstrap image back into the
> tmpfs, try again... using an emulated serial console for developer
> access and a shared directory for file transfer is particularly 
> powerful.
>
> I recognise that this approach has limitations that make it 
> unsuitable for many GNOME developers, though: I'm lucky in that I 
> mostly work on plumbing and OS-building rather than hardware 
> integration.

Do you build in the VM or outside the VM?

- Owen