From: Cleber Rosa <crosa@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: "Fam Zheng" <fam@euphon.net>,
"Eduardo Habkost" <ehabkost@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
qemu-devel@nongnu.org,
"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: [Qemu-devel] [PATCH 7/8] VNC Acceptance test: check protocol version
Date: Fri, 7 Jun 2019 14:12:07 -0400 [thread overview]
Message-ID: <20190607181207.GA20051@localhost.localdomain> (raw)
In-Reply-To: <20190607172915.GN28838@redhat.com>
On Fri, Jun 07, 2019 at 06:29:15PM +0100, Daniel P. Berrangé wrote:
> On Fri, Jun 07, 2019 at 11:22:22AM -0400, Cleber Rosa wrote:
> > This goes a bit further than the other tests, and does a basic (read
> > only) interaction with the VNC protocol.
> >
> > This is not a enough to perform a handshake, but enough to make sure
> > that the socket is somewhat operational and that the expected initial
> > step of the handshake is performed by the server and that the version
> > matches.
>
> The GTK-VNC project provides a low level library libgvnc that can
> be used to talk the RFB protocol in a fairly fine grained manner.
> This is built using GObject, so is accessible from Python thanks
> to GObject Introspection.
>
Interesting.
> We could use libgvnc for exercising the VNC server instead of writing
> custom RFB code. For your simple test just sending/receiving the
> version it won't save much, but if we ever want to test TLS or
> SASL integration, it would save alot of work dealing wth the auth
> handshake and subsequent encryption needs.
>
Absolutely.
> The main limitation it would have is that it would only work well
> for sending "well formed" RFB protocol messages. If we ever want to
> send intentionally evil/bad RFB data to check QEMU's VNC server
> security hardening it would be harder.
>
Right. Still, there's a lot that can be done until we eventually
exaust all possibilities and look into sending bad messages.
> As the maintainer of GTK-VNC though, I would be open to adding more
> APIs to the low level gvnc library to facilitate QEMU's testing
> needs if we want.
>
I personally need to get acquainted with the currently available APIs
first, but it looks like you alread have ideas for extensions that
would come in handy.
Also, the one concern I have is how to deploy the library and Python
bindings so that we can host those more advanced tests and still allow
for a "make check-acceptance"-like experience. What I mean is, I
expect the Python bindings to be easily installed by pip, by I'd be
(positively) surprised if the libgvnc would also have such an easy
bootstrap.
Any ideas on this?
Thanks!
- Cleber.
> >
> > Signed-off-by: Cleber Rosa <crosa@redhat.com>
> > ---
> > tests/acceptance/vnc.py | 12 ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/tests/acceptance/vnc.py b/tests/acceptance/vnc.py
> > index d32ae46685..b000446d7c 100644
> > --- a/tests/acceptance/vnc.py
> > +++ b/tests/acceptance/vnc.py
> > @@ -11,6 +11,7 @@
> > import os
> > import tempfile
> > import shutil
> > +import socket
> >
> > from avocado_qemu import Test
> >
> > @@ -71,5 +72,16 @@ class VncUnixSocket(Test):
> > arg='new_password')
> > self.assertEqual(set_password_response['return'], {})
> >
> > + def test_protocol_version(self):
> > + self.vm.add_args('-nodefaults', '-S',
> > + '-vnc', 'unix:%s' % self.socket_path)
> > + self.vm.launch()
> > + self.assertTrue(self.vm.qmp('query-vnc')['return']['enabled'])
> > + client = socket.socket(socket.AF_UNIX)
> > + client.connect(self.socket_path)
> > + expected = b'RFB 003.008'
> > + actual = client.recv(len(expected))
> > + self.assertEqual(expected, actual, "Wrong protocol version")
> > +
> > def tearDown(self):
> > shutil.rmtree(self.socket_dir)
> > --
> > 2.21.0
> >
> >
>
> 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 :|
next prev parent reply other threads:[~2019-06-07 19:20 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-07 15:22 [Qemu-devel] [PATCH 0/8] Miscellaneous acceptance test and Travis CI improvements Cleber Rosa
2019-06-07 15:22 ` [Qemu-devel] [PATCH 1/8] Travis: print acceptance tests logs in case of job failure Cleber Rosa
2019-06-10 19:46 ` Wainer dos Santos Moschetta
2019-06-14 14:14 ` Alex Bennée
2019-06-07 15:22 ` [Qemu-devel] [PATCH 2/8] tests/requirements.txt: pin paramiko version requirement Cleber Rosa
2019-06-10 19:47 ` Wainer dos Santos Moschetta
2019-06-14 14:17 ` Philippe Mathieu-Daudé
2019-06-07 15:22 ` [Qemu-devel] [PATCH 3/8] Acceptance tests: drop left over usage of ":avocado: enable" Cleber Rosa
2019-06-10 19:48 ` Wainer dos Santos Moschetta
2019-06-14 14:17 ` Philippe Mathieu-Daudé
2019-06-07 15:22 ` [Qemu-devel] [PATCH 4/8] Boot Linux Console Test: add a test for ppc64 + pseries Cleber Rosa
2019-06-10 20:02 ` Wainer dos Santos Moschetta
2019-06-07 15:22 ` [Qemu-devel] [PATCH 5/8] VNC Acceptance test: use UNIX domain sockets to avoid port collisions Cleber Rosa
2019-06-10 20:27 ` Wainer dos Santos Moschetta
2019-06-07 15:22 ` [Qemu-devel] [PATCH 6/8] VNC Acceptance test: simplify test names Cleber Rosa
2019-06-10 20:28 ` Wainer dos Santos Moschetta
2019-06-14 14:18 ` Philippe Mathieu-Daudé
2019-06-07 15:22 ` [Qemu-devel] [PATCH 7/8] VNC Acceptance test: check protocol version Cleber Rosa
2019-06-07 17:29 ` Daniel P. Berrangé
2019-06-07 18:12 ` Cleber Rosa [this message]
2019-06-10 8:58 ` Daniel P. Berrangé
2019-06-10 20:43 ` Wainer dos Santos Moschetta
2019-06-07 15:22 ` [Qemu-devel] [PATCH 8/8] Migration acceptance test: reduce the possibility of port collisions Cleber Rosa
2019-06-07 15:26 ` [Qemu-devel] [PATCH 0/8] Miscellaneous acceptance test and Travis CI improvements Cleber Rosa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190607181207.GA20051@localhost.localdomain \
--to=crosa@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=berrange@redhat.com \
--cc=ehabkost@redhat.com \
--cc=fam@euphon.net \
--cc=philmd@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=wainersm@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.