On Mon, 2014-07-14 at 21:12 +0200, Daniel Stenberg wrote:
> >> This is rather unfortunate. I'll improve the error message as you suggest,
> >> but I wonder what the best way is to determine whether SRP is supported or
> >> not. Is there a compile-time check that can be used, or will it have to be
On Mon, Jul 14, 2014 at 09:12:41PM +0200, Daniel Stenberg wrote:
> On Sun, 13 Jul 2014, David Woodhouse wrote:
>
> >>This is rather unfortunate. I'll improve the error message as you
> >>suggest, but I wonder what the best way is to determine whether
> >>SRP is supported or not. Is there a compile
On Sun, 13 Jul 2014, David Woodhouse wrote:
This is rather unfortunate. I'll improve the error message as you suggest,
but I wonder what the best way is to determine whether SRP is supported or
not. Is there a compile-time check that can be used, or will it have to be
done through some kind of
On Sun, Jul 13, 2014 at 07:14:33AM +0100, David Woodhouse wrote:
> On Sun, 2014-07-13 at 01:09 +0200, Dan Fandrich wrote:
> > On Sat, Jul 12, 2014 at 05:59:56PM +0100, David Woodhouse wrote:
> > > The cipher list problem was because Fedora's GnuTLS doesn't have SRP
> > > support. Given that gnutls_
On Sat, 12 Jul 2014, David Woodhouse wrote:
Before GnuTLS 3.3.6, the gnutls_x509_crt_check_hostname() function didn't
actually check IP addresses in SubjectAltName, even though it was explicitly
documented as doing so. So do it ourselves...
Ugh. Thanks for this patch!
I only have one little
On Sun, 2014-07-13 at 01:09 +0200, Dan Fandrich wrote:
> On Sat, Jul 12, 2014 at 05:59:56PM +0100, David Woodhouse wrote:
> > The cipher list problem was because Fedora's GnuTLS doesn't have SRP
> > support. Given that gnutls_set_priority_direct() actually *gives* us a
> > pointer to the part of th
On Sat, Jul 12, 2014 at 05:59:56PM +0100, David Woodhouse wrote:
> The cipher list problem was because Fedora's GnuTLS doesn't have SRP
> support. Given that gnutls_set_priority_direct() actually *gives* us a
> pointer to the part of the string that it objected to, our error
> handling could stand