Runtime conversion from a string to uint32 is storing the magic with the same
endianness on both LE and BE machines. This requires aditional byte swap
when sending magic between LE/BE machines.
Changing quic magic to a constant will ensure, that it will be always stored in
native endianness, and the second byte swap won't be needed.
Commit d39dfbfe changes lz magic to be always treated as LE when encoded.
Runtime conversion from a string to uint32 is storing the magic with the same
endianness on both LE and BE machines. This requires aditional byte swap
when sending magic between LE/BE machines.
Changing lz magic to a constant will ensure, that it will be always stored in
native endianness, and the second byte swap won't be needed.
This commit reverts d39dfbfe changes in lz.c while keeping the rest.
They will be needed in future commit for quic.c
When accessing a virtual desktop from different devices, some may have
different image compression requirements, e.g. slow devices may prefer
the faster LZ4 over GLZ. This message instructs the server to switch the
image compression algorithm. This patch also promotes the
SPICE_IMAGE_COMPRESS_* constants so that they are available from both
the server and the client.
Signed-off-by: Erlon R. Cruz <erlon.cruz@br.flextronics.com>
Signed-off-by: Rafael F. Santos <fonsecasantos.rafael@gmail.com>
Signed-off-by: Fabiano Fidêncio <Fabiano.Fidêncio@fit-tecnologia.org.br>
Both wincrypt.h and openssl try to define X509_NAME. The wincrypt.h one
is not useful for us, so we currently #undef it if this was set.
However, it's done very late, right before including x509v3.h which
defines the X509_NAME type. Any header included in between may try to
#include x509v3.h so it's better to undefine X509_NAME right after
including wincrypt.h.
Every time it's used, it's in constructs similar to:
#ifdef SW_CANVAS_CACHE
, SpiceImageCache *bits_cache
, SpicePaletteCache *palette_cache
#elif defined(SW_CANVAS_IMAGE_CACHE)
, SpiceImageCache *bits_cache
#endif
This can be rewritten as:
, SpiceImageCache *bits_cache
#ifdef SW_CANVAS_CACHE
, SpicePaletteCache *palette_cache
#endif
allowing to get rid of SW_CANVAS_IMAGE_CACHE.
Fix the row alignment for 16/24 bpp images when it is not in a 32bit
boundary. This is needed for 16bpp images when the width is an odd
number, and for the future support of 24bpp images.
SW_CANVAS_CACHE is always defined when building spice-gtk,
SW_CANVAS_IMAGE_CACHE is always defined when building spice-server, and
they are the only 2 users of spice-common. Moreover, build when none of
these is defined is broken.
All canvas_get_{quic,jpeg,lz4,jpeg_alpha,lz} methods have an 'invers'
argument, but are always called with that argument being 0, so we can
drop it from the argument list, and remove the code triggerring when
it's true.
Commit 4fafa210 added WARN_CFLAGS, VISIBILITY_HIDDEN_CFLAGS and
-std=gnu99 to AM_CFLAGS in common/Makefile.am, but these are not
needed. WARN_CFLAGS and VISIBILITY_HIDDEN_CFLAGS are not defined
anywhere in spice-common, and spice-common compiles fine without
-std=gnu99 on my f21 box.
- Add a new LZ4 image type to spice.proto.
- Add canvas_get_lz4() to common_canvas_base, to get a pixmap from an
lz4 image.
- Add an enable-lz4 switch to the configure script, disabled by default.
Check for MELCSTATES - 1 to get inside the branch, otherwise
(...)->rgb_state.melcstate may be up to MELCSTATES after the
pre-incrementing, which would result in an access to a position
that is out bounds of the array size MELCSTATES.
These 2 files are not build as part of spice-common
build system, but modules using spice-common will build
them with the appropriate options. We need to let automake
know that these are source files so that it can properly
track these files dependencies.
Without this change, when eg spice-gtk switches to use 'subdir-objects'
to build sw_canvas.c as recommended by automake 1.14, the build
will fail because $(top_srcdir)/spice-common/common/.deps/sw_canvas.Plo
will not have been generated.
Now that they are created in $builddir, their includes will need to refer
to files in $srcdir, which can be different. It's cleaner to add
-I $(top_srcdir)/spice-common/ to modules using spice-common rather than
having -I $(top_srcdir)/spice-common/common which would could create header
collisions.
The rules to generate the .c/.h (de)marshalling files have targets based in
$builddir, but the CLIENT_MARSHALLERS/SERVER_MARSHALLERS list refer to
files in $srcdir.
When using a $srcdir != $builddir, these $srcdir files will not exist, and
it will not be possible to generate them, which causes the build to fail.
When using $srcdir == $builddir from git or from tarballs, this will not
make a difference. When building from git, if $srcdir and $builddir are the
same, then the files will be found regardless of if we look for them in
$srcdir or $builddir as they are the same.
In tarballs, the files will be shipped with the tarball and thus available
in $srcdir. As $builddir is the same as $srcdir, the files will already
exist and not be regenerated.
The only change of behaviour will be when using a tarball and doing a
$srcdir != $builddir build. In this case, the files will need to be
regenerated, so the tools needed for that must be installed on the
machine doing the build.
find_model_params() is first doing *nbuckets = 0; and it then checks
nbuckets for NULL. This is redundant as the dereferencing would cause a
segfault if nbuckets was NULL, so the if (nbuckets) test can't be false.
As Uri pointed out, the "/* bucket start */" comment on the same line
probably implies that the test was meant to be 'if (*nbuckets)'
I've ran a few test and I did not observe issues because of it...
If verify_subject() is called with a SpiceOpenSSLVerify struct containing a
non-NULL 'in_subject' member, it would try to use the local 'in_entries'
variable without having initialized it first. This could happen if
verify_subject() was called multiple time with the same SpiceOpenSSLVerify
context, which probably isn't occurring the way we are using it.
However, since verify_subject() is the only method which needs in_subject,
we don't need to have it stored in SpiceOpenSSLVerify, and we can
recreate it as needed locally in that method, which avoids that issue.
Unhandled values call an error callback, and then fall through the default:
case, which will call again the error callback. This commit adds some
break; after these cases to avoid this.
We are mostly likely not running as root, so this call will fail. As we are
supposed to check its return value as it's declared with
warn_unused_result, the current way of using it is wrong, so this commit just
removes the call.
Currently, SSL verification of the peer certificate checks if
the certificate's subject CN or one of its subjectAltName match
the hostname. If this succeeds, then the verification succeeds.
Otherwise openssl_verify() checks the cert subject if this was set,
which means it checks the certificate's subject (not just its CN) matches
exactly the cert subject string that is set in SpiceSession.
Given that the cert subject is something the user specifies in addition
to the hostname, the cert subject check should have priority over the
hostname check, that is, when we have a cert subject set, the
success/failure of the cert subject cert should determine the
success/failure of openssl_verify(), and the hostname check
should only be carried out when no cert subject was set.
This fixes rhbz#871034
