For example, with qemu, a webdav channel can be created this way:
-chardev spiceport,name=org.spice-space.webdav.0,...
And redirected to a virtio port:
-device virtserialport,...,name=org.spice-space.webdav.0
When trying to start mjpeg compression mode, mjpeg_encoder_start_frame()
tests the image format as its only able to compress 24/32bpp images. On
images with lower bit depths, we return MJPEG_ENCODER_FRAME_UNSUPPORTED to
indicate this is not a format we can compress. However, this return goes
with a spice_warning("unsupported format"). As the rest of the code can
cope with this unsupported format by not doing mjpeg compression, it's
nicer to downgrade this spice_warning() to spice_debug().
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1070028
The private data is allocated at the same time as RedsStream and
goes immediatly after the main RedsStream data.
This private member will allow to hide internal RedsStream
implementation details from the rest of spice-server.
SASL authentication mostly use members from RedsStream to do its work, so
it makes sense to have its code in reds_stream.c. This should allow to make
RedsStream::sasl private in the future.
The AsyncRead structure in reds.h wraps an async read + callback to
be done on a stream. Moving it to reds_stream.h is needed in order
to move SASL authentication there.
Now that stream creation and SSL enabling are done by helpers
in reds_stream.c, we can move the initialization of the vfunc
read/write pointers there too.
Initializing a new stream means initializing quite a few fields.
This commit factors this initialization in a dedicated reds_stream_new
helper. This also helps moving more code from reds.c to reds_stream.c
test-display-streaming is calling malloc() without checking its return
value. Coverity warns about this. This commit switches to g_malloc() to
sidestep this warning (g_malloc() never returns NULL but aborts instead).
When creating a TLS socket, both spice-server and spice-gtk currently
call SSL_CTX_new(TLSv1_method()). The TLSv1_method() function set the
protocol version to TLS 1.0 exclusively. The correct way to support
multiple protocol versions is to call SSLv23_method() in spite of its
scary name. This method will enable all SSL/TLS protocol versions. The
protocol suite may be further narrowed down by setting respective
SSL_OP_NO_<version_code> options of SSL context. This possibility is
used in this patch in order to block use of SSLv3 that is enabled by
default in openssl for client sockets as of now but spice has never used
it.
This file was added in bc50ff076 a few months ago, but is not listed
in Makefile.am, and thus not part of tarballs. However, it's being included
from other C files, so not having it causes compilation breakage.
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
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
