Daniel Stenberg | 1 Nov 09:56 2005
Picon

Re: 1.2.9 release candidate

On Fri, 28 Oct 2005, Simon Josefsson wrote:

> NEWS entries below.  Suggestions on the text is also appreciated.

A minor mistake appears in the man page 
doc/manpages/gnutls_certificate_set_verify_flags.3:

When describing the 'flags' argument iy says:

   .IP "unsigned int flags" 12
   are the flagsis a structure that holds diffie hellman parameters.

Which is just confusing! ;-) (this is of course also visible in the HTML 
version etc)

--

-- 
          -=- Daniel Stenberg -=- http://daniel.haxx.se -=-
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Daniel Stenberg | 1 Nov 10:01 2005
Picon

Re: 1.2.9 release candidate

On Fri, 28 Oct 2005, Simon Josefsson wrote:

> GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2,
> GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5: New gnutls_certificate_verify_flags values.

Any ideas on how we can know at compile-time if these are present or not? Them 
being enum values make it rather tricky since we can't simply do:

#ifdef GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2
flags | = GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2;
#endif

or similar. Of course I can make a configure-check for them, but it would be 
nice with some simple preprocessor magic...

--

-- 
          -=- Daniel Stenberg -=- http://daniel.haxx.se -=-
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Daniel Stenberg | 1 Nov 10:38 2005
Picon

Re: 1.2.9 release candidate

On Tue, 1 Nov 2005, Simon Josefsson wrote:

>> Of course I can make a configure-check for them, but it would be nice with 
>> some simple preprocessor magic...
>
> I think a configure check is the simplest solution available.  If you don't 
> want to pollute your source code with #ifdef's, you could have configure 
> define those two symbols to 0 if they aren't defined by gnutls.h.

Of course. But my argument was not so much of concern of how the #ifdefs will 
look in my code (libcurl being massively portable we have #ifdefs all over 
already), it is how my code figures out what the installed GnuTLS supports or 
not. (Or in this case, what the headers contain or not.)

In OpenSSL land, I've almost always been able to avoid checking for version- 
specific features in configure by using preprocessor magic such as checking 
for specific version numbers etc. Like this:

#if OPENSSL_VERSION_NUMBER >= 0x0090581fL
#define HAVE_SSL_GET1_SESSION 1
#else
#undef HAVE_SSL_GET1_SESSION
#endif

> I usually want to make the core code look good for the latest-and-greatest 
> features, and work around missing functionality in earlier releases through 
> some replacement stuff in configure.

Well, you could easily just add a simple define in the header file next to the 
enums that we could #ifdef with to figure this out.
(Continue reading)

Simon Josefsson | 1 Nov 10:27 2005

Re: 1.2.9 release candidate

Daniel Stenberg <daniel <at> haxx.se> writes:

> On Fri, 28 Oct 2005, Simon Josefsson wrote:
>
>> GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2,
>> GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5: New gnutls_certificate_verify_flags values.
>
> Any ideas on how we can know at compile-time if these are present or
> not? Them being enum values make it rather tricky since we can't
> simply do:
>
> #ifdef GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2
> flags | = GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2;
> #endif
>
> or similar. Of course I can make a configure-check for them, but it
> would be nice with some simple preprocessor magic...

I think a configure check is the simplest solution available.  If you
don't want to pollute your source code with #ifdef's, you could have
configure define those two symbols to 0 if they aren't defined by
gnutls.h.  I usually want to make the core code look good for the
latest-and-greatest features, and work around missing functionality in
earlier releases through some replacement stuff in configure.

Thanks,
Simon
Simon Josefsson | 1 Nov 11:26 2005

Re: 1.2.9 release candidate

Daniel Stenberg <daniel <at> haxx.se> writes:

> On Tue, 1 Nov 2005, Simon Josefsson wrote:
>
>>> Of course I can make a configure-check for them, but it would be
>>> nice with some simple preprocessor magic...
>>
>> I think a configure check is the simplest solution available.  If
>> you don't want to pollute your source code with #ifdef's, you could
>> have configure define those two symbols to 0 if they aren't defined
>> by gnutls.h.
>
> Of course. But my argument was not so much of concern of how the
> #ifdefs will look in my code (libcurl being massively portable we have
> #ifdefs all over already), it is how my code figures out what the
> installed GnuTLS supports or not. (Or in this case, what the headers
> contain or not.)

Ok.

> In OpenSSL land, I've almost always been able to avoid checking for
> version- 
> specific features in configure by using preprocessor magic such as
> checking for specific version numbers etc. Like this:
>
> #if OPENSSL_VERSION_NUMBER >= 0x0090581fL
> #define HAVE_SSL_GET1_SESSION 1
> #else
> #undef HAVE_SSL_GET1_SESSION
> #endif
(Continue reading)

Simon Josefsson | 1 Nov 10:18 2005

Re: 1.2.9 release candidate

Daniel Stenberg <daniel <at> haxx.se> writes:

> On Fri, 28 Oct 2005, Simon Josefsson wrote:
>
>> NEWS entries below.  Suggestions on the text is also appreciated.
>
> A minor mistake appears in the man page
> doc/manpages/gnutls_certificate_set_verify_flags.3:
>
> When describing the 'flags' argument iy says:
>
>   .IP "unsigned int flags" 12
>   are the flagsis a structure that holds diffie hellman parameters.
>
> Which is just confusing! ;-) (this is of course also visible in the
> HTML version etc)

Oops!  It should have been only "are the flags".  Fixed in CVS.

Thanks,
Simon
Nikos Mavrogiannopoulos | 1 Nov 11:56 2005

Re: 1.2.9 release candidate

On Tuesday 01 November 2005 10:01, Daniel Stenberg wrote:

> #ifdef GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2
> flags | = GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2;
> #endif

No you don't want to add this line. It is not needed to verify the certificate 
in question (the one sent some days ago) since it was self signed with MD2, 
and it is very dangerous to enable MD2 for any algorithm. If you insist into 
adding it make it configurable by the user.

--

-- 
Nikos Mavrogiannopoulos
Daniel Stenberg | 1 Nov 12:07 2005
Picon

Re: 1.2.9 release candidate

On Tue, 1 Nov 2005, Simon Josefsson wrote:

> My experience has been that it is more reliable to test for features rather 
> than version numbers, even if it takes a few more line of codes to do so.

Then we have different views on this.

(The preprocessor check also works on _all_ platforms, and thus isn't limited 
to those which can run configure. Possibly this is a moot point in this case, 
as possibly GnuTLS doesn't build in such environments?)

> #define GNUTLS_CERTIFICATE_VERIFY_FLAGS_LAST 32

> Does this solve your concern?  Did you have a better solution in mind?

That solves it and is perfect. Thanks!

> If you don't want to add specific feature checks, you could always require 
> the earliest version of the GnuTLS library that you know support everything 
> you need, e.g.:
>
> 	AM_PATH_LIBGNUTLS(1.2.9, starttls=yes, starttls=no)

In my experience, the majority of all users will continue using out-dated 
versions (very often they simply remain with the version that comes with their 
Linux distro). Setting up strict requirements on "3rd party libraries" will 
only cause me grief.

--

-- 
          -=- Daniel Stenberg -=- http://daniel.haxx.se -=-
(Continue reading)

Simon Josefsson | 1 Nov 12:17 2005

Re: 1.2.9 release candidate

Daniel Stenberg <daniel <at> haxx.se> writes:

> (The preprocessor check also works on _all_ platforms, and thus isn't
> limited to those which can run configure. Possibly this is a moot
> point in this case, as possibly GnuTLS doesn't build in such
> environments?)

In theory, it should be possible to build autoconf-based programs even
if you can't run configure or make.  Copy config.h.in to config.h,
manually edit system specific matters, and invoke the compiler and
linker manually.  It is sometimes easier to make autoconf/make work on
the system, though...

>> #define GNUTLS_CERTIFICATE_VERIFY_FLAGS_LAST 32
>
>> Does this solve your concern?  Did you have a better solution in mind?
>
> That solves it and is perfect. Thanks!

We discussed this some more, and we'll likely add an OpenSSL-like
version number integer.  If that works, I'll remove this symbol, since
the version number integer is more generic.  And it would be less
maintenance work for us.

>> If you don't want to add specific feature checks, you could always
>> require the earliest version of the GnuTLS library that you know
>> support everything you need, e.g.:
>>
>> 	AM_PATH_LIBGNUTLS(1.2.9, starttls=yes, starttls=no)
>
(Continue reading)

Daniel Stenberg | 1 Nov 12:22 2005
Picon

Re: 1.2.9 release candidate

On Tue, 1 Nov 2005, Simon Josefsson wrote:

> We discussed this some more, and we'll likely add an OpenSSL-like version 
> number integer.  If that works, I'll remove this symbol, since the version 
> number integer is more generic.  And it would be less maintenance work for 
> us.

FYI:

We've done it for many years in libcurl as well, and many users are 
successfully using version number checks in source code based on those 
defines.

This is how we do it:

http://cool.haxx.se/cvs.cgi/curl/include/curl/curlver.h?rev=HEAD&content-type=text/vnd.viewcvs-markup

--

-- 
          -=- Daniel Stenberg -=- http://daniel.haxx.se -=-
   ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol

Gmane