[Spice-devel] [PATCH spice-streaming-agent] Revert "build: Use pkgconfig to detect libjpeg"

This reverts commit 5240f212ed364d5139f30810b14884f8e2c03535. RHEL 7 does not provide a pkg-config module for libjpeg. Signed-off-by: Frediano Ziglio --- configure.ac | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/configure.ac

[Spice-devel] The streaming port is renamed

Hello, as a heads-up, I've merged the SPICE streaming port rename patch [1]. Once you pull either SPICE server or the streaming agent, you'll need to pull the other one (or, with the streaming agent, you can use the old one and pass it the port name via the -p argument) and also rename the port

Re: [Spice-devel] [PATCH spice v2 1/1] rename the virtio port for streaming

> On Thu, 2018-04-05 at 08:23 -0400, Frediano Ziglio wrote: > > > On Mon, 2018-03-26 at 08:31 -0400, Frediano Ziglio wrote: > > > > > > > > > > On Fri, 2018-03-23 at 11:09 -0400, Frediano Ziglio wrote: > > > > > > > > > > > > > > From: Lukáš Hrázký > > > > > > > > > > > > > >

Re: [Spice-devel] [PATCH spice v2 1/1] rename the virtio port for streaming

On Thu, 2018-04-05 at 08:23 -0400, Frediano Ziglio wrote: > > On Mon, 2018-03-26 at 08:31 -0400, Frediano Ziglio wrote: > > > > > > > > On Fri, 2018-03-23 at 11:09 -0400, Frediano Ziglio wrote: > > > > > > > > > > > > From: Lukáš Hrázký > > > > > > > > > > > > The name

Re: [Spice-devel] [PATCH 1/2] Ensure that plugins cannot bypass version check

On Fri, Mar 23, 2018 at 01:05:23PM +0100, Christophe de Dinechin wrote: > 3. Major.minor numbering scheme > > The major.minor numbering scheme initially selected makes it harder > to fixes cases where an incompatibility was detected after release. I'm still of the opinion that we should break

Re: [Spice-devel] [PATCH spice v2 1/1] rename the virtio port for streaming

> On Mon, 2018-03-26 at 08:31 -0400, Frediano Ziglio wrote: > > > > > > On Fri, 2018-03-23 at 11:09 -0400, Frediano Ziglio wrote: > > > > > > > > > > From: Lukáš Hrázký > > > > > > > > > > The name 'com.redhat.stream.0' is too generic and in no way denotes > > > > > it > > >

Re: [Spice-devel] [PATCH spice v2 1/1] rename the virtio port for streaming

On Mon, 2018-03-26 at 08:31 -0400, Frediano Ziglio wrote: > > > > On Fri, 2018-03-23 at 11:09 -0400, Frediano Ziglio wrote: > > > > > > > > From: Lukáš Hrázký > > > > > > > > The name 'com.redhat.stream.0' is too generic and in no way denotes it > > > > belongs to SPICE. It

Re: [Spice-devel] [PATCH spice-gtk v2] spice-channel: Disable TLS v1.0

On Thu, Apr 05, 2018 at 10:56:57AM +0100, Frediano Ziglio wrote: > TLS v1.0 is now considered insecure. > The protocol is already disabled on the server side (cfr commit commit > fac12737d "reds: Disable TLS 1.0"). > To avoid downgrade attacks disable it even on the client. > > Related:

[Spice-devel] [PATCH spice-gtk v2] spice-channel: Disable TLS v1.0

TLS v1.0 is now considered insecure. The protocol is already disabled on the server side (cfr commit commit fac12737d "reds: Disable TLS 1.0"). To avoid downgrade attacks disable it even on the client. Related: https://bugzilla.redhat.com/show_bug.cgi?id=1521053 Signed-off-by: Frediano Ziglio

Re: [Spice-devel] [spice-server] cursor: Consistently use g_memdup() for cursor data

> > On Thu, Apr 05, 2018 at 10:55:13AM +0200, Christophe Fergeau wrote: > > On Thu, Apr 05, 2018 at 04:43:17AM -0400, Frediano Ziglio wrote: > > > > > > > > Currently, red-parse-qxl.c open codes g_memdup() when it needs to > > > > > > "open codes" ? > > > well, currently uses g_malloc+memcpy

Re: [Spice-devel] [spice-server] cursor: Consistently use g_memdup() for cursor data

On Thu, Apr 05, 2018 at 10:55:13AM +0200, Christophe Fergeau wrote: > On Thu, Apr 05, 2018 at 04:43:17AM -0400, Frediano Ziglio wrote: > > > > > > Currently, red-parse-qxl.c open codes g_memdup() when it needs to > > > > "open codes" ? > > well, currently uses g_malloc+memcpy which can be

Re: [Spice-devel] [PATCH spice-gtk] spice-channel: Disable TLS v1.0

On Thu, Apr 05, 2018 at 10:35:55AM +0100, Frediano Ziglio wrote: > TLS v1.0 is now considered insecure. > The protocol is already disabled on the server side. + commit fac12737d > To avoid downgrade attacks disable it even on the client. + Related:

[Spice-devel] [PATCH spice-gtk] spice-channel: Disable TLS v1.0

TLS v1.0 is now considered insecure. The protocol is already disabled on the server side. To avoid downgrade attacks disable it even on the client. Signed-off-by: Frediano Ziglio --- src/spice-channel.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [Spice-devel] Gitlab - 2018!

Hi, So, no bug migration at this point. Repos can be done as soon as team sign up for Gitlab. If you have ssh access already, just go to link [0], add your username and request for a password in 'Forgot your password' - that will send you an url by email to (re)set it. [0]

Re: [Spice-devel] [spice-server] cursor: Consistently use g_memdup() for cursor data

On Thu, Apr 05, 2018 at 04:43:17AM -0400, Frediano Ziglio wrote: > > > > Currently, red-parse-qxl.c open codes g_memdup() when it needs to > > "open codes" ? > well, currently uses g_malloc+memcpy which can be rewritten with > g_memdup. Yes, doing this can be seen as reimplementing g_memdup,

Re: [Spice-devel] Gitlab - 2018!

Hi, On Thu, Apr 05, 2018 at 04:37:13AM -0400, Frediano Ziglio wrote: > > > > Hi, > > > > On Wed, Apr 04, 2018 at 11:50:47PM -0300, Eduardo Lima (Etrunko) wrote: > > > On 04/04/18 10:44, Victor Toso wrote: > > > > Hey, > > > > > > > > Considering [2], is there anyone with issue in me filing a

Re: [Spice-devel] [spice-server] cursor: Consistently use g_memdup() for cursor data

> > Currently, red-parse-qxl.c open codes g_memdup() when it needs to "open codes" ? well, currently uses g_malloc+memcpy which can be rewritten with g_memdup. > duplicate the cursor data, while red-stream-device.c does this using > spice_memdup(). This commit makes use of g_memdup() in both

Re: [Spice-devel] Gitlab - 2018!

> > Hi, > > On Wed, Apr 04, 2018 at 11:50:47PM -0300, Eduardo Lima (Etrunko) wrote: > > On 04/04/18 10:44, Victor Toso wrote: > > > Hey, > > > > > > Considering [2], is there anyone with issue in me filing a bug to > > > migrate to freedesktop's instance of gitlab? > > > > > > > Go Victor,

[Spice-devel] [spice-server] cursor: Delay release of QXL guest cursor resources

There's an implicit API/ABI contract between QEMU and SPICE that SPICE will keep the guest QXL resources alive as long as QEMU can hold a pointer to them. This implicit contract was broken in 1c6e7cf7 "Release cursor as soon as possible", causing crashes at migration time. While the proper fix

[Spice-devel] [spice-server] cursor: Consistently use g_memdup() for cursor data

Currently, red-parse-qxl.c open codes g_memdup() when it needs to duplicate the cursor data, while red-stream-device.c does this using spice_memdup(). This commit makes use of g_memdup() in both cases so that this memory is consistently allocated through glib. Signed-off-by: Christophe Fergeau

Re: [Spice-devel] [spice-gtk v1 03/11] channel-display: remove unneeded function

Hi, On Wed, Apr 04, 2018 at 06:07:49AM -0400, Frediano Ziglio wrote: > > > > From: Victor Toso > > > > The get_stream_id_by_stream() was introduced in 141c2d82 to debug > > GStreamer's pipeline. But with previous patch, we are moving the ID to > > the display_stream

Re: [Spice-devel] [spice-gtk v1 02/11] channel-display: rename display_stream_destroy()

On Tue, Mar 13, 2018 at 09:20:11AM -0400, Frediano Ziglio wrote: > > > > From: Victor Toso > > > > This patch also renames destroy_display_stream() to > > I would remove the "also", I think just a leftover. Yes, it is. I'll remove it locally > > >

Re: [Spice-devel] [linux vdagent PATCH v2] x11-randr: do not assume each output has ncrtc=1

Hi, On Mon, Apr 02, 2018 at 04:22:11PM +0300, Uri Lublin wrote: > Unlike virtual graphic cards, device-assigned graphic cards can > have more than one crtc per output. > > Still we currently pick only a single crtc for each output > (but looping over them to find an active one) > >

Re: [Spice-devel] Gitlab - 2018!

Hi, On Wed, Apr 04, 2018 at 11:50:47PM -0300, Eduardo Lima (Etrunko) wrote: > On 04/04/18 10:44, Victor Toso wrote: > > Hey, > > > > Considering [2], is there anyone with issue in me filing a bug to > > migrate to freedesktop's instance of gitlab? > > > > Go Victor, GO!!! Okay, just filed the