From nmav at gnutls.org  Sat Jun  1 13:26:06 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 01 Jun 2013 13:26:06 +0200
Subject: [gnutls-help] gnutls 3.2.1
Message-ID: <51A9DA4E.9020004@gnutls.org>

Hello,
 I've just released gnutls 3.2.1. This is a bug-fix release on the
current stable branch.

* Version 3.2.1 (released 2013-06-01)

** libgnutls: Allow ECC when in SSL 3.0 to work-around a bug in certain
openssl versions.

** libgnutls: Fixes in interrupted function resumption. Report
and patch by Tim Kosse.

** libgnutls: Corrected issue when receiving client hello verify
requests in DTLS.

** libgnutls: Fixes in DTLS record overhead size calculations.

** libgnutls: gnutls_handshake_get_last_in() was fixed. Reported
by Mann Ern Kang.

** API and ABI modifications:
gnutls_session_set_id: Added


Getting the Software
====================

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>.  A list of GnuTLS mirrors can be
found at <http://www.gnutls.org/download.html>.

Here are the XZ and LZIP compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.1.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.1.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.1.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.1.tar.lz.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid                  Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos


From nmav at gnutls.org  Sat Jun  1 13:21:41 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 01 Jun 2013 13:21:41 +0200
Subject: [gnutls-help] gnutls 3.0.30
Message-ID: <51A9D945.70501@gnutls.org>

Hello,
 I've just released gnutls 3.0.30. This is a bug-fix release on the
previous stable branch.

* Version 3.0.30 (released 2013-06-01)

** libgnutls: Allow ECC when in SSL 3.0 to work-around a bug in certain
openssl versions.

** libgnutls: When in compatibility mode allow for a wrong version in
the RSA PMS.

** libgnutls: gnutls_handshake_get_last_in() was fixed. Reported
by Mann Ern Kang.

** API and ABI modifications:
No changes since last version.



Getting the Software
====================

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>.  A list of GnuTLS mirrors can be
found at <http://www.gnutls.org/download.html>.

Here are the XZ and LZIP compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-3.0.30.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-3.0.30.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-3.0.30.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-3.0.30.tar.lz.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid                  Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos


From nmav at gnutls.org  Sat Jun  1 13:23:35 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 01 Jun 2013 13:23:35 +0200
Subject: [gnutls-help] gnutls 3.1.12
Message-ID: <51A9D9B7.7030809@gnutls.org>

Hello,
 I've just released gnutls 3.1.12. This is a bug-fix release on the 3.1
stable branch.

* Version 3.1.12 (released 2013-06-01)

** libgnutls: Allow ECC when in SSL 3.0 to work-around a bug in certain
openssl versions.

** libgnutls: Fixes in interrupted function resumption. Report
and patch by Tim Kosse.

** libgnutls: gnutls_handshake_get_last_in() was fixed. Reported
by Mann Ern Kang.

** API and ABI modifications:
No changes since last version.


Getting the Software
====================

GnuTLS may be downloaded directly from
<ftp://ftp.gnutls.org/gcrypt/gnutls/>.  A list of GnuTLS mirrors can be
found at <http://www.gnutls.org/download.html>.

Here are the XZ and LZIP compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.12.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.12.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.12.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.12.tar.lz.sig

Note that it has been signed with my openpgp key:
pub   3104R/96865171 2008-05-04 [expires: 2028-04-29]
uid                  Nikos Mavrogiannopoulos <nmav <at> gnutls.org>
uid                  Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at>
gmail.com>
sub   2048R/9013B842 2008-05-04 [expires: 2018-05-02]
sub   2048R/1404A91D 2008-05-04 [expires: 2018-05-02]

regards,
Nikos


From cloos at jhcloos.com  Mon Jun  3 00:49:59 2013
From: cloos at jhcloos.com (James Cloos)
Date: Sun, 02 Jun 2013 18:49:59 -0400
Subject: [gnutls-help] Problem with https://archive.org
In-Reply-To: <20130529201728.GR6512@vicerveza.homeunix.net>
 (=?iso-8859-1?Q?=22Llu=EDs?= Batlle i
 Rossell"'s message of "Wed, 29 May 2013 22:17:28 +0200")
References: <20130517210014.GU5577@vicerveza.homeunix.net>
 <51A6533C.3060903@gnutls.org>
 <20130529201728.GR6512@vicerveza.homeunix.net>
Message-ID: <m3d2s43z67.fsf@carbon.jhcloos.org>

>>>>> "LBiR" == Llu?s Batlle i Rossell <viric at viric.name> writes:

LBiR> Is there anything I can do (env vars, config files) to tweak that
LBiR> gnutls behaviour so it could connect with a reasonable ciphersuite?

Upgrade to 3.2.1.  With that, one now gets:

:; gnutls-cli archive.org
... ... ... ...
- Description: (SSL3.0-PKIX)-(ECDHE-RSA-SECP256R1)-(AES-128-CBC)-(SHA1)
... ... ... ...
- Handshake was completed

- Simple Client Mode:


-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6


From viric at viric.name  Mon Jun  3 12:18:32 2013
From: viric at viric.name (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell)
Date: Mon, 3 Jun 2013 12:18:32 +0200
Subject: [gnutls-help] Problem with https://archive.org
In-Reply-To: <m3d2s43z67.fsf@carbon.jhcloos.org>
References: <20130517210014.GU5577@vicerveza.homeunix.net>
 <51A6533C.3060903@gnutls.org>
 <20130529201728.GR6512@vicerveza.homeunix.net>
 <m3d2s43z67.fsf@carbon.jhcloos.org>
Message-ID: <20130603101832.GG14616@vicerveza.homeunix.net>

On Sun, Jun 02, 2013 at 06:49:59PM -0400, James Cloos wrote:
> >>>>> "LBiR" == Llu?s Batlle i Rossell <viric at viric.name> writes:
> 
> LBiR> Is there anything I can do (env vars, config files) to tweak that
> LBiR> gnutls behaviour so it could connect with a reasonable ciphersuite?
> 
> Upgrade to 3.2.1.  With that, one now gets:
> 
> :; gnutls-cli archive.org
> ... ... ... ...
> - Description: (SSL3.0-PKIX)-(ECDHE-RSA-SECP256R1)-(AES-128-CBC)-(SHA1)
> ... ... ... ...
> - Handshake was completed
> 
> - Simple Client Mode:

Right, now wget works perfect, thank you!


From viric at viric.name  Mon Jun  3 15:01:55 2013
From: viric at viric.name (=?iso-8859-1?Q?Llu=EDs?= Batlle i Rossell)
Date: Mon, 3 Jun 2013 15:01:55 +0200
Subject: [gnutls-help] Problem with https://archive.org
In-Reply-To: <20130603101832.GG14616@vicerveza.homeunix.net>
References: <20130517210014.GU5577@vicerveza.homeunix.net>
 <51A6533C.3060903@gnutls.org>
 <20130529201728.GR6512@vicerveza.homeunix.net>
 <m3d2s43z67.fsf@carbon.jhcloos.org>
 <20130603101832.GG14616@vicerveza.homeunix.net>
Message-ID: <20130603130155.GJ14616@vicerveza.homeunix.net>

On Mon, Jun 03, 2013 at 12:18:32PM +0200, Llu?s Batlle i Rossell wrote:
> On Sun, Jun 02, 2013 at 06:49:59PM -0400, James Cloos wrote:
> > >>>>> "LBiR" == Llu?s Batlle i Rossell <viric at viric.name> writes:
> > 
> > LBiR> Is there anything I can do (env vars, config files) to tweak that
> > LBiR> gnutls behaviour so it could connect with a reasonable ciphersuite?
> > 
> > Upgrade to 3.2.1.  With that, one now gets:
> > 
> > :; gnutls-cli archive.org
> > ... ... ... ...
> > - Description: (SSL3.0-PKIX)-(ECDHE-RSA-SECP256R1)-(AES-128-CBC)-(SHA1)
> > ... ... ... ...
> > - Handshake was completed
> > 
> > - Simple Client Mode:
> 
> Right, now wget works perfect, thank you!

One note: for 3.2.1, a test fails on i686: pem-decoding
http://hydra.nixos.org/build/5222124/nixlog/1/tail-reload

It looks like related to a date limit on 32-bit timestamps. On x86_64 it works
fine.

3.1.12 works fine.

Thank you,
Llu?s.


From n.mavrogiannopoulos at gmail.com  Mon Jun  3 21:23:40 2013
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 03 Jun 2013 21:23:40 +0200
Subject: [gnutls-help] Problem with https://archive.org
In-Reply-To: <20130603130155.GJ14616@vicerveza.homeunix.net>
References: <20130517210014.GU5577@vicerveza.homeunix.net>
 <51A6533C.3060903@gnutls.org> <20130529201728.GR6512@vicerveza.homeunix.net>
 <m3d2s43z67.fsf@carbon.jhcloos.org>
 <20130603101832.GG14616@vicerveza.homeunix.net>
 <20130603130155.GJ14616@vicerveza.homeunix.net>
Message-ID: <51ACED3C.4010609@gmail.com>

On 06/03/2013 03:01 PM, Llu?s Batlle i Rossell wrote:

>>> :; gnutls-cli archive.org
>>> ... ... ... ...
>>> - Description: (SSL3.0-PKIX)-(ECDHE-RSA-SECP256R1)-(AES-128-CBC)-(SHA1)
>>> ... ... ... ...
>>> - Handshake was completed
>>>
>>> - Simple Client Mode:
>>
>> Right, now wget works perfect, thank you!
> 
> One note: for 3.2.1, a test fails on i686: pem-decoding
> http://hydra.nixos.org/build/5222124/nixlog/1/tail-reload
> 
> It looks like related to a date limit on 32-bit timestamps. On x86_64 it works
> fine.


Thanks. It seems that this was reported few days ago. A fix is already
in the repository but the bug is on the testsuite so you can ignore it.

regards,
Nikos



From sdecugis at freediameter.net  Tue Jun  4 12:10:47 2013
From: sdecugis at freediameter.net (Sebastien Decugis)
Date: Tue, 4 Jun 2013 18:10:47 +0800
Subject: [gnutls-help] DLTS/SCTP (RFC6083) support?
Message-ID: <006801ce610b$cb7a0870$626e1950$@net>

Hello,

I would like to know if anyone has implemented DTLS over SCTP with GnuTLS, or at least had a look at RFC6083 ?
Would you have any advice about the amount of work that will be required to support this mechanism ?

Thank you in advance for any information!
Best regards,
S?bastien






From marco.maggi-ipsu at poste.it  Thu Jun  6 21:19:50 2013
From: marco.maggi-ipsu at poste.it (Marco Maggi)
Date: Thu, 06 Jun 2013 21:19:50 +0200
Subject: [gnutls-help] on finding nettle under /usr/local rather than
	under /usr (GNU+Linux 64-bit system)
In-Reply-To: <CAJU7zaKQH7YBFBQk2kvD9vXK+UZ25GwoOUS+mrr6iJyZs3z6FQ@mail.gmail.com>
 (Nikos  Mavrogiannopoulos's  message of  "Fri,  31  May 2013  13:16:28
 +0200")
References: <87obbslpkq.fsf@governatore.luna>
 <CAJU7zaJLpy2=-1_MO+GPgLLNPZVQmwPFBaDVXHfH+dsV55p3Sw@mail.gmail.com>
 <87li6vqumc.fsf@governatore.luna>
 <CAJU7zaKQH7YBFBQk2kvD9vXK+UZ25GwoOUS+mrr6iJyZs3z6FQ@mail.gmail.com>
Message-ID: <87r4gf59nt.fsf@governatore.luna>

Nikos Mavrogiannopoulos wrote:
> That's pretty strange. Did you run ldconfig on your system (and does
> its configuration include /usr/local/lib)? I'd expect that the latest
> library would be used.

Sorry for  the very late  reply and  for this very  long message.
Unfortunately Gnutls 3.2.1 still does not work.  To recapitulate:

* I have the libraries:

    $ ls -1 \
         /usr/lib64/libgmp.so \
         /usr/lib64/libnettle.so \
         /usr/lib64/libhogweed.so \
         /usr/lib64/libtasn1.so
    /usr/lib64/libgmp.so
    /usr/lib64/libhogweed.so
    /usr/lib64/libnettle.so
    /usr/lib64/libtasn1.so

    $ ls -1 \
         /usr/local/lib/libgmp.so \
         /usr/local/lib/libnettle.so \
         /usr/local/lib/libhogweed.so \
         /usr/local/lib/libtasn1.so
    /usr/local/lib/libgmp.so
    /usr/local/lib/libhogweed.so
    /usr/local/lib/libnettle.so
    /usr/local/lib/libtasn1.so

* I have the ld config file

    $ cat /etc/ld.so.conf
    /usr/local/lib
    /usr/local/lib64
    ...

  and see the libraries:

    $ /sbin/ldconfig -p | grep '\(gmp\|tasn1\|nettle\|hogweed\)'
    libtasn1.so.6 (libc6,x86-64) => /usr/local/lib/libtasn1.so.6
    libtasn1.so.3 (libc6,x86-64) => /usr/lib64/libtasn1.so.3
    libtasn1.so (libc6,x86-64) => /usr/local/lib/libtasn1.so
    libtasn1.so (libc6,x86-64) => /usr/lib64/libtasn1.so
    libnettle.so.4 (libc6,x86-64) => /usr/local/lib/libnettle.so.4
    libnettle.so.4 (libc6,x86-64) => /usr/lib64/libnettle.so.4
    libnettle.so (libc6,x86-64) => /usr/local/lib/libnettle.so
    libnettle.so (libc6,x86-64) => /usr/lib64/libnettle.so
    libhogweed.so.2 (libc6,x86-64) => /usr/local/lib/libhogweed.so.2
    libhogweed.so.2 (libc6,x86-64) => /usr/lib64/libhogweed.so.2
    libhogweed.so (libc6,x86-64) => /usr/local/lib/libhogweed.so
    libhogweed.so (libc6,x86-64) => /usr/lib64/libhogweed.so
    libgmpxx.so.4 (libc6,x86-64) => /usr/lib64/libgmpxx.so.4
    libgmpxx.so (libc6,x86-64) => /usr/lib64/libgmpxx.so
    libgmp.so.10 (libc6,x86-64) => /usr/local/lib/libgmp.so.10
    libgmp.so.10 (libc6,x86-64) => /usr/lib64/libgmp.so.10
    libgmp.so.3 (libc6,x86-64) => /usr/lib64/libgmp.so.3
    libgmp.so (libc6,x86-64) => /usr/local/lib/libgmp.so
    libgmp.so (libc6,x86-64) => /usr/lib64/libgmp.so

* I prepare the environment:

    $ export LD_LIBRARY_PATH=
    $ export LD_RUN_PATH=

* I see:

    $ ldd /usr/local/lib/libhogweed.so | grep nettle
    libnettle.so.4 => /usr/local/lib/libnettle.so.4 (0x00007fef99914000)

* I prepare the file:

    $ cat demo.c
    #include <stdio.h>
    #include <nettle/base64.h>
    #include <libtasn1.h>

    int
    main (int argc, const char *const argv[])
    {
      struct base64_encode_ctx ctx;
      base64_encode_init(&ctx);
      printf("%s\n", asn1_strerror(ASN1_SUCCESS));
      return 0;
    }

  and compile it with:

    $ gcc -Wall -I/usr/local/include -L/usr/local/lib \
       -o demo demo.c \
       -ltasn1 -lnettle -lhogweed

  it compiles fine and runs fine,  and it appears to be linked to
  the right libraries under "/usr/local/lib":

    $ ldd ./demo
    linux-vdso.so.1 (0x00007fff91df4000)
    libtasn1.so.6 => /usr/local/lib/libtasn1.so.6 (0x00007f9074638000)
    libnettle.so.4 => /usr/local/lib/libnettle.so.4 (0x00007f9074407000)
    libhogweed.so.2 => /usr/local/lib/libhogweed.so.2 (0x00007f90741d8000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f9073e18000)
    libgmp.so.10 => /usr/local/lib/libgmp.so.10 (0x00007f9073ba0000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f907487a000)

* When compiling the same program without the local flags:

    $ gcc -Wall -o demo demo.c -ltasn1 -lnettle -lhogweed

  the program compiles  fine, runs fine, and  it *almost* appears
  to be linked to the correct libraries:

    $ ldd ./demo
    linux-vdso.so.1 (0x00007ffff4fff000)
    libtasn1.so.3 => /usr/lib64/libtasn1.so.3 (0x00007fa01ea3e000)
    libnettle.so.4 => /usr/local/lib/libnettle.so.4 (0x00007fa01e80d000)
    libhogweed.so.2 => /usr/local/lib/libhogweed.so.2 (0x00007fa01e5de000)
    libc.so.6 => /lib64/libc.so.6 (0x00007fa01e21e000)
    libgmp.so.10 => /usr/local/lib/libgmp.so.10 (0x00007fa01dfa6000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fa01ec7d000)

  with the exception of libtasn1, for no reason I can understand.

  I conclude that  my system is almost fine  when running outside
of the GNU Autotools infrastructure... whatever this means.  Also
I have the  packages GMP and MPFR with  libraries installed under
"/usr/lib64" and also a local installation of GMP, MPFR, MPC with
libraries  installed under  "/usr/local/lib"; all  these packages
make  use of  Libtool  (they  install .la  files)  and the  local
installations   are  correctly   linked   with  libraries   under
"/usr/local/lib".  Nettle does not use Libtool, but this does not
appear to be a problem when compiling by hand.

  Now I  start with a  fresh unpacking  of Gnutls 3.2.1  and just
run:

   $ ./configure

it appears to complete successfully and:

   $ grep '\(nettle\|NETTLE\)' config.log
   config.log:589:configure:8667: checking for NETTLE
   config.log:590:configure:8675: $PKG_CONFIG --exists --print-errors "nettle >= 2.7"
   config.log:592:configure:8693: $PKG_CONFIG --exists --print-errors "nettle >= 2.7"
   config.log:716:| #define HAVE_LIBNETTLE 1
   ...
   config.log:37166:config.status:3259: creating lib/nettle/Makefile
   config.log:37301:ac_cv_env_NETTLE_CFLAGS_set=
   config.log:37302:ac_cv_env_NETTLE_CFLAGS_value=
   config.log:37303:ac_cv_env_NETTLE_LIBS_set=
   config.log:37304:ac_cv_env_NETTLE_LIBS_value=
   config.log:38427:pkg_cv_NETTLE_CFLAGS='-I/usr/local/include '
   config.log:38428:pkg_cv_NETTLE_LIBS='-L/usr/local/lib -lnettle '
   config.log:38524:ENABLE_NETTLE_FALSE='#'
   config.log:38525:ENABLE_NETTLE_TRUE=''
   config.log:38954:GNUTLS_REQUIRES_PRIVATE='Requires.private: nettle, hogweed, libtasn1, p11-kit-1, zlib'
   config.log:39414:NETTLE_CFLAGS='-I/usr/local/include '
   config.log:39415:NETTLE_LIBS='-L/usr/local/lib -lnettle '
   config.log:39851:#define HAVE_LIBNETTLE 1

   $ find -name Makefile| xargs grep NETTLE
   ./doc/credentials/x509/Makefile:NETTLE_CFLAGS = -I/usr/local/include
   ./doc/credentials/x509/Makefile:NETTLE_LIBS = -L/usr/local/lib -lnettle
   ...

everything looks fine.  Now I run "make" and it fails:

   $ make
   ...
   CCLD crywrap
   ../../lib/.libs/libgnutls.so: undefined reference to `nettle_umac96_set_key'
   ../../lib/.libs/libgnutls.so: undefined reference to `nettle_secp_224r1'
   ../../lib/.libs/libgnutls.so: undefined reference to `nettle_ecc_point_get'
   ...

  I have refreshed my memory reading the documentation of Libtool
and my understanding  is that it imposes its own  karma both when
linking libraries in the build tree and when linking libraries in
the installation  directory; so I  am not  sure it make  sense to
apply "ldd" upon the libraries in the build tree, but anyway:

   $ ldd ./lib/.libs/libgnutls.so |grep '\(nettle\|tasn\|gmp\)'
   libtasn1.so.6 => /usr/local/lib/libtasn1.so.6 (0x00007f27b394b000)
   libnettle.so.4 => /usr/lib64/libnettle.so.4 (0x00007f27b3726000)
   libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007f27b2ac6000)

for what is worth: it is not  right.  In the mess of the Makefile
it seems to me that the command that links libgnutls is:

   echo " CCLD " libgnutls.la;/bin/sh ../libtool --silent --tag=CC --mode=link gcc -std=gnu99 -g -O2 -no-undefined -version-info 50:0:22 -Wl,--version-script=./libgnutls.map -o libgnutls.la -rpath /usr/local/lib gnutls_range.lo gnutls_record.lo gnutls_compress.lo debug.lo gnutls_cipher.lo gnutls_mbuffers.lo gnutls_buffers.lo gnutls_handshake.lo gnutls_num.lo gnutls_errors.lo gnutls_dh.lo gnutls_kx.lo gnutls_priority.lo gnutls_hash_int.lo gnutls_cipher_int.lo gnutls_session.lo gnutls_db.lo x509_b64.lo gnutls_extensions.lo gnutls_auth.lo gnutls_v2_compat.lo gnutls_datum.lo gnutls_session_pack.lo gnutls_mpi.lo gnutls_pk.lo gnutls_cert.lo gnutls_global.lo gnutls_constate.lo gnutls_anon_cred.lo pkix_asn1_tab.lo gnutls_asn1_tab.lo gnutls_mem.lo gnutls_ui.lo gnutls_sig.lo gnutls_ecc.lo gnutls_dh_primes.lo gnutls_alert.lo system.lo gnutls_str.lo gnutls_state.lo gnutls_x509.lo gnutls_rsa_export.lo gnutls_helper.lo gnutls_supplemental.lo random.lo crypto-api.lo gnutls_privkey.lo gnutls_pcert.lo gnutls_pubkey.lo locks.lo gnutls_dtls.lo system_override.lo crypto-backend.lo verify-tofu.lo pin.lo tpm.lo pkcs11.lo pkcs11_privkey.lo pkcs11_write.lo pkcs11_secret.lo gnutls_srp.lo gnutls_psk.lo ../gl/libgnu.la x509/libgnutls_x509.la accelerated/libaccelerated.la ext/libgnutls_ext.la auth/libgnutls_auth.la algorithms/libgnutls_alg.la extras/libgnutls_extras.la openpgp/libgnutls_openpgp.la opencdk/libminiopencdk.la nettle/libcrypto.la -lz -lp11-kit -L/usr/local/lib -ltasn1 -L/usr/local/lib -lnettle -L/usr/local/lib -lhogweed

which looks  fine.  The only thing  I can say is  that "-lz" will
find the  library "/usr/lib64/libz.so" and "-lp11-kit"  will find
"/usr/lib64/libp11-kit.la"     and    "/usr/lib64/libp11-kit.so";
"libp11-kit.la" contains:

   libdir='/usr/lib64'

but I doubt it makes some difference.

  Of course  I can  just use  the old  libraries in  my Slackware
installation; I am lost here. :-/
-- 
"Now feel the funk blast!"
Rage Against the Machine - "Calm like a bomb"


From nmav at gnutls.org  Fri Jun  7 08:41:23 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 07 Jun 2013 08:41:23 +0200
Subject: [gnutls-help] on finding nettle under /usr/local rather than
 under /usr (GNU+Linux 64-bit system)
In-Reply-To: <87r4gf59nt.fsf@governatore.luna>
References: <87obbslpkq.fsf@governatore.luna>
 <CAJU7zaJLpy2=-1_MO+GPgLLNPZVQmwPFBaDVXHfH+dsV55p3Sw@mail.gmail.com>
 <87li6vqumc.fsf@governatore.luna>
 <CAJU7zaKQH7YBFBQk2kvD9vXK+UZ25GwoOUS+mrr6iJyZs3z6FQ@mail.gmail.com>
 <87r4gf59nt.fsf@governatore.luna>
Message-ID: <51B18093.3080004@gnutls.org>

On 06/06/2013 09:19 PM, Marco Maggi wrote:

> Nikos Mavrogiannopoulos wrote:
>> That's pretty strange. Did you run ldconfig on your system (and does
>> its configuration include /usr/local/lib)? I'd expect that the latest
>> library would be used.
> 
> Sorry for  the very late  reply and  for this very  long message.
> Unfortunately Gnutls 3.2.1 still does not work.  To recapitulate:

Hello,
 I have exactly the same situation in my system but never experienced
what you describe.

> everything looks fine.  Now I run "make" and it fails:
[...]

>   I have refreshed my memory reading the documentation of Libtool

> and my understanding  is that it imposes its own  karma both when
> linking libraries in the build tree and when linking libraries in
> the installation  directory; so I  am not  sure it make  sense to
> apply "ldd" upon the libraries in the build tree, but anyway:


Do you have in /usr/lib64, any .la files?

regards,
Nikos


From sdecugis at freediameter.net  Fri Jun  7 12:09:30 2013
From: sdecugis at freediameter.net (Sebastien Decugis)
Date: Fri, 7 Jun 2013 18:09:30 +0800
Subject: [gnutls-help] Disable anti-replay protection in DTLS ?
Message-ID: <001f01ce6367$1de4d380$59ae7a80$@net>

Hello,

I am looking at implementing DTLS over SCTP (as per RFC 6083) in my application, and I noticed that one of the requirements is to disable the anti-replay protection, as the higher layer expects reliable delivery above SCTP link. Could you tell me if this can be done with GNUTLS ? I was not able to find any information in gnutls manual about this feature.

I also noticed that the retransmissions must be disabled for the handshake protocol, I think this can be done with gnutls_heartbeat_set_timeouts by setting a retrains_timeout greater than the total_timeout; can you confirm?

Thank you in advance!

Best regards,
Sebastien.









From nmav at gnutls.org  Fri Jun  7 14:37:35 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 7 Jun 2013 14:37:35 +0200
Subject: [gnutls-help] Disable anti-replay protection in DTLS ?
In-Reply-To: <001f01ce6367$1de4d380$59ae7a80$@net>
References: <001f01ce6367$1de4d380$59ae7a80$@net>
Message-ID: <CAJU7za+9V0AUC3F5S-OD6K5xB8ecEYzd1LsV0uWCcEmhC1-u4w@mail.gmail.com>

On Fri, Jun 7, 2013 at 12:09 PM, Sebastien Decugis
<sdecugis at freediameter.net> wrote:
> Hello,
> I am looking at implementing DTLS over SCTP (as per RFC 6083) in my application, and I noticed that one of the requirements is to disable the anti-replay protection, as the higher layer expects reliable delivery above SCTP link. Could you tell me if this can be done with GNUTLS ? I was not able to find any information in gnutls manual about this feature.

Hello,
 Currently there is no way to disable anti-replay protection. Would it
really matter though? If you say there are no replays over SCTP what
would this disabling buy?

> I also noticed that the retransmissions must be disabled for the handshake protocol, I think this can be done with gnutls_heartbeat_set_timeouts by setting a retrains_timeout greater than the total_timeout; can you confirm?

No. gnutls_heartbeat_set_timeouts() is relevant to heartbeat message
retransmission, not the DTLS handshake. There is (again) no direct way
to disable those timeouts, but you can always set a retransmission
timeout that is larger than the total handshake timeout, which is
equivalent to having no retransmissions. You can set that using
gnutls_dtls_set_timeouts().

regards,
Nikos


From joke at seiken.de  Fri Jun  7 17:30:41 2013
From: joke at seiken.de (Joke de Buhr)
Date: Fri, 07 Jun 2013 17:30:41 +0200
Subject: [gnutls-help] on finding nettle under /usr/local rather than
	under /usr (GNU+Linux 64-bit system)
In-Reply-To: <51B18093.3080004@gnutls.org>
References: <87obbslpkq.fsf@governatore.luna>
 <87r4gf59nt.fsf@governatore.luna> <51B18093.3080004@gnutls.org>
Message-ID: <2397509.MxOEW3R46X@oberon>

hi,

this message might not fit the topic but might be related to these problems 
regarding nettle.


i installed nettle using a custom --prefix=/home/...

gnutls 3.2.1 configure script is invoked with a PKG_CONFIG_PATH=/home/...
pointing to right pkgconfig location underneath the prefix.

unfortunately gnutls doesn't use the values supplied by pkgconfig.
the makefile ?x509/Makefile? contains the right include path NETTLE_CFLAGS but 
the values isn't passed to the compiler later on. gcc can't find 
?<nettle/memxor.h>?


regards joke



On Friday 07 June 2013 08:41:23 Nikos Mavrogiannopoulos wrote:
> On 06/06/2013 09:19 PM, Marco Maggi wrote:
> > Nikos Mavrogiannopoulos wrote:
> >> That's pretty strange. Did you run ldconfig on your system (and does
> >> its configuration include /usr/local/lib)? I'd expect that the latest
> >> library would be used.
> > 
> > Sorry for  the very late  reply and  for this very  long message.
> 
> > Unfortunately Gnutls 3.2.1 still does not work.  To recapitulate:
> Hello,
>  I have exactly the same situation in my system but never experienced
> what you describe.
> 
> > everything looks fine.  Now I run "make" and it fails:
> [...]
> 
> >   I have refreshed my memory reading the documentation of Libtool
> > 
> > and my understanding  is that it imposes its own  karma both when
> > linking libraries in the build tree and when linking libraries in
> > the installation  directory; so I  am not  sure it make  sense to
> 
> > apply "ldd" upon the libraries in the build tree, but anyway:
> Do you have in /usr/lib64, any .la files?
> 
> regards,
> Nikos
> 
> _______________________________________________
> Gnutls-help mailing list
> Gnutls-help at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-help


From marco.maggi-ipsu at poste.it  Fri Jun  7 22:05:20 2013
From: marco.maggi-ipsu at poste.it (Marco Maggi)
Date: Fri, 07 Jun 2013 22:05:20 +0200
Subject: [gnutls-help] on finding nettle under /usr/local rather than
	under /usr (GNU+Linux 64-bit system)
In-Reply-To: marco.maggi-ipsu@poste.it of "Fri\, 07 Jun 2013 08\:41\:23 +0200")
References: <87obbslpkq.fsf@governatore.luna>
 <CAJU7zaJLpy2=-1_MO+GPgLLNPZVQmwPFBaDVXHfH+dsV55p3Sw@mail.gmail.com>
 <87li6vqumc.fsf@governatore.luna>
 <CAJU7zaKQH7YBFBQk2kvD9vXK+UZ25GwoOUS+mrr6iJyZs3z6FQ@mail.gmail.com>
 <87r4gf59nt.fsf@governatore.luna> <51B18093.3080004@gnutls.org>
Message-ID: <87vc5pk7pb.fsf@governatore.luna>

Nikos Mavrogiannopoulos wrote:
> Do you have in /usr/lib64, any .la files?

Yes, the  Slackware packages  include the  .la files  of the
original distributions; I think the relevant ones are:

   /usr/lib64/libp11-kit.la
   /usr/lib64/libgmp.la
   /usr/lib64/libgnutls.la

the latest Slackware comes with Gnutls 3.0.23.
-- 
Marco Maggi


From sdecugis at freediameter.net  Sat Jun  8 04:19:49 2013
From: sdecugis at freediameter.net (Sebastien Decugis)
Date: Sat, 08 Jun 2013 10:19:49 +0800
Subject: [gnutls-help] Disable anti-replay protection in DTLS ?
In-Reply-To: <CAJU7za+9V0AUC3F5S-OD6K5xB8ecEYzd1LsV0uWCcEmhC1-u4w@mail.gmail.com>
References: <001f01ce6367$1de4d380$59ae7a80$@net>
 <CAJU7za+9V0AUC3F5S-OD6K5xB8ecEYzd1LsV0uWCcEmhC1-u4w@mail.gmail.com>
Message-ID: <51B294C5.3010406@freediameter.net>

Thank you for your answers Nikos, more comments inline.

>   Currently there is no way to disable anti-replay protection. Would it
> really matter though? If you say there are no replays over SCTP what
> would this disabling buy?

I plan to use several streams over SCTP, and send my application 
messages (Diameter messages) over each streams in turn.
Let's imagine I have a large message (1^14 bytes) followed by a series 
of very short messages (few bytes). On the sending side, I am sending a 
first record with sequence number #1 over stream #1, length is 1^14 (I 
am simplifying). Then short record #2 over stream #2, record #3 over 
stream #3, etc...  Because the payload sizes are different, on the 
receiving side the messages for streams #2, #3, ... get delivered first 
and successfully parsed by the DTLS layer.

If I undertand correctly, the anti-replay protection might cause the 
record with sequence #1 to be discarded if it is delivered "too late" 
with respect to the sequence number. Is it correct? This would be an 
issue for the upper layer, hence the requirement in RFC 6083 to disable it.

I apologize if my understanding is incorrect, I am new to DTLS...

> No. gnutls_heartbeat_set_timeouts() is relevant to heartbeat message
> retransmission, not the DTLS handshake.

Ok, thank you for the clarification. Then, the documentation of gnutls 
is quite misleading :)
http://gnutls.org/manual/gnutls.html#index-gnutls_005fheartbeat_005fset_005ftimeouts

I think this is actually the same exact text as the 
gnutls_dtls_set_timeouts() documentation (which I not seen before your 
mail).

> There is (again) no direct way
> to disable those timeouts, but you can always set a retransmission
> timeout that is larger than the total handshake timeout, which is
> equivalent to having no retransmissions. You can set that using
> gnutls_dtls_set_timeouts().

Thank you for the hint! I will do so.

Best regards,
Sebastien.



From nmav at gnutls.org  Sat Jun  8 20:18:36 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 08 Jun 2013 20:18:36 +0200
Subject: [gnutls-help] Disable anti-replay protection in DTLS ?
In-Reply-To: <51B294C5.3010406@freediameter.net>
References: <001f01ce6367$1de4d380$59ae7a80$@net>
 <CAJU7za+9V0AUC3F5S-OD6K5xB8ecEYzd1LsV0uWCcEmhC1-u4w@mail.gmail.com>
 <51B294C5.3010406@freediameter.net>
Message-ID: <51B3757C.2070105@gnutls.org>

On 06/08/2013 04:19 AM, Sebastien Decugis wrote:

> Thank you for your answers Nikos, more comments inline.
> 
>>   Currently there is no way to disable anti-replay protection. Would it
>> really matter though? If you say there are no replays over SCTP what
>> would this disabling buy?
> 
> I plan to use several streams over SCTP, and send my application
> messages (Diameter messages) over each streams in turn.
> Let's imagine I have a large message (1^14 bytes) followed by a series
> of very short messages (few bytes). On the sending side, I am sending a
> first record with sequence number #1 over stream #1, length is 1^14 (I
> am simplifying). Then short record #2 over stream #2, record #3 over
> stream #3, etc...  Because the payload sizes are different, on the
> receiving side the messages for streams #2, #3, ... get delivered first
> and successfully parsed by the DTLS layer.
> 
> If I undertand correctly, the anti-replay protection might cause the
> record with sequence #1 to be discarded if it is delivered "too late"
> with respect to the sequence number. Is it correct? This would be an
> issue for the upper layer, hence the requirement in RFC 6083 to disable it.
> 
> I apologize if my understanding is incorrect, I am new to DTLS...

Your understanding looks correct, having a method to disable the replay
protection may seem reasonable then. How would malicious replays be
detected in that case? Does the SCTP/DTLS protocol include it?

> Ok, thank you for the clarification. Then, the documentation of gnutls
> is quite misleading :)

>
http://gnutls.org/manual/gnutls.html#index-gnutls_005fheartbeat_005fset_005ftimeouts

Thanks. I've now corrected it.

regards,
Nikos


From nmav at gnutls.org  Sat Jun  8 20:21:14 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 08 Jun 2013 20:21:14 +0200
Subject: [gnutls-help] on finding nettle under /usr/local rather than
 under /usr (GNU+Linux 64-bit system)
In-Reply-To: <87vc5pk7pb.fsf@governatore.luna>
References: <87obbslpkq.fsf@governatore.luna>
 <CAJU7zaJLpy2=-1_MO+GPgLLNPZVQmwPFBaDVXHfH+dsV55p3Sw@mail.gmail.com>
 <87li6vqumc.fsf@governatore.luna>
 <CAJU7zaKQH7YBFBQk2kvD9vXK+UZ25GwoOUS+mrr6iJyZs3z6FQ@mail.gmail.com>
 <87r4gf59nt.fsf@governatore.luna> <51B18093.3080004@gnutls.org>
 <87vc5pk7pb.fsf@governatore.luna>
Message-ID: <51B3761A.5030208@gnutls.org>

On 06/07/2013 10:05 PM, Marco Maggi wrote:

> Nikos Mavrogiannopoulos wrote:
>> Do you have in /usr/lib64, any .la files?
> 
> Yes, the  Slackware packages  include the  .la files  of the
> original distributions; I think the relevant ones are:
>    /usr/lib64/libp11-kit.la
>    /usr/lib64/libgmp.la
>    /usr/lib64/libgnutls.la
> the latest Slackware comes with Gnutls 3.0.23.


My Debian doesn't ship those files, so could it be them that prohibit
the correct linkage?



From sdecugis at freediameter.net  Mon Jun 10 04:43:19 2013
From: sdecugis at freediameter.net (Sebastien Decugis)
Date: Mon, 10 Jun 2013 10:43:19 +0800
Subject: [gnutls-help] Disable anti-replay protection in DTLS ?
In-Reply-To: <51B3757C.2070105@gnutls.org>
References: <001f01ce6367$1de4d380$59ae7a80$@net>
 <CAJU7za+9V0AUC3F5S-OD6K5xB8ecEYzd1LsV0uWCcEmhC1-u4w@mail.gmail.com>
 <51B294C5.3010406@freediameter.net> <51B3757C.2070105@gnutls.org>
Message-ID: <002401ce6584$498c6830$dca53890$@net>

Hi Nikos,

> Your understanding looks correct, having a method to disable the replay
> protection may seem reasonable then. How would malicious replays be
> detected in that case? Does the SCTP/DTLS protocol include it?


This is a very good question :) I have done some more research and it appears that yes, when using DTLS over SCTP, the SCTP-AUTH extension must be used and this extension provides the anti-replay detection at the SCTP layer. When the extension is not used, there is a "light" protection in SCTP that is probably not sufficient to protect against malicious attacks.

However, I realize that in order to use this SCTP-AUTH extension, more interaction between GNU TLS and the SCTP stack is required, in particular:
- support for DTLS Keying Material Exporters as described in RFC5705 ( I did not find in the documentation if this is supported in GNU TLS),
- ability to be notified *during* handshake so that the new derived key can be set for SCTP-AUTH before the "Finished" message is sent.

Would you have any advice about these additional requirements?


I am going to start implementing DTLS over SCTP without using the SCTP-AUTH mechanism and without disabling the replay protection in a first step. Can you tell me the characteristics of the anti-replay window in GNU TLS? If I limit the number of streams I am using to this window, I should be able to avoid the messages being dropped.

If you are interested, I will send you the link to this implementation (open source) so that you can use it for further tests.

Best regards,
S?bastien.



From nmav at gnutls.org  Mon Jun 10 10:04:33 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 10 Jun 2013 10:04:33 +0200
Subject: [gnutls-help] Disable anti-replay protection in DTLS ?
In-Reply-To: <002401ce6584$498c6830$dca53890$@net>
References: <001f01ce6367$1de4d380$59ae7a80$@net>
 <CAJU7za+9V0AUC3F5S-OD6K5xB8ecEYzd1LsV0uWCcEmhC1-u4w@mail.gmail.com>
 <51B294C5.3010406@freediameter.net> <51B3757C.2070105@gnutls.org>
 <002401ce6584$498c6830$dca53890$@net>
Message-ID: <CAJU7zaK2RRb6v5orhDFGiYqCwBeEvtpwQDb9tYrtsM+=7TTXzA@mail.gmail.com>

On Mon, Jun 10, 2013 at 4:43 AM, Sebastien Decugis
<sdecugis at freediameter.net> wrote:
> Hi Nikos,
>> Your understanding looks correct, having a method to disable the replay
>> protection may seem reasonable then. How would malicious replays be
>> detected in that case? Does the SCTP/DTLS protocol include it?
> This is a very good question :) I have done some more research and it appears that yes, when using DTLS over SCTP, the SCTP-AUTH extension must be used and this extension provides the anti-replay detection at the SCTP layer. When the extension is not used, there is a "light" protection in SCTP that is probably not sufficient to protect against malicious attacks.
> However, I realize that in order to use this SCTP-AUTH extension, more interaction between GNU TLS and the SCTP stack is required, in particular:
> - support for DTLS Keying Material Exporters as described in RFC5705 ( I did not find in the documentation if this is supported in GNU TLS),

Check gnutls_prf(). That allows access to the key material exporter.

> - ability to be notified *during* handshake so that the new derived key can be set for SCTP-AUTH before the "Finished" message is sent.

Currently hooks are allowed after client hello (post_client_hello) and
when a certificate is received. Most probably a hook to intercept the
handshake before or after any arbitrary handshake message would be
useful here. I'll try to add such functionality to 3.2 releases (in
addition with an API to disable the replay protection).

> I am going to start implementing DTLS over SCTP without using the SCTP-AUTH mechanism and without disabling the replay protection in a first step. Can you tell me the characteristics of the anti-replay window in GNU TLS? If I limit the number of streams I am using to this window, I should be able to avoid the messages being dropped.

The window size is 64 after gnutls 3.1.0 (may be 32 on 3.0.x).

> If you are interested, I will send you the link to this implementation (open source) so that you can use it for further tests.

That would be nice.

regards,
Nikos


From marco.maggi-ipsu at poste.it  Wed Jun 12 21:06:54 2013
From: marco.maggi-ipsu at poste.it (Marco Maggi)
Date: Wed, 12 Jun 2013 21:06:54 +0200
Subject: [gnutls-help] on finding nettle under /usr/local rather than
	under /usr (GNU+Linux 64-bit system)
In-Reply-To: <51B3761A.5030208@gnutls.org> (Nikos Mavrogiannopoulos's message
 of "Sat, 08 Jun 2013 20:21:14 +0200")
References: <87obbslpkq.fsf@governatore.luna>
 <CAJU7zaJLpy2=-1_MO+GPgLLNPZVQmwPFBaDVXHfH+dsV55p3Sw@mail.gmail.com>
 <87li6vqumc.fsf@governatore.luna>
 <CAJU7zaKQH7YBFBQk2kvD9vXK+UZ25GwoOUS+mrr6iJyZs3z6FQ@mail.gmail.com>
 <87r4gf59nt.fsf@governatore.luna>        <51B18093.3080004@gnutls.org>
 <87vc5pk7pb.fsf@governatore.luna> <51B3761A.5030208@gnutls.org>
Message-ID: <877ghzjghd.fsf@governatore.luna>

Nikos Mavrogiannopoulos wrote:

> On 06/07/2013 10:05 PM, Marco Maggi wrote:

>> Nikos Mavrogiannopoulos wrote:
>>> Do you have in /usr/lib64, any .la files?

>> Yes, the  Slackware packages  include the  .la files  of the
>> original distributions; I think the relevant ones are:
>>    /usr/lib64/libp11-kit.la
>>    /usr/lib64/libgmp.la
>>    /usr/lib64/libgnutls.la
>> the latest Slackware comes with Gnutls 3.0.23.

> My Debian doesn't ship those files, so could it be them that prohibit
> the correct linkage?

Indeed, this appears to be  the problem.  If I (temporarily)
remove  *all*  the  .la  files from  /usr/lib64  then  build
Gnutls: everything works and, after installation:

   $ ldd /usr/local/lib/libgnutls.so
   linux-vdso.so.1 (0x00007fff437ff000)
   libz.so.1 => /usr/lib64/libz.so.1 (0x00007fc9247c2000)
   libp11-kit.so.0 => /usr/lib64/libp11-kit.so.0 (0x00007fc9245b0000)
   libtasn1.so.6 => /usr/local/lib/libtasn1.so.6 (0x00007fc92439d000)
   libnettle.so.4 => /usr/local/lib/libnettle.so.4 (0x00007fc92416c000)
   libhogweed.so.2 => /usr/local/lib/libhogweed.so.2 (0x00007fc923f3d000)
   libc.so.6 => /lib64/libc.so.6 (0x00007fc923b4f000)
   libdl.so.2 => /lib64/libdl.so.2 (0x00007fc92394b000)
   libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc92372e000)
   libgmp.so.10 => /usr/local/lib/libgmp.so.10 (0x00007fc9234b6000)
   /lib64/ld-linux-x86-64.so.2 (0x00007fc924ce5000)

  Fine.  But  I am  unable to find  *which* .la  files cause
problems; if I remove only:

   libgmp.la
   libgmpxx.la
   libgnutls.la
   libgnutls-openssl.la
   libgnutlsxx.la
   libp11-kit.la

the  build fails.   Are there  other .la  files relevant  to
Gnutls?   Notice  that (with  all  the  .la files  in  their
place):

   $ ls -1 /usr/lib64/libgnutls*.la
   /usr/lib64/libgnutls-openssl.la
   /usr/lib64/libgnutls.la
   /usr/lib64/libgnutlsxx.la

   $ ls -1 /usr/lib64/libtasn*.la
   /usr/lib64/libtasn*.la: No such file or directory

   $ ls -1 /usr/lib64/libgmp*.la
   /usr/lib64/libgmp.la
   /usr/lib64/libgmpxx.la

   $ ls -1 /usr/lib64/libp11*.la
   /usr/lib64/libp11-kit.la

-- 
"Now feel the funk blast!"
Rage Against the Machine - "Calm like a bomb"


From nmav at gnutls.org  Thu Jun 13 16:12:10 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 13 Jun 2013 16:12:10 +0200
Subject: [gnutls-help] on finding nettle under /usr/local rather than
 under /usr (GNU+Linux 64-bit system)
In-Reply-To: <877ghzjghd.fsf@governatore.luna>
References: <87obbslpkq.fsf@governatore.luna>
 <CAJU7zaJLpy2=-1_MO+GPgLLNPZVQmwPFBaDVXHfH+dsV55p3Sw@mail.gmail.com>
 <87li6vqumc.fsf@governatore.luna>
 <CAJU7zaKQH7YBFBQk2kvD9vXK+UZ25GwoOUS+mrr6iJyZs3z6FQ@mail.gmail.com>
 <87r4gf59nt.fsf@governatore.luna> <51B18093.3080004@gnutls.org>
 <87vc5pk7pb.fsf@governatore.luna> <51B3761A.5030208@gnutls.org>
 <877ghzjghd.fsf@governatore.luna>
Message-ID: <CAJU7zaLpTcEqmhN2-X6D8KtCmuFbpWp9WkKYb1DdQ7jwr9uuww@mail.gmail.com>

On Wed, Jun 12, 2013 at 9:06 PM, Marco Maggi <marco.maggi-ipsu at poste.it> wrote:

>> My Debian doesn't ship those files, so could it be them that prohibit
>> the correct linkage?
> Indeed, this appears to be  the problem.  If I (temporarily)
> remove  *all*  the  .la  files from  /usr/lib64  then  build
> Gnutls: everything works and, after installation:

That's pretty interesting issue. I would expect that the presence of
those files would improve any issues in linking rather than cause new
ones.  May I ask you to report your issue to the libtool [0] people
(and keep me CC if possible)?

[0]. http://www.gnu.org/software/libtool/

regards,
Nikos


From mammar at gmail.com  Mon Jun 17 09:11:17 2013
From: mammar at gmail.com (mammar)
Date: Mon, 17 Jun 2013 12:11:17 +0500
Subject: [gnutls-help] gnutls compile error with custom application
Message-ID: <CADiUXRxJMHVCZSSvOvz6voKAHmfeUKq8bH-D=Sb5gY72JWB90Q@mail.gmail.com>

Hi

I want to embed gnutls into my application, currently i am playing with
exmples included with gnutls. Examples work fine. The problem is when i
standalone compile the simple X.509 example at
http://www.gnutls.org/manual/gnutls.html#Echo-server-with-X_002e509-authentication,
i am getting compile errors.

Here is my Makefile

CC=gcc

CFLAGS= -g \
-I./gnutls

CFILES = server_x509.c


LIBS = -lgnutls

all: server

server:
$(CC) $(CFILES) $(CFLAGS) $(LIBS) -o server_x509
clean:
rm -f server_x509


Compile error i am getting

$ make -f Makefile
gcc server_x509.c -g -I./gnutls -lgnutls -o server_x509
/tmp/cc6UmJrw.o: In function `main':
/home/ma1/OS/1GNUTLS/examples/server_x509.c:126: undefined reference to
`gnutls_transport_set_int2'
collect2: error: ld returned 1 exit status
make: *** [server] Error 1

How to fix this error?

So, can anyone tell me how to embed gnutls to an application or is there
any guide available for this?


Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130617/79365cda/attachment-0001.html>

From nmav at gnutls.org  Mon Jun 17 11:44:40 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 17 Jun 2013 11:44:40 +0200
Subject: [gnutls-help] gnutls compile error with custom application
In-Reply-To: <CADiUXRxJMHVCZSSvOvz6voKAHmfeUKq8bH-D=Sb5gY72JWB90Q@mail.gmail.com>
References: <CADiUXRxJMHVCZSSvOvz6voKAHmfeUKq8bH-D=Sb5gY72JWB90Q@mail.gmail.com>
Message-ID: <CAJU7zaK64EeZD2X9MxaM=44E1ypppfta1kSevsZ_022f_7XZwg@mail.gmail.com>

On Mon, Jun 17, 2013 at 9:11 AM, mammar <mammar at gmail.com> wrote:
> Hi
> I want to embed gnutls into my application, currently i am playing with
> exmples included with gnutls. Examples work fine. The problem is when i
> standalone compile the simple X.509 example at
> http://www.gnutls.org/manual/gnutls.html#Echo-server-with-X_002e509-authentication,
> i am getting compile errors.

Hello,
 The examples on the web work only on the applicable version, which it
typically the latest released. It is better to stick in the
documentation shipped by your system libraries, if you'd like to use
them, or just install the latest gnutls version.

regards,
Nikos


From sdecugis at freediameter.net  Tue Jun 18 13:21:08 2013
From: sdecugis at freediameter.net (Sebastien Decugis)
Date: Tue, 18 Jun 2013 19:21:08 +0800
Subject: [gnutls-help] Cannot build gnutls from source: picks the wrong
	libnettle
Message-ID: <006801ce6c15$f1341b40$d39c51c0$@net>

Hello,

I am trying to build latest gnutls from source, and I encounter an issue. My system is Ubuntu Precise.

I have installed all dependencies as described in README-alpha.
In addition, I have built from source and installed under my home folder the latest automake and nettle.

[Side comment, when I ran "make bootstrap" I encountered an issue already reported here about missing src/libopts/Makefile.in, and I had to run "autoreconf -fvi" to fix it. Is it normal? It could be worth writing this in the README-alpha file...]


I am now encountering an error when I try to make GNUTLS:
make[4]: Entering directory `/home/thedoc/sources/gnutls-latest/src/crywrap'
  CC       crywrap.o
crywrap.c: In function '_crywrap_do_one':
crywrap.c:867:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
crywrap.c:868:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
crywrap.c: In function '_crywrap_setup_pidfile':
crywrap.c:819:10: warning: ignoring return value of 'fchown', declared with attribute warn_unused_result [-Wunused-result]
crywrap.c:823:9: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result]
  CCLD     crywrap
../../lib/.libs/libgnutls.so: undefined reference to `nettle_rsa_pkcs1_sign_tr'
../../lib/.libs/libgnutls.so: undefined reference to `nettle_umac96_set_key'
../../lib/.libs/libgnutls.so: undefined reference to `nettle_sha512_digest'
../../lib/.libs/libgnutls.so: undefined reference to `nettle_sha384_init'
../../lib/.libs/libgnutls.so: undefined reference to `nettle_md5_digest'
../../lib/.libs/libgnutls.so: undefined reference to `nettle_gcm_encr

It seems that the ./configure script is correctly following my NETTLE_LIBS=-L/home/user/bin/nettle/lib/ instruction (when I don't add it, I cannot configure successfully), but somehow the value is not propagated to the crywrap Makefile. I also tried to add LDFLAGS= and LD_LIBRARY_PATH= but got the same issue. The complete configure line I am using is:

LD_LIBRARY_PATH=/home/user/bin/nettle/lib/ LDFLAGS=-L/home/user/bin/nettle/lib/ NETTLE_LIBS=-L/home/user/bin/nettle/lib/ HOGWEED_LIBS=-L/home/user/bin/nettle/lib/ NETTLE_CFLAGS=-I/home/user/bin/nettle/include HOGWEED_CFLAGS=-I/home/user/bin/nettle/include ./configure

Has someone encountered the same situation? Do I have to actually replace the nettle lib from my system ?

Best regards,
S?bastien.







From sdecugis at freediameter.net  Wed Jun 19 06:14:33 2013
From: sdecugis at freediameter.net (Sebastien Decugis)
Date: Wed, 19 Jun 2013 12:14:33 +0800
Subject: [gnutls-help] Cannot build gnutls from source: picks the
	wrong	libnettle
In-Reply-To: <006801ce6c15$f1341b40$d39c51c0$@net>
References: <006801ce6c15$f1341b40$d39c51c0$@net>
Message-ID: <00c501ce6ca3$8373da80$8a5b8f80$@net>

Hello again,

For what it's worth, I could finally complete the build after making the following change:

index 790cdb1..c1b9867 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -141,6 +141,7 @@ endif
 
 if ENABLE_NETTLE
 libgnutls_la_LIBADD += nettle/libcrypto.la
+thirdparty_libadd += $(NETTLE_LIBS) $(HOGWEED_LIBS) $(GMP_LIBS)
 endif
 
 if HAVE_LD_OUTPUT_DEF


Best regards,
S?bastien.



> -----Original Message-----
> From: Gnutls-help [mailto:gnutls-help-bounces at lists.gnutls.org] On
> Behalf Of Sebastien Decugis
> Sent: mardi 18 juin 2013 19:21
> To: gnutls-help at lists.gnutls.org
> Subject: [gnutls-help] Cannot build gnutls from source: picks the wrong
> libnettle
> 
> Hello,
> 
> I am trying to build latest gnutls from source, and I encounter an
> issue. My system is Ubuntu Precise.
> 
> I have installed all dependencies as described in README-alpha.
> In addition, I have built from source and installed under my home
> folder the latest automake and nettle.
> 
> [Side comment, when I ran "make bootstrap" I encountered an issue
> already reported here about missing src/libopts/Makefile.in, and I had
> to run "autoreconf -fvi" to fix it. Is it normal? It could be worth
> writing this in the README-alpha file...]
> 
> 
> I am now encountering an error when I try to make GNUTLS:
> make[4]: Entering directory `/home/thedoc/sources/gnutls-
> latest/src/crywrap'
>   CC       crywrap.o
> crywrap.c: In function '_crywrap_do_one':
> crywrap.c:867:9: warning: cast to pointer from integer of different
> size [-Wint-to-pointer-cast]
> crywrap.c:868:9: warning: cast to pointer from integer of different
> size [-Wint-to-pointer-cast]
> crywrap.c: In function '_crywrap_setup_pidfile':
> crywrap.c:819:10: warning: ignoring return value of 'fchown', declared
> with attribute warn_unused_result [-Wunused-result]
> crywrap.c:823:9: warning: ignoring return value of 'write', declared
> with attribute warn_unused_result [-Wunused-result]
>   CCLD     crywrap
> ../../lib/.libs/libgnutls.so: undefined reference to
> `nettle_rsa_pkcs1_sign_tr'
> ../../lib/.libs/libgnutls.so: undefined reference to
> `nettle_umac96_set_key'
> ../../lib/.libs/libgnutls.so: undefined reference to
> `nettle_sha512_digest'
> ../../lib/.libs/libgnutls.so: undefined reference to
> `nettle_sha384_init'
> ../../lib/.libs/libgnutls.so: undefined reference to
> `nettle_md5_digest'
> ../../lib/.libs/libgnutls.so: undefined reference to `nettle_gcm_encr
> 
> It seems that the ./configure script is correctly following my
> NETTLE_LIBS=-L/home/user/bin/nettle/lib/ instruction (when I don't add
> it, I cannot configure successfully), but somehow the value is not
> propagated to the crywrap Makefile. I also tried to add LDFLAGS= and
> LD_LIBRARY_PATH= but got the same issue. The complete configure line I
> am using is:
> 
> LD_LIBRARY_PATH=/home/user/bin/nettle/lib/ LDFLAGS=-
> L/home/user/bin/nettle/lib/ NETTLE_LIBS=-L/home/user/bin/nettle/lib/
> HOGWEED_LIBS=-L/home/user/bin/nettle/lib/ NETTLE_CFLAGS=-
> I/home/user/bin/nettle/include HOGWEED_CFLAGS=-
> I/home/user/bin/nettle/include ./configure
> 
> Has someone encountered the same situation? Do I have to actually
> replace the nettle lib from my system ?
> 
> Best regards,
> S?bastien.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Gnutls-help mailing list
> Gnutls-help at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-help



From mohan.kemparaju at gmail.com  Tue Jun 25 06:01:50 2013
From: mohan.kemparaju at gmail.com (Mohan Kemparaju)
Date: Tue, 25 Jun 2013 09:31:50 +0530
Subject: [gnutls-help] Not able to build gnutls3.2.1 on cygwin
Message-ID: <CADqvo6Sg8tQki+HxCtd3VSqTtAmKBC-o65oO8EAVEvjjdd4KRQ@mail.gmail.com>

Hello everyone,

I am unable to build gnutls 3.2.1 on cygwin. I am successful in building
gmp5.1.2 and nettle2.7.1 libraries. I have cygwin 1.7.10(0.259/5/3).

The libraries are present at
/cygdrive/c/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/lib and
the include files are at
/cygdrive/c/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/include.
The lib folder contains .dll.a and .a files of libgmp, libnettle and
libhogweed.
The ./configure command fails with " Libnettle 2.7 was not found." error.
But i am using nettle2.7.1 library.
The configure parameters is mentioned below

./configure --disable-cxx --with-included-libtasn1 --disable-doc
--disable-tests
CPPFLAGS=-I/cygdrive/c/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/include
LDFLAGS=-L/cygdrive/c/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/lib/
 LIBS="-lgmp -lnettle -lhogweed"
NETTLE_CFLAGS=-I/cygdrive/c/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/include
NETTLE_LIBS=-L/cygdrive/c/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/lib/
--prefix=/cygdrive/c/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library
--exec-prefix=/cygdrive/c/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library
--datadir=/cygdrive/c/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/data
--htmldir=/cygdrive/c/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/doc
--dvidir=/cygdrive/c/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/doc
--pdfdir=/cygdrive/c/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/doc
--psdir=/cygdrive/c/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/doc

With the same packages and parameters, i am able to build gnutls on
Ubuntu.I must have this working on cygwin in our developemnt environment.
I do not know the reason for the failure. Request help in solving the above
issue.

Thank you and look forward to some assistance.

Regards
Mohan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130625/bb0ba8d3/attachment.html>

From nmav at gnutls.org  Wed Jun 26 18:59:02 2013
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 26 Jun 2013 18:59:02 +0200
Subject: [gnutls-help] Not able to build gnutls3.2.1 on cygwin
In-Reply-To: <CADqvo6Sg8tQki+HxCtd3VSqTtAmKBC-o65oO8EAVEvjjdd4KRQ@mail.gmail.com>
References: <CADqvo6Sg8tQki+HxCtd3VSqTtAmKBC-o65oO8EAVEvjjdd4KRQ@mail.gmail.com>
Message-ID: <51CB1DD6.2060108@gnutls.org>

On 06/25/2013 06:01 AM, Mohan Kemparaju wrote:

> Hello everyone,
> 
> I am unable to build gnutls 3.2.1 on cygwin. I am successful in building
> gmp5.1.2 and nettle2.7.1 libraries. I have cygwin 1.7.10(0.259/5/3).


Hello,
 Could you try cross.mk from master [0]? I use that to build gnutls in
mingw64.

regards,
Nikos

[0]. https://gitorious.org/gnutls/gnutls/trees/master



From mohan.kemparaju at gmail.com  Fri Jun 28 13:24:24 2013
From: mohan.kemparaju at gmail.com (Mohan Kemparaju)
Date: Fri, 28 Jun 2013 16:54:24 +0530
Subject: [gnutls-help] Not able to build gnutls3.2.1 on cygwin
In-Reply-To: <51CB1DD6.2060108@gnutls.org>
References: <CADqvo6Sg8tQki+HxCtd3VSqTtAmKBC-o65oO8EAVEvjjdd4KRQ@mail.gmail.com>
 <51CB1DD6.2060108@gnutls.org>
Message-ID: <CADqvo6Tdx3fuHQT-YT_NAEGsLFepeCUUJotxWsZZEyd_XedNbw@mail.gmail.com>

Hello Nikos,

Thank you for your reply.
Since i wanted to build gnutls and dependent libraries for a target machine
using arm, i use the arm cross-compiler from codesourcery. I was successful
is building using MinGW. Thanks for the pointer. I had to install the
pkg-config package in MinGW, which solved the problem.

Now, using MinGW, i was to build gnutls for the PC using gcc. I want the
client app using gnutls on the PC, this i need this. I use the same
code-base that was used above. I was successful in building gmp/nettle. The
.a / .dll files are generated.

With gnutls, i get an error while configuring.
My configure parameters are

$./configure --disable-cxx --with-included-libtasn1 --disable-doc
--disable-tests
CPPFLAGS=-I/c/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/include
LDFLAGS=-L/c/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/lib/
LIBS="-lgmp -lnettle -lhogweed"
 PKG_CONFIG_PATH=/c/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/lib/pkgconfig

I get the below error
configure : error : C compiler cannot create executables.See config.log
file for more details.

In the config.log, i see the below error, since i generate the nettle,gmp
library using gcc, i do not understand this error.

Target: mingw32
Configured with: ../gcc-4.6.1/configure
--enable-languages=c,c++,fortran,objc,obj-c++ --disable-sjlj-exceptions
--with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry
--enable-libstdcxx-debug --enable-version-specific-runtime-libs
--build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.6.1 (GCC)
configure:5130: $? = 0
configure:5119: gcc -V >&5
gcc.exe: error: unrecognized option '-V'
gcc.exe: fatal error: no input files
compilation terminated.
configure:5130: $? = 1
configure:5119: gcc -qversion >&5
gcc.exe: error: unrecognized option '-qversion'
gcc.exe: fatal error: no input files
compilation terminated.
configure:5130: $? = 1
configure:5150: checking whether the C compiler works
configure:5172: gcc
 -I/c/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/include
-L/c/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/lib conftest.c
-lgmp -lnettle -lhogweed >&5
c:/mingw/bin/../lib/gcc/mingw32/4.6.1/../../../../mingw32/bin/ld.exe:
cannot find -lgmp
c:/mingw/bin/../lib/gcc/mingw32/4.6.1/../../../../mingw32/bin/ld.exe:
skipping incompatible
c:/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/lib/libnettle.a
when searching for -lnettle
c:/mingw/bin/../lib/gcc/mingw32/4.6.1/../../../../mingw32/bin/ld.exe:
skipping incompatible
c:/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/lib\libnettle.a
when searching for -lnettle
c:/mingw/bin/../lib/gcc/mingw32/4.6.1/../../../../mingw32/bin/ld.exe:
skipping incompatible
c:/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/lib/libnettle.a
when searching for -lnettle
c:/mingw/bin/../lib/gcc/mingw32/4.6.1/../../../../mingw32/bin/ld.exe:
cannot find -lnettle
c:/mingw/bin/../lib/gcc/mingw32/4.6.1/../../../../mingw32/bin/ld.exe:
skipping incompatible
c:/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/lib/libhogweed.a
when searching for -lhogweed
c:/mingw/bin/../lib/gcc/mingw32/4.6.1/../../../../mingw32/bin/ld.exe:
skipping incompatible
c:/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/lib\libhogweed.a
when searching for -lhogweed
c:/mingw/bin/../lib/gcc/mingw32/4.6.1/../../../../mingw32/bin/ld.exe:
skipping incompatible
c:/UserData/0.0.Projects/0.1.PFS/GAD/Source/Gnutls/Library/lib/libhogweed.a
when searching for -lhogweed
c:/mingw/bin/../lib/gcc/mingw32/4.6.1/../../../../mingw32/bin/ld.exe:
cannot find -lhogweed
collect2: ld returned 1 exit status

Can you please help?

Regards
Mohan



On Wed, Jun 26, 2013 at 10:29 PM, Nikos Mavrogiannopoulos
<nmav at gnutls.org>wrote:

> On 06/25/2013 06:01 AM, Mohan Kemparaju wrote:
>
> > Hello everyone,
> >
> > I am unable to build gnutls 3.2.1 on cygwin. I am successful in building
> > gmp5.1.2 and nettle2.7.1 libraries. I have cygwin 1.7.10(0.259/5/3).
>
>
> Hello,
>  Could you try cross.mk from master [0]? I use that to build gnutls in
> mingw64.
>
> regards,
> Nikos
>
> [0]. https://gitorious.org/gnutls/gnutls/trees/master
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20130628/503f2e9e/attachment-0001.html>