Re: [Qemu-devel] [PULL v4 00/38] Test and build patches

[Daniel P. Berrange]

On Fri, Sep 15, 2017 at 11:55:44AM +0100, Peter Maydell wrote:
> On 15 September 2017 at 10:02, Fam Zheng <address@hidden> wrote:
> > The following changes since commit 04ef33052c205170c92df21ca0b4be4f3b102188:
> >
> >   tcg/tci: do not use ldst label (never implemented) (2017-09-11 19:24:05 
> > +0100)
> >
> > are available in the git repository at:
> >
> >   git://github.com/famz/qemu.git tags/test-and-build-pull-request
> >
> > for you to fetch changes up to be78fe670401af14e6d63fce5c5467f751207871:
> >
> >   buildsys: Move rdma libs to per object (2017-09-15 15:05:24 +0800)
> >
> > ----------------------------------------------------------------
> >
> > ----------------------------------------------------------------
> >
> > Alex Bennée (4):
> >   docker: ensure NOUSER for travis images
> >   docker: docker.py make --no-cache skip checksum test
> >   docker: don't install device-tree-compiler build-deps in travis.docker
> >   docker: reduce noise when building travis.docker
> >
> > Fam Zheng (34):
> >   docker: Update ubuntu image
> >   docker: Enable features explicitly in test-full
> >   tests/docker: Clean up paths
> >   gitignore: Ignore vm test images
> >   qemu.py: Add "wait()" method
> >   scripts: Add archive-source.sh
> >   tests: Add a test key pair
> 
> So, before I commit an ssh private key to our git repo,
> can you explain why it's ok that this is public? The
> commit message for the relevant patch doesn't really say.

IIUC, the public part of the key gets exposed to the guest images via
cloud-init metadata. During boot the guest read this metadata and add
the public key to authorized_keys. The private key is used by the test
suite on the host so that it can now login to the guests.

So the risk here is that if these guests were exposed to the LAN in any
way, someone could grab our private key and login to these guests.

What saves us is that the VMs are run with user mode slirp networking
so AFAICT, aren't exposed to the LAN.  So as long as we don't change
this to any kind of real networking, I think its acceptable to have
the private key in it and doesn't expose developer's workstations to
undue risk and avoids consuming system entropy to generate new keys
during build.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|