Hey guys,
the alsa libraries/header seem to be required only when configured with
--enable-client so I wrote a patch to make configure respect it.
--
Regards,
Christian Ruppert
From 53683cc75ba092799f856f710cb45b2aacfb6123 Mon Sep 17 00:00:00 2001
From: Christian Ruppert <idl0r@gentoo.org>
Date: Sun, 3 Nov 2013 18:36:26 +0100
Subject: [PATCH] Require alsa only with --enable-client
reds_handle_ticket uses a fixed size 'password' buffer for the decrypted
password whose size is SPICE_MAX_PASSWORD_LENGTH. However,
RSA_private_decrypt which we call for the decryption expects the
destination buffer to be at least RSA_size(link->tiTicketing.rsa)
bytes long. On my spice-server build, SPICE_MAX_PASSWORD_LENGTH
is 60 while RSA_size() is 128, so we end up overflowing 'password'
when using long passwords (this was reproduced using the string:
'fullscreen=1proxy=#enter proxy here; e.g spice_proxy = http://[proxy]:[port]'
as a password).
When the overflow occurs, QEMU dies with:
*** stack smashing detected ***: qemu-system-x86_64 terminated
This commit ensures we use a corectly sized 'password' buffer,
and that it's correctly nul-terminated so that we can use strcmp
instead of strncmp. To keep using strncmp, we'd need to figure out
which one of 'password' and 'taTicket.password' is the smaller buffer,
and use that size.
This fixes rhbz#999839
It's depending on an unmaintained package (slirp), and I don't
think anyone uses that code. It's not tested upstream nor in fedora,
so let's remove it.
Some versions of gcc warn about:
red_channel.c: In function 'red_channel_client_wait_outgoing_item':
red_channel.c:2331: error: 'end_time' may be used uninitialized in this function [-Wuninitialized]
red_channel.c: In function 'red_channel_client_wait_pipe_item_sent':
red_channel.c:2363: error: 'end_time' may be used uninitialized in this function [-Wuninitialized]
red_channel.c: In function 'red_channel_wait_all_sent':
red_channel.c:2401: error: 'end_time' may be used uninitialized in this function [-Wuninitialized]
This is a false positive as end_time is unitialized when timeout is -1, and
we will only try to use end_time if timeout is not -1.
This commit initializes end_time to UINT64_MAX to avoid that warning. As
the test involving end_time will never be reached, we ensure it's always
TRUE so that it would be a noop even if it was reached.
This commit reuse several macros from libvirt to test for
support for "-Wl,-z -Wl,relro", "-Wl,-z -Wl,now" and
"-Wl,--no-copy-dt-needed-entries", and use them if available.
Releasing modifiers keys unconditionally on disconnect leads to
unexpected guest wakeups. To improve the situation, the server can
release only the pressed keys, which will prevent the wakeup in most
cases.
Furthermore, it's not sufficient to release only the modifiers keys.
Any key should be released on client disconnect to avoid sticky key
press across connections.
https://bugzilla.redhat.com/show_bug.cgi?id=871240
The primary buffer doesn't use stencil test. However, this should be
explicitely disabled, since the canvas might change stencil state, and
this will affect primary stencil buffer, making some of further update
operations clipped in unwanted ways.
Setting CHECKDIFF=1 environment variable will compare the rendering of
the selected canvas with a software canvas. This is useful for debugging
some rendering issues, however it is far from being perfect, since it's
not able to tell whether one or the other is actually faulty. It's a
strong indication though of which operations are incorrect.
Ideally, all operations should be checked, however, a few of them are
disabled by default because they fail all the time, and it looks like
pixman is not very accurate for blending/compositing (at least visually,
it seems gl has better rendering)
First, context must set it, then Draw/ReadBuffer must be set to FRONT,
and then explicit Flush is needed.
This patch is mostly for future reference, it is mostly discarded in
following patch using double-buffer.
rhbz#1004443
The methods that trigger waitings on the client pipe require that
the waiting will succeed in order to continue, or otherwise, that
all the living pipe items will be released (e.g., when
we must destroy a surface, we need that all its related pipe items will
be released). Shutdown of the socket will eventually trigger
red_channel_client_disconnect (*), which will empty the pipe. However,
if the blocking method failed, we need to empty the pipe synchronously.
It is not safe(**) to call red_channel_client_disconnect from ChannelCbs
, but all the blocking calls in red_worker are done from callbacks that
are triggered from the device.
To summarize, calling red_channel_client_disconnect instead of calling
red_channel_client_shutdown will immediately release all the pipe items that are
held by the channel client (by calling red_channel_client_pipe_clear).
If red_clear_surface_drawables_from_pipe timeouts,
red_channel_client_disconnect will make sure that the surface we wish to
release is not referenced by any pipe-item.
(*) After a shutdown of a socket, we expect that later, when
red_peer_handle_incoming is called, it will encounter a socket
error and will call the channel's on_error callback which calls
red_channel_client_disconnect.
(**) I believe it was not safe before commit 2d2121a170 (before adding ref
count to ChannelClient). However, I think it might still be unsafe, because
red_channel_client_disconnect sets rcc->stream to NULL, and rcc->stream
may be referred later inside a red_channel_client method unsafely. So instead
of checking if (stream != NULL) after calling callbacks, we try to avoid
calling red_channel_client_disconnect from callbacks.
(1) merge 'force' and 'wait_for_outgoing_item' to one parameter.
'wait_for_outgoing_item' is a derivative of 'force'.
(2) move the call to red_wait_outgoing_item to red_clear_surface_drawables_from_pipe
client/Makefile.am:199: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
server/tests/Makefile.am:3: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
If the _FORTIFY_SOURCE has been already defined, we shouldn't redefine
it, or it will raise a build error as below:
In file included from agent-msg-filter.c:21:0:
../config.h:17:0: error: "_FORTIFY_SOURCE" redefined [-Werror]
agent-msg-filter.c:1:0: note: this is the location of the previous definition
Suggested-by: Christophe Fergeau <cfergeau@redhat.com>
Signed-off-by: Dunrong Huang <riegamaths@gmail.com>
After eb09c25c, red_parse_qxl.c still has some spice_error() which
will kill the server even though the code is trying to return an error
when the spice_error() is hit.
This commit replaces these occurrences with a spice_warning() which
will not kill spice-server.
bitmap_consistent should return true or false.
Currently it aborts instead of returning false, due to spice_error.
Replacing spice_error with spice_warning, provides information and returns
false, as expected.
This fixes Fedora bz#997932
rhbz#994175
When a client connection is closed surprisingly (i.e., without a FIN
segment), we cannot identify it by a socket error (which is the only
way by which we identified disconnections so far).
This patch allows a channel client to periodically check the state of
the connection and identify surprise disconnections.
