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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
