Hey guys,
Following a suggestion by a developer, in order to enable audio
recording on Android, I changed spice-gstaudio.c from:
gchar *pipeline =
g_strdup_printf("autoaudiosrc name=audiosrc ! queue !
audioconvert ! audioresample ! "
"appsink caps=\"%s\
- Original Message -
> When the client advertises support for unencrypted tickets, the server
> can instruct it it should send one. For now, this is restricted to
> encrypted channels as we don't want to expose an unencrypted password over
> a non-TLS channel.
> Clients with unencrypted p
- Original Message -
> Now that TicketInfo can contain a plain text ticket, having rsa_ or
> encrypted_ as prefix to most members is not correct.
> ---
> server/reds-private.h | 9 ++---
> server/reds.c | 11 ++-
> 2 files changed, 12 insertions(+), 8 deletions(-)
>
ack
- Original Message -
> In preparation to encrypt the SPICE ticket with either RSA or as plain text
> ticket, it's useful to know which one is expected in TicketInfo.
> ---
> server/reds-private.h | 1 +
> server/reds.c | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletion(-)
- Original Message -
> Currently, SPICE tickets sent to the server are encrypted using a 1024 bit
> public RSA key provided by the server. This key type/size is unfortunately
> set in stone in the SPICE protocol as part of the SpiceLinkReply message,
> and the key is sent by the server ea
ack
- Original Message -
> ---
> server/reds.c | 23 +--
> 1 file changed, 17 insertions(+), 6 deletions(-)
>
> diff --git a/server/reds.c b/server/reds.c
> index 19a3298..f45092b 100644
> --- a/server/reds.c
> +++ b/server/reds.c
> @@ -1843,15 +1843,11 @@ static void
- Original Message -
> ---
> server/reds.c | 68
> +++
> 1 file changed, 41 insertions(+), 27 deletions(-)
>
> diff --git a/server/reds.c b/server/reds.c
> index 1e169ad..19a3298 100644
> --- a/server/reds.c
> +++ b/server/reds.c
ack,
Although my gusts tell me it's better to compose the test_capability() call
with a new link_info_get_caps(), for 2 reasons:
- use prefix by class/struct name
- a get_caps() would nicely abstract that ugly caps= line.
- Original Message -
> This just hides a bit of pointer arithmet
ack, you could commit right away
- Original Message -
> It was spelt 'capabilty'
> ---
> server/red_channel.c | 14 +++---
> server/red_channel.h | 2 +-
> server/reds.c| 4 ++--
> 3 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/server/red_channel.c
- Original Message -
> Currently, SPICE tickets sent to the server are encrypted using a 1024 bit
> public RSA key provided by the server. This key type/size is unfortunately
> set in stone in the SPICE protocol as part of the SpiceLinkReply message,
> and the key is sent by the server ea
>support for unencrypted tickets, the server can
> instruct it it should send one. For now, this is restricted to encrypted
> channels as
> we don't want to expose an unencrypted password over a non-TLS channel.
> Clients with unencrypted password support won't send these just yet as the
> server
---
server/reds.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 19a3298..f45092b 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -1843,15 +1843,11 @@ static void reds_handle_link(RedLinkInfo *link)
}
}
-st
Now that TicketInfo can contain a plain text ticket, having rsa_ or
encrypted_ as prefix to most members is not correct.
---
server/reds-private.h | 9 ++---
server/reds.c | 11 ++-
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/server/reds-private.h b/server/
It was spelt 'capabilty'
---
server/red_channel.c | 14 +++---
server/red_channel.h | 2 +-
server/reds.c| 4 ++--
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/server/red_channel.c b/server/red_channel.c
index b81deeb..4f85365 100644
--- a/server/red_channel.c
---
server/reds.c | 68 +++
1 file changed, 41 insertions(+), 27 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 1e169ad..19a3298 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -1327,6 +1327,46 @@ static void reds_channel_in
When the client advertises support for unencrypted tickets, the server
can instruct it it should send one. For now, this is restricted to
encrypted channels as we don't want to expose an unencrypted password over
a non-TLS channel.
Clients with unencrypted password support won't send these just yet
FIPS is some US-government security thing, which among other things cause
the 1024 bit RSA encryption SPICE tries to use for its password not to work.
This series is an attempt at solving this issue by allowing to encrypt the
password using different methods.
This series only adds a 'plain text' pa
This commit adds the needed caps to let clients know the server can handle
unencrypted tickets, and it adds support for receiving such tickets from
clients.
---
server/reds.c | 42 +-
1 file changed, 25 insertions(+), 17 deletions(-)
diff --git a/server/red
Currently, SPICE tickets sent to the server are encrypted using a 1024 bit
public RSA key provided by the server. This key type/size is unfortunately
set in stone in the SPICE protocol as part of the SpiceLinkReply message,
and the key is sent by the server early in the link process (before the
ser
This just hides a bit of pointer arithmetic away from reds_send_link_ack.
This helper will be used in the next commits.
---
server/reds.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/server/reds.c b/server/reds.c
index 0a28032..1e169ad 100644
--- a/server/red
In preparation to encrypt the SPICE ticket with either RSA or as plain text
ticket, it's useful to know which one is expected in TicketInfo.
---
server/reds-private.h | 1 +
server/reds.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/server/reds-private.h b/server/
Currently, SPICE tickets sent to the server are encrypted using a 1024 bit
public RSA key provided by the server. This key type/size is unfortunately
set in stone in the SPICE protocol as part of the SpiceLinkReply message,
and the key is sent by the server early in the link process (before the
ser
On Wed, Mar 12, 2014 at 3:37 PM, Christophe Fergeau wrote:
> Does this address your concerns?
thanks, I would prefer someone else to review this patch, though... Alon?
--
Marc-André Lureau
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.or
Ping ?
Does this address your concerns?
On Tue, Feb 25, 2014 at 04:14:55PM +0100, Christophe Fergeau wrote:
> Hey,
>
> On Mon, Feb 24, 2014 at 08:26:34PM +0100, Marc-André Lureau wrote:
> > On Mon, Feb 24, 2014 at 6:44 PM, Christophe Fergeau
> > wrote:
> > > During seamless migration, after swi
On Wed, Mar 12, 2014 at 02:35:05PM +0100, Marc-André Lureau wrote:
> > Regardless of that, refusing to connect when the client got passed TLS and
> > non-TLS port if the server is not listening on a non-TLS port is a change
> > of behaviour with earlier versions. And I would not be surprised this
>
On Wed, Mar 12, 2014 at 2:30 PM, Christophe Fergeau wrote:
> On Wed, Mar 12, 2014 at 02:18:04PM +0100, Marc-André Lureau wrote:
>> On Wed, Mar 12, 2014 at 2:15 PM, Christophe Fergeau
>> wrote:
>> > On Tue, Mar 11, 2014 at 07:12:56PM +0100, Marc-André Lureau wrote:
>> >> On Tue, Mar 11, 2014 at 6
On Wed, Mar 12, 2014 at 02:18:04PM +0100, Marc-André Lureau wrote:
> On Wed, Mar 12, 2014 at 2:15 PM, Christophe Fergeau
> wrote:
> > On Tue, Mar 11, 2014 at 07:12:56PM +0100, Marc-André Lureau wrote:
> >> On Tue, Mar 11, 2014 at 6:03 PM, Christophe Fergeau
> >> wrote:
> >> > When qemu only acc
This can fail in fips mode for example. If we ignore the failure, we'll get
a crash:
#0 0x7f38d63728a0 in BN_num_bits () from /lib64/libcrypto.so.10
#1 0x7f38d639661d in RSA_size () from /lib64/libcrypto.so.10
#2 0x7f38d7991762 in reds_handle_read_link_done () from
/lib64/libspi
On Wed, Mar 12, 2014 at 2:15 PM, Christophe Fergeau wrote:
> On Tue, Mar 11, 2014 at 07:12:56PM +0100, Marc-André Lureau wrote:
>> On Tue, Mar 11, 2014 at 6:03 PM, Christophe Fergeau
>> wrote:
>> > When qemu only accepts TLS connections, but spice-gtk is given an URI with
>> > both port and tls-
On Tue, Mar 11, 2014 at 07:12:56PM +0100, Marc-André Lureau wrote:
> On Tue, Mar 11, 2014 at 6:03 PM, Christophe Fergeau
> wrote:
> > When qemu only accepts TLS connections, but spice-gtk is given an URI with
> > both port and tls-port specified, spice_session_channel_open_host() is
> > first att
Hi
- Original Message -
> Support,
> The Linux magazine article mentioned your product. Normally when I need a
> remote desktop, we use mstsc.exe. We have VPN connections that then allow
> the mstsc connection. I was on your download page and I would like to know
> for a Windows7 workstati
FTR.
On Mon, Mar 10, 2014 at 1:08 PM, Marc-André Lureau wrote:
>
> - Original Message -
>> On Mon, Mar 10, 2014 at 11:44 AM, Marc-André Lureau
>> wrote:
>> > - Original Message -
>> >> I have a Windows7 guest with KVM/Qemu on a Gentoo host with i3 window
>> >> manager. I have ins
Support,
The Linux magazine article mentioned your product. Normally when I need a
remote desktop, we use mstsc.exe. We have VPN connections that then allow the
mstsc connection. I was on your download page and I would like to know for a
Windows7 workstation on both ends, which downloads wou
33 matches
Mail list logo
