From simon at josefsson.org  Thu Oct  1 13:51:09 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 01 Oct 2009 13:51:09 +0200
Subject: TLS 1.2 server
In-Reply-To: <87ljjwdv8c.fsf@broken.deisui.org> (Daiki Ueno's message of "Thu, 
	01 Oct 2009 05:37:55 +0900")
References: <87iqf1p592.fsf@broken.deisui.org>
	<87r5tp56c4.fsf@mocca.josefsson.org>
	<87ske44pfy.fsf@mocca.josefsson.org>
	<87pr98eha4.fsf@broken.deisui.org>
	<87eipo4jgc.fsf@mocca.josefsson.org>
	<87ljjwdv8c.fsf@broken.deisui.org>
Message-ID: <87zl8buyc2.fsf@mocca.josefsson.org>

Daiki Ueno <ueno at unixuser.org> writes:

>>>>>> In <87eipo4jgc.fsf at mocca.josefsson.org> 
>>>>>>	Simon Josefsson <simon at josefsson.org> wrote:
>> >> The x509self self-test started failing, and it may be TLS 1.2 related.
>> >> Can you take a look?
>> >
>> > Sure, but I couldn't reproduce the failure.  What architecture did you
>> > run the test on?
>
>> Debian x86.
>
> I'm now able to reproduce it on x86.  I wonder why this is not the case
> on amd64.
>
>> >> ==12233== Invalid read of size 4
>> >> ==12233==    at 0x40479CC: _gnutls_hash_deinit (gnutls_hash_int.c:172)
>> >> ==12233==    by 0x4058683: _gnutls_tls_sign_hdata (gnutls_sig.c:157)
>
> It should be fixed with:
> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=01c50c13f7e7a1d676451015ef66c95511d1d734
>
> That was actually my mistake - when I changed the underlying hash
> function from SHA-1 to SHA256, I forgot to increase the buffer size of
> internal hash values.

Thanks!

I'll do a release shortly, so we can more easily test how TLS 1.2 works
in some real applications now that it is the default.

/Simon




From ludo at gnu.org  Fri Oct  2 09:50:10 2009
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Fri, 02 Oct 2009 09:50:10 +0200
Subject: Guile 2.x updates
In-Reply-To: <87d45akthw.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Tue, 29 Sep 2009 11:08:59 +0200")
References: <87my4e4wsq.fsf@gnu.org> <87d45akthw.fsf@mocca.josefsson.org>
Message-ID: <87ws3e9qvh.fsf@gnu.org>

Hi Simon,

Simon Josefsson <simon at josefsson.org> writes:

> It looks fine to me (or rather, I don't spot anything that would break
> anything non-guile, and I trust you on the Guile-specific portion), so
> please backport it to the v2.8 branch.

Done, thanks!

Ludo?.




From bkasarov at gmail.com  Mon Oct  5 15:42:32 2009
From: bkasarov at gmail.com (Boyan Kasarov)
Date: Mon, 05 Oct 2009 16:42:32 +0300
Subject: libgnutlsxx link problems
Message-ID: <1254750152.4356.41.camel@175-58.evo.bg>

Hello,
I am having problems linking against libgnutlsxx.

The test program I used:
( NOTE It requires the helper functions from
http://www.gnu.org/software/gnutls/manual/gnutls.html#Helper-function-for-TCP-connections wrapped in extern "C" )

#include <iostream>
#include <stdexcept>
#include <gnutls/gnutls.h>
#include <gnutls/gnutlsxx.h>
#include <cstring> /* for strlen */

/* A very basic TLS client, with SRP authentication.
 * written by Eduardo Villanueva Che, changed by Boyan Kasarov.
 */

#define MAX_BUF 1024
#define SA struct sockaddr

#define CAFILE "ca.pem"
#define USERNAME "username"
#define PASSWORD "password"
#define MSG "GET / HTTP/1.0\r\n\r\n"

extern "C"
{
    int tcp_connect(void);
    void tcp_close(int sd);
}


int main(void)
{
    int sd = -1;
    gnutls_global_init();

    try
    {
        /* Allow connections to servers that have OpenPGP keys as well.
         */
        gnutls::client_session session;

        /* X509 stuff */
        gnutls::certificate_credentials credentials;

        /* SRP stuff */
        gnutls::srp_client_credentials srp_credentials;

        /* sets the trusted cas file
         */
        credentials.set_x509_trust_file(CAFILE, GNUTLS_X509_FMT_PEM);

        /* enter username and passowrd
         */
        srp_credentials.set_credentials(USERNAME, PASSWORD);

        /* put the x509 credentials to the current session
         */
        session.set_credentials(credentials);

        /* put the srp credentials to the current session
         */
        session.set_credentials(srp_credentials);

        /* Use default priorities */
        session.set_priority ("NORMAL:+SRP:+SRP-RSA:+SRP-DSS:-DHE-RSA",
NULL);

        /* connect to the peer
         */
        sd = tcp_connect();
        session.set_transport_ptr((gnutls_transport_ptr_t) sd);

        /* Perform the TLS handshake
         */
        int ret = session.handshake();
        if (ret < 0)
        {
//             gnutls_perror(ret);
            throw std::runtime_error("Handshake failed");
        }
        else
        {
            std::cout << "- Handshake was completed" << std::endl;
        }

        session.send(MSG, strlen(MSG));
        char buffer[MAX_BUF + 1];
        ret = session.recv(buffer, MAX_BUF);
        if (ret == 0)
        {
            throw std::runtime_error("Peer has closed the TLS
connection");
        }
        else if (ret < 0)
        {
            throw std::runtime_error(gnutls_strerror(ret));
        }

        std::cout << "- Received " << ret << " bytes:" << std::endl;
        std::cout.write(buffer, ret);
        std::cout << std::endl;

        session.bye(GNUTLS_SHUT_RDWR);
    }
    catch (gnutls::exception &ex)
    {
        std::cerr << "Exception caught: " << ex.what() << std::endl;
    }

    if (sd != -1)
        tcp_close(sd);

    gnutls_global_deinit();

    return 0;
}

The problem I have is this:

derex at laptop ~/workspace/gnutls-test $ g++ ./test.cpp -lgnutlsxx
/tmp/cccjLXmv.o: In function `main':
test.cpp:(.text+0x15f): undefined reference to
`gnutls::srp_client_credentials::srp_client_credentials()'
test.cpp:(.text+0x188): undefined reference to
`gnutls::srp_client_credentials::set_credentials(char const*, char
const*)'
test.cpp:(.text+0x721): undefined reference to
`gnutls::srp_client_credentials::~srp_client_credentials()'
test.cpp:(.text+0x74b): undefined reference to
`gnutls::srp_client_credentials::~srp_client_credentials()'
/tmp/cccjLXmv.o:(.gcc_except_table+0xac): undefined reference to
`typeinfo for gnutls::exception'
collect2: ld returned 1 exit status

This errors appears if I use versions from 2.8.3 upto 2.9.4 (snapshot
20091004 from http://daily.josefsson.org/gnutls/ ) , I couldn't find
where gnutls source is , I didn't test versions before 2.8.3

The way I see it the link problem consists of 2 problems:

**** SRP related classes don't get build because of missing ENABLE_SRP
preprocessor flag ( even if srp is enabled from configure ). It can be
fixed by including config.h in lib/gnutlsxx.cpp, here is patch :

diff --git a/lib/gnutlsxx.cpp b/lib/gnutlsxx.cpp
index 83453f0..cdca728 100644
--- a/lib/gnutlsxx.cpp
+++ b/lib/gnutlsxx.cpp
@@ -1,3 +1,7 @@
+#ifdef HAVE_CONFIG_H
+# include <config.h>
+#endif
+
 #include <gnutls/gnutlsxx.h>

 namespace gnutls


**** The second problem is missing typeinfo for some classes, including
gnutls::exception in the example. I used this hack to fix it:

diff --git a/lib/libgnutlsxx.map b/lib/libgnutlsxx.map
index f049df4..62f6c12 100644
--- a/lib/libgnutlsxx.map
+++ b/lib/libgnutlsxx.map
@@ -24,7 +24,11 @@ GNUTLS_1_6
 {
   global:
     extern "C++" {
-      gnutls*;
+      gnutls::*;
   };
+
+  # export typeinfo names and structures
+  _ZTI*;
+
   local: *;
 };

However I think some solution like explained at this url - 
http://gcc.gnu.org/wiki/Visibility could be implemented for the C++
bindings.

Boyan Kasarov






From simon at josefsson.org  Tue Oct  6 11:49:51 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 06 Oct 2009 11:49:51 +0200
Subject: libgnutlsxx link problems
In-Reply-To: <1254750152.4356.41.camel@175-58.evo.bg> (Boyan Kasarov's message
	of "Mon, 05 Oct 2009 16:42:32 +0300")
References: <1254750152.4356.41.camel@175-58.evo.bg>
Message-ID: <878wfoets0.fsf@mocca.josefsson.org>

Boyan Kasarov <bkasarov at gmail.com> writes:

> Hello,
> I am having problems linking against libgnutlsxx.

Hi.  Thanks for the report!

> This errors appears if I use versions from 2.8.3 upto 2.9.4 (snapshot
> 20091004 from http://daily.josefsson.org/gnutls/ ) , I couldn't find
> where gnutls source is , I didn't test versions before 2.8.3

Source code for all versions are available from:

http://www.gnu.org/software/gnutls/download.html

Version controlled sources are available from:

https://savannah.gnu.org/git/?group=gnutls

> **** SRP related classes don't get build because of missing ENABLE_SRP
> preprocessor flag ( even if srp is enabled from configure ). It can be
> fixed by including config.h in lib/gnutlsxx.cpp, here is patch :

Indeed, thank you it has been pushed.

> **** The second problem is missing typeinfo for some classes, including
> gnutls::exception in the example. I used this hack to fix it:

I used your hack for now...

> However I think some solution like explained at this url - 
> http://gcc.gnu.org/wiki/Visibility could be implemented for the C++
> bindings.

...however I agree with this, but don't have time to work on it.
Patches are welcome, but I think you will need to sign a copyright
transfer to the FSF because such a patch would end up being more than a
couple of lines.  Let me know privately if you want to make that happen.

/Simon




From simon at josefsson.org  Thu Oct 15 08:34:16 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 15 Oct 2009 08:34:16 +0200
Subject: libgnutlsxx link problems
In-Reply-To: <1255103108.20764.36.camel@175-58.evo.bg> (Boyan Kasarov's
	message of "Fri, 09 Oct 2009 18:45:08 +0300")
References: <1254750152.4356.41.camel@175-58.evo.bg>
	<878wfoets0.fsf@mocca.josefsson.org>
	<1255103108.20764.36.camel@175-58.evo.bg>
Message-ID: <87bpk9f9nb.fsf@mocca.josefsson.org>

Boyan Kasarov <bkasarov at gmail.com> writes:

> Here is patch to export the names in more proper way:
>
> diff --git a/lib/libgnutlsxx.map b/lib/libgnutlsxx.map
> index 62f6c12..f61d861 100644
> --- a/lib/libgnutlsxx.map
> +++ b/lib/libgnutlsxx.map
> @@ -24,11 +24,18 @@ GNUTLS_1_6
>  {
>    global:
>      extern "C++" {
> -      gnutls::*;
> -  };
> +      # To specify a class we also need to specify its typeinfo,
> +      # typeinfo name and vtable objects.
> +      # For example for class gnutls::psk_client_credentials,
> +      # we need to declare this 4 lines:
> +      #
> +      # gnutls::psk_client_credentials::*;
> +      # "typeinfo for gnutls::psk_client_credentials";
> +      # "typeinfo name for gnutls::psk_client_credentials";
> +      # "vtable for gnutls::psk_client_credentials";
>  
> -  # export typeinfo names and structures
> -  _ZTI*;
> +      *gnutls::*;
> +  };
>  
>    local: *;
>  };

Applied.

> As you see specifying what to export from version script is somehow not
> flexible for C++, and it does not work well on all platforms, I can
> implement solution like in
> http://www.gnu.org/software/gnulib/manual/gnulib.html#Exported-Symbols-of-Shared-Libraries , the 3th solution.

I think that is the right solution, so it would be great.  The best is
to start use it for the C++ library first and not couple this with doing
the same change for the C library.  So please look into creating a patch
to use it for the C++ library first.

Thanks,
/Simon




From vivek at collabora.co.uk  Thu Oct 15 20:13:04 2009
From: vivek at collabora.co.uk (Vivek Dasmohapatra)
Date: Thu, 15 Oct 2009 19:13:04 +0100 (BST)
Subject: TLS1.1 handshake problem (demonstrated with gnutls-cli)
Message-ID: <alpine.DEB.2.00.0910151846050.26028@noise>

While investigating a report of a problem connecting to a particular 
server when using the gnutls backend of our XMPP library, we (collabora)
stumbled across this problem :

/usr/local/src/gnutls26-2.8.4/src/gnutls-cli --priority "NORMAL:%COMPAT" \
     -p 5223 stbeehive.oracle.com
Resolving 'stbeehive.oracle.com'...
Connecting to '141.146.118.11:5223'...
proto  [0] = 3 TLS1.1
        [1] = 2 TLS1.0
        [2] = 1 SSL3.0
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [10]: Unexpected message
*** Handshake has failed
GNUTLS ERROR: A TLS fatal alert has been received.

(the proto lines are some extra debugging I added myself)
Whereas:

/usr/local/src/gnutls26-2.8.4/src/gnutls-cli \
     --priority "NORMAL:%COMPAT:-VERS-TLS1.1"  -p 5223 stbeehive.oracle.com
Resolving 'stbeehive.oracle.com'...
Connecting to '141.146.118.11:5223'...
proto  [0] = 1 SSL3.0
        [1] = 2 TLS1.0
- The hostname in the certificate matches 'stbeehive.oracle.com'.
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.0
- Key Exchange: RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed

Now I'm not sure who's in the wrong here, the server or the client 
library: fwiw openssl negotiates TLS1 with the server out of the box,
but s_client doesn't state which explicit TLS minor version it's using,
so it could just be that it doesn't implement TLS 1.1 or 1.2 yet.

Enabling 1.2 and disablinng 1.1 also causes the error above (Unexpected 
message).

Disabling %COMPAT (padding) triggers:

*** Received alert [20]: Bad record MAC

instead.

So, is this a bug in the TLS1.1/TLS1.2 implementation in gnutls, or
is it the server doing something wrong, or both?





From simon at josefsson.org  Fri Oct 16 07:51:44 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 16 Oct 2009 07:51:44 +0200
Subject: TLS1.1 handshake problem (demonstrated with gnutls-cli)
In-Reply-To: <alpine.DEB.2.00.0910151846050.26028@noise> (Vivek Dasmohapatra's
	message of "Thu, 15 Oct 2009 19:13:04 +0100 (BST)")
References: <alpine.DEB.2.00.0910151846050.26028@noise>
Message-ID: <87vdifyjgv.fsf@mocca.josefsson.org>

Vivek Dasmohapatra <vivek at collabora.co.uk> writes:

> While investigating a report of a problem connecting to a particular
> server when using the gnutls backend of our XMPP library, we
> (collabora)
> stumbled across this problem :
>
> /usr/local/src/gnutls26-2.8.4/src/gnutls-cli --priority "NORMAL:%COMPAT" \
>     -p 5223 stbeehive.oracle.com
> Resolving 'stbeehive.oracle.com'...
> Connecting to '141.146.118.11:5223'...
> proto  [0] = 3 TLS1.1
>        [1] = 2 TLS1.0
>        [2] = 1 SSL3.0
> *** Fatal error: A TLS fatal alert has been received.
> *** Received alert [10]: Unexpected message
> *** Handshake has failed
> GNUTLS ERROR: A TLS fatal alert has been received.
>
> (the proto lines are some extra debugging I added myself)
> Whereas:
>
> /usr/local/src/gnutls26-2.8.4/src/gnutls-cli \
>     --priority "NORMAL:%COMPAT:-VERS-TLS1.1"  -p 5223 stbeehive.oracle.com
> Resolving 'stbeehive.oracle.com'...
> Connecting to '141.146.118.11:5223'...
> proto  [0] = 1 SSL3.0
>        [1] = 2 TLS1.0
> - The hostname in the certificate matches 'stbeehive.oracle.com'.
> - Peer's certificate issuer is unknown
> - Peer's certificate is NOT trusted
> - Version: TLS1.0
> - Key Exchange: RSA
> - Cipher: AES-128-CBC
> - MAC: SHA1
> - Compression: NULL
> - Handshake was completed
>
> Now I'm not sure who's in the wrong here, the server or the client
> library: fwiw openssl negotiates TLS1 with the server out of the box,
> but s_client doesn't state which explicit TLS minor version it's using,
> so it could just be that it doesn't implement TLS 1.1 or 1.2 yet.

OpenSSL doesn't support TLS 1.1 or 1.2.

> Enabling 1.2 and disablinng 1.1 also causes the error above
> (Unexpected message).
>
> Disabling %COMPAT (padding) triggers:
>
> *** Received alert [20]: Bad record MAC
>
> instead.
>
> So, is this a bug in the TLS1.1/TLS1.2 implementation in gnutls, or
> is it the server doing something wrong, or both?

The symptom indicates a fairly common TLS server problem.  To know for
sure requires debugging the server side.  But if you cannot get it to
work with any other TLS client (that supports TLS > 1.0) I would suspect
a server bug rather than a GnuTLS bug.

What you need to do in your application is to expose an interface to
provide a GnuTLS priority string, preferrably per IP address, to allow
users to work around buggy servers.

/Simon




From simon at josefsson.org  Fri Oct 16 16:04:58 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 16 Oct 2009 16:04:58 +0200
Subject: TLS1.1 handshake problem (demonstrated with gnutls-cli)
In-Reply-To: <alpine.DEB.2.00.0910161251110.26028@noise> (Vivek Dasmohapatra's
	message of "Fri, 16 Oct 2009 14:22:11 +0100 (BST)")
References: <alpine.DEB.2.00.0910151846050.26028@noise>
	<87vdifyjgv.fsf@mocca.josefsson.org>
	<alpine.DEB.2.00.0910161251110.26028@noise>
Message-ID: <87zl7r3051.fsf@mocca.josefsson.org>

Vivek Dasmohapatra <vivek at collabora.co.uk> writes:

>>> So, is this a bug in the TLS1.1/TLS1.2 implementation in gnutls, or
>>> is it the server doing something wrong, or both?
>>
>> The symptom indicates a fairly common TLS server problem.  To know for
>> sure requires debugging the server side.  But if you cannot get it to
>> work with any other TLS client (that supports TLS > 1.0) I would suspect
>> a server bug rather than a GnuTLS bug.
>
> Ok, thanks. I doubt we can get any debugging done on the server itself,
> ssltap indicates it gets a { 3, 2 } handshake and immedately returns
> an alert saying "unexpected message", so it does look like a server bug.

Yes, that is a typical symptom.

> Not sure if anything else implements 1.x yet, openssl doesn't and libnss3
> doesn't seem to either.

I suspect there will be interop problems in this area, but the pain paid
by us using new software will help to phase out older software on the
net..  just make sure users can disable TLS > 1.0 in your app and you
should be fine.

> Thanks for the quick response.

/Simon




From bkasarov at gmail.com  Sat Oct 17 16:42:33 2009
From: bkasarov at gmail.com (Boyan Kasarov)
Date: Sat, 17 Oct 2009 17:42:33 +0300
Subject: libgnutlsxx link problems
In-Reply-To: <87bpk9f9nb.fsf@mocca.josefsson.org>
References: <87bpk9f9nb.fsf@mocca.josefsson.org>
Message-ID: <1255790555-28286-1-git-send-email-bkasarov@gmail.com>


Hello,
I am sending two patches to add symbol visibility support.

[PATCH 1/2] Import lib-symbol-visibility from gnulib
[PATCH 2/2] Use lib-symbol-visibility for the C++ library

The first patch is the result of running:
# gnulib-tool --import lib-symbol-visibility
from latest gnulib from git, but I think it also updated some other files, if you have your ways to invoke it, please feel free to do it.

The second patch adds the necessary changes as explained in lib-symbol-visibility manual to add support for libgnutlsxx. I also removed the "local: *;" directive from libgnutlsxx.map, because it is no longer needed to hide symbols using it.

I have tested on freebsd, linux and opensolaris with gcc 4.2, 4.3 and 3.4.

Boyan





From bkasarov at gmail.com  Sat Oct 17 16:42:34 2009
From: bkasarov at gmail.com (Boyan Kasarov)
Date: Sat, 17 Oct 2009 17:42:34 +0300
Subject: [PATCH 1/2] Import lib-symbol-visibility from gnulib
In-Reply-To: <1255790555-28286-1-git-send-email-bkasarov@gmail.com>
References: <87bpk9f9nb.fsf@mocca.josefsson.org>
	<1255790555-28286-1-git-send-email-bkasarov@gmail.com>
Message-ID: <d8280f4cfed62560277e417c26386e7503ca96eb.1255777754.git.bkasarov@gmail.com>

---
 lib/gl/Makefile.am        |   15 ++++-
 lib/gl/m4/gnulib-cache.m4 |    3 +-
 lib/gl/m4/gnulib-comp.m4  |    1 +
 lib/gl/m4/sys_stat_h.m4   |   51 +++++++------
 lib/gl/sys_stat.in.h      |  176 +++++++++++++++++++++++++--------------------
 5 files changed, 143 insertions(+), 103 deletions(-)

diff --git a/lib/gl/Makefile.am b/lib/gl/Makefile.am
index c1e87e2..ce6fce6 100644
--- a/lib/gl/Makefile.am
+++ b/lib/gl/Makefile.am
@@ -9,7 +9,7 @@
 # the same distribution terms as the rest of that program.
 #
 # Generated by gnulib-tool.
-# Reproduce by: gnulib-tool --import --dir=. --local-dir=gl/override --lib=liblgnu --source-base=gl --m4-base=gl/m4 --doc-base=doc --tests-base=gl/tests --aux-dir=build-aux --with-tests --avoid=alignof-tests --avoid=lseek-tests --lgpl=2 --libtool --macro-prefix=lgl --no-vc-files byteswap c-ctype fseeko func gettext lib-msvc-compat lib-symbol-versions memmem-simple minmax netdb read-file snprintf sockets socklen stdint strcase strverscmp sys_socket sys_stat time_r unistd vasprintf vsnprintf
+# Reproduce by: gnulib-tool --import --dir=. --local-dir=gl/override --lib=liblgnu --source-base=gl --m4-base=gl/m4 --doc-base=doc --tests-base=gl/tests --aux-dir=build-aux --with-tests --avoid=alignof-tests --avoid=lseek-tests --lgpl=2 --libtool --macro-prefix=lgl --no-vc-files byteswap c-ctype fseeko func gettext lib-msvc-compat lib-symbol-versions lib-symbol-visibility memmem-simple minmax netdb read-file snprintf sockets socklen stdint strcase strverscmp sys_socket sys_stat time_r unistd vasprintf vsnprintf
 
 AUTOMAKE_OPTIONS = 1.5 gnits
 
@@ -191,6 +191,16 @@ EXTRA_DIST += $(top_srcdir)/build-aux/config.rpath
 
 ## end   gnulib module havelib
 
+## begin gnulib module lib-symbol-visibility
+
+# The value of $(CFLAG_VISIBILITY) needs to be added to the CFLAGS for the
+# compilation of all sources that make up the library. This line here does it
+# only for the gnulib part of it. The developer is responsible for adding
+# $(CFLAG_VISIBILITY) to the Makefile.ams of the other portions of the library.
+AM_CFLAGS += $(CFLAG_VISIBILITY)
+
+## end   gnulib module lib-symbol-visibility
+
 ## begin gnulib module link-warning
 
 LINK_WARNING_H=$(top_srcdir)/build-aux/link-warning.h
@@ -745,6 +755,7 @@ sys/stat.h: sys_stat.in.h
 	      -e 's|@''GNULIB_MKFIFOAT''@|$(GNULIB_MKFIFOAT)|g' \
 	      -e 's|@''GNULIB_MKNODAT''@|$(GNULIB_MKNODAT)|g' \
 	      -e 's|@''GNULIB_STAT''@|$(GNULIB_STAT)|g' \
+	      -e 's|@''GNULIB_UTIMENSAT''@|$(GNULIB_UTIMENSAT)|g' \
 	      -e 's|@''HAVE_FCHMODAT''@|$(HAVE_FCHMODAT)|g' \
 	      -e 's|@''HAVE_FSTATAT''@|$(HAVE_FSTATAT)|g' \
 	      -e 's|@''HAVE_FUTIMENS''@|$(HAVE_FUTIMENS)|g' \
@@ -753,12 +764,14 @@ sys/stat.h: sys_stat.in.h
 	      -e 's|@''HAVE_MKDIRAT''@|$(HAVE_MKDIRAT)|g' \
 	      -e 's|@''HAVE_MKFIFOAT''@|$(HAVE_MKFIFOAT)|g' \
 	      -e 's|@''HAVE_MKNODAT''@|$(HAVE_MKNODAT)|g' \
+	      -e 's|@''HAVE_UTIMENSAT''@|$(HAVE_UTIMENSAT)|g' \
 	      -e 's|@''REPLACE_FSTAT''@|$(REPLACE_FSTAT)|g' \
 	      -e 's|@''REPLACE_FSTATAT''@|$(REPLACE_FSTATAT)|g' \
 	      -e 's|@''REPLACE_FUTIMENS''@|$(REPLACE_FUTIMENS)|g' \
 	      -e 's|@''REPLACE_LSTAT''@|$(REPLACE_LSTAT)|g' \
 	      -e 's|@''REPLACE_MKDIR''@|$(REPLACE_MKDIR)|g' \
 	      -e 's|@''REPLACE_STAT''@|$(REPLACE_STAT)|g' \
+	      -e 's|@''REPLACE_UTIMENSAT''@|$(REPLACE_UTIMENSAT)|g' \
 	      -e '/definition of GL_LINK_WARNING/r $(LINK_WARNING_H)' \
 	      < $(srcdir)/sys_stat.in.h; \
 	} > $@-t && \
diff --git a/lib/gl/m4/gnulib-cache.m4 b/lib/gl/m4/gnulib-cache.m4
index de6f4c7..18da12a 100644
--- a/lib/gl/m4/gnulib-cache.m4
+++ b/lib/gl/m4/gnulib-cache.m4
@@ -15,7 +15,7 @@
 
 
 # Specification in the form of a command-line invocation:
-#   gnulib-tool --import --dir=. --local-dir=gl/override --lib=liblgnu --source-base=gl --m4-base=gl/m4 --doc-base=doc --tests-base=gl/tests --aux-dir=build-aux --with-tests --avoid=alignof-tests --avoid=lseek-tests --lgpl=2 --libtool --macro-prefix=lgl --no-vc-files byteswap c-ctype fseeko func gettext lib-msvc-compat lib-symbol-versions memmem-simple minmax netdb read-file snprintf sockets socklen stdint strcase strverscmp sys_socket sys_stat time_r unistd vasprintf vsnprintf
+#   gnulib-tool --import --dir=. --local-dir=gl/override --lib=liblgnu --source-base=gl --m4-base=gl/m4 --doc-base=doc --tests-base=gl/tests --aux-dir=build-aux --with-tests --avoid=alignof-tests --avoid=lseek-tests --lgpl=2 --libtool --macro-prefix=lgl --no-vc-files byteswap c-ctype fseeko func gettext lib-msvc-compat lib-symbol-versions lib-symbol-visibility memmem-simple minmax netdb read-file snprintf sockets socklen stdint strcase strverscmp sys_socket sys_stat time_r unistd vasprintf vsnprintf
 
 # Specification in the form of a few gnulib-tool.m4 macro invocations:
 gl_LOCAL_DIR([gl/override])
@@ -27,6 +27,7 @@ gl_MODULES([
   gettext
   lib-msvc-compat
   lib-symbol-versions
+  lib-symbol-visibility
   memmem-simple
   minmax
   netdb
diff --git a/lib/gl/m4/gnulib-comp.m4 b/lib/gl/m4/gnulib-comp.m4
index 9265e44..25d2436 100644
--- a/lib/gl/m4/gnulib-comp.m4
+++ b/lib/gl/m4/gnulib-comp.m4
@@ -57,6 +57,7 @@ AC_DEFUN([lgl_INIT],
   AC_SUBST([LTLIBINTL])
   gl_LD_OUTPUT_DEF
   gl_LD_VERSION_SCRIPT
+  gl_VISIBILITY
   gl_FUNC_LSEEK
   gl_UNISTD_MODULE_INDICATOR([lseek])
   gl_FUNC_MEMCHR
diff --git a/lib/gl/m4/sys_stat_h.m4 b/lib/gl/m4/sys_stat_h.m4
index 6004890..1edf548 100644
--- a/lib/gl/m4/sys_stat_h.m4
+++ b/lib/gl/m4/sys_stat_h.m4
@@ -1,4 +1,4 @@
-# sys_stat_h.m4 serial 18   -*- Autoconf -*-
+# sys_stat_h.m4 serial 19   -*- Autoconf -*-
 dnl Copyright (C) 2006-2009 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -39,28 +39,31 @@ AC_DEFUN([gl_SYS_STAT_MODULE_INDICATOR],
 AC_DEFUN([gl_SYS_STAT_H_DEFAULTS],
 [
   AC_REQUIRE([gl_UNISTD_H_DEFAULTS]) dnl for REPLACE_FCHDIR
-  GNULIB_FCHMODAT=0;  AC_SUBST([GNULIB_FCHMODAT])
-  GNULIB_FSTATAT=0;   AC_SUBST([GNULIB_FSTATAT])
-  GNULIB_FUTIMENS=0;  AC_SUBST([GNULIB_FUTIMENS])
-  GNULIB_LCHMOD=0;    AC_SUBST([GNULIB_LCHMOD])
-  GNULIB_LSTAT=0;     AC_SUBST([GNULIB_LSTAT])
-  GNULIB_MKDIRAT=0;   AC_SUBST([GNULIB_MKDIRAT])
-  GNULIB_MKFIFOAT=0;  AC_SUBST([GNULIB_MKFIFOAT])
-  GNULIB_MKNODAT=0;   AC_SUBST([GNULIB_MKNODAT])
-  GNULIB_STAT=0;      AC_SUBST([GNULIB_STAT])
+  GNULIB_FCHMODAT=0;    AC_SUBST([GNULIB_FCHMODAT])
+  GNULIB_FSTATAT=0;     AC_SUBST([GNULIB_FSTATAT])
+  GNULIB_FUTIMENS=0;    AC_SUBST([GNULIB_FUTIMENS])
+  GNULIB_LCHMOD=0;      AC_SUBST([GNULIB_LCHMOD])
+  GNULIB_LSTAT=0;       AC_SUBST([GNULIB_LSTAT])
+  GNULIB_MKDIRAT=0;     AC_SUBST([GNULIB_MKDIRAT])
+  GNULIB_MKFIFOAT=0;    AC_SUBST([GNULIB_MKFIFOAT])
+  GNULIB_MKNODAT=0;     AC_SUBST([GNULIB_MKNODAT])
+  GNULIB_STAT=0;        AC_SUBST([GNULIB_STAT])
+  GNULIB_UTIMENSAT=0;   AC_SUBST([GNULIB_UTIMENSAT])
   dnl Assume proper GNU behavior unless another module says otherwise.
-  HAVE_FCHMODAT=1;    AC_SUBST([HAVE_FCHMODAT])
-  HAVE_FSTATAT=1;     AC_SUBST([HAVE_FSTATAT])
-  HAVE_FUTIMENS=1;    AC_SUBST([HAVE_FUTIMENS])
-  HAVE_LCHMOD=1;      AC_SUBST([HAVE_LCHMOD])
-  HAVE_LSTAT=1;       AC_SUBST([HAVE_LSTAT])
-  HAVE_MKDIRAT=1;     AC_SUBST([HAVE_MKDIRAT])
-  HAVE_MKFIFOAT=1;    AC_SUBST([HAVE_MKFIFOAT])
-  HAVE_MKNODAT=1;     AC_SUBST([HAVE_MKNODAT])
-  REPLACE_FSTAT=0;    AC_SUBST([REPLACE_FSTAT])
-  REPLACE_FSTATAT=0;  AC_SUBST([REPLACE_FSTATAT])
-  REPLACE_FUTIMENS=0; AC_SUBST([REPLACE_FUTIMENS])
-  REPLACE_LSTAT=0;    AC_SUBST([REPLACE_LSTAT])
-  REPLACE_MKDIR=0;    AC_SUBST([REPLACE_MKDIR])
-  REPLACE_STAT=0;     AC_SUBST([REPLACE_STAT])
+  HAVE_FCHMODAT=1;      AC_SUBST([HAVE_FCHMODAT])
+  HAVE_FSTATAT=1;       AC_SUBST([HAVE_FSTATAT])
+  HAVE_FUTIMENS=1;      AC_SUBST([HAVE_FUTIMENS])
+  HAVE_LCHMOD=1;        AC_SUBST([HAVE_LCHMOD])
+  HAVE_LSTAT=1;         AC_SUBST([HAVE_LSTAT])
+  HAVE_MKDIRAT=1;       AC_SUBST([HAVE_MKDIRAT])
+  HAVE_MKFIFOAT=1;      AC_SUBST([HAVE_MKFIFOAT])
+  HAVE_MKNODAT=1;       AC_SUBST([HAVE_MKNODAT])
+  HAVE_UTIMENSAT=1;     AC_SUBST([HAVE_UTIMENSAT])
+  REPLACE_FSTAT=0;      AC_SUBST([REPLACE_FSTAT])
+  REPLACE_FSTATAT=0;    AC_SUBST([REPLACE_FSTATAT])
+  REPLACE_FUTIMENS=0;   AC_SUBST([REPLACE_FUTIMENS])
+  REPLACE_LSTAT=0;      AC_SUBST([REPLACE_LSTAT])
+  REPLACE_MKDIR=0;      AC_SUBST([REPLACE_MKDIR])
+  REPLACE_STAT=0;       AC_SUBST([REPLACE_STAT])
+  REPLACE_UTIMENSAT=0;  AC_SUBST([REPLACE_UTIMENSAT])
 ])
diff --git a/lib/gl/sys_stat.in.h b/lib/gl/sys_stat.in.h
index 298985b..13cfcbf 100644
--- a/lib/gl/sys_stat.in.h
+++ b/lib/gl/sys_stat.in.h
@@ -293,41 +293,6 @@ extern "C" {
 #endif
 
 
-#if @GNULIB_LSTAT@
-# if ! @HAVE_LSTAT@
-/* mingw does not support symlinks, therefore it does not have lstat.  But
-   without links, stat does just fine.  */
-#  define lstat stat
-# elif @REPLACE_LSTAT@
-#  undef lstat
-#  define lstat rpl_lstat
-extern int rpl_lstat (const char *name, struct stat *buf);
-# endif
-#elif defined GNULIB_POSIXCHECK
-# undef lstat
-# define lstat(p,b)							\
-  (GL_LINK_WARNING ("lstat is unportable - "				\
-		    "use gnulib module lstat for portability"),		\
-   lstat (p, b))
-#endif
-
-#if @GNULIB_STAT@
-# if @REPLACE_STAT@
-/* We can't use the object-like #define stat rpl_stat, because of
-   struct stat.  This means that rpl_stat will not be used if the user
-   does (stat)(a,b).  Oh well.  */
-#  undef stat
-#  define stat(name, st) rpl_stat (name, st)
-extern int stat (const char *name, struct stat *buf);
-# endif
-#elif defined GNULIB_POSIXCHECK
-# undef stat
-# define stat(p,b)							\
-  (GL_LINK_WARNING ("stat is unportable - "				\
-		    "use gnulib module stat for portability"),		\
-   stat (p, b))
-#endif
-
 #if @GNULIB_FCHMODAT@
 # if !@HAVE_FCHMODAT@
 extern int fchmodat (int fd, char const *file, mode_t mode, int flag);
@@ -341,6 +306,12 @@ extern int fchmodat (int fd, char const *file, mode_t mode, int flag);
 #endif
 
 
+#if @REPLACE_FSTAT@
+# define fstat rpl_fstat
+extern int fstat (int fd, struct stat *buf);
+#endif
+
+
 #if @GNULIB_FSTATAT@
 # if @REPLACE_FSTATAT@
 #  undef fstatat
@@ -375,6 +346,71 @@ extern int futimens (int fd, struct timespec const times[2]);
 #endif
 
 
+#if @GNULIB_LCHMOD@
+/* Change the mode of FILENAME to MODE, without dereferencing it if FILENAME
+   denotes a symbolic link.  */
+# if !@HAVE_LCHMOD@
+/* The lchmod replacement follows symbolic links.  Callers should take
+   this into account; lchmod should be applied only to arguments that
+   are known to not be symbolic links.  On hosts that lack lchmod,
+   this can lead to race conditions between the check and the
+   invocation of lchmod, but we know of no workarounds that are
+   reliable in general.  You might try requesting support for lchmod
+   from your operating system supplier.  */
+#  define lchmod chmod
+# endif
+# if 0 /* assume already declared */
+extern int lchmod (const char *filename, mode_t mode);
+# endif
+#elif defined GNULIB_POSIXCHECK
+# undef lchmod
+# define lchmod(f,m) \
+    (GL_LINK_WARNING ("lchmod is unportable - " \
+                      "use gnulib module lchmod for portability"), \
+     lchmod (f, m))
+#endif
+
+
+#if @GNULIB_LSTAT@
+# if ! @HAVE_LSTAT@
+/* mingw does not support symlinks, therefore it does not have lstat.  But
+   without links, stat does just fine.  */
+#  define lstat stat
+# elif @REPLACE_LSTAT@
+#  undef lstat
+#  define lstat rpl_lstat
+extern int rpl_lstat (const char *name, struct stat *buf);
+# endif
+#elif defined GNULIB_POSIXCHECK
+# undef lstat
+# define lstat(p,b)							\
+  (GL_LINK_WARNING ("lstat is unportable - "				\
+		    "use gnulib module lstat for portability"),		\
+   lstat (p, b))
+#endif
+
+
+#if @REPLACE_MKDIR@
+# undef mkdir
+# define mkdir rpl_mkdir
+extern int mkdir (char const *name, mode_t mode);
+#else
+/* mingw's _mkdir() function has 1 argument, but we pass 2 arguments.
+   Additionally, it declares _mkdir (and depending on compile flags, an
+   alias mkdir), only in the nonstandard <io.h>, which is included above.  */
+# if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
+
+static inline int
+rpl_mkdir (char const *name, mode_t mode)
+{
+  return _mkdir (name);
+}
+
+#  define mkdir rpl_mkdir
+# endif
+#endif
+
+
 #if @GNULIB_MKDIRAT@
 # if !@HAVE_MKDIRAT@
 extern int mkdirat (int fd, char const *file, mode_t mode);
@@ -387,6 +423,7 @@ extern int mkdirat (int fd, char const *file, mode_t mode);
      mkdirat (d, n, m))
 #endif
 
+
 #if @GNULIB_MKFIFOAT@
 # if !@HAVE_MKFIFOAT@
 int mkfifoat (int fd, char const *file, mode_t mode);
@@ -399,6 +436,7 @@ int mkfifoat (int fd, char const *file, mode_t mode);
      mkfifoat (d, n, m))
 #endif
 
+
 #if @GNULIB_MKNODAT@
 # if !@HAVE_MKNODAT@
 int mknodat (int fd, char const *file, mode_t mode, dev_t dev);
@@ -411,56 +449,40 @@ int mknodat (int fd, char const *file, mode_t mode, dev_t dev);
      mknodat (f, n, m, d))
 #endif
 
-#if @REPLACE_FSTAT@
-# define fstat rpl_fstat
-extern int fstat (int fd, struct stat *buf);
-#endif
-
-#if @REPLACE_MKDIR@
-# undef mkdir
-# define mkdir rpl_mkdir
-extern int mkdir (char const *name, mode_t mode);
-#else
-/* mingw's _mkdir() function has 1 argument, but we pass 2 arguments.
-   Additionally, it declares _mkdir (and depending on compile flags, an
-   alias mkdir), only in the nonstandard <io.h>, which is included above.  */
-# if (defined _WIN32 || defined __WIN32__) && ! defined __CYGWIN__
 
-static inline int
-rpl_mkdir (char const *name, mode_t mode)
-{
-  return _mkdir (name);
-}
-
-#  define mkdir rpl_mkdir
+#if @GNULIB_STAT@
+# if @REPLACE_STAT@
+/* We can't use the object-like #define stat rpl_stat, because of
+   struct stat.  This means that rpl_stat will not be used if the user
+   does (stat)(a,b).  Oh well.  */
+#  undef stat
+#  define stat(name, st) rpl_stat (name, st)
+extern int stat (const char *name, struct stat *buf);
 # endif
+#elif defined GNULIB_POSIXCHECK
+# undef stat
+# define stat(p,b)							\
+  (GL_LINK_WARNING ("stat is unportable - "				\
+		    "use gnulib module stat for portability"),		\
+   stat (p, b))
 #endif
 
 
-/* Declare BSD extensions.  */
-
-#if @GNULIB_LCHMOD@
-/* Change the mode of FILENAME to MODE, without dereferencing it if FILENAME
-   denotes a symbolic link.  */
-# if !@HAVE_LCHMOD@
-/* The lchmod replacement follows symbolic links.  Callers should take
-   this into account; lchmod should be applied only to arguments that
-   are known to not be symbolic links.  On hosts that lack lchmod,
-   this can lead to race conditions between the check and the
-   invocation of lchmod, but we know of no workarounds that are
-   reliable in general.  You might try requesting support for lchmod
-   from your operating system supplier.  */
-#  define lchmod chmod
+#if @GNULIB_UTIMENSAT@
+# if @REPLACE_UTIMENSAT@
+#  undef utimensat
+#  define utimensat rpl_utimensat
 # endif
-# if 0 /* assume already declared */
-extern int lchmod (const char *filename, mode_t mode);
+# if !@HAVE_UTIMENSAT@ || @REPLACE_UTIMENSAT@
+   extern int utimensat (int fd, char const *name,
+                         struct timespec const times[2], int flag);
 # endif
 #elif defined GNULIB_POSIXCHECK
-# undef lchmod
-# define lchmod(f,m) \
-    (GL_LINK_WARNING ("lchmod is unportable - " \
-                      "use gnulib module lchmod for portability"), \
-     lchmod (f, m))
+# undef utimensat
+# define utimensat(d,n,t,f)                          \
+    (GL_LINK_WARNING ("utimensat is not portable - " \
+                      "use gnulib module utimensat for portability"), \
+     utimensat (d, n, t, f))
 #endif
 
 
-- 
1.6.4.4





From bkasarov at gmail.com  Sat Oct 17 16:42:35 2009
From: bkasarov at gmail.com (Boyan Kasarov)
Date: Sat, 17 Oct 2009 17:42:35 +0300
Subject: [PATCH 2/2] Use lib-symbol-visibility for the C++ library
In-Reply-To: <d8280f4cfed62560277e417c26386e7503ca96eb.1255777754.git.bkasarov@gmail.com>
References: <87bpk9f9nb.fsf@mocca.josefsson.org>
	<1255790555-28286-1-git-send-email-bkasarov@gmail.com>
	<d8280f4cfed62560277e417c26386e7503ca96eb.1255777754.git.bkasarov@gmail.com>
Message-ID: <be438c5f94e552819d41d4001f535b7250053636.1255777754.git.bkasarov@gmail.com>

---
 lib/Makefile.am                |    5 +++-
 lib/includes/gnutls/gnutlsxx.h |   46 ++++++++++++++++++++++++---------------
 lib/libgnutlsxx.map            |    2 -
 3 files changed, 32 insertions(+), 21 deletions(-)

diff --git a/lib/Makefile.am b/lib/Makefile.am
index 350a087..ab4ddb4 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -141,7 +141,10 @@ endif
 # C++ library
 
 if ENABLE_CXX
-libgnutlsxx_la_CPPFLAGS = -I$(top_srcdir)/includes -I$(top_builddir)/includes
+libgnutlsxx_la_CPPFLAGS = -DBUILDING_GNUTLSXX \
+                          $(CFLAG_VISIBILITY) \
+                          -I$(top_srcdir)/includes \
+                          -I$(top_builddir)/includes
 
 AM_CXXFLAGS = -I$(top_srcdir)/includes/
 
diff --git a/lib/includes/gnutls/gnutlsxx.h b/lib/includes/gnutls/gnutlsxx.h
index b3013d2..f331b45 100644
--- a/lib/includes/gnutls/gnutlsxx.h
+++ b/lib/includes/gnutls/gnutlsxx.h
@@ -5,10 +5,20 @@
 #include <vector>
 #include <gnutls/gnutls.h>
 
+#if BUILDING_GNUTLSXX && HAVE_VISIBILITY
+#define GNUTLSXX_DLL_EXPORTED __attribute__((__visibility__("default")))
+#elif BUILDING_GNUTLSXX && defined _MSC_VER
+#define GNUTLSXX_DLL_EXPORTED __declspec(dllexport)
+#elif defined _MSC_VER
+#define GNUTLSXX_DLL_EXPORTED __declspec(dllimport)
+#else
+#define GNUTLSXX_DLL_EXPORTED
+#endif
+
 namespace gnutls
 {
 
-  class noncopyable
+  class GNUTLSXX_DLL_EXPORTED noncopyable
   {
   protected:
     noncopyable ()
@@ -25,7 +35,7 @@ namespace gnutls
   };
 
 
-  class exception:public std::exception
+  class GNUTLSXX_DLL_EXPORTED exception:public std::exception
   {
   public:
     exception (int x);
@@ -36,7 +46,7 @@ namespace gnutls
   };
 
 
-  class dh_params:private noncopyable
+  class GNUTLSXX_DLL_EXPORTED dh_params:private noncopyable
   {
   public:
     dh_params ();
@@ -58,7 +68,7 @@ namespace gnutls
   };
 
 
-  class rsa_params:private noncopyable
+  class GNUTLSXX_DLL_EXPORTED rsa_params:private noncopyable
   {
   public:
     rsa_params ();
@@ -84,7 +94,7 @@ namespace gnutls
       gnutls_rsa_params_t params;
   };
 
-  class session:private noncopyable
+  class GNUTLSXX_DLL_EXPORTED session:private noncopyable
   {
   protected:
     gnutls_session_t s;
@@ -204,7 +214,7 @@ namespace gnutls
   };
 
 // interface for databases
-  class DB:private noncopyable
+  class GNUTLSXX_DLL_EXPORTED DB:private noncopyable
   {
   public:
     virtual ~ DB () = 0;
@@ -215,7 +225,7 @@ namespace gnutls
     virtual bool remove (const gnutls_datum_t & key) = 0;
   };
 
-  class server_session:public session
+  class GNUTLSXX_DLL_EXPORTED server_session:public session
   {
   public:
     server_session ();
@@ -239,7 +249,7 @@ namespace gnutls
     void set_certificate_request (gnutls_certificate_request_t);
   };
 
-  class client_session:public session
+  class GNUTLSXX_DLL_EXPORTED client_session:public session
   {
   public:
     client_session ();
@@ -252,7 +262,7 @@ namespace gnutls
   };
 
 
-  class credentials:private noncopyable
+  class GNUTLSXX_DLL_EXPORTED credentials:private noncopyable
   {
   public:
     virtual ~ credentials ()
@@ -269,7 +279,7 @@ namespace gnutls
     void *cred;
   };
 
-  class certificate_credentials:public credentials
+  class GNUTLSXX_DLL_EXPORTED certificate_credentials:public credentials
   {
   public:
     ~certificate_credentials ();
@@ -314,7 +324,7 @@ namespace gnutls
       gnutls_certificate_credentials_t cred;
   };
 
-  class certificate_server_credentials:public certificate_credentials
+  class GNUTLSXX_DLL_EXPORTED certificate_server_credentials:public certificate_credentials
   {
   public:
     void set_retrieve_function (gnutls_certificate_server_retrieve_function *
@@ -322,7 +332,7 @@ namespace gnutls
     void set_params_function (gnutls_params_function * func);
   };
 
-  class certificate_client_credentials:public certificate_credentials
+  class GNUTLSXX_DLL_EXPORTED certificate_client_credentials:public certificate_credentials
   {
   public:
     void set_retrieve_function (gnutls_certificate_client_retrieve_function *
@@ -332,7 +342,7 @@ namespace gnutls
 
 
 
-  class anon_server_credentials:public credentials
+  class GNUTLSXX_DLL_EXPORTED anon_server_credentials:public credentials
   {
   public:
     anon_server_credentials ();
@@ -343,7 +353,7 @@ namespace gnutls
       gnutls_anon_server_credentials_t cred;
   };
 
-  class anon_client_credentials:public credentials
+  class GNUTLSXX_DLL_EXPORTED anon_client_credentials:public credentials
   {
   public:
     anon_client_credentials ();
@@ -353,7 +363,7 @@ namespace gnutls
   };
 
 
-  class srp_server_credentials:public credentials
+  class GNUTLSXX_DLL_EXPORTED srp_server_credentials:public credentials
   {
   public:
     srp_server_credentials ();
@@ -366,7 +376,7 @@ namespace gnutls
       gnutls_srp_server_credentials_t cred;
   };
 
-  class srp_client_credentials:public credentials
+  class GNUTLSXX_DLL_EXPORTED srp_client_credentials:public credentials
   {
   public:
     srp_client_credentials ();
@@ -379,7 +389,7 @@ namespace gnutls
   };
 
 
-  class psk_server_credentials:public credentials
+  class GNUTLSXX_DLL_EXPORTED psk_server_credentials:public credentials
   {
   public:
     psk_server_credentials ();
@@ -393,7 +403,7 @@ namespace gnutls
       gnutls_psk_server_credentials_t cred;
   };
 
-  class psk_client_credentials:public credentials
+  class GNUTLSXX_DLL_EXPORTED psk_client_credentials:public credentials
   {
   public:
     psk_client_credentials ();
diff --git a/lib/libgnutlsxx.map b/lib/libgnutlsxx.map
index f61d861..8ced950 100644
--- a/lib/libgnutlsxx.map
+++ b/lib/libgnutlsxx.map
@@ -36,6 +36,4 @@ GNUTLS_1_6
 
       *gnutls::*;
   };
-
-  local: *;
 };
-- 
1.6.4.4





From simon at josefsson.org  Mon Oct 19 12:51:36 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 19 Oct 2009 12:51:36 +0200
Subject: libgnutlsxx link problems
In-Reply-To: <1255790555-28286-1-git-send-email-bkasarov@gmail.com> (Boyan
	Kasarov's message of "Sat, 17 Oct 2009 17:42:33 +0300")
References: <87bpk9f9nb.fsf@mocca.josefsson.org>
	<1255790555-28286-1-git-send-email-bkasarov@gmail.com>
Message-ID: <878wf7hd1j.fsf@mocca.josefsson.org>

Boyan Kasarov <bkasarov at gmail.com> writes:

> Hello,
> I am sending two patches to add symbol visibility support.
>
> [PATCH 1/2] Import lib-symbol-visibility from gnulib
> [PATCH 2/2] Use lib-symbol-visibility for the C++ library

Thanks!  The patch looks good, so I'll push it once your FSF copyright
papers have arrived (if I didn't send these off-list, please remind me).

> The second patch adds the necessary changes as explained in
> lib-symbol-visibility manual to add support for libgnutlsxx. I also
> removed the "local: *;" directive from libgnutlsxx.map, because it is
> no longer needed to hide symbols using it.

I'm not sure, maybe the 'local: *' is still needed: what if you use a
compiler that doesn't support symbol visibility but supports linker
version scripts?  Then 'local: *' would be useful.  Is there any harm in
keeping it?

/Simon




From bkasarov at gmail.com  Mon Oct 19 13:14:24 2009
From: bkasarov at gmail.com (Boyan Kasarov)
Date: Mon, 19 Oct 2009 14:14:24 +0300
Subject: libgnutlsxx link problems
In-Reply-To: <878wf7hd1j.fsf@mocca.josefsson.org>
References: <87bpk9f9nb.fsf@mocca.josefsson.org>
	<1255790555-28286-1-git-send-email-bkasarov@gmail.com>
	<878wf7hd1j.fsf@mocca.josefsson.org>
Message-ID: <1255950864.17001.20.camel@175-58.evo.bg>

Hello,

On Mon, 2009-10-19 at 12:51 +0200, Simon Josefsson wrote:

> I'm not sure, maybe the 'local: *' is still needed: what if you use a
> compiler that doesn't support symbol visibility but supports linker
> version scripts?  Then 'local: *' would be useful.  Is there any harm in
> keeping it?

I agree, there is no harm to keep the 'local: *;' as long as classes are
specified in the correct way in the script. So feel free to cut the
modification in libgnutlsxx.map from the patch.

Boyan






From simon at josefsson.org  Mon Oct 19 14:16:12 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 19 Oct 2009 14:16:12 +0200
Subject: libgnutlsxx link problems
In-Reply-To: <1255950864.17001.20.camel@175-58.evo.bg> (Boyan Kasarov's
	message of "Mon, 19 Oct 2009 14:14:24 +0300")
References: <87bpk9f9nb.fsf@mocca.josefsson.org>
	<1255790555-28286-1-git-send-email-bkasarov@gmail.com>
	<878wf7hd1j.fsf@mocca.josefsson.org>
	<1255950864.17001.20.camel@175-58.evo.bg>
Message-ID: <871vkzh94j.fsf@mocca.josefsson.org>

Boyan Kasarov <bkasarov at gmail.com> writes:

> Hello,
>
> On Mon, 2009-10-19 at 12:51 +0200, Simon Josefsson wrote:
>
>> I'm not sure, maybe the 'local: *' is still needed: what if you use a
>> compiler that doesn't support symbol visibility but supports linker
>> version scripts?  Then 'local: *' would be useful.  Is there any harm in
>> keeping it?
>
> I agree, there is no harm to keep the 'local: *;' as long as classes are
> specified in the correct way in the script. So feel free to cut the
> modification in libgnutlsxx.map from the patch.

Great, thanks.

/Simon




From jpettiss at yahoo.com  Thu Oct 22 18:38:33 2009
From: jpettiss at yahoo.com (Jason Pettiss)
Date: Thu, 22 Oct 2009 09:38:33 -0700 (PDT)
Subject: Missing curly braces in rsa_params::operator= (gnutlsxx.cpp)?
Message-ID: <130711.95185.qm@web110203.mail.gq1.yahoo.com>

I have version 2.8.4 of the source... tried to check the latest in the CVS repository but the CVS server itself seems to be out of disk space?

Anyway it looks like the error check in rsa_params::operator= is missing a code block and will unconditionally throw.

rsa_params & rsa_params::operator=(const rsa_params& src)
{
    rsa_params* dst = new rsa_params;
    int ret;
    ret = gnutls_rsa_params_cpy( dst->params, src.params);
    if (ret < 0)
        delete dst;
    throw(ret);
    return *dst;
}

Probably should have been:

    if (ret < 0) {
        delete dst;
        throw(ret);
    }

--jason


      




From simon at josefsson.org  Fri Oct 23 18:22:38 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 23 Oct 2009 18:22:38 +0200
Subject: Missing curly braces in rsa_params::operator= (gnutlsxx.cpp)?
In-Reply-To: <130711.95185.qm@web110203.mail.gq1.yahoo.com> (Jason Pettiss's
	message of "Thu, 22 Oct 2009 09:38:33 -0700 (PDT)")
References: <130711.95185.qm@web110203.mail.gq1.yahoo.com>
Message-ID: <87iqe62i7l.fsf@mocca.josefsson.org>

Jason Pettiss <jpettiss at yahoo.com> writes:

> I have version 2.8.4 of the source... tried to check the latest in the CVS repository but the CVS server itself seems to be out of disk space?

We haven't used CVS in quite a while, please check instructions on how
to retrieve sources from Git:

https://savannah.gnu.org/git/?group=gnutls

Btw, did you read that we used CVS somewhere?  I may have forgotten to
update some old information.

> Anyway it looks like the error check in rsa_params::operator= is missing a code block and will unconditionally throw.
>
> rsa_params & rsa_params::operator=(const rsa_params& src)
> {
>     rsa_params* dst = new rsa_params;
>     int ret;
>     ret = gnutls_rsa_params_cpy( dst->params, src.params);
>     if (ret < 0)
>         delete dst;
>     throw(ret);
>     return *dst;
> }
>
> Probably should have been:
>
>     if (ret < 0) {
>         delete dst;
>         throw(ret);

Heh.  Fixed, thank you.

/Simon




From jpettiss at yahoo.com  Fri Oct 23 18:38:53 2009
From: jpettiss at yahoo.com (Jason Pettiss)
Date: Fri, 23 Oct 2009 09:38:53 -0700 (PDT)
Subject: Missing curly braces in rsa_params::operator= (gnutlsxx.cpp)?
In-Reply-To: <87iqe62i7l.fsf@mocca.josefsson.org>
Message-ID: <966932.90326.qm@web110204.mail.gq1.yahoo.com>

> We haven't used CVS in quite a while, please check
> instructions on how
> to retrieve sources from Git:
> 
> https://savannah.gnu.org/git/?group=gnutls

Oh thank goodness.  CVS gives me hives.  :)

> Btw, did you read that we used CVS somewhere?  I may
> have forgotten to
> update some old information.

http://josefsson.org/gnutls4win/

"First checkout the files in this directory as follows:

cvs -z3 -d:pserver:anonymous at cvs.savannah.gnu.org:/sources/gnutls co gnutls4win
"

There is a CVS server there, and the ViewCVS link does work... I followed that around to find the libraries I thought I needed.

--jason

--- On Fri, 10/23/09, Simon Josefsson <simon at josefsson.org> wrote:

> From: Simon Josefsson <simon at josefsson.org>
> Subject: Re: Missing curly braces in rsa_params::operator= (gnutlsxx.cpp)?
> To: "Jason Pettiss" <jpettiss at yahoo.com>
> Cc: bug-gnutls at gnu.org
> Date: Friday, October 23, 2009, 11:22 AM
> Jason Pettiss <jpettiss at yahoo.com>
> writes:
> 
> > I have version 2.8.4 of the source... tried to check
> the latest in the CVS repository but the CVS server itself
> seems to be out of disk space?
> 
> We haven't used CVS in quite a while, please check
> instructions on how
> to retrieve sources from Git:
> 
> https://savannah.gnu.org/git/?group=gnutls
> 
> Btw, did you read that we used CVS somewhere?? I may
> have forgotten to
> update some old information.
> 
> > Anyway it looks like the error check in
> rsa_params::operator= is missing a code block and will
> unconditionally throw.
> >
> > rsa_params & rsa_params::operator=(const
> rsa_params& src)
> > {
> >? ???rsa_params* dst = new
> rsa_params;
> >? ???int ret;
> >? ???ret = gnutls_rsa_params_cpy(
> dst->params, src.params);
> >? ???if (ret < 0)
> >? ? ? ???delete dst;
> >? ???throw(ret);
> >? ???return *dst;
> > }
> >
> > Probably should have been:
> >
> >? ???if (ret < 0) {
> >? ? ? ???delete dst;
> >? ? ? ???throw(ret);
> 
> Heh.? Fixed, thank you.
> 
> /Simon
> 


      




From simon at josefsson.org  Fri Oct 23 18:45:47 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 23 Oct 2009 18:45:47 +0200
Subject: Missing curly braces in rsa_params::operator= (gnutlsxx.cpp)?
In-Reply-To: <966932.90326.qm@web110204.mail.gq1.yahoo.com> (Jason Pettiss's
	message of "Fri, 23 Oct 2009 09:38:53 -0700 (PDT)")
References: <87iqe62i7l.fsf@mocca.josefsson.org>
	<966932.90326.qm@web110204.mail.gq1.yahoo.com>
Message-ID: <8763a62h50.fsf@mocca.josefsson.org>

Jason Pettiss <jpettiss at yahoo.com> writes:

>> Btw, did you read that we used CVS somewhere?  I may
>> have forgotten to
>> update some old information.
>
> http://josefsson.org/gnutls4win/
>
> "First checkout the files in this directory as follows:
>
> cvs -z3 -d:pserver:anonymous at cvs.savannah.gnu.org:/sources/gnutls co gnutls4win
> "
>
> There is a CVS server there, and the ViewCVS link does work... I
> followed that around to find the libraries I thought I needed.

Yeah, that isn't the GnuTLS source code, it is the source code (and
binaries...) for building GnuTLS under Windows.  That is in CVS because
it is just a Makefile and some other files, and I haven't had time to
migrate it.

/Simon




From jpettiss at yahoo.com  Fri Oct 23 18:54:29 2009
From: jpettiss at yahoo.com (Jason Pettiss)
Date: Fri, 23 Oct 2009 09:54:29 -0700 (PDT)
Subject: Missing curly braces in rsa_params::operator= (gnutlsxx.cpp)?
In-Reply-To: <8763a62h50.fsf@mocca.josefsson.org>
Message-ID: <518574.8372.qm@web110217.mail.gq1.yahoo.com>

> Yeah, that isn't the GnuTLS source code, it is the source
> code (and binaries...) for building GnuTLS under Windows.
> That is in CVS because it is just a Makefile and some other
> files, and I haven't had time to migrate it.

Sorry if this is getting off topic but are there source changes necessary to make that happen (and if so, how intense are they?), or is it really just build tweaks?  

Also if I need to do some work to get it rebuilt & running should I comment directly to you, or is there a specific "gnutls4win" mailing list?

Thanks,

--jason



      




From simon at josefsson.org  Fri Oct 23 19:00:00 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 23 Oct 2009 19:00:00 +0200
Subject: Missing curly braces in rsa_params::operator= (gnutlsxx.cpp)?
In-Reply-To: <518574.8372.qm@web110217.mail.gq1.yahoo.com> (Jason Pettiss's
	message of "Fri, 23 Oct 2009 09:54:29 -0700 (PDT)")
References: <518574.8372.qm@web110217.mail.gq1.yahoo.com>
Message-ID: <87zl7i11wv.fsf@mocca.josefsson.org>

Jason Pettiss <jpettiss at yahoo.com> writes:

>> Yeah, that isn't the GnuTLS source code, it is the source
>> code (and binaries...) for building GnuTLS under Windows.
>> That is in CVS because it is just a Makefile and some other
>> files, and I haven't had time to migrate it.
>
> Sorry if this is getting off topic but are there source changes
> necessary to make that happen (and if so, how intense are they?), or
> is it really just build tweaks?

No, CVS is just used as a transport mechanism here.  One (of few)
advantage with CVS over Git is that you can have multiple repositories
in a CVS root -- to get the same with Git, I would need to create a new
savannah project for the gnutls4win files and that is really too much
overhead for a few files.

Also, the binaries stored in CVS for gnutls4win should really not be in
CVS, the savannah admins doesn't like that.  I'm not sure where to host
them, though...  I guess they could be uploaded to alpha.gnu.org though.

> Also if I need to do some work to get it rebuilt & running should I
> comment directly to you, or is there a specific "gnutls4win" mailing
> list?

It is fine to keep it on this list.

/Simon




From dkg at fifthhorseman.net  Fri Oct 23 20:52:32 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 23 Oct 2009 14:52:32 -0400
Subject: gnutls test server X.509 certificate expired
Message-ID: <4AE1FB70.5040103@fifthhorseman.net>

Hi folks--

The GnuTLS test server (test.gnutls.org) uses an X.509 certificate which
appears to have expired last year (on 2008-04-17).

Could that be updated for people who want to test connections to it?

Thanks,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20091023/35b4d888/attachment.pgp>

From kreijack at gmail.com  Fri Oct 23 19:46:12 2009
From: kreijack at gmail.com (Goffredo Baroncelli)
Date: Fri, 23 Oct 2009 19:46:12 +0200
Subject: Fatal error: Key usage violation in certificate has been detected
Message-ID: <200910231946.13290.kreijack@inwind.it>

Hi all,

I used freepops [*] to download my email from my provider (www.alice.it). If 
freepops uses the https protocol I get the following error

   *** Fatal error: Key usage violation in certificate has been detected.
   *** Handshake has failed

After googling, I discovered that:
- freepops uses the GNU tls library
- the error message seems to be an GNU tls library error
- the problem is also reproducible with the following command 

   ghigo at venice:~$ gnutls-cli -p 443 authsrs.alice.it
   Resolving 'authsrs.alice.it'...
   Connecting to '81.74.238.31:443'...
   *** Fatal error: Key usage violation in certificate has been detected.
   *** Handshake has failed
   GNUTLS ERROR: Key usage violation in certificate has been detected.

Note: "authsrs.alice.it" is the server resposible for the user authentication 
of the webmail interface. My idea is that there is a problem between the 
authsrs.alice.it https certificate and gnutls, that causes the freepops 
failure.

I am not an expert about the certificates. Looking in the gnutls mailing list, 
I found some similar bugs report, and in these cases the conclusions were an 
incorrect certificate.  Could someone help me to confirm that the problem is 
the certificate even in this case?
And if it is the case (and I think that it IS the case), which possibles 
workarounds exist ?

TIA & BR
G.Baroncelli.

NB: please cc'me in the reply, because I am not subscribed to the mailing 
list.

[*] FreePOPs allows access to the most varied resources through the POP3 
protocol. Mainly, it can be used to download mail from a webmail interface, 
when it is not available a pop3 protocol.

-- 
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijackATinwind.it>
Key fingerprint = 4769 7E51 5293 D36C 814E  C054 BF04 F161 3DC5 0512




From dkg at fifthhorseman.net  Fri Oct 23 23:09:27 2009
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 23 Oct 2009 17:09:27 -0400
Subject: Fatal error: Key usage violation in certificate has been
	detected
In-Reply-To: <200910231946.13290.kreijack@inwind.it>
References: <200910231946.13290.kreijack@inwind.it>
Message-ID: <4AE21B87.3040204@fifthhorseman.net>

On 10/23/2009 01:46 PM, Goffredo Baroncelli wrote:
> Could someone help me to confirm that the problem is 
> the certificate even in this case?

here's a quick way to check with openssl (sorry i'm not using gnutls tools
-- if someone wants to show the same thing with gnutls tools i'd gladly
learn).

0 dkg at pip:~$ echo | openssl s_client -connect google.com:443 2>/dev/null | openssl x509 -noout -text  | grep -i -A1 usage 
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
0 dkg at pip:~$ echo | openssl s_client -connect authsrs.alice.it:443 2>/dev/null | openssl x509 -noout -text  | grep -i -A1 usage 
            X509v3 Key Usage: 
                Key Encipherment
0 dkg at pip:~$ 

note that google's certificate allows "TLS Web Server Authentication",
but authsrs.alice.it's certificate does not.  I think that's the root
of your problem.

> And if it is the case (and I think that it IS the case), which possibles 
> workarounds exist ?

Maybe there's a GnuTLS priority string you can set to disable usage flag
checking as a workaround?  if there is, i couldn't find it here:

 http://www.gnu.org/software/gnutls/manual/html_node/Core-functions.html#gnutls_priority_set

seems like they should reall use a certificate with the right usage 
flags set, though.

hth,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20091023/34f23133/attachment.pgp>

From n.mavrogiannopoulos at gmail.com  Sat Oct 24 03:11:42 2009
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sat, 24 Oct 2009 04:11:42 +0300
Subject: Fatal error: Key usage violation in certificate has been
	detected
In-Reply-To: <4AE21B87.3040204@fifthhorseman.net>
References: <200910231946.13290.kreijack@inwind.it>
	<4AE21B87.3040204@fifthhorseman.net>
Message-ID: <4AE2544E.4070709@gmail.com>

Daniel Kahn Gillmor wrote:

>> And if it is the case (and I think that it IS the case), which possibles 
>> workarounds exist ?
> 
> Maybe there's a GnuTLS priority string you can set to disable usage flag
> checking as a workaround?  if there is, i couldn't find it here:
> 
>  http://www.gnu.org/software/gnutls/manual/html_node/Core-functions.html#gnutls_priority_set
> 
> seems like they should reall use a certificate with the right usage 
> flags set, though.

I can see that the certificate allow:
            X509v3 Key Usage:
                Key Encipherment

and that means it will issue key usage violation for all ciphersuites
except for RSA (not even DHE-RSA, just RSA). Thus the server sending
this certificate must be configured to disable all other ciphersuites.

regards,
Nikos




From nmav at gnutls.org  Sat Oct 24 05:03:15 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 24 Oct 2009 06:03:15 +0300
Subject: TLS 1.2 server
In-Reply-To: <87zl8buyc2.fsf@mocca.josefsson.org>
References: <87iqf1p592.fsf@broken.deisui.org>	<87r5tp56c4.fsf@mocca.josefsson.org>	<87ske44pfy.fsf@mocca.josefsson.org>	<87pr98eha4.fsf@broken.deisui.org>	<87eipo4jgc.fsf@mocca.josefsson.org>	<87ljjwdv8c.fsf@broken.deisui.org>
	<87zl8buyc2.fsf@mocca.josefsson.org>
Message-ID: <4AE26E73.4070907@gnutls.org>

Simon Josefsson wrote:

> I'll do a release shortly, so we can more easily test how TLS 1.2 works
> in some real applications now that it is the default.

Hi,
 I've checked TLS 1.2 recently, and as far as I understand the only part
missing is support for SignatureAndHashAlgorithm in Certificate Request,
as well as the extension 'signature_algorithms'. Am I correct? Is there
something else missing?

As I see it for the support of SignatureAndHashAlgorithm in Certificate
Request the handshake must be changed (for the client at least), to hold
all handshake messages and calculate the hash based on what the server
sent. This is tricky since if implemented only for TLS 1.2 we have a
code full of ifs that will be impossible to read. I'll see whether I can
make something for it the next few days.

regards,
Nikos




From simon at josefsson.org  Mon Oct 26 10:24:09 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 26 Oct 2009 10:24:09 +0100
Subject: TLS 1.2 server
In-Reply-To: <4AE26E73.4070907@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sat, 24 Oct 2009 06:03:15 +0300")
References: <87iqf1p592.fsf@broken.deisui.org>
	<87r5tp56c4.fsf@mocca.josefsson.org>
	<87ske44pfy.fsf@mocca.josefsson.org>
	<87pr98eha4.fsf@broken.deisui.org>
	<87eipo4jgc.fsf@mocca.josefsson.org>
	<87ljjwdv8c.fsf@broken.deisui.org>
	<87zl8buyc2.fsf@mocca.josefsson.org> <4AE26E73.4070907@gnutls.org>
Message-ID: <873a56cxty.fsf@mocca.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Simon Josefsson wrote:
>
>> I'll do a release shortly, so we can more easily test how TLS 1.2 works
>> in some real applications now that it is the default.
>
> Hi,
>  I've checked TLS 1.2 recently, and as far as I understand the only part
> missing is support for SignatureAndHashAlgorithm in Certificate Request,
> as well as the extension 'signature_algorithms'. Am I correct? Is there
> something else missing?

That's missing, right.  Client-authentication with TLS 1.2 and
certificate signing callbacks doesn't seem to be working right either,
the sign callback receives a string of size 36 (SHA1+MD5) but it should
be a PKCS#1 SHA1/SHA2 structure.

> As I see it for the support of SignatureAndHashAlgorithm in Certificate
> Request the handshake must be changed (for the client at least), to hold
> all handshake messages and calculate the hash based on what the server
> sent. This is tricky since if implemented only for TLS 1.2 we have a
> code full of ifs that will be impossible to read. I'll see whether I can
> make something for it the next few days.

Yeah, I know. :-(

My plan was to create some helper functions to do the hashing, and set
up separate hashing for all of MD5, SHA-1, SHA-2 and let the later code
figure out which hash to actually use.  This is wasteful, but that is
the TLS 1.2 design.

/Simon




From simon at josefsson.org  Mon Oct 26 13:41:33 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 26 Oct 2009 13:41:33 +0100
Subject: gnutls 2.8.5 release candidate: please test!
Message-ID: <87tyxm9vk2.fsf@mocca.josefsson.org>

I'm planning to release 2.8.5 shortly.  It will be the same as

http://daily.josefsson.org/gnutls-2.8/gnutls-2.8-20091026.tar.bz2

unless you holler.  In other words: please test the above as if it were
the next stable release!

/Simon




From ametzler at downhill.at.eu.org  Mon Oct 26 14:26:16 2009
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 26 Oct 2009 14:26:16 +0100
Subject: Timebombs in testsuite
Message-ID: <20091026132616.GF3347@downhill.g.la>

Hello,

I have just seen that 2.8.4 cannot be built (well checked) successfull
anymore, since a certificate expired 2009-10-19. (This is fixed in
2.8.5 prerelease). I think this is the third time something like this
happened, and browsing over the buildlog the next instances will happen
soon:

Certificate 0: subject `C=US,ST=New Jersey,L=Weehawken,O=Citigroup,OU=whg-oak6,CN=www.citibank.com', issuer `O=VeriSign Trust Network,OU=VeriSign\, Inc.,OU=VeriSign International Server CA - Class 3,OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign', RSA key 1024 bits, signed using RSA-SHA, activated `2008-08-29 00:00:00 UTC', expires `2010-08-29 23:59:59 UTC', SHA-1 fingerprint `8b410d9cf13f191596a65f1f77580ddfa37aba49'

        Certificate 1: subject `O=VeriSign Trust Network,OU=VeriSign\, Inc.,OU=VeriSign International Server CA - Class 3,OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 1024 bits, signed using RSA-SHA, activated `1997-04-17 00:00:00 UTC', expires `2011-10-24 23:59:59 UTC', SHA-1 fingerprint `c2f0087d01e686053a4d633e7e70d4ef65c2cc4f'
        Adding certificate 2...done

        Certificate 0: subject `CN=fry.serverama.de', issuer `O=CAcert Inc.,OU=http://www.CAcert.org,CN=CAcert Class 3 Root', RSA key 1024 bits, signed using RSA-SHA, activated `2009-01-16 22:29:47 UTC', expires `2011-01-16 22:29:47 UTC', SHA-1 fingerprint `7d18c5e1f1fc350458b499ee5d95bbf41274597d'
        Adding certificate 1...done

        Certificate 1: subject `C=US,O=VeriSign\, Inc.,OU=VeriSign Trust Network,OU=Terms of use at https://www.verisign.com/rpa (c)05,CN=VeriSign Class 3 Secure Server CA', issuer `C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority', RSA key 2048 bits, signed using RSA-SHA, activated `2005-01-19 00:00:00 UTC', expires `2015-01-18 23:59:59 UTC', SHA-1 fingerprint `188590e94878478e33b6194e59fbbb28ff0888d5'

Can these be handled proactively before they actually break?

thanks, cu andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'




From nmav at gnutls.org  Wed Oct 28 09:55:13 2009
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 28 Oct 2009 10:55:13 +0200
Subject: Bootstrap parallel connections using session resume ?
In-Reply-To: <4AE7F1F1.4040303@nict.go.jp>
References: <4AE7D03F.1050803@nict.go.jp> <4AE7E7A9.8090405@gnutls.org>
	<4AE7F1F1.4040303@nict.go.jp>
Message-ID: <4AE806F1.1020400@gnutls.org>

Sebastien Decugis wrote:

> [talking about the client side here]
> Ok, so if I understand correctly the transport parameters are not stored
> inside the data returned by gnutls_session_get_data2, right ?

Indeed.

> What about the credentials (priority, CA, key, ...) ? Do I have to set
> them before I set the session data, or does this operation set them for
> me (so I don't have to do it at all ?)

Those are needed to be set since the server might decide not to resume.
If he doesn't typically they are ignored.

>>> I don't know if it is relevant, my different channels are actually the
>>> same socket object, but different SCTP streams, and I use customs
>>> push/pull functions to mux/demux the messages. I can send my code
>>> showing the actual implementation if you are interested.
>>>     
>> Actually I'm interested in the implementation. Would you be interested
>> to write few words and example push/pull functions on how to use gnutls
>> over SCTP, to add in the manual? It can be something like the examples
>> there:
>> http://www.gnu.org/software/gnutls/manual/html_node/Client-examples.html#Client-examples
>>   
> Well, I can at least send you pointers to my code with some explanation
> so that you get an idea of how I am doing it, and then if you're still
> interested I'll try to extract the parts interesting for the manual or
> build a demonstration sample. 

That would be perfect. Please send me.

>>> So far, I was not able to use multithreading and resuming efficiently.
>>> Most of the sessions fail to resume and fallback to a full handshake. I
>>> have seen also some strange behavior (store operation with the same key
>>> but different data) so I am wondering if this whole mechanism is really
>>> possible with GnuTLS. 
>>>     
>> Was this on the server side or client side? If it is on client side, you
>> should note that you need not and better shouldn't keep the session data
>> of a resumed session. Just use the session data of the original one or
>> the last on that didn't success in resuming. If this is not the case
>> please let me know of the details as well.
>>   
> Well, currently I am using the db_* functions only on the server side,
> my understanding was that they are not used on the client side, right ?
> On the client side, I only get the data of my primary (handshaken)
> session and then set this data in all other sessions before handshake.

Correct.

> Anyway for some reason that I don't understand, it seems that now it
> started to work properly, and I see successfully resumed sessions -- I
> really don't know what I changed in my code for this result -- but I am
> not complaining ^^

I'm quite curious on the previous behavior, where you noticed the same
session ID being save twice in server side. It seems the server was
wrongly trying to overwrite the initial session parameters with the
resumed one. The attached patch should fix what you have noticed.
(what you see now might be a timing issue if all the clients connect
before the server has overwritten the initial parameters).


regards,
Nikos

-------------- next part --------------
A non-text attachment was scrubbed...
Name: resuming.patch
Type: text/x-patch
Size: 1165 bytes
Desc: not available
URL: </pipermail/attachments/20091028/01ca3adb/attachment.bin>

From sdecugis at nict.go.jp  Wed Oct 28 10:46:01 2009
From: sdecugis at nict.go.jp (Sebastien Decugis)
Date: Wed, 28 Oct 2009 18:46:01 +0900
Subject: Bootstrap parallel connections using session resume ?
In-Reply-To: <4AE806F1.1020400@gnutls.org>
References: <4AE7D03F.1050803@nict.go.jp> <4AE7E7A9.8090405@gnutls.org>
	<4AE7F1F1.4040303@nict.go.jp> <4AE806F1.1020400@gnutls.org>
Message-ID: <4AE812D9.3020401@nict.go.jp>

Hi again Nikos,

>> Well, I can at least send you pointers to my code with some explanation
>> so that you get an idea of how I am doing it, and then if you're still
>> interested I'll try to extract the parts interesting for the manual or
>> build a demonstration sample. 
>>     
>
> That would be perfect. Please send me.
>   
Ok, I am sending this in private mail, to avoid spamming the list :)

>> Anyway for some reason that I don't understand, it seems that now it
>> started to work properly, and I see successfully resumed sessions -- I
>> really don't know what I changed in my code for this result -- but I am
>> not complaining ^^
>>     
>
> I'm quite curious on the previous behavior, where you noticed the same
> session ID being save twice in server side. It seems the server was
> wrongly trying to overwrite the initial session parameters with the
> resumed one. The attached patch should fix what you have noticed.
> (what you see now might be a timing issue if all the clients connect
> before the server has overwritten the initial parameters).
>   
Well, I might have used some un-initialized pointers at some point when
I saw those traces, so maybe it's better to ignore them... I'll
investigate more seriously if I run into them again.
Thank you for the patch, but I am using a pre-compiled GnuTLS library
currently, and I would prefer to stick with it if I can...

Best regards,
Sebastien.




From simon at josefsson.org  Thu Oct 29 08:50:50 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 29 Oct 2009 08:50:50 +0100
Subject: testing gcrypt thread-safety
In-Reply-To: <4AE8B7EA.50603@fifthhorseman.net> (Daniel Kahn Gillmor's message
	of "Wed, 28 Oct 2009 17:30:18 -0400")
References: <4AE8B7EA.50603@fifthhorseman.net>
Message-ID: <87my3ak59h.fsf@mocca.josefsson.org>

Taken from the libgcrypt list:

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> I don't see any code in the tests/ directory which exercises this stuff,
> but i'd be willing to write a test if anyone has a particular feature
> that they think would be worth testing against threadsafe initialization.

It would be useful to have a threaded self-test in GnuTLS too -- if you
have a minimal test case that initializes gcrypt and does some gcrypt
testing in two (or more) parallel threads, it would be great if you
could contribute that to GnuTLS too, and I can adapt it to do TLS
sessions in each thread.

I'm thinking it would be nice to a have a threaded version of
tests/mini.c which does in-process TLS negotiations.  It could set up
two threads that talked to each other with its own push/pull functions
protected by a mutex.

/Simon




From simon at josefsson.org  Thu Oct 29 09:02:34 2009
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 29 Oct 2009 09:02:34 +0100
Subject: Timebombs in testsuite
In-Reply-To: <20091026132616.GF3347@downhill.g.la> (Andreas Metzler's message
	of "Mon, 26 Oct 2009 14:26:16 +0100")
References: <20091026132616.GF3347@downhill.g.la>
Message-ID: <87hbtik4px.fsf@mocca.josefsson.org>

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> Hello,
>
> I have just seen that 2.8.4 cannot be built (well checked) successfull
> anymore, since a certificate expired 2009-10-19. (This is fixed in
> 2.8.5 prerelease). I think this is the third time something like this
> happened, and browsing over the buildlog the next instances will happen
> soon:
...
> Can these be handled proactively before they actually break?

Good point.  I'm thinking of using something like the patch below.
Thoughts?

/Simon

diff --git a/tests/chainverify.c b/tests/chainverify.c
index 19b27eb..13d4710 100644
--- a/tests/chainverify.c
+++ b/tests/chainverify.c
@@ -32,6 +32,21 @@
 #include <gnutls/gnutls.h>
 #include <gnutls/x509.h>
 
+/* GnuTLS internally calls time() to find out the current time when
+   verifying certificates.  To avoid a time bomb, we hard code the
+   current time.  This should work fine on systems where the library
+   call to time is resolved at run-time.  */
+time_t
+time (time_t *t)
+{
+  time_t then = 1256803113;
+
+  if (t)
+    *t = then;
+
+  return then;
+}
+
 /* *INDENT-OFF* */
 
 /* Triggers incorrect verification success on older versions */