| Message ID | 1314274278-19582-1-git-send-email-stefanha@linux.vnet.ibm.com |
|---|---|
| State | New |
| Headers | show |
On 25 August 2011 13:11, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> wrote: > From: Raghavendra D Prabhu <raghu.prabhu13@gmail.com> > > The gnutls_*_set_priority family of functions has been marked deprecated > in 2.12.x. These functions have been superceded by > gnutls_priority_set_direct(). Does this constitute a change in the required version of gnutls which we need to document in the proto-changelog for the next release? Is it worth updating the configure tls check to check for this function so we fall back to no-tls if the system version is too old? -- PMM
On Thu, Aug 25, 2011 at 01:27:00PM +0100, Peter Maydell wrote: > On 25 August 2011 13:11, Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> wrote: > > From: Raghavendra D Prabhu <raghu.prabhu13@gmail.com> > > > > The gnutls_*_set_priority family of functions has been marked deprecated > > in 2.12.x. These functions have been superceded by > > gnutls_priority_set_direct(). > > Does this constitute a change in the required version of gnutls which > we need to document in the proto-changelog for the next release? > Is it worth updating the configure tls check to check for this function > so we fall back to no-tls if the system version is too old? The gnutls_priority_set_direct() function has existed since 2.1.7 according to the GNUTLS NEWS files. Our configure check merely looks for 'gnutls.h' which will match any gnutls 1.x or 2.x release, and I can currently build qemu with TLS support on a RHEL-5 host which has gnutls 1.4.1 So I believe this change will significantly increase our min required gnutls version. We could #ifdef the code to deal with this, or perhaps do a patch based on use of gnutls_set_default_priority() which I believe is available in both 1.x and 2.x and is not deprecated Regards, Daniel
On 25 August 2011 14:13, Daniel P. Berrange <berrange@redhat.com> wrote: > On Thu, Aug 25, 2011 at 01:27:00PM +0100, Peter Maydell wrote: >> Does this constitute a change in the required version of gnutls which >> we need to document in the proto-changelog for the next release? >> Is it worth updating the configure tls check to check for this function >> so we fall back to no-tls if the system version is too old? > > The gnutls_priority_set_direct() function has existed since 2.1.7 according > to the GNUTLS NEWS files. > > Our configure check merely looks for 'gnutls.h' which will match any > gnutls 1.x or 2.x release, and I can currently build qemu with TLS > support on a RHEL-5 host which has gnutls 1.4.1 > > So I believe this change will significantly increase our min required > gnutls version. We could #ifdef the code to deal with this, or perhaps > do a patch based on use of gnutls_set_default_priority() which I > believe is available in both 1.x and 2.x and is not deprecated Thanks for chasing down the version numbers. I definitely don't think we should stop being able to compile on RHEL5 so I think we should take one of the other approaches you suggest rather than committing this patch. -- PMM
On Fri, Aug 26, 2011 at 11:24 AM, Peter Maydell <peter.maydell@linaro.org> wrote: > On 25 August 2011 14:13, Daniel P. Berrange <berrange@redhat.com> wrote: >> On Thu, Aug 25, 2011 at 01:27:00PM +0100, Peter Maydell wrote: >>> Does this constitute a change in the required version of gnutls which >>> we need to document in the proto-changelog for the next release? >>> Is it worth updating the configure tls check to check for this function >>> so we fall back to no-tls if the system version is too old? >> >> The gnutls_priority_set_direct() function has existed since 2.1.7 according >> to the GNUTLS NEWS files. >> >> Our configure check merely looks for 'gnutls.h' which will match any >> gnutls 1.x or 2.x release, and I can currently build qemu with TLS >> support on a RHEL-5 host which has gnutls 1.4.1 >> >> So I believe this change will significantly increase our min required >> gnutls version. We could #ifdef the code to deal with this, or perhaps >> do a patch based on use of gnutls_set_default_priority() which I >> believe is available in both 1.x and 2.x and is not deprecated > > Thanks for chasing down the version numbers. I definitely don't > think we should stop being able to compile on RHEL5 so I think > we should take one of the other approaches you suggest rather than > committing this patch. Agreed. The gnutls_set_default_priority() idea sounds promising. Stefan
diff --git a/ui/vnc-tls.c b/ui/vnc-tls.c index 2e2456e..48c818a 100644 --- a/ui/vnc-tls.c +++ b/ui/vnc-tls.c @@ -286,10 +286,6 @@ int vnc_tls_validate_certificate(struct VncState *vs) int vnc_tls_client_setup(struct VncState *vs, int needX509Creds) { - static const int cert_type_priority[] = { GNUTLS_CRT_X509, 0 }; - static const int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0, GNUTLS_SSL3, 0 }; - static const int kx_anon[] = {GNUTLS_KX_ANON_DH, 0}; - static const int kx_x509[] = {GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA, GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0}; VNC_DEBUG("Do TLS setup\n"); if (vnc_tls_initialize() < 0) { @@ -310,21 +306,7 @@ int vnc_tls_client_setup(struct VncState *vs, return -1; } - if (gnutls_kx_set_priority(vs->tls.session, needX509Creds ? kx_x509 : kx_anon) < 0) { - gnutls_deinit(vs->tls.session); - vs->tls.session = NULL; - vnc_client_error(vs); - return -1; - } - - if (gnutls_certificate_type_set_priority(vs->tls.session, cert_type_priority) < 0) { - gnutls_deinit(vs->tls.session); - vs->tls.session = NULL; - vnc_client_error(vs); - return -1; - } - - if (gnutls_protocol_set_priority(vs->tls.session, protocol_priority) < 0) { + if (gnutls_priority_set_direct(vs->tls.session, needX509Creds ? "NORMAL" : "NORMAL:+ANON-DH", NULL) < 0) { gnutls_deinit(vs->tls.session); vs->tls.session = NULL; vnc_client_error(vs);