Re: [Spice-devel] virt-viewer for Windows is quite difficult to download

2014-03-20 Thread Uri Lublin 

On 03/20/2014 04:22 PM, Jonathon Jongsma wrote:

alternately, we could just change the link text to something else so the user 
doesn't think that the link will lead directly to an .msi file?


Done.

Thanks,
Uri.

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH 2/3] Introduce red_link_info_test_capability()

2014-03-20 Thread Marc-André Lureau 
ack

- Original Message -
> 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 | 21 ++---
>  1 file changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/server/reds.c b/server/reds.c
> index fb2a19b..79a685b 100644
> --- a/server/reds.c
> +++ b/server/reds.c
> @@ -1325,6 +1325,22 @@ static void reds_channel_init_auth_caps(RedLinkInfo
> *link, RedChannel *channel)
>  red_channel_set_common_cap(channel,
>  SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION);
>  }
>  
> +
> +static const uint32_t *red_link_info_get_caps(const RedLinkInfo *link)
> +{
> +const uint8_t *caps_start = (const uint8_t *)link->link_mess;
> +
> +return (const uint32_t *)(caps_start + link->link_mess->caps_offset);
> +}
> +
> +static bool red_link_info_test_capability(const RedLinkInfo *link, uint32_t
> cap)
> +{
> +const uint32_t *caps = red_link_info_get_caps(link);
> +
> +return test_capability(caps, link->link_mess->num_common_caps, cap);
> +}
> +
> +
>  static int reds_send_link_ack(RedLinkInfo *link)
>  {
>  SpiceLinkHeader header;
> @@ -2038,7 +2054,6 @@ static void reds_handle_read_link_done(void *opaque)
>  RedLinkInfo *link = (RedLinkInfo *)opaque;
>  SpiceLinkMess *link_mess = link->link_mess;
>  uint32_t num_caps = link_mess->num_common_caps +
>  link_mess->num_channel_caps;
> -uint32_t *caps = (uint32_t *)((uint8_t *)link_mess +
> link_mess->caps_offset);
>  int auth_selection;
>  
>  if (num_caps && (num_caps * sizeof(uint32_t) + link_mess->caps_offset >
> @@ -2049,8 +2064,8 @@ static void reds_handle_read_link_done(void *opaque)
>  return;
>  }
>  
> -auth_selection = test_capability(caps, link_mess->num_common_caps,
> -
> SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION);
> +auth_selection = red_link_info_test_capability(link,
> +
> SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION);
>  
>  if (!reds_security_check(link)) {
>  if (reds_stream_is_ssl(link->stream)) {
> --
> 1.8.5.3
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice] Translate docbook -> asciidoc

2014-03-20 Thread Marc-André Lureau 
On Thu, Mar 20, 2014 at 3:28 PM, Christophe Fergeau wrote:

> It seems it does not create previous/next/up links, which is not really
> useful :(
>

a2x -f chunked manual.txt

works here

(see also the nice pdf output etc)


-- 
Marc-André Lureau
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice] Translate docbook -> asciidoc

2014-03-20 Thread Christophe Fergeau 
On Thu, Mar 20, 2014 at 01:50:31PM +0100, Marc-André Lureau wrote:
> On Thu, Mar 20, 2014 at 12:11 PM, Christophe Fergeau 
> wrote:
> 
> > Hey,
> >
> > On Wed, Mar 19, 2014 at 02:07:39PM +0100, Marc-André Lureau wrote:
> > > It's much much easier to read and edit
> >
> > Hmm, this changes things to one big txt file and one big html file.
> > The one source file per section approach plus one html file per
> > section versions were imo easier to handle, is it possible to have that
> > with asciidoc as well
> 
> 
> Yes, see:
> 
> http://www.methods.co.nz/asciidoc/userguide.html
> 36.6. Processing document sections separately

It seems it does not create previous/next/up links, which is not really
useful :(

Christophe


pgpCJK1F18yGF.pgp
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] virt-viewer for Windows is quite difficult to download

2014-03-20 Thread Jonathon Jongsma 
alternately, we could just change the link text to something else so the user 
doesn't think that the link will lead directly to an .msi file?



- Original Message -
> From: "Christophe Fergeau" 
> To: "Anthony Loiseau" 
> Cc: spice-devel@lists.freedesktop.org
> Sent: Thursday, March 20, 2014 8:52:07 AM
> Subject: Re: [Spice-devel] virt-viewer for Windows is quite difficult to 
> download
> 
> Hey,
> 
> On Thu, Mar 20, 2014 at 02:12:47PM +0100, Anthony Loiseau wrote:
> > Dear spice developpers and dear spice-space website maintainers,
> > 
> > For you to know, the link to download virt viewer windows installer (msi
> > file) is currently buggy.
> > 
> > Page : http://www.spice-space.org/download.html
> > extract : " virt-viewer Windows installer - 32 bit -
> > virt-viewer-x86.msi
> >  "
> > 
> > 
> > The link is coded as this, which force the user to download the HTML page
> > containing the final MSI download link.
> >  > href="http://virt-manager.org/download/";
> > download="">virt-viewer-x86.msi
> 
> Hmm why 'download'? Do you mean the user needs to access that page, and
> then click on the right link? If so, this is intentional so that we don't
> have to update the link on spice-space.org every time a new virt-viewer
> windows build is available.
> 
> Maybe the virt-viewer people would be ok with having a virt-viewer-x86.msi
> symlink which would point to the latest release, and we could link to that,
> dunno how convenient this would be for them.
> 
> Thanks for the feedback,
> 
> Christophe
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice] Translate docbook -> asciidoc

2014-03-20 Thread Jonathon Jongsma 
for what it's worth, I think asciidoc looks a bit easier to maintain, so I'm in 
favor of using it.  I don't really have an opinion on the other issues.



- Original Message -
> From: "Christophe Fergeau" 
> To: "Marc-André Lureau" 
> Cc: spice-devel@lists.freedesktop.org
> Sent: Thursday, March 20, 2014 8:32:33 AM
> Subject: Re: [Spice-devel] [PATCH spice] Translate docbook -> asciidoc
> 
> On Thu, Mar 20, 2014 at 09:06:51AM -0400, Marc-André Lureau wrote:
> > 
> > 
> > - Original Message -
> > > Hey,
> > > 
> > > On Wed, Mar 19, 2014 at 02:07:39PM +0100, Marc-André Lureau wrote:
> > > > It's much much easier to read and edit
> > > 
> > > Hmm, this changes things to one big txt file and one big html file.
> > > The one source file per section approach plus one html file per
> > > section versions were imo easier to handle, is it possible to have that
> > > with asciidoc as well?
> > 
> > Oh, I much prefer a single document, since it's easier to browse.
> > 
> > But you should be able to generate multi-page document with docbook
> > toolchain. But then, I would quite strongly discourage this. What's the
> > problem with single page?
> 
> Dunno, I'm more comfortable with smaller pages rather than single big one,
> matter of personal preference I guess. The link you gave seems to imply
> it's possible to generate both anyway ?
> 
> Christophe
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] virt-viewer for Windows is quite difficult to download

2014-03-20 Thread Christophe Fergeau 
Hey,

On Thu, Mar 20, 2014 at 02:12:47PM +0100, Anthony Loiseau wrote:
> Dear spice developpers and dear spice-space website maintainers,
> 
> For you to know, the link to download virt viewer windows installer (msi
> file) is currently buggy.
> 
> Page : http://www.spice-space.org/download.html
> extract : " virt-viewer Windows installer - 32 bit -
> virt-viewer-x86.msi
>  "
> 
> 
> The link is coded as this, which force the user to download the HTML page
> containing the final MSI download link.
> http://virt-manager.org/download/";
> download="">virt-viewer-x86.msi

Hmm why 'download'? Do you mean the user needs to access that page, and
then click on the right link? If so, this is intentional so that we don't
have to update the link on spice-space.org every time a new virt-viewer
windows build is available.

Maybe the virt-viewer people would be ok with having a virt-viewer-x86.msi
symlink which would point to the latest release, and we could link to that,
dunno how convenient this would be for them.

Thanks for the feedback,

Christophe


pgp5xqLoaCJYP.pgp
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice] Translate docbook -> asciidoc

2014-03-20 Thread Christophe Fergeau 
On Thu, Mar 20, 2014 at 09:06:51AM -0400, Marc-André Lureau wrote:
> 
> 
> - Original Message -
> > Hey,
> > 
> > On Wed, Mar 19, 2014 at 02:07:39PM +0100, Marc-André Lureau wrote:
> > > It's much much easier to read and edit
> > 
> > Hmm, this changes things to one big txt file and one big html file.
> > The one source file per section approach plus one html file per
> > section versions were imo easier to handle, is it possible to have that
> > with asciidoc as well?
> 
> Oh, I much prefer a single document, since it's easier to browse.
> 
> But you should be able to generate multi-page document with docbook
> toolchain. But then, I would quite strongly discourage this. What's the
> problem with single page?

Dunno, I'm more comfortable with smaller pages rather than single big one,
matter of personal preference I guess. The link you gave seems to imply
it's possible to generate both anyway ?

Christophe


pgptUq3UJz7wY.pgp
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] virt-viewer for Windows is quite difficult to download

2014-03-20 Thread Anthony Loiseau 
Dear spice developpers and dear spice-space website maintainers,

For you to know, the link to download virt viewer windows installer (msi
file) is currently buggy.

Page : http://www.spice-space.org/download.html
extract : " virt-viewer Windows installer - 32 bit -
virt-viewer-x86.msi
 "


The link is coded as this, which force the user to download the HTML page
containing the final MSI download link.
http://virt-manager.org/download/";
download="">virt-viewer-x86.msi


Best regards.
Anthony.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice] Translate docbook -> asciidoc

2014-03-20 Thread Marc-André Lureau 


- Original Message -
> Hey,
> 
> On Wed, Mar 19, 2014 at 02:07:39PM +0100, Marc-André Lureau wrote:
> > It's much much easier to read and edit
> 
> Hmm, this changes things to one big txt file and one big html file.
> The one source file per section approach plus one html file per
> section versions were imo easier to handle, is it possible to have that
> with asciidoc as well?

Oh, I much prefer a single document, since it's easier to browse.

But you should be able to generate multi-page document with docbook toolchain. 
But then, I would quite strongly discourage this. What's the problem with 
single page? There are also other html5 output with toc always visible in a 
sidebar, eventually.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH 1/3] Add const to test_capability first argument

2014-03-20 Thread Marc-André Lureau 
trivial, ack

- Original Message -
> We don't modify the capabilities content, so it can be marked as const.
> ---
>  server/red_channel.c | 2 +-
>  server/red_channel.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/server/red_channel.c b/server/red_channel.c
> index 4f85365..617a0df 100644
> --- a/server/red_channel.c
> +++ b/server/red_channel.c
> @@ -1172,7 +1172,7 @@ void red_channel_register_client_cbs(RedChannel
> *channel, ClientCbs *client_cbs)
>  }
>  }
>  
> -int test_capability(uint32_t *caps, int num_caps, uint32_t cap)
> +int test_capability(const uint32_t *caps, int num_caps, uint32_t cap)
>  {
>  uint32_t index = cap / 32;
>  if (num_caps < index + 1) {
> diff --git a/server/red_channel.h b/server/red_channel.h
> index f9cfb95..24d29fe 100644
> --- a/server/red_channel.h
> +++ b/server/red_channel.h
> @@ -223,7 +223,7 @@ typedef struct RedChannelCapabilities {
>  uint32_t *caps;
>  } RedChannelCapabilities;
>  
> -int test_capability(uint32_t *caps, int num_caps, uint32_t cap);
> +int test_capability(const uint32_t *caps, int num_caps, uint32_t cap);
>  
>  typedef struct RedChannelClientLatencyMonitor {
>  int state;
> --
> 1.8.5.3
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [spice-gtk] Advertise SASL cap from client

2014-03-20 Thread Marc-André Lureau 


- Original Message -
> A client setting this capability indicates to the server that it's able
> to handle SASL authentication, and it also indicates that if SASL is
> to be used for authentication, then it won't expect a valid 'pub_key' field
> in SpiceLinkReply.

sounds good to me.
ack

> The reason for making guarantees about not looking at the pub_key field is
> that its presence and size is hardcoded in the protocol, but in some
> hardened setups (using fips mode), generating a RSA 1024 bit key as
> expected is forbidden and fails. With this new capability, the server
> knows the client will be able to handle SASL if needed, and can skip
> the generation of the key altogether. This means that on the setups
> described above, SASL authentication has to be used.

> ---
>  gtk/spice-channel.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/gtk/spice-channel.c b/gtk/spice-channel.c
> index 83c7006..1498162 100644
> --- a/gtk/spice-channel.c
> +++ b/gtk/spice-channel.c
> @@ -114,6 +114,9 @@ static void spice_channel_init(SpiceChannel *channel)
>  c->remote_common_caps = g_array_new(FALSE, TRUE, sizeof(guint32));
>  spice_channel_set_common_capability(channel,
>  SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION);
>  spice_channel_set_common_capability(channel,
>  SPICE_COMMON_CAP_MINI_HEADER);
> +#if HAVE_SASL
> +spice_channel_set_common_capability(channel,
> SPICE_COMMON_CAP_AUTH_SASL);
> +#endif
>  g_queue_init(&c->xmit_queue);
>  STATIC_MUTEX_INIT(c->xmit_queue_lock);
>  }
> --
> 1.8.5.3
> 
> ___
> Spice-devel mailing list
> Spice-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
> 
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice] Translate docbook -> asciidoc

2014-03-20 Thread Marc-André Lureau 
On Thu, Mar 20, 2014 at 12:11 PM, Christophe Fergeau wrote:

> Hey,
>
> On Wed, Mar 19, 2014 at 02:07:39PM +0100, Marc-André Lureau wrote:
> > It's much much easier to read and edit
>
> Hmm, this changes things to one big txt file and one big html file.
> The one source file per section approach plus one html file per
> section versions were imo easier to handle, is it possible to have that
> with asciidoc as well


Yes, see:

http://www.methods.co.nz/asciidoc/userguide.html
36.6. Processing document sections separately



-- 
Marc-André Lureau
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH 1/3] Add const to test_capability first argument

2014-03-20 Thread Christophe Fergeau 
We don't modify the capabilities content, so it can be marked as const.
---
 server/red_channel.c | 2 +-
 server/red_channel.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/server/red_channel.c b/server/red_channel.c
index 4f85365..617a0df 100644
--- a/server/red_channel.c
+++ b/server/red_channel.c
@@ -1172,7 +1172,7 @@ void red_channel_register_client_cbs(RedChannel *channel, 
ClientCbs *client_cbs)
 }
 }
 
-int test_capability(uint32_t *caps, int num_caps, uint32_t cap)
+int test_capability(const uint32_t *caps, int num_caps, uint32_t cap)
 {
 uint32_t index = cap / 32;
 if (num_caps < index + 1) {
diff --git a/server/red_channel.h b/server/red_channel.h
index f9cfb95..24d29fe 100644
--- a/server/red_channel.h
+++ b/server/red_channel.h
@@ -223,7 +223,7 @@ typedef struct RedChannelCapabilities {
 uint32_t *caps;
 } RedChannelCapabilities;
 
-int test_capability(uint32_t *caps, int num_caps, uint32_t cap);
+int test_capability(const uint32_t *caps, int num_caps, uint32_t cap);
 
 typedef struct RedChannelClientLatencyMonitor {
 int state;
-- 
1.8.5.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [spice-gtk] Advertise SASL cap from client

2014-03-20 Thread Christophe Fergeau 
A client setting this capability indicates to the server that it's able
to handle SASL authentication, and it also indicates that if SASL is
to be used for authentication, then it won't expect a valid 'pub_key' field
in SpiceLinkReply.

The reason for making guarantees about not looking at the pub_key field is
that its presence and size is hardcoded in the protocol, but in some
hardened setups (using fips mode), generating a RSA 1024 bit key as
expected is forbidden and fails. With this new capability, the server
knows the client will be able to handle SASL if needed, and can skip
the generation of the key altogether. This means that on the setups
described above, SASL authentication has to be used.
---
 gtk/spice-channel.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gtk/spice-channel.c b/gtk/spice-channel.c
index 83c7006..1498162 100644
--- a/gtk/spice-channel.c
+++ b/gtk/spice-channel.c
@@ -114,6 +114,9 @@ static void spice_channel_init(SpiceChannel *channel)
 c->remote_common_caps = g_array_new(FALSE, TRUE, sizeof(guint32));
 spice_channel_set_common_capability(channel, 
SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION);
 spice_channel_set_common_capability(channel, SPICE_COMMON_CAP_MINI_HEADER);
+#if HAVE_SASL
+spice_channel_set_common_capability(channel, SPICE_COMMON_CAP_AUTH_SASL);
+#endif
 g_queue_init(&c->xmit_queue);
 STATIC_MUTEX_INIT(c->xmit_queue_lock);
 }
-- 
1.8.5.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice] Translate docbook -> asciidoc

2014-03-20 Thread Christophe Fergeau 
Hey,

On Wed, Mar 19, 2014 at 02:07:39PM +0100, Marc-André Lureau wrote:
> It's much much easier to read and edit

Hmm, this changes things to one big txt file and one big html file.
The one source file per section approach plus one html file per
section versions were imo easier to handle, is it possible to have that
with asciidoc as well?

Christophe



pgpxObruLrhqd.pgp
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH 8/9] Ask for unencrypted tickets if client supports it

2014-03-20 Thread Christophe Fergeau 
Hey,

On Wed, Mar 12, 2014 at 06:45:37PM +, Dietmar Maurer wrote:
> >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 does not expose the required capability.
> 
> Wouldn't it make more sense to add PLAIN username/password AUTH instead.

This comment, and Marc-André concerns about some backward-compatibility
bits made me realize it would be much easier and less invasive to add a way
for the client to advertise it can use SASL, and to make guarantees it
won't try to use the RSA key when it uses SASL.

Christophe


pgpsvyA_CKC8C.pgp
Description: PGP signature
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH 3/3] Don't set SpiceLinkReply::pub_key if client advertises SASL cap

2014-03-20 Thread Christophe Fergeau 
If the client advertises the SASL cap, it means it guarantees it will be
able to use SASL if the server supports, and that it does not need a valid
SpiceLinkReply::pub_key field when using SASL.

When the client cap is set, we thus don't need to create a RSA public key
if SASL is enabled server side.

The reason for needing client guarantees about not looking at the pub_key
field is that its presence and size is hardcoded in the protocol, but in
some hardened setups (using fips mode), generating a RSA 1024 bit key as
expected is forbidden and fails. With this new capability, the server
knows the client will be able to handle SASL if needed, and can skip
the generation of the key altogether. This means that on the setups
described above, SASL authentication has to be used.
---
 server/reds.c | 49 -
 1 file changed, 32 insertions(+), 17 deletions(-)

diff --git a/server/reds.c b/server/reds.c
index 79a685b..e05d913 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -1348,7 +1348,7 @@ static int reds_send_link_ack(RedLinkInfo *link)
 RedChannel *channel;
 RedChannelCapabilities *channel_caps;
 BUF_MEM *bmBuf;
-BIO *bio;
+BIO *bio = NULL;
 int ret = FALSE;
 
 header.magic = SPICE_MAGIC;
@@ -1372,24 +1372,38 @@ static int reds_send_link_ack(RedLinkInfo *link)
 ack.num_channel_caps = channel_caps->num_caps;
 header.size += (ack.num_common_caps + ack.num_channel_caps) * 
sizeof(uint32_t);
 ack.caps_offset = sizeof(SpiceLinkReply);
+if (!sasl_enabled
+|| !red_link_info_test_capability(link, SPICE_COMMON_CAP_AUTH_SASL)) {
+if (!(link->tiTicketing.rsa = RSA_new())) {
+spice_warning("RSA new failed");
+return FALSE;
+}
 
-if (!(link->tiTicketing.rsa = RSA_new())) {
-spice_warning("RSA new failed");
-return FALSE;
-}
-
-if (!(bio = BIO_new(BIO_s_mem( {
-spice_warning("BIO new failed");
-return FALSE;
-}
+if (!(bio = BIO_new(BIO_s_mem( {
+spice_warning("BIO new failed");
+return FALSE;
+}
 
-RSA_generate_key_ex(link->tiTicketing.rsa, SPICE_TICKET_KEY_PAIR_LENGTH, 
link->tiTicketing.bn,
-NULL);
-link->tiTicketing.rsa_size = RSA_size(link->tiTicketing.rsa);
+RSA_generate_key_ex(link->tiTicketing.rsa, 
SPICE_TICKET_KEY_PAIR_LENGTH, link->tiTicketing.bn,
+NULL);
+link->tiTicketing.rsa_size = RSA_size(link->tiTicketing.rsa);
 
-i2d_RSA_PUBKEY_bio(bio, link->tiTicketing.rsa);
-BIO_get_mem_ptr(bio, &bmBuf);
-memcpy(ack.pub_key, bmBuf->data, sizeof(ack.pub_key));
+i2d_RSA_PUBKEY_bio(bio, link->tiTicketing.rsa);
+BIO_get_mem_ptr(bio, &bmBuf);
+memcpy(ack.pub_key, bmBuf->data, sizeof(ack.pub_key));
+} else {
+/* if the client sets the AUTH_SASL cap, it indicates that it
+ * supports SASL, and will use it if the server supports SASL as
+ * well. Moreover, a client setting the AUTH_SASL cap also
+ * indicates that it will not try using the RSA-related content
+ * in the SpiceLinkReply message, so we don't need to initialize
+ * it. Reason to avoid this is to fix auth in fips mode where
+ * the generation of a 1024 bit RSA key as we are trying to do
+ * will fail.
+ */
+spice_warning("not initialising RSA key");
+memset(ack.pub_key, '\0', sizeof(ack.pub_key));
+}
 
 if (!reds_stream_write_all(link->stream, &header, sizeof(header)))
 goto end;
@@ -1403,7 +1417,8 @@ static int reds_send_link_ack(RedLinkInfo *link)
 ret = TRUE;
 
 end:
-BIO_free(bio);
+if (bio != NULL)
+BIO_free(bio);
 return ret;
 }
 
-- 
1.8.5.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

Re: [Spice-devel] [PATCH spice-gtk 1/2] Add webdav channel

2014-03-20 Thread Alon Levy 
On 03/19/2014 07:33 PM, Marc-André Lureau wrote:
> Hi
> 
> On Mon, Mar 17, 2014 at 8:54 AM, Alon Levy  wrote:
> 
>> Would be nice to use an actual constant for this instead of relying on
>> G_MAXUINT16 here and above.
>>
> 
> 
> Sorry, I forgot to address your comments.
> 
> What about MAX_MUX_SIZE?

ACK.

> 
> Rest of the diff would be:
> 
> diff --git a/gtk/channel-webdav.c b/gtk/channel-webdav.c
> index ffd617e..2cc242b 100644
> --- a/gtk/channel-webdav.c
> +++ b/gtk/channel-webdav.c
> @@ -79,7 +79,7 @@ typedef struct _OutputQueueElem {
>  OutputQueue *queue;
>  const guint8 *buf;
>  gsize size;
> -GFunc cb;
> +GFunc pushed_cb;
>  gpointer user_data;
>  } OutputQueueElem;
> 
> @@ -97,7 +97,6 @@ static void output_queue_free(OutputQueue *queue)
>  {
>  g_warn_if_fail(g_queue_get_length(queue->queue) == 0);
>  g_warn_if_fail(!queue->flushing);
> -g_warn_if_fail(!queue->idle_id);
> 
>  g_queue_free_full(queue->queue, g_free);
>  g_clear_object(&queue->output);
> @@ -150,8 +149,8 @@ static gboolean output_queue_idle(gpointer user_data)
>  g_output_stream_write_all(q->output, e->buf, e->size, NULL, NULL,
> &error);
>  if (error)
>  goto err;
> -else if (e->cb)
> -e->cb(q, e->user_data);
> +else if (e->pushed_cb)
> +e->pushed_cb(q, e->user_data);
> 
>  q->flushing = TRUE;
>  g_output_stream_flush_async(q->output, G_PRIORITY_DEFAULT, NULL,
> output_queue_flush_cb, e);
> @@ -173,7 +172,7 @@ static void output_queue_push(OutputQueue *q, const
> guint8 *buf, gsize size,
> 
>  e->buf = buf;
>  e->size = size;
> -e->cb = pushed_cb;
> +e->pushed_cb = pushed_cb;
>  e->user_data = user_data;
>  e->queue = q;
>  g_queue_push_tail(q->queue, e);
> @@ -248,6 +247,8 @@ static void mux_pushed_cb(OutputQueue *q, gpointer
> user_data)
>  client_unref(client);
> 
> 

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCHv2 0/3] Fix use of SPICE in fips mode

2014-03-20 Thread Christophe Fergeau 
In FIPS mode, the 1024 bit RSA key which is hardcoded in the protocol through
SpiceLinkReply::pub_key cannot be created, causing any connection attempt to 
fail
as it's unconditionnally generated.

However, when using SASL, we don't need that key. Unfortunately, we don't have
way of knowing if the client can use SASL or not before the key is generated
and sent. In this series, we introduce the use of a client-side
SPICE_COMMON_CAP_AUTH_SASL, which indicates that the client will be able to
use SASL authentication if needed, and that it does not need
SpiceLinkReply::pub_key to be set in this case.

This replaces my previous attempt which was much more invasive, and
not much better than this approach. This approach has the drawback that
fips mode has to use SASL auth as the 1024 bit RSA keys are disabled in
such setups.

Christophe






___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel

[Spice-devel] [PATCH 2/3] Introduce red_link_info_test_capability()

2014-03-20 Thread Christophe Fergeau 
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 | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/server/reds.c b/server/reds.c
index fb2a19b..79a685b 100644
--- a/server/reds.c
+++ b/server/reds.c
@@ -1325,6 +1325,22 @@ static void reds_channel_init_auth_caps(RedLinkInfo 
*link, RedChannel *channel)
 red_channel_set_common_cap(channel, 
SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION);
 }
 
+
+static const uint32_t *red_link_info_get_caps(const RedLinkInfo *link)
+{
+const uint8_t *caps_start = (const uint8_t *)link->link_mess;
+
+return (const uint32_t *)(caps_start + link->link_mess->caps_offset);
+}
+
+static bool red_link_info_test_capability(const RedLinkInfo *link, uint32_t 
cap)
+{
+const uint32_t *caps = red_link_info_get_caps(link);
+
+return test_capability(caps, link->link_mess->num_common_caps, cap);
+}
+
+
 static int reds_send_link_ack(RedLinkInfo *link)
 {
 SpiceLinkHeader header;
@@ -2038,7 +2054,6 @@ static void reds_handle_read_link_done(void *opaque)
 RedLinkInfo *link = (RedLinkInfo *)opaque;
 SpiceLinkMess *link_mess = link->link_mess;
 uint32_t num_caps = link_mess->num_common_caps + 
link_mess->num_channel_caps;
-uint32_t *caps = (uint32_t *)((uint8_t *)link_mess + 
link_mess->caps_offset);
 int auth_selection;
 
 if (num_caps && (num_caps * sizeof(uint32_t) + link_mess->caps_offset >
@@ -2049,8 +2064,8 @@ static void reds_handle_read_link_done(void *opaque)
 return;
 }
 
-auth_selection = test_capability(caps, link_mess->num_common_caps,
- SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION);
+auth_selection = red_link_info_test_capability(link,
+   
SPICE_COMMON_CAP_PROTOCOL_AUTH_SELECTION);
 
 if (!reds_security_check(link)) {
 if (reds_stream_is_ssl(link->stream)) {
-- 
1.8.5.3

___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel