qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Philippe Mathieu-Daudé
Subject: Re: [Qemu-devel] [PULL v4 00/38] Test and build patches
Date: Fri, 15 Sep 2017 11:47:04 -0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0

Hi Daniel,

On 09/15/2017 08:40 AM, Daniel P. Berrange wrote:
On Fri, Sep 15, 2017 at 11:55:44AM +0100, Peter Maydell wrote:
[...]

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.

which systems are you worried about? build-farms or developer's stations?

why do you want to generate more than 1 key? why not generate 1 key in tests/vm/ (or clever ~/.cache/qemu-vm/ already used by those scripts) once when the make vm-test rule is called, that would be 1 key per repository clone (or 1 per user using ~/.cache).

Distrib aren't using the test suite in binary packages.

Regards,

Phil.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]