From nmav at gnutls.org  Sat Apr  2 10:40:30 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 02 Apr 2011 10:40:30 +0200
Subject: gnutls 2.12.1
Message-ID: <4D96E0FE.10200@gnutls.org>

I've just released gnutls 2.12.1. It is a bugfix release.

What's New
==========
** certtool: Generated certificate request with stricter permissions.
Reported by Luca Capello.

** libgnutls: Bug fixes in opencdk code. Reported by Vitaly Kruglikov.

** libgnutls: Corrected windows system_errno() function prototype.

** libgnutls: C++ compatibility fix for compat.h. Reported by Mark Brand.

** libgnutls: Fix size of gnutls_openpgp_keyid_t by using the
GNUTLS_OPENPGP_KEYID_SIZE definition. Reported by Andreas Metzler.

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

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

GnuTLS may be downloaded from one of the GNU mirror sites or directly
>From <ftp://ftp.gnu.org/gnu/gnutls/>.  The list of GNU mirrors can be
found at <http://www.gnu.org/prep/ftp.html> and a list of GnuTLS mirrors
can be found at <http://www.gnu.org/software/gnutls/download.html>.

Here are the BZIP2 compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.1.tar.bz2
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.1.tar.bz2

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.1.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.1.tar.bz2.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  Sun Apr  3 01:42:10 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 03 Apr 2011 01:42:10 +0200
Subject: different lib directories for gnutls and nettle
In-Reply-To: <437hbgql64.wl%bjg@gnu.org>
References: <437hbgql64.wl%bjg@gnu.org>
Message-ID: <4D97B452.9080100@gnutls.org>

On 03/31/2011 12:48 AM, Brian Gough wrote:
> Hi, now that GNU TLS is using nettle I notice there is a difference
> between the --libdir for the two packages on 64 bit.
> Nettle installs to $prefix/lib64/ and GNU TLS looks for it in
> $prefix/lib/ -- so it fails and the standard configure/install to a
> prefix doesn't work.

Indeed it seems nettle for some reason uses the /usr/lib64. Niels,
is there really a reason for that? As I understand from the FHS[0]
/usr/lib is the system library directory. /usr/lib64 and /usr/lib32
might not even be there.

regards,
Nikos

[0].
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA



From dbreiser at gmail.com  Sat Apr  2 17:42:30 2011
From: dbreiser at gmail.com (David Reiser)
Date: Sat, 2 Apr 2011 11:42:30 -0400
Subject: gnutls 2.12.1 won't build for me on OS X
Message-ID: <BA789BCF-4907-4E9C-B450-9B1319EF2C81@gmail.com>

Under 'Making all in examples' the build quits a little later with:

  CCLD   ex-cert-select
libtool: link: warning: `-no-install' is ignored for i386-apple-darwin10.7.0
libtool: link: warning: assuming `-no-fast-install' instead
libtool: link: warning: library `/sw/lib/libgmp.la' was moved.
ld: duplicate symbol _main in ./.libs/libexamples.a(ex-cert-select-pkcs11.o) and ex-cert-select.o
collect2: ld returned 1 exit status
make[4]: *** [ex-cert-select] Error 1

And while I'm here, if nettle is replacing libgcrypt, why does lib/nettle/init.c still #include <gcrypt.h>?
--
David Reiser
dbreiser at gmail.com






From nmav at gnutls.org  Sun Apr  3 23:47:39 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 03 Apr 2011 23:47:39 +0200
Subject: gnutls 2.12.1 won't build for me on OS X
In-Reply-To: <BA789BCF-4907-4E9C-B450-9B1319EF2C81@gmail.com>
References: <BA789BCF-4907-4E9C-B450-9B1319EF2C81@gmail.com>
Message-ID: <4D98EAFB.3010406@gnutls.org>

On 04/02/2011 05:42 PM, David Reiser wrote:
> Under 'Making all in examples' the build quits a little later with:
>   CCLD   ex-cert-select
> libtool: link: warning: `-no-install' is ignored for i386-apple-darwin10.7.0
> libtool: link: warning: assuming `-no-fast-install' instead
> libtool: link: warning: library `/sw/lib/libgmp.la' was moved.
> ld: duplicate symbol _main in ./.libs/libexamples.a(ex-cert-select-pkcs11.o) and ex-cert-select.o
> collect2: ld returned 1 exit status
> make[4]: *** [ex-cert-select] Error 1

Thanks for reporting that. I've committed a fix.

> And while I'm here, if nettle is replacing libgcrypt, why does lib/nettle/init.c still #include <gcrypt.h>?

It shouldn't have been there. I've removed that. Apart from these
did you have any issues using gnutls 2.12 in OSX?

regards,
Nikos



From lrn1986 at gmail.com  Mon Apr  4 03:04:57 2011
From: lrn1986 at gmail.com (LRN)
Date: Mon, 04 Apr 2011 05:04:57 +0400
Subject: W32 testsuite results
Message-ID: <4D991939.6040701@gmail.com>

Does anyone have testsuite (make -k check) results for gnutls-2.12.1 on 
W32 (i would prefer native W32, but the ones from Wine are better than 
nothing at all)? Built against libgcrypt.
I'm building gnutls myself (with some minor patches) and i'm not sure 
whether my mixed testsuite results are expected (known bugs or unported 
features) or not (i broke something).



From INVALID.NOREPLY at gnu.org  Mon Apr  4 14:49:31 2011
From: INVALID.NOREPLY at gnu.org (LRN)
Date: Mon, 04 Apr 2011 12:49:31 +0000
Subject: [sr #107647] Gnutls fails several tests - A TLS packet with
	unexpected length was received.
Message-ID: <20110404-124930.sv74148.75292@savannah.gnu.org>

URL:
  <http://savannah.gnu.org/support/?107647>

                 Summary: Gnutls fails several tests - A TLS packet with
unexpected length was received.
                 Project: GnuTLS
            Submitted by: lrn
            Submitted on: Mon 04 Apr 2011 12:49:30 PM GMT
                Category: None
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: Microsoft Windows

    _______________________________________________________

Details:

Probable cause might be located by this line in the log:
|<7>| WRITE: enqueued 83 bytes for ffffffff. Total 83 bytes.
Which, AFAIU, means that transport_send_ptr is -1. transport_recv_ptr is also
-1, and reading from it suddenly fails. Makes me wonder.
AFAIU, transport_*_ptr are set by gnutls_transport_set_ptr() or
gnutls_transport_set_ptr2(). The only in-library functions that call any of
these are weirdly-defined s_scm_gnutls_set_session_transport_fd_x and
s_scm_gnutls_set_session_transport_port_x. These two are not used by mini.c,
and neither are transport_*_ptr.
Log is attached.



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Mon 04 Apr 2011 12:49:30 PM GMT  Name: gdb.log.tar.xz  Size: 3kB   By:
lrn
Log of a debugging session
<http://savannah.gnu.org/support/download.php?file_id=23100>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107647>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From nmav at gnutls.org  Mon Apr  4 16:15:26 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 04 Apr 2011 16:15:26 +0200
Subject: W32 testsuite results
In-Reply-To: <4D991939.6040701@gmail.com>
References: <4D991939.6040701@gmail.com>
Message-ID: <4D99D27E.7030002@gnutls.org>

On 04/04/2011 03:04 AM, LRN wrote:
> Does anyone have testsuite (make -k check) results for gnutls-2.12.1 on
> W32 (i would prefer native W32, but the ones from Wine are better than
> nothing at all)? Built against libgcrypt.
> I'm building gnutls myself (with some minor patches) and i'm not sure
> whether my mixed testsuite results are expected (known bugs or unported
> features) or not (i broke something).

Not me. Which tests failed? Do gnutls-cli and gnutls-serv operate?

regards,
Nikos



From lrn1986 at gmail.com  Mon Apr  4 18:01:12 2011
From: lrn1986 at gmail.com (LRN)
Date: Mon, 04 Apr 2011 20:01:12 +0400
Subject: W32 testsuite results
In-Reply-To: <4D99D27E.7030002@gnutls.org>
References: <4D991939.6040701@gmail.com> <4D99D27E.7030002@gnutls.org>
Message-ID: <4D99EB48.9030200@gmail.com>

On 04.04.2011 18:15, Nikos Mavrogiannopoulos wrote:
> On 04/04/2011 03:04 AM, LRN wrote:
>> Does anyone have testsuite (make -k check) results for gnutls-2.12.1 on
>> W32 (i would prefer native W32, but the ones from Wine are better than
>> nothing at all)? Built against libgcrypt.
>> I'm building gnutls myself (with some minor patches) and i'm not sure
>> whether my mixed testsuite results are expected (known bugs or unported
>> features) or not (i broke something).
> Not me. Which tests failed? Do gnutls-cli and gnutls-serv operate?
>

make[7]: Entering directory `/f/src/for-mingwmsys/gnutls/bld/lib/gl/tests'
PASS: test-alloca-opt.exe
FAIL: test-binary-io.sh
PASS: test-byteswap.exe
PASS: test-c-ctype.exe
PASS: test-errno.exe
PASS: test-fcntl-h.exe
PASS: test-fseeko.sh
PASS: test-fseeko2.sh
PASS: test-ftello.sh
PASS: test-ftello2.sh
PASS: test-ftello3.exe
PASS: test-func.exe
PASS: test-memchr.exe
PASS: test-netdb.exe
PASS: test-read-file.exe
PASS: test-snprintf.exe
PASS: test-sockets.exe
PASS: test-stdbool.exe
PASS: test-stddef.exe
PASS: test-stdint.exe
PASS: test-stdio.exe
PASS: test-stdlib.exe
PASS: test-string.exe
PASS: test-strings.exe
PASS: test-strverscmp.exe
PASS: test-sys_socket.exe
PASS: test-sys_stat.exe
PASS: test-time.exe
PASS: test-unistd.exe
PASS: test-vasnprintf.exe
PASS: test-vasprintf.exe
PASS: test-verify.exe
PASS: test-verify.sh
PASS: test-vsnprintf.exe
===================================
1 of 34 tests failed
Please report to bug-gnutls at gnu.org
===================================

make[6]: Entering directory `/f/src/for-mingwmsys/gnutls/bld/gl/tests'
PASS: test-alignof.exe
PASS: test-alloca-opt.exe
PASS: test-arpa_inet.exe
FAIL: test-binary-io.sh
PASS: test-c-ctype.exe
PASS: test-errno.exe
PASS: test-fcntl-h.exe
PASS: test-fseeko.sh
PASS: test-fseeko2.sh
PASS: test-ftello.sh
PASS: test-ftello2.sh
PASS: test-ftello3.exe
PASS: test-getaddrinfo.exe
PASS: test-getdelim.exe
PASS: test-getline.exe
PASS: test-gettimeofday.exe
PASS: test-inet_ntop.exe
PASS: test-inet_pton.exe
PASS: test-lseek.sh
PASS: test-memchr.exe
PASS: test-netdb.exe
PASS: test-netinet_in.exe
PASS: test-perror.sh
PASS: test-pipe.exe
PASS: test-read-file.exe
Unconnected socket test... passed
Connected sockets test... passed
General socket test with fork... passed
Pipe test... passed
PASS: test-select.exe
PASS: test-select-in.sh
PASS: test-select-out.sh
PASS: test-snprintf.exe
PASS: test-sockets.exe
PASS: test-stdbool.exe
PASS: test-stddef.exe
PASS: test-stdint.exe
PASS: test-stdio.exe
PASS: test-stdlib.exe
PASS: test-strerror.exe
PASS: test-string.exe
PASS: test-sys_ioctl.exe
PASS: test-sys_select.exe
PASS: test-sys_socket.exe
PASS: test-sys_stat.exe
PASS: test-sys_time.exe
PASS: test-time.exe
PASS: test-unistd.exe
PASS: test-update-copyright.sh
PASS: test-vasnprintf.exe
PASS: test-vc-list-files-git.sh
PASS: test-vc-list-files-cvs.sh
PASS: test-verify.exe
PASS: test-verify.sh
PASS: test-version-etc.sh
===================================
1 of 51 tests failed
Please report to bug-gnutls at gnu.org
===================================

make[3]: Entering directory `/f/src/for-mingwmsys/gnutls/bld/tests'
Self test `f:/src/for-mingwmsys/gnutls/bld/tests/.libs/simple.exe' 
finished with 0 errors
PASS: simple.exe
Self test `f:/src/for-mingwmsys/gnutls/bld/tests/.libs/gc.exe' finished 
with 0 errors
PASS: gc.exe
Self test 
`f:/src/for-mingwmsys/gnutls/bld/tests/.libs/set_pkcs12_cred.exe' 
finished with 0 errors
PASS: set_pkcs12_cred.exe
Self test `f:/src/for-mingwmsys/gnutls/bld/tests/.libs/certder.exe' 
finished with 0 errors
PASS: certder.exe
Self test `f:/src/for-mingwmsys/gnutls/bld/tests/.libs/certuniqueid.exe' 
finished with 0 errors
PASS: certuniqueid.exe
mpi ops ok
Self test `f:/src/for-mingwmsys/gnutls/bld/tests/.libs/mpi.exe' finished 
with 0 errors
PASS: mpi.exe
PASS: certificate_set_x509_crl.exe
Self test `f:/src/for-mingwmsys/gnutls/bld/tests/.libs/dn.exe' finished 
with 0 errors
PASS: dn.exe
Self test `f:/src/for-mingwmsys/gnutls/bld/tests/.libs/parse_ca.exe' 
finished with 0 errors
PASS: parse_ca.exe
Self test `f:/src/for-mingwmsys/gnutls/bld/tests/.libs/moredn.exe' 
finished with 0 errors
PASS: moredn.exe
rng registered ok
Self test `f:/src/for-mingwmsys/gnutls/bld/tests/.libs/crypto_rng.exe' 
finished with 0 errors
PASS: crypto_rng.exe
Self test `f:/src/for-mingwmsys/gnutls/bld/tests/.libs/mini.exe' 
finished with 2 errors
server: error: The specified session has been invalidated for some reason.
client: Error: The specified session has been invalidated for some reason.
FAIL: mini.exe
Self test 
`f:/src/for-mingwmsys/gnutls/bld/tests/.libs/hostname-check.exe' 
finished with 2 errors
gnutls_openpgp_crt_import: -59
Hostname incorrectly does not match (0)
FAIL: hostname-check.exe
PASS: cve-2008-4989.exe
Self test `f:/src/for-mingwmsys/gnutls/bld/tests/.libs/pkcs12_s2k.exe' 
finished with 0 errors
PASS: pkcs12_s2k.exe
chain[cacertrsamd5 ok]: verify_status: 1026 expected: 0
FAIL: chainverify.exe
Self test `f:/src/for-mingwmsys/gnutls/bld/tests/.libs/crq_key_id.exe' 
finished with 0 errors
PASS: crq_key_id.exe
Self test 
`f:/src/for-mingwmsys/gnutls/bld/tests/.libs/x509sign-verify.exe' 
finished with 0 errors
PASS: x509sign-verify.exe
PASS: cve-2009-1415.exe
success!
PASS: cve-2009-1416.exe
Self test `f:/src/for-mingwmsys/gnutls/bld/tests/.libs/crq_apis.exe' 
finished with 0 errors
PASS: crq_apis.exe
Self test 
`f:/src/for-mingwmsys/gnutls/bld/tests/.libs/init_roundtrip.exe' 
finished with 0 errors
PASS: init_roundtrip.exe
PASS: pkcs12_s2k_pem.exe
Self test `f:/src/for-mingwmsys/gnutls/bld/tests/.libs/dn2.exe' finished 
with 0 errors
PASS: dn2.exe
Self test `f:/src/for-mingwmsys/gnutls/bld/tests/.libs/mini-eagain.exe' 
finished with 1 errors
server: error: The specified session has been invalidated for some reason.
FAIL: mini-eagain.exe
Self test 
`f:/src/for-mingwmsys/gnutls/bld/tests/.libs/nul-in-x509-names.exe' 
finished with 0 errors
PASS: nul-in-x509-names.exe
Self test `f:/src/for-mingwmsys/gnutls/bld/tests/.libs/x509_altname.exe' 
finished with 0 errors
PASS: x509_altname.exe
Self test 
`f:/src/for-mingwmsys/gnutls/bld/tests/.libs/pkcs12_encode.exe' finished 
with 0 errors
PASS: pkcs12_encode.exe
FAIL: mini-x509.exe

This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information.
FAIL: mini-x509-rehandshake.exe
SKIP: rng-fork.exe
Self test `f:/src/for-mingwmsys/gnutls/bld/tests/.libs/openssl.exe' 
finished with 0 errors
PASS: openssl.exe
SKIP: openpgp-auth.exe
Self test 
`f:/src/for-mingwmsys/gnutls/bld/tests/.libs/openpgp-keyring.exe' 
finished with 0 errors
PASS: openpgp-keyring.exe
gnutls_openpgp_privkey_import rc -59: GnuTLS internal error.
FAIL: pgps2kgnu.exe
PASS: rfc2253-escape-test
===================================
7 of 34 tests failed
(2 tests were not run)
Please report to bug-gnutls at gnu.org
===================================

make[3]: Entering directory 
`/f/src/for-mingwmsys/gnutls/bld/tests/rsa-md5-collision'
     Verification output: Not verified, Insecure algorithm.
Chain verification output: Not verified, Insecure algorithm.
     Verification output: Not verified, Insecure algorithm.
Chain verification output: Not verified, Insecure algorithm.
PASS: rsa-md5-collision
=============
1 test passed
=============

make[3]: Entering directory 
`/f/src/for-mingwmsys/gnutls/bld/tests/pkcs1-padding'
./pkcs1-pad: line 28: datefudge: command not found
Cannot fake timestamps, please install datefudge...
SKIP: pkcs1-pad
====================
All 0 tests passed
(1 test was not run)
====================

make[3]: Entering directory 
`/f/src/for-mingwmsys/gnutls/bld/tests/pkcs8-decode'
PKCS8 OK encpkcs8.pem foobar
PKCS8 OK unencpkcs8.pem
PKCS8 OK enc2pkcs8.pem baz
PKCS8 DONE (rc 0)
PASS: pkcs8
=============
1 test passed
=============

make[3]: Entering directory 
`/f/src/for-mingwmsys/gnutls/bld/tests/pkcs12-decode'
NEON PKCS12 OK client.p12 foobar
NEON PKCS12 OK noclient.p12
NEON PKCS12 OK unclient.p12
NEON PKCS12 OK pkcs12_2certs.p12
NEON PKCS12 DONE (rc 0)
PASS: pkcs12
=============
1 test passed
=============

make[3]: Entering directory `/f/src/for-mingwmsys/gnutls/bld/tests/userid'
PASS: userid
=============
1 test passed
=============

make[3]: Entering directory `/f/src/for-mingwmsys/gnutls/bld/tests/pathlen'
PASS: pathlen
=============
1 test passed
=============

make[3]: Entering directory `/f/src/for-mingwmsys/gnutls/bld/tests/key-id'
PASS: key-id
=============
1 test passed
=============

make[3]: Entering directory `/f/src/for-mingwmsys/gnutls/bld/tests/sha2'
PASS: sha2
PASS: sha2-dsa
==================
All 2 tests passed
==================

make[3]: Entering directory 
`/f/src/for-mingwmsys/gnutls/bld/tests/safe-renegotiation'

This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information.
|<0>| Session not using safe renegotiation!
FAIL: srn0.exe
PASS: srn1.exe

This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information.
Client or server not using safe renegotiation extension?
FAIL: srn2.exe
FAIL: srn3.exe

This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information.
FAIL: srn4.exe

This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information.
FAIL: srn5.exe
===================================
5 of 6 tests failed
Please report to bug-gnutls at gnu.org
===================================

make[3]: Entering directory `/f/src/for-mingwmsys/gnutls/bld/tests/dsa'
Checking various DSA key sizes
Checking DSA-1024 with TLS 1.0
*** Fatal error: A TLS packet with unexpected length was received.
*** Server has terminated the connection abnormally.
Failure: Failed connection to a server with DSA 1024 key and TLS 1.0!
FAIL: testdsa
===================================
1 of 1 test failed
Please report to bug-gnutls at gnu.org
===================================

make[3]: Entering directory 
`/f/src/for-mingwmsys/gnutls/bld/tests/openpgp-certs'
Checking OpenPGP certificate self verification
certtool.exe: import error: The scanning of a large integer has failed.
Failure: Self sig Verification should have succeeded!
certtool.exe: import error: The scanning of a large integer has failed.
Failure: Self sig Verification should have failed!
certtool.exe: import error: The scanning of a large integer has failed.
Failure: Self sig Verification should have failed!
certtool.exe: import error: The scanning of a large integer has failed.
Failure: Self sig Verification should have failed!
FAIL: testselfsigs
===================================
1 of 1 test failed
Please report to bug-gnutls at gnu.org
===================================

I'm blaming test-binary-io.sh on libtool (the test itself, the one in 
.libs subdirectory, exits with 0 and writes the right 6-byte string into 
stdout, but when it is run by a libtool wrapper, _spawn() returns 3).

Hangs up at "Checking DSA-1024 with TLS 1.0" (or, rather, enters 
infinite loop; consumes very little resources though, so it must either 
use a timer or some kind of wait function), have to kill the server to 
kick it going again (or kill the client. Twice. And then kill the 
server, also twice, because it just keeps waiting for a client to connect).

Also, obviously, i've had to skip rng-fork (because it uses fork()) and 
openpgp-auth (because it uses socketpair(), and with unix domain sockets 
at that!) tests. Other tests had to be patched to NOT to include 
#include <sys/wait.h> and some other headers not provided by MinGW.

I've also submitted a bug report about mini.exe (see the bug tracker), 
because its cause seemed obvious to me (writes/reads to/from 
fd==0xffffffff).



From INVALID.NOREPLY at gnu.org  Tue Apr  5 03:52:45 2011
From: INVALID.NOREPLY at gnu.org (Christopher Head)
Date: Tue, 05 Apr 2011 01:52:45 +0000
Subject: [sr #107648] Misleading documentation for
	GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
Message-ID: <20110405-015244.sv82329.53884@savannah.gnu.org>

URL:
  <http://savannah.gnu.org/support/?107648>

                 Summary: Misleading documentation for
GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
                 Project: GnuTLS
            Submitted by: hawk777
            Submitted on: Tue 05 Apr 2011 01:52:44 AM GMT
                Category: None
                Priority: 5 - Normal
                Severity: 2 - Minor
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: None

    _______________________________________________________

Details:

The GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT option has as its first documentation
sentence "Allow only trusted CA certificates that have version 1.".

This is misleading. The first time I read it, I thought it meant it would
reject V3 CA certificates, allowing only V1 CA certificates! It might read
better as "Allow only trusted CA certificates *to be* version 1."




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107648>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From nmav at gnutls.org  Tue Apr  5 09:52:21 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 05 Apr 2011 09:52:21 +0200
Subject: W32 testsuite results
In-Reply-To: <4D99EB48.9030200@gmail.com>
References: <4D991939.6040701@gmail.com> <4D99D27E.7030002@gnutls.org>
	<4D99EB48.9030200@gmail.com>
Message-ID: <4D9ACA35.1080000@gnutls.org>

On 04/04/2011 06:01 PM, LRN wrote:
> On 04.04.2011 18:15, Nikos Mavrogiannopoulos wrote:
>> On 04/04/2011 03:04 AM, LRN wrote:
>>> Does anyone have testsuite (make -k check) results for gnutls-2.12.1 on
>>> W32 (i would prefer native W32, but the ones from Wine are better than
>>> nothing at all)? Built against libgcrypt.
>>> I'm building gnutls myself (with some minor patches) and i'm not sure
>>> whether my mixed testsuite results are expected (known bugs or unported
>>> features) or not (i broke something).
>> Not me. Which tests failed? Do gnutls-cli and gnutls-serv operate?

> FAIL: test-binary-io.sh
> FAIL: mini.exe
> FAIL: hostname-check.exe
> FAIL: chainverify.exe
> FAIL: mini-eagain.exe
> FAIL: mini-x509.exe
> FAIL: mini-x509-rehandshake.exe
> FAIL: pgps2kgnu.exe

Did these tests succeed in previous gnutls versions at win32?
Unfortunately I cannot debug them, but if you run individual tests
with the -v option, they will provide more information about the
actual point of failure.

> I'm blaming test-binary-io.sh on libtool (the test itself, the one in
> .libs subdirectory, exits with 0 and writes the right 6-byte string into
> stdout, but when it is run by a libtool wrapper, _spawn() returns 3).

I have no idea about this test. It is a gnulib test. It should have
been introduced on the previous gnulib update.

> Hangs up at "Checking DSA-1024 with TLS 1.0" (or, rather, enters
> infinite loop; consumes very little resources though, so it must either
> use a timer or some kind of wait function), have to kill the server to
> kick it going again (or kill the client. Twice. And then kill the
> server, also twice, because it just keeps waiting for a client to connect).
> 
> Also, obviously, i've had to skip rng-fork (because it uses fork()) and
> openpgp-auth (because it uses socketpair(), and with unix domain sockets
> at that!) tests. Other tests had to be patched to NOT to include
> #include <sys/wait.h> and some other headers not provided by MinGW.

Could you send me those changes?

> I've also submitted a bug report about mini.exe (see the bug tracker),
> because its cause seemed obvious to me (writes/reads to/from
> fd==0xffffffff).

This shouldn't be a problem. The mini-* programs use fd==0xfffffff
because they emulate the communication and don't really use an fd.

regards,
Nikos



From lrn1986 at gmail.com  Tue Apr  5 10:20:39 2011
From: lrn1986 at gmail.com (LRN)
Date: Tue, 05 Apr 2011 12:20:39 +0400
Subject: W32 testsuite results
In-Reply-To: <4D9ACA35.1080000@gnutls.org>
References: <4D991939.6040701@gmail.com> <4D99D27E.7030002@gnutls.org>
	<4D99EB48.9030200@gmail.com> <4D9ACA35.1080000@gnutls.org>
Message-ID: <4D9AD0D7.8030602@gmail.com>

On 05.04.2011 11:52, Nikos Mavrogiannopoulos wrote:
> On 04/04/2011 06:01 PM, LRN wrote:
>> On 04.04.2011 18:15, Nikos Mavrogiannopoulos wrote:
>>> On 04/04/2011 03:04 AM, LRN wrote:
>>>> Does anyone have testsuite (make -k check) results for gnutls-2.12.1 on
>>>> W32 (i would prefer native W32, but the ones from Wine are better than
>>>> nothing at all)? Built against libgcrypt.
>>>> I'm building gnutls myself (with some minor patches) and i'm not sure
>>>> whether my mixed testsuite results are expected (known bugs or unported
>>>> features) or not (i broke something).
>>> Not me. Which tests failed? Do gnutls-cli and gnutls-serv operate?
>> FAIL: test-binary-io.sh
>> FAIL: mini.exe
>> FAIL: hostname-check.exe
>> FAIL: chainverify.exe
>> FAIL: mini-eagain.exe
>> FAIL: mini-x509.exe
>> FAIL: mini-x509-rehandshake.exe
>> FAIL: pgps2kgnu.exe
> Did these tests succeed in previous gnutls versions at win32?
No idea. This is the first time i'm building and testing it by myself 
(used pre-built binaries from http://josefsson.org/gnutls4win/ until 
recently)
> Unfortunately I cannot debug them, but if you run individual tests
> with the -v option, they will provide more information about the
> actual point of failure.
Would you want me to make a new entry in bug tracker? One for each 
failing test, or just a single entry with debug logs for all failing 
tests? Or just keep discussing it here?
>
>> I'm blaming test-binary-io.sh on libtool (the test itself, the one in
>> .libs subdirectory, exits with 0 and writes the right 6-byte string into
>> stdout, but when it is run by a libtool wrapper, _spawn() returns 3).
> I have no idea about this test. It is a gnulib test. It should have
> been introduced on the previous gnulib update.
That's what i thought. Anyway, i'm not very concerned about it.
>
>> Hangs up at "Checking DSA-1024 with TLS 1.0" (or, rather, enters
>> infinite loop; consumes very little resources though, so it must either
>> use a timer or some kind of wait function), have to kill the server to
>> kick it going again (or kill the client. Twice. And then kill the
>> server, also twice, because it just keeps waiting for a client to connect).
>>
>> Also, obviously, i've had to skip rng-fork (because it uses fork()) and
>> openpgp-auth (because it uses socketpair(), and with unix domain sockets
>> at that!) tests. Other tests had to be patched to NOT to include
>> #include<sys/wait.h>  and some other headers not provided by MinGW.
> Could you send me those changes?
Attached (these, and some other patches not related to the testsuite; 
you might want to NOT to push these upstream, in particular sigalrm 
patch is completely untested, and testsuite-makefile patch is only 
necessary because some files are missing (?) from the release tarball).
>
>> I've also submitted a bug report about mini.exe (see the bug tracker),
>> because its cause seemed obvious to me (writes/reads to/from
>> fd==0xffffffff).
> This shouldn't be a problem. The mini-* programs use fd==0xfffffff
> because they emulate the communication and don't really use an fd.
>
Oh. Well, anyway, the log is in bug report. If you need anything else - 
just ask.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 02-mingw32-don't-look-for-non-existing-makefile.mingw32.patch
URL: </pipermail/attachments/20110405/e15ca580/attachment.asc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 03-mingw32-fix-includes-on-windows.mingw32.patch
URL: </pipermail/attachments/20110405/e15ca580/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 01-mingw32-fix-sigalrm-on-windows.mingw32.patch
URL: </pipermail/attachments/20110405/e15ca580/attachment-0001.asc>

From nmav at gnutls.org  Tue Apr  5 10:40:46 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 5 Apr 2011 10:40:46 +0200
Subject: W32 testsuite results
In-Reply-To: <4D9AD0D7.8030602@gmail.com>
References: <4D991939.6040701@gmail.com> <4D99D27E.7030002@gnutls.org>
	<4D99EB48.9030200@gmail.com> <4D9ACA35.1080000@gnutls.org>
	<4D9AD0D7.8030602@gmail.com>
Message-ID: <BANLkTinF6i9eD=MLb-ewhXrN4N6LWphVaA@mail.gmail.com>

On Tue, Apr 5, 2011 at 10:20 AM, LRN <lrn1986 at gmail.com> wrote:

> Would you want me to make a new entry in bug tracker? One for each failing
> test, or just a single entry with debug logs for all failing tests? Or just
> keep discussing it here?

I'd prefer the list.

regards,
Nikos



From lrn1986 at gmail.com  Tue Apr  5 14:27:16 2011
From: lrn1986 at gmail.com (LRN)
Date: Tue, 05 Apr 2011 16:27:16 +0400
Subject: W32 testsuite results
In-Reply-To: <4D9ACA35.1080000@gnutls.org>
References: <4D991939.6040701@gmail.com> <4D99D27E.7030002@gnutls.org>
	<4D99EB48.9030200@gmail.com> <4D9ACA35.1080000@gnutls.org>
Message-ID: <4D9B0AA4.7000405@gmail.com>

On 05.04.2011 11:52, Nikos Mavrogiannopoulos wrote:
> On 04/04/2011 06:01 PM, LRN wrote:
>> On 04.04.2011 18:15, Nikos Mavrogiannopoulos wrote:
>>> On 04/04/2011 03:04 AM, LRN wrote:
>>>> Does anyone have testsuite (make -k check) results for gnutls-2.12.1 on
>>>> W32 (i would prefer native W32, but the ones from Wine are better than
>>>> nothing at all)? Built against libgcrypt.
>>>> I'm building gnutls myself (with some minor patches) and i'm not sure
>>>> whether my mixed testsuite results are expected (known bugs or unported
>>>> features) or not (i broke something).
>>> Not me. Which tests failed? Do gnutls-cli and gnutls-serv operate?
>> I've also submitted a bug report about mini.exe (see the bug tracker),
>> because its cause seemed obvious to me (writes/reads to/from
>> fd==0xffffffff).
> This shouldn't be a problem. The mini-* programs use fd==0xfffffff
> because they emulate the communication and don't really use an fd.
I think i've found the problem. The code in client_pull() in mini.c 
calls gnutls_transport_set_global_errno (EAGAIN); to tell gnutls library 
code that the pull operation should be postponed. However, gnutls 
library code in _gnutls_read() in gnutls_buffers.c:306 calls int err = 
get_errno (session); to obain errno, which, in turn, returns 
session->internals.errno_func (session->internals.transport_recv_ptr);, 
which is the same as system_errno(session->internals.transport_recv_ptr) 
at system.c:55, which simply calls WSAGetLastError(), switch'es over its 
value and sets errno.
That is, the problem is in the fact that on Windows gnutls assumes that 
underlying read() implementation is incapable of setting errno and is, 
in fact, a socket (since gnutls uses WSAGetLastError()).
Possible fixes:
A) Fix gnutls_transport_set_global_errno() to call SetLastError() (note 
that there's no difference between WSAGLE and GLE, unless you're writing 
for WinSock 1.x, which is crazy, because WinSock 2.x has been shipped 
with NT since NT 4.0). And maybe set errno too, just to be safe.
B) Fix system_errno() to also check errno itself and use it instead of 
the result of GLE if errno is not 0. This way both WinAPI and CRT I/O 
functions can be used as read() implementation, and system_errno would 
work for both (although errno bleeding from previous calls could, in 
theory, cause false negatives).
C) Call SetLastError(0) more often. In this particular case 
WSAGetLastError() returns error 3, which is ERROR_PATH_NOT_FOUND, and is 
likely not related to this particular problem - it is probably just a 
leftover from some earlier WinAPI call. SetLastError(0) should clean 
that (OTOH that wouldn't fix this particular problem, since 
WSAGetLastError() will just return 0, and that would STILL result in 
system_error setting errno to EIO - by the way, that's a bit extreme, it 
should set errno to 0 if GLE is 0; consider getting yourself a better 
GLE-handling routine, generrmap.c from Python or win32error.c from 
PostgreSQL would be a good start).

P.S. All fixes are theoretical, i have not tried to implement any of 
that yet.



From INVALID.NOREPLY at gnu.org  Tue Apr  5 16:36:28 2011
From: INVALID.NOREPLY at gnu.org (Daniel Kahn Gillmor)
Date: Tue, 05 Apr 2011 14:36:28 +0000
Subject: [sr #107648] Misleading documentation for
	GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
In-Reply-To: <20110405-015244.sv82329.53884@savannah.gnu.org>
References: <20110405-015244.sv82329.53884@savannah.gnu.org>
Message-ID: <20110405-103628.sv57531.47577@savannah.gnu.org>

Follow-up Comment #1, sr #107648 (project gnutls):

Or perhaps just drop the "only".

how about:

 "Allow version 1 X.509 certificates in the list of trusted CAs"

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107648>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From lrn1986 at gmail.com  Tue Apr  5 21:08:26 2011
From: lrn1986 at gmail.com (LRN)
Date: Tue, 05 Apr 2011 23:08:26 +0400
Subject: W32 testsuite results
In-Reply-To: <4D9B668B.5070703@gnutls.org>
References: <4D991939.6040701@gmail.com> <4D99D27E.7030002@gnutls.org>
	<4D99EB48.9030200@gmail.com> <4D9ACA35.1080000@gnutls.org>
	<4D9B0AA4.7000405@gmail.com> <4D9B668B.5070703@gnutls.org>
Message-ID: <4D9B68AA.507@gmail.com>

On 05.04.2011 22:59, Nikos Mavrogiannopoulos wrote:
> On 04/05/2011 02:27 PM, LRN wrote:
>
>>> This shouldn't be a problem. The mini-* programs use fd==0xfffffff
>>> because they emulate the communication and don't really use an fd.
>> I think i've found the problem. The code in client_pull() in mini.c
>> calls gnutls_transport_set_global_errno (EAGAIN); to tell gnutls library
>> code that the pull operation should be postponed. However, gnutls
>> library code in _gnutls_read() in gnutls_buffers.c:306 calls int err =
>> get_errno (session); to obain errno, which, in turn, returns
>> session->internals.errno_func (session->internals.transport_recv_ptr);,
>> which is the same as system_errno(session->internals.transport_recv_ptr)
>> at system.c:55, which simply calls WSAGetLastError(), switch'es over its
>> value and sets errno.
>> That is, the problem is in the fact that on Windows gnutls assumes that
>> underlying read() implementation is incapable of setting errno and is,
>> in fact, a socket (since gnutls uses WSAGetLastError()).
>> Possible fixes:
>> A) Fix gnutls_transport_set_global_errno() to call SetLastError() (note
>> that there's no difference between WSAGLE and GLE, unless you're writing
>> for WinSock 1.x, which is crazy, because WinSock 2.x has been shipped
>> with NT since NT 4.0). And maybe set errno too, just to be safe.
> I think I'll switch it to gnutls_transport_set_errno(), fix and
> deprecate the set_global_errno() function. I don't see any point
> in it as a function.
How do you access a session object in pull function?



From nmav at gnutls.org  Tue Apr  5 20:59:23 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 05 Apr 2011 20:59:23 +0200
Subject: W32 testsuite results
In-Reply-To: <4D9B0AA4.7000405@gmail.com>
References: <4D991939.6040701@gmail.com> <4D99D27E.7030002@gnutls.org>
	<4D99EB48.9030200@gmail.com> <4D9ACA35.1080000@gnutls.org>
	<4D9B0AA4.7000405@gmail.com>
Message-ID: <4D9B668B.5070703@gnutls.org>

On 04/05/2011 02:27 PM, LRN wrote:

>> This shouldn't be a problem. The mini-* programs use fd==0xfffffff
>> because they emulate the communication and don't really use an fd.
> I think i've found the problem. The code in client_pull() in mini.c
> calls gnutls_transport_set_global_errno (EAGAIN); to tell gnutls library
> code that the pull operation should be postponed. However, gnutls
> library code in _gnutls_read() in gnutls_buffers.c:306 calls int err =
> get_errno (session); to obain errno, which, in turn, returns
> session->internals.errno_func (session->internals.transport_recv_ptr);,
> which is the same as system_errno(session->internals.transport_recv_ptr)
> at system.c:55, which simply calls WSAGetLastError(), switch'es over its
> value and sets errno.
> That is, the problem is in the fact that on Windows gnutls assumes that
> underlying read() implementation is incapable of setting errno and is,
> in fact, a socket (since gnutls uses WSAGetLastError()).
> Possible fixes:
> A) Fix gnutls_transport_set_global_errno() to call SetLastError() (note
> that there's no difference between WSAGLE and GLE, unless you're writing
> for WinSock 1.x, which is crazy, because WinSock 2.x has been shipped
> with NT since NT 4.0). And maybe set errno too, just to be safe.

I think I'll switch it to gnutls_transport_set_errno(), fix and
deprecate the set_global_errno() function. I don't see any point
in it as a function.

regards,
Nikos



From lrn1986 at gmail.com  Wed Apr  6 00:16:14 2011
From: lrn1986 at gmail.com (LRN)
Date: Wed, 06 Apr 2011 02:16:14 +0400
Subject: W32 testsuite results
In-Reply-To: <4D9B68AA.507@gmail.com>
References: <4D991939.6040701@gmail.com> <4D99D27E.7030002@gnutls.org>
	<4D99EB48.9030200@gmail.com> <4D9ACA35.1080000@gnutls.org>
	<4D9B0AA4.7000405@gmail.com> <4D9B668B.5070703@gnutls.org>
	<4D9B68AA.507@gmail.com>
Message-ID: <4D9B94AE.3040208@gmail.com>

On 05.04.2011 23:08, LRN wrote:
> On 05.04.2011 22:59, Nikos Mavrogiannopoulos wrote:
>> On 04/05/2011 02:27 PM, LRN wrote:
>>
>>>> This shouldn't be a problem. The mini-* programs use fd==0xfffffff
>>>> because they emulate the communication and don't really use an fd.
>>> I think i've found the problem. The code in client_pull() in mini.c
>>> calls gnutls_transport_set_global_errno (EAGAIN); to tell gnutls 
>>> library
>>> code that the pull operation should be postponed. However, gnutls
>>> library code in _gnutls_read() in gnutls_buffers.c:306 calls int err =
>>> get_errno (session); to obain errno, which, in turn, returns
>>> session->internals.errno_func (session->internals.transport_recv_ptr);,
>>> which is the same as 
>>> system_errno(session->internals.transport_recv_ptr)
>>> at system.c:55, which simply calls WSAGetLastError(), switch'es over 
>>> its
>>> value and sets errno.
>>> That is, the problem is in the fact that on Windows gnutls assumes that
>>> underlying read() implementation is incapable of setting errno and is,
>>> in fact, a socket (since gnutls uses WSAGetLastError()).
>>> Possible fixes:
>>> A) Fix gnutls_transport_set_global_errno() to call SetLastError() (note
>>> that there's no difference between WSAGLE and GLE, unless you're 
>>> writing
>>> for WinSock 1.x, which is crazy, because WinSock 2.x has been shipped
>>> with NT since NT 4.0). And maybe set errno too, just to be safe.
>> I think I'll switch it to gnutls_transport_set_errno(), fix and
>> deprecate the set_global_errno() function. I don't see any point
>> in it as a function.
> How do you access a session object in pull function?
Anyway, i've fixed it in my local copy (patch is attached; since i don't 
know how to access session in pull(), my patch is a bit crude)

FAIL: hostname-check.exe
FAIL: chainverify.exe
FAIL: pgps2kgnu.exe
FAIL: testdsa
FAIL: testselfsigs

Obviously, the improvement is considerable. Half of safe-renegotiation 
tests failed previously, now they all pass. Mini and its variants all pass.

hostname check might fail because function_to_get_host_by_ip(127.0.0.1) 
!= "localhost" (known winsock bug).

chainverify fails because 2 certificates have expired in January 2011. A 
patch fixes that (although it would be better to get some new 
certificates for this test, no?)

pgps2kgnu fails because of unexplainable (and quiet!) strstr() failure 
in armor_decode:
Starting program: 
f:\src\for-mingwmsys\gnutls\bld\tests/./.libs/pgps2kgnu.exe -v
[New Thread 7464.0x1524]
[New Thread 7464.0x3dc8]
[New Thread 7464.0x450c]

Breakpoint 9, armor_decode (data=0x21547f0, in=0x75f92960, 
out=0x75f92980) at armor.c:488
488       armor_filter_t *afx = data;
(gdb) n
492       u32 crc2 = 0;
(gdb)
493       ssize_t nread = 0;
(gdb)
494       int i, pgp_data = 0;
(gdb)
495       cdk_error_t rc = 0;
(gdb)
497       if (!afx)
(gdb)
503       _gnutls_buffers_log ("armor filter: decode\n");
(gdb)
505       fseek (in, 0, SEEK_SET);
(gdb)
507       while (!feof (in) && !pgp_data)
(gdb)
509           s = fgets (buf, DIM (buf) - 1, in);
(gdb)
510           if (!s)
(gdb)
512           afx->idx = search_header (buf, armor_begin);
(gdb)
513           if (afx->idx >= 0)
(gdb)
514             pgp_data = 1;
(gdb)
507       while (!feof (in) && !pgp_data)
(gdb)
517       if (feof (in) || !pgp_data)
(gdb)
524       while (!feof (in))
(gdb)
526           s = fgets (buf, DIM (buf) - 1, in);
(gdb)
527           if (!s)
(gdb)
529           if (strlen (s) == strlen (LF))
(gdb)
537           if (!strstr (buf, ": "))
(gdb) p buf
$68 = "Version: GnuPG v1.4.9 
(GNU/Linux)\n\000--\n\000?:?u<?(\000\003\000\000\000\000\000\000\000??(\000B??u:??w6?-u\f\001\000\000$?(\000,?(\000\b\000\000\00
0\016\000\000\000\000\000\000\000\003\000\000\000\000\005?uj\000\000 at l\000\000\000|\n=\000\066?-u\f\001\000\000T?("
(gdb) call strstr(buf, ": ")
$69 = 0
(gdb) call strstr(buf, ":")
$70 = 0
(gdb) p strstr
$71 = {<text variable, no debug info>} 0x77d79715 <strstr>
(gdb) s
542           rc = CDK_General_Error;
(gdb) call strstr(buf, ":")
$72 = 0
(gdb) call strstr(buf, "V")
$73 = 0
(gdb) call strstr("V", buf)
$74 = 0
(gdb) call strstr("123","1")
$75 = 0

I have no explanation whatsoever. Gnulib does not override this 
function, it is imported from msvcrt.
mbsstr works correctly (at least when called from gdb). Also, gnulib 
warns about strstr() not working with multibyte charsets. This is not 
the case here, but makes me wonder. I'll dig further.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 04-mingw32-fix-global-error-processing.mingw32.patch
URL: </pipermail/attachments/20110406/94e86b21/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 05-fix-expired-certs.all.patch
URL: </pipermail/attachments/20110406/94e86b21/attachment.asc>

From nmav at gnutls.org  Wed Apr  6 00:29:28 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 06 Apr 2011 00:29:28 +0200
Subject: W32 testsuite results
In-Reply-To: <4D9B68AA.507@gmail.com>
References: <4D991939.6040701@gmail.com> <4D99D27E.7030002@gnutls.org>
	<4D99EB48.9030200@gmail.com> <4D9ACA35.1080000@gnutls.org>
	<4D9B0AA4.7000405@gmail.com> <4D9B668B.5070703@gnutls.org>
	<4D9B68AA.507@gmail.com>
Message-ID: <4D9B97C8.3040604@gnutls.org>

On 04/05/2011 09:08 PM, LRN wrote:

>>> A) Fix gnutls_transport_set_global_errno() to call SetLastError() (note
>>> that there's no difference between WSAGLE and GLE, unless you're writing
>>> for WinSock 1.x, which is crazy, because WinSock 2.x has been shipped
>>> with NT since NT 4.0). And maybe set errno too, just to be safe.
>> I think I'll switch it to gnutls_transport_set_errno(), fix and
>> deprecate the set_global_errno() function. I don't see any point
>> in it as a function.
> How do you access a session object in pull function?

The pull or push functions receive a pointer. This pointer need not
to be the actual descriptor. It can be any private structure that
contains the session.

regards,
Nikos



From lrn1986 at gmail.com  Wed Apr  6 20:17:17 2011
From: lrn1986 at gmail.com (LRN)
Date: Wed, 06 Apr 2011 22:17:17 +0400
Subject: W32 testsuite results
In-Reply-To: <4D9B94AE.3040208@gmail.com>
References: <4D991939.6040701@gmail.com> <4D99D27E.7030002@gnutls.org>
	<4D99EB48.9030200@gmail.com> <4D9ACA35.1080000@gnutls.org>
	<4D9B0AA4.7000405@gmail.com> <4D9B668B.5070703@gnutls.org>
	<4D9B68AA.507@gmail.com> <4D9B94AE.3040208@gmail.com>
Message-ID: <4D9CAE2D.3090903@gmail.com>

On 06.04.2011 2:16, LRN wrote:
> On 05.04.2011 23:08, LRN wrote:
>> On 05.04.2011 22:59, Nikos Mavrogiannopoulos wrote:
>>> On 04/05/2011 02:27 PM, LRN wrote:
>>>
>>>>> This shouldn't be a problem. The mini-* programs use fd==0xfffffff
>>>>> because they emulate the communication and don't really use an fd.
>>>> I think i've found the problem. The code in client_pull() in mini.c
>>>> calls gnutls_transport_set_global_errno (EAGAIN); to tell gnutls 
>>>> library
>>>> code that the pull operation should be postponed. However, gnutls
>>>> library code in _gnutls_read() in gnutls_buffers.c:306 calls int err =
>>>> get_errno (session); to obain errno, which, in turn, returns
>>>> session->internals.errno_func 
>>>> (session->internals.transport_recv_ptr);,
>>>> which is the same as 
>>>> system_errno(session->internals.transport_recv_ptr)
>>>> at system.c:55, which simply calls WSAGetLastError(), switch'es 
>>>> over its
>>>> value and sets errno.
>>>> That is, the problem is in the fact that on Windows gnutls assumes 
>>>> that
>>>> underlying read() implementation is incapable of setting errno and is,
>>>> in fact, a socket (since gnutls uses WSAGetLastError()).
>>>> Possible fixes:
>>>> A) Fix gnutls_transport_set_global_errno() to call SetLastError() 
>>>> (note
>>>> that there's no difference between WSAGLE and GLE, unless you're 
>>>> writing
>>>> for WinSock 1.x, which is crazy, because WinSock 2.x has been shipped
>>>> with NT since NT 4.0). And maybe set errno too, just to be safe.
>>> I think I'll switch it to gnutls_transport_set_errno(), fix and
>>> deprecate the set_global_errno() function. I don't see any point
>>> in it as a function.
>> How do you access a session object in pull function?
> Anyway, i've fixed it in my local copy (patch is attached; since i 
> don't know how to access session in pull(), my patch is a bit crude)
>
> FAIL: hostname-check.exe
> FAIL: chainverify.exe
> FAIL: pgps2kgnu.exe
> FAIL: testdsa
> FAIL: testselfsigs
>
> Obviously, the improvement is considerable. Half of safe-renegotiation 
> tests failed previously, now they all pass. Mini and its variants all 
> pass.
>
> hostname check might fail because 
> function_to_get_host_by_ip(127.0.0.1) != "localhost" (known winsock bug).
>
> chainverify fails because 2 certificates have expired in January 2011. 
> A patch fixes that (although it would be better to get some new 
> certificates for this test, no?)
>
> pgps2kgnu fails because of unexplainable (and quiet!) strstr() failure 
> in armor_decode:
>
> I have no explanation whatsoever. Gnulib does not override this 
> function, it is imported from msvcrt.
> mbsstr works correctly (at least when called from gdb). Also, gnulib 
> warns about strstr() not working with multibyte charsets. This is not 
> the case here, but makes me wonder. I'll dig further.
>
The newest batch of patches (no pun intended) is attached.
Fixes:

hostname-check - as a side-effect of fixing pgps2kgnu, i think

test-binary-io - as i have thought, it's a libtool wrapper bug: instead 
of exec()'ing it spawnv()'s its child, and because of that it keeps 
sitting on top of stdout FD, blocking it, which prevents its child from 
stat()'ing it later to get its size. Hacking the script to run 
.libs/test-binary-io.exe instead solves the problem

pgps2kgnu - armor.c had a weird notion that on Windows all text files 
have CRLF EOLs, while on other systems all files have LF EOLs, no 
exceptions. Obviously this is not the case in objective reality (you can 
get certificates from wide variety of sources, some of them originate 
from different OSes), particularly in this testcase (in which the 
certificate has only LF EOLs). I've modified the code to try to match an 
empty line to both \n and \r\n. Also modified it to strip (when 
stripping EOLs) \n first, and then strip \r if it is present.
It should be noted that gdb lied about the string contents. I've been 
able to find the source of the problem only by inserting debug logging 
statements all over the place. Never trust gdb! :)

testselfsigs - Probably I/O-related. Running certtool with --infile 
"filename" appears to be working, while running with <"filename" fails 
(certtool.exe: import error: The scanning of a large integer has 
failed). I've fixed the test script to use --infile (much easier than 
hacking the source yet again to be able to debug it with gdb while 
feeding data from stdin; might be related to the way msys does its piping).

Now the only problem left is:
FAIL: testdsa
still hangs. Not sure why, too complex for me to debug. Logs are attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patches.tar.xz
Type: application/octet-stream
Size: 5760 bytes
Desc: not available
URL: </pipermail/attachments/20110406/693d2e9e/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testdsa.logs.tar.xz
Type: application/octet-stream
Size: 3996 bytes
Desc: not available
URL: </pipermail/attachments/20110406/693d2e9e/attachment-0001.obj>

From nmav at gnutls.org  Thu Apr  7 09:47:18 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 07 Apr 2011 09:47:18 +0200
Subject: W32 testsuite results
In-Reply-To: <4D9CAE2D.3090903@gmail.com>
References: <4D991939.6040701@gmail.com> <4D99D27E.7030002@gnutls.org>
	<4D99EB48.9030200@gmail.com> <4D9ACA35.1080000@gnutls.org>
	<4D9B0AA4.7000405@gmail.com> <4D9B668B.5070703@gnutls.org>
	<4D9B68AA.507@gmail.com> <4D9B94AE.3040208@gmail.com>
	<4D9CAE2D.3090903@gmail.com>
Message-ID: <4D9D6C06.4080308@gnutls.org>

On 04/06/2011 08:17 PM, LRN wrote:

Thank you.

> Now the only problem left is:
> FAIL: testdsa
> still hangs. Not sure why, too complex for me to debug. Logs are attached.

It might be that the included gnutls-cli and gnutls-serv don't operate
well in windows. I remember some issues with select() but I don't know
if the issue is the same. I'll see how I could disable this test
at windows.

regards,
Nikos



From lrn1986 at gmail.com  Thu Apr  7 12:23:02 2011
From: lrn1986 at gmail.com (LRN)
Date: Thu, 07 Apr 2011 14:23:02 +0400
Subject: W32 testsuite results
In-Reply-To: <4D9D6C06.4080308@gnutls.org>
References: <4D991939.6040701@gmail.com> <4D99D27E.7030002@gnutls.org>
	<4D99EB48.9030200@gmail.com> <4D9ACA35.1080000@gnutls.org>
	<4D9B0AA4.7000405@gmail.com> <4D9B668B.5070703@gnutls.org>
	<4D9B68AA.507@gmail.com> <4D9B94AE.3040208@gmail.com>
	<4D9CAE2D.3090903@gmail.com> <4D9D6C06.4080308@gnutls.org>
Message-ID: <4D9D9086.8020906@gmail.com>

On 07.04.2011 11:47, Nikos Mavrogiannopoulos wrote:
> On 04/06/2011 08:17 PM, LRN wrote:
>
> Thank you.
>
>> Now the only problem left is:
>> FAIL: testdsa
>> still hangs. Not sure why, too complex for me to debug. Logs are attached.
> It might be that the included gnutls-cli and gnutls-serv don't operate
> well in windows. I remember some issues with select() but I don't know
> if the issue is the same. I'll see how I could disable this test
> at windows.
>
Oh, that's easy - just check for a Windows-only envvar in the shell 
script that governs the test and return 77 on positive result.



From dbreiser at gmail.com  Thu Apr  7 20:54:28 2011
From: dbreiser at gmail.com (David Reiser)
Date: Thu, 7 Apr 2011 14:54:28 -0400
Subject: gnutls 2.12.1 won't build for me on OS X
In-Reply-To: <4D98EAFB.3010406@gnutls.org>
References: <BA789BCF-4907-4E9C-B450-9B1319EF2C81@gmail.com>
	<4D98EAFB.3010406@gnutls.org>
Message-ID: <BANLkTimTHg4LDjvTSf1nZtWQJJqUfss=Uw@mail.gmail.com>

On Sun, Apr 3, 2011 at 5:47 PM, Nikos Mavrogiannopoulos <nmav at gnutls.org>wrote:

> On 04/02/2011 05:42 PM, David Reiser wrote:
> > Under 'Making all in examples' the build quits a little later with:
> >   CCLD   ex-cert-select
> > libtool: link: warning: `-no-install' is ignored for
> i386-apple-darwin10.7.0
> > libtool: link: warning: assuming `-no-fast-install' instead
> > libtool: link: warning: library `/sw/lib/libgmp.la' was moved.
> > ld: duplicate symbol _main in
> ./.libs/libexamples.a(ex-cert-select-pkcs11.o) and ex-cert-select.o
> > collect2: ld returned 1 exit status
> > make[4]: *** [ex-cert-select] Error 1
>
> Thanks for reporting that. I've committed a fix.
>
> > And while I'm here, if nettle is replacing libgcrypt, why does
> lib/nettle/init.c still #include <gcrypt.h>?
>
> It shouldn't have been there. I've removed that. Apart from these
> did you have any issues using gnutls 2.12 in OSX?
>
> regards,
> Nikos
>

Those changes did allow 2.12.1+ to build for me. I found a packaging problem
I created in nettle trying to build nettle as shared libraries. I think I
have that one fixed. Gnutls with the mods seems to work for me with https
connections (via gwenhywfar for connections to bank data streams). I'm
trying to get some friends at fink to test my packaging more thoroughly with
some other packages. But so far it looks good.

Thanks for the fixes.

--
Dave Reiser
dbreiser at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20110407/f535bd09/attachment.htm>

From nmav at gnutls.org  Thu Apr  7 23:55:35 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 07 Apr 2011 23:55:35 +0200
Subject: W32 testsuite results
In-Reply-To: <4D9B94AE.3040208@gmail.com>
References: <4D991939.6040701@gmail.com> <4D99D27E.7030002@gnutls.org>
	<4D99EB48.9030200@gmail.com> <4D9ACA35.1080000@gnutls.org>
	<4D9B0AA4.7000405@gmail.com> <4D9B668B.5070703@gnutls.org>
	<4D9B68AA.507@gmail.com> <4D9B94AE.3040208@gmail.com>
Message-ID: <4D9E32D7.6060102@gnutls.org>

On 04/06/2011 12:16 AM, LRN wrote:

> chainverify fails because 2 certificates have expired in January 2011. A
> patch fixes that (although it would be better to get some new
> certificates for this test, no?)

chainverify hardcodes the time by defining the time() function. It
seems in windows the system one is used. It seems the windows loader
operates differently than the Linux one. If you don't know of any
way to override a system function in windows it might be better
to disable those tests there.

regards,
Nikos




From nmav at gnutls.org  Fri Apr  8 00:06:14 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 08 Apr 2011 00:06:14 +0200
Subject: W32 testsuite results
In-Reply-To: <4D9CAE2D.3090903@gmail.com>
References: <4D991939.6040701@gmail.com> <4D99D27E.7030002@gnutls.org>
	<4D99EB48.9030200@gmail.com> <4D9ACA35.1080000@gnutls.org>
	<4D9B0AA4.7000405@gmail.com> <4D9B668B.5070703@gnutls.org>
	<4D9B68AA.507@gmail.com> <4D9B94AE.3040208@gmail.com>
	<4D9CAE2D.3090903@gmail.com>
Message-ID: <4D9E3556.1090504@gnutls.org>

On 04/06/2011 08:17 PM, LRN wrote:

Does this in configure.ac cause a problem in windows?
-if test -d tests/suite;then
-AC_CONFIG_FILES([tests/suite/Makefile])
-fi

We use it to run extra tests on the git branch. Is test
the problem?


regards,
Nikos



From INVALID.NOREPLY at gnu.org  Fri Apr  8 01:27:40 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Thu, 07 Apr 2011 23:27:40 +0000
Subject: [sr #107648] Misleading documentation for
	GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT
In-Reply-To: <20110405-103628.sv57531.47577@savannah.gnu.org>
References: <20110405-015244.sv82329.53884@savannah.gnu.org>
	<20110405-103628.sv57531.47577@savannah.gnu.org>
Message-ID: <20110408-022740.sv707.99394@savannah.gnu.org>

Update of sr #107648 (project gnutls):

                  Status:                    None => Done                   
             Assigned to:                    None => nmav                   
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up Comment #2:

You are correct. It will be fixed in the next version.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107648>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From vincent.torri at gmail.com  Fri Apr  8 07:58:07 2011
From: vincent.torri at gmail.com (Vincent Torri)
Date: Fri, 8 Apr 2011 07:58:07 +0200
Subject: W32 testsuite results
In-Reply-To: <4D9E3556.1090504@gnutls.org>
References: <4D991939.6040701@gmail.com> <4D99D27E.7030002@gnutls.org>
	<4D99EB48.9030200@gmail.com> <4D9ACA35.1080000@gnutls.org>
	<4D9B0AA4.7000405@gmail.com> <4D9B668B.5070703@gnutls.org>
	<4D9B68AA.507@gmail.com> <4D9B94AE.3040208@gmail.com>
	<4D9CAE2D.3090903@gmail.com> <4D9E3556.1090504@gnutls.org>
Message-ID: <BANLkTikBa02wbBhXQrCH48sBCAGtobankg@mail.gmail.com>

On Fri, Apr 8, 2011 at 12:06 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org>wrote:

> On 04/06/2011 08:17 PM, LRN wrote:
>
> Does this in configure.ac cause a problem in windows?
> -if test -d tests/suite;then
> -AC_CONFIG_FILES([tests/suite/Makefile])
> -fi
>
> We use it to run extra tests on the git branch. Is test
> the problem?
>

It's not the correct way to do what you want . Do that instead:

AM_CONDITIONAL([WANT_TEST_SUITE], [test -d tests/suite])

and in tests/Makefile.am, remove 'suite' from SUBDIRS and add:

if WANT_TEST_SUITE
SUBDIRS += suite
endif

Vincent Torri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20110408/b44dfb59/attachment.htm>

From lrn1986 at gmail.com  Fri Apr  8 08:24:22 2011
From: lrn1986 at gmail.com (LRN)
Date: Fri, 08 Apr 2011 10:24:22 +0400
Subject: W32 testsuite results
In-Reply-To: <4D9E3556.1090504@gnutls.org>
References: <4D991939.6040701@gmail.com> <4D99D27E.7030002@gnutls.org>
	<4D99EB48.9030200@gmail.com> <4D9ACA35.1080000@gnutls.org>
	<4D9B0AA4.7000405@gmail.com> <4D9B668B.5070703@gnutls.org>
	<4D9B68AA.507@gmail.com> <4D9B94AE.3040208@gmail.com>
	<4D9CAE2D.3090903@gmail.com> <4D9E3556.1090504@gnutls.org>
Message-ID: <4D9EAA16.8030209@gmail.com>

On 08.04.2011 2:06, Nikos Mavrogiannopoulos wrote:
> On 04/06/2011 08:17 PM, LRN wrote:
>
> Does this in configure.ac cause a problem in windows?
> -if test -d tests/suite;then
> -AC_CONFIG_FILES([tests/suite/Makefile])
> -fi
>
> We use it to run extra tests on the git branch. Is test
> the problem?
>
Yes, it is the problem, because tests/suite/Makefile does not exist in 
the source tarball, which makes it impossible to run `autoreconf` on it. 
Reconfiguring might not be strictly necessary though, i'll try to make 
do without it and will get back to you on this if that works.



From nmav at gnutls.org  Fri Apr  8 10:00:31 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 8 Apr 2011 10:00:31 +0200
Subject: W32 testsuite results
In-Reply-To: <BANLkTikBa02wbBhXQrCH48sBCAGtobankg@mail.gmail.com>
References: <4D991939.6040701@gmail.com> <4D99D27E.7030002@gnutls.org>
	<4D99EB48.9030200@gmail.com> <4D9ACA35.1080000@gnutls.org>
	<4D9B0AA4.7000405@gmail.com> <4D9B668B.5070703@gnutls.org>
	<4D9B68AA.507@gmail.com> <4D9B94AE.3040208@gmail.com>
	<4D9CAE2D.3090903@gmail.com> <4D9E3556.1090504@gnutls.org>
	<BANLkTikBa02wbBhXQrCH48sBCAGtobankg@mail.gmail.com>
Message-ID: <BANLkTinGGr5snKLPbbOQo=q2QVjAw=1A7w@mail.gmail.com>

On Fri, Apr 8, 2011 at 7:58 AM, Vincent Torri <vincent.torri at gmail.com> wrote:

>> Does this in configure.ac cause a problem in windows?
>> -if test -d tests/suite;then
>> -AC_CONFIG_FILES([tests/suite/Makefile])
>> -fi
>> We use it to run extra tests on the git branch. Is test
>> the problem?
> It's not the correct way to do what you want . Do that instead:
> AM_CONDITIONAL([WANT_TEST_SUITE], [test -d tests/suite])
> and in tests/Makefile.am, remove 'suite' from SUBDIRS and add:
> if WANT_TEST_SUITE
> SUBDIRS += suite
> endif

The problem is that I don't want to distribute that directory. If I use
this approach the directory is being included in the distribution.

regards,
Nikos



From lrn1986 at gmail.com  Fri Apr  8 10:12:18 2011
From: lrn1986 at gmail.com (LRN)
Date: Fri, 08 Apr 2011 12:12:18 +0400
Subject: W32 testsuite results
In-Reply-To: <BANLkTinGGr5snKLPbbOQo=q2QVjAw=1A7w@mail.gmail.com>
References: <4D991939.6040701@gmail.com> <4D99D27E.7030002@gnutls.org>
	<4D99EB48.9030200@gmail.com> <4D9ACA35.1080000@gnutls.org>
	<4D9B0AA4.7000405@gmail.com> <4D9B668B.5070703@gnutls.org>
	<4D9B68AA.507@gmail.com> <4D9B94AE.3040208@gmail.com>
	<4D9CAE2D.3090903@gmail.com> <4D9E3556.1090504@gnutls.org>
	<BANLkTikBa02wbBhXQrCH48sBCAGtobankg@mail.gmail.com>
	<BANLkTinGGr5snKLPbbOQo=q2QVjAw=1A7w@mail.gmail.com>
Message-ID: <4D9EC362.2040707@gmail.com>

On 08.04.2011 12:00, Nikos Mavrogiannopoulos wrote:
> On Fri, Apr 8, 2011 at 7:58 AM, Vincent Torri<vincent.torri at gmail.com>  wrote:
>
>>> Does this in configure.ac cause a problem in windows?
>>> -if test -d tests/suite;then
>>> -AC_CONFIG_FILES([tests/suite/Makefile])
>>> -fi
>>> We use it to run extra tests on the git branch. Is test
>>> the problem?
>> It's not the correct way to do what you want . Do that instead:
>> AM_CONDITIONAL([WANT_TEST_SUITE], [test -d tests/suite])
>> and in tests/Makefile.am, remove 'suite' from SUBDIRS and add:
>> if WANT_TEST_SUITE
>> SUBDIRS += suite
>> endif
> The problem is that I don't want to distribute that directory. If I use
> this approach the directory is being included in the distribution.
>
The problem is that you should make this conditional.
WANT_TEST_SUITE automake conditional variable will be TRUE if 
tests/suite exists and FALSE otherwise.
Then while processing Makefile.am Automake will add 'suite' to the list 
of subdirs if it exists and will not add it otherwise.
You'd also need to put AC_CONFIG_FILES into

AM_COND_IF([WANT_TEST_SUITE],
                 [AC_CONFIG_FILES([tests/suite/Makefile])])


Well, that's my theory anyway.



From vincent.torri at gmail.com  Fri Apr  8 11:05:59 2011
From: vincent.torri at gmail.com (Vincent Torri)
Date: Fri, 8 Apr 2011 11:05:59 +0200
Subject: W32 testsuite results
In-Reply-To: <BANLkTinGGr5snKLPbbOQo=q2QVjAw=1A7w@mail.gmail.com>
References: <4D991939.6040701@gmail.com> <4D99D27E.7030002@gnutls.org>
	<4D99EB48.9030200@gmail.com> <4D9ACA35.1080000@gnutls.org>
	<4D9B0AA4.7000405@gmail.com> <4D9B668B.5070703@gnutls.org>
	<4D9B68AA.507@gmail.com> <4D9B94AE.3040208@gmail.com>
	<4D9CAE2D.3090903@gmail.com> <4D9E3556.1090504@gnutls.org>
	<BANLkTikBa02wbBhXQrCH48sBCAGtobankg@mail.gmail.com>
	<BANLkTinGGr5snKLPbbOQo=q2QVjAw=1A7w@mail.gmail.com>
Message-ID: <BANLkTikGnaz=i5vwxM5RRbHFcUZSr2eQPQ@mail.gmail.com>

On Fri, Apr 8, 2011 at 10:00 AM, Nikos Mavrogiannopoulos <nmav at gnutls.org>wrote:

> On Fri, Apr 8, 2011 at 7:58 AM, Vincent Torri <vincent.torri at gmail.com>
> wrote:
>
> >> Does this in configure.ac cause a problem in windows?
> >> -if test -d tests/suite;then
> >> -AC_CONFIG_FILES([tests/suite/Makefile])
> >> -fi
> >> We use it to run extra tests on the git branch. Is test
> >> the problem?
> > It's not the correct way to do what you want . Do that instead:
> > AM_CONDITIONAL([WANT_TEST_SUITE], [test -d tests/suite])
> > and in tests/Makefile.am, remove 'suite' from SUBDIRS and add:
> > if WANT_TEST_SUITE
> > SUBDIRS += suite
> > endif
>
> The problem is that I don't want to distribute that directory. If I use
> this approach the directory is being included in the distribution.
>


http://sources.redhat.com/automake/automake.html#Fine_002dgrained-Distribution-Control

Vincent Torri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20110408/c53776cc/attachment.htm>

From nmav at gnutls.org  Fri Apr  8 18:43:07 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 08 Apr 2011 18:43:07 +0200
Subject: gnutls 2.12.2
Message-ID: <4D9F3B1B.8030301@gnutls.org>

I've just released gnutls 2.12.2. No new features, but several
bug fixes.

What's New
==========
* Version 2.12.2 (released 2011-04-08)

** libgnutls: Several updates and fixes for win32. Patches by LRN.

** libgnutls: Several bug and memory leak fixes.

** srptool: Accepts the -d option to enable debugging.

** libgnutls: Corrected bug in gnutls_srp_verifier() that prevented
the allocation of a verifier. Reported by Andrew Wiseman.

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

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

GnuTLS may be downloaded from one of the GNU mirror sites or directly
>From <ftp://ftp.gnu.org/gnu/gnutls/?.  The list of GNU mirrors can be
found at <http://www.gnu.org/prep/ftp.html> and a list of GnuTLS mirrors
can be found at <http://www.gnu.org/software/gnutls/download.html>.

Here are the BZIP2 compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.2.tar.bz2
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.2.tar.bz2

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.2.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.2.tar.bz2.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 Apr  9 10:05:56 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 09 Apr 2011 10:05:56 +0200
Subject: gnutls 2.99.0
Message-ID: <4DA01364.3010306@gnutls.org>

Hello,

The GnuTLS 2.99.x branch is NOT what you want for your stable system.
It is intended for developers and experienced users.

This is an update release that includes features such as Datagram TLS
AES-GCM and more.

This release includes documentation for the usage of DTLS as part
of the main GnuTLS manual, but the major changes are summarized by
this commit:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=08a1b04b3d049a4a44132c0bce0c017c0c70f892

The changes since the last stable branch are:
* Version 2.99.0 (released 2011-04-09)

** libgnutls: Added Datagram TLS support.

** libgnutls: Uses a single configure file and a single
gnulib library to save space.

** libgnutls: Several bug fixes.

** libgnutls: gnutls_transport_set_lowat() is no more.

** libgnutls-openssl: modified to use modern gnutls' functions.
This introduces an ABI incompatibility with previous versions.

** libgnutls: Corrected signature generation and verification
in the Certificate Verify message when in TLS 1.2. Reported
by Todd A. Ouska.

** libgnutlsxx: The C++ interface returns exception on
every error and not only on fatal ones. This allows easier
handling of errors.

** libgnutls: Corrected issue in DHE-PSK ciphersuites that ignored
the PSK callback.

** libgnutls: SRP and PSK are no longer set on the default priorities.
They have to be explicitly set.

** libgnutls: During handshake message verification using DSS
use the hash algorithm required by it.

** libgnutls: gnutls_recv() return GNUTLS_E_PREMATURE_TERMINATION
on unexpected EOF, instead of GNUTLS_E_UNEXPECTED_PACKET_LENGTH.

** libgnutls: Added GCM mode (interoperates with tls.secg.org)

** libgnutls-extra: Inner application extension was removed.
It was never standardized nor published as an RFC.

** libgnutls: Added new certificate verification functions, that
can provide more details and are more efficient. Check
gnutls_x509_trust_list_*.

** certtool: Uses the new certificate verification functions for
--verify-chain.

** certtool: Added new certificate verification functionality
using the --verify option. Combined with --load-ca-certificate
it can verify a certificate chain against a list of certificates.

** API and ABI modifications:
gnutls_dtls_set_timeouts: ADDED
gnutls_dtls_get_mtu: ADDED
gnutls_dtls_get_data_mtu: ADDED
gnutls_dtls_set_mtu: ADDED
gnutls_dtls_cookie_send: ADDED
gnutls_dtls_cookie_verify: ADDED
gnutls_dtls_prestate_set: ADDED
gnutls_x509_trust_list_verify_crt: ADDED
gnutls_x509_trust_list_add_crls: ADDED
gnutls_x509_trust_list_add_cas: ADDED
gnutls_x509_trust_list_init: ADDED
gnutls_x509_trust_list_deinit: ADDED
gnutls_cipher_add_auth: ADDED
gnutls_cipher_tag: ADDED
gnutls_psk_netconf_derive_key: REMOVED
gnutls_certificate_verify_peers: REMOVED
gnutls_session_set_finished_function: REMOVED
gnutls_ext_register: REMOVED
gnutls_certificate_get_x509_crls: REMOVED
gnutls_certificate_get_x509_cas: REMOVED
gnutls_certificate_get_openpgp_keyring: REMOVED
gnutls_session_get_server_random: REMOVED
gnutls_session_get_client_random: REMOVED
gnutls_session_get_master_secret: REMOVED
gnutls_ia_allocate_client_credentials: REMOVED
gnutls_ia_allocate_server_credentials: REMOVED
gnutls_ia_enable: REMOVED
gnutls_ia_endphase_send: REMOVED
gnutls_ia_extract_inner_secret: REMOVED
gnutls_ia_free_client_credentials: REMOVED
gnutls_ia_free_server_credentials: REMOVED
gnutls_ia_generate_challenge: REMOVED
gnutls_ia_get_client_avp_ptr: REMOVED
gnutls_ia_get_server_avp_ptr: REMOVED
gnutls_ia_handshake: REMOVED
gnutls_ia_handshake_p: REMOVED
gnutls_ia_permute_inner_secret: REMOVED
gnutls_ia_recv: REMOVED
gnutls_ia_send: REMOVED
gnutls_ia_set_client_avp_function: REMOVED
gnutls_ia_set_client_avp_ptr: REMOVED
gnutls_ia_set_server_avp_function: REMOVED
gnutls_ia_set_server_avp_ptr: REMOVED
gnutls_ia_verify_endphase: REMOVED


Here are the compressed sources:
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.99.0.tar.bz2
  ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-2.99.0.tar.bz2

Here is the OpenPGP signature:
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.99.0.tar.bz2.sig
  ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-2.99.0.tar.bz2.sig

regards,
Nikos




From nmav at gnutls.org  Sat Apr  9 11:41:55 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 09 Apr 2011 11:41:55 +0200
Subject: gnutls 2.99.0
In-Reply-To: <4DA01364.3010306@gnutls.org>
References: <4DA01364.3010306@gnutls.org>
Message-ID: <4DA029E3.8090607@gnutls.org>

On 04/09/2011 10:05 AM, Nikos Mavrogiannopoulos wrote:

> This is an update release that includes features such as Datagram TLS
> AES-GCM and more.

For the support of AES-GCM you need the libnettle library from
the cvs. There are instructions to obtain it at:
http://www.lysator.liu.se/~nisse/nettle/

regards,
Nikos



From INVALID.NOREPLY at gnu.org  Sun Apr 10 20:44:59 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 10 Apr 2011 18:44:59 +0000
Subject: [sr #107647] Gnutls fails several tests - A TLS packet with
	unexpected length was received.
In-Reply-To: <20110404-124930.sv74148.75292@savannah.gnu.org>
References: <20110404-124930.sv74148.75292@savannah.gnu.org>
Message-ID: <20110410-214459.sv707.60867@savannah.gnu.org>

Update of sr #107647 (project gnutls):

                  Status:                    None => Done                   
             Assigned to:                    None => nmav                   
             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107647>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sun Apr 10 20:45:39 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 10 Apr 2011 18:45:39 +0000
Subject: [sr #107606] Use of uninitialized variable kid in
	_gnutls_check_key_cert_match
In-Reply-To: <20110226-025435.sv81876.52067@savannah.gnu.org>
References: <20110226-025435.sv81876.52067@savannah.gnu.org>
Message-ID: <20110410-214539.sv707.7140@savannah.gnu.org>

Update of sr #107606 (project gnutls):

                  Status:                    None => Done                   
             Assigned to:                    None => nmav                   
             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107606>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sun Apr 10 20:45:49 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 10 Apr 2011 18:45:49 +0000
Subject: [sr #107605] Uninitialized variable "md" use in
	file_verify_clearsign()
In-Reply-To: <20110325-195035.sv81876.96911@savannah.gnu.org>
References: <20110226-024147.sv81876.49001@savannah.gnu.org>
	<20110325-213725.sv707.86817@savannah.gnu.org>
	<20110325-195035.sv81876.96911@savannah.gnu.org>
Message-ID: <20110410-214548.sv707.31797@savannah.gnu.org>

Update of sr #107605 (project gnutls):

             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107605>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sun Apr 10 20:46:29 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 10 Apr 2011 18:46:29 +0000
Subject: [sr #107527] Use of dangerous/banned functions (Analysis)
In-Reply-To: <20101119-085011.sv73003.11981@savannah.gnu.org>
References: <20101119-030342.sv80862.45182@savannah.gnu.org>
	<20101119-063507.sv7213.93644@savannah.gnu.org>
	<20101119-085011.sv73003.11981@savannah.gnu.org>
Message-ID: <20110410-214629.sv707.61435@savannah.gnu.org>

Update of sr #107527 (project gnutls):

                  Status:                    None => Need Info              
             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107527>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sun Apr 10 20:46:45 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 10 Apr 2011 18:46:45 +0000
Subject: [sr #107525] Use of dangerous/banned functions (Particular
	Instances)
In-Reply-To: <20101119-062638.sv7213.29249@savannah.gnu.org>
References: <20101119-000016.sv80862.1214@savannah.gnu.org>
	<20101119-062638.sv7213.29249@savannah.gnu.org>
Message-ID: <20110410-214645.sv707.53906@savannah.gnu.org>

Update of sr #107525 (project gnutls):

                  Status:                    None => Done                   
             Assigned to:                    None => nmav                   
             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107525>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sun Apr 10 20:47:15 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 10 Apr 2011 18:47:15 +0000
Subject: [sr #107524] Test suite: gnutls_global_init/gnutls_global_deinit
In-Reply-To: <20101119-062258.sv7213.84357@savannah.gnu.org>
References: <20101118-100108.sv80862.92544@savannah.gnu.org>
	<20101118-115752.sv80862.70845@savannah.gnu.org>
	<20101118-115955.sv80862.42903@savannah.gnu.org>
	<20101119-062258.sv7213.84357@savannah.gnu.org>
Message-ID: <20110410-214715.sv707.33925@savannah.gnu.org>

Update of sr #107524 (project gnutls):

             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107524>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sun Apr 10 20:47:36 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 10 Apr 2011 18:47:36 +0000
Subject: [sr #107522] Use of dangerous/banned functions
In-Reply-To: <20101118-032144.sv80862.63609@savannah.gnu.org>
References: <20101116-233010.sv80862.81354@savannah.gnu.org>
	<20101117-000900.sv80862.28538@savannah.gnu.org>
	<20101117-004941.sv80862.38538@savannah.gnu.org>
	<20101117-035230.sv80862.66785@savannah.gnu.org>
	<20101117-143404.sv7213.15048@savannah.gnu.org>
	<20101117-231851.sv80862.84166@savannah.gnu.org>
	<20101118-032144.sv80862.63609@savannah.gnu.org>
Message-ID: <20110410-214736.sv707.74473@savannah.gnu.org>

Update of sr #107522 (project gnutls):

             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107522>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sun Apr 10 20:47:53 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 10 Apr 2011 18:47:53 +0000
Subject: [sr #107521] Lint encountered during compile
In-Reply-To: <20101117-143607.sv7213.47574@savannah.gnu.org>
References: <20101116-175050.sv80862.34609@savannah.gnu.org>
	<20101116-212719.sv7213.99920@savannah.gnu.org>
	<20101117-071759.sv80862.73064@savannah.gnu.org>
	<20101117-072435.sv80862.19583@savannah.gnu.org>
	<20101117-075640.sv80862.14088@savannah.gnu.org>
	<20101117-120638.sv0.32188@savannah.gnu.org>
	<20101117-143607.sv7213.47574@savannah.gnu.org>
Message-ID: <20110410-214753.sv707.93451@savannah.gnu.org>

Update of sr #107521 (project gnutls):

             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107521>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sun Apr 10 20:48:04 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 10 Apr 2011 18:48:04 +0000
Subject: [sr #107409] The lack of built-in threading support is a critical
	design flaw
In-Reply-To: <20100712-165922.sv79072.50027@savannah.gnu.org>
References: <20100624-155547.sv79072.29581@savannah.gnu.org>
	<20100703-133746.sv707.92700@savannah.gnu.org>
	<20100703-134327.sv707.35926@savannah.gnu.org>
	<20100712-165922.sv79072.50027@savannah.gnu.org>
Message-ID: <20110410-214804.sv707.6897@savannah.gnu.org>

Update of sr #107409 (project gnutls):

                  Status:             In Progress => Done                   
             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107409>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sun Apr 10 20:48:13 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 10 Apr 2011 18:48:13 +0000
Subject: [sr #107312] Problem compiling gnutls 2.8.6
In-Reply-To: <20100703-134415.sv707.54929@savannah.gnu.org>
References: <20100316-180040.sv12134.88040@savannah.gnu.org>
	<20100316-183817.sv12134.66826@savannah.gnu.org>
	<20100317-064939.sv7213.48926@savannah.gnu.org>
	<20100317-083531.sv15145.74631@savannah.gnu.org>
	<20100703-134415.sv707.54929@savannah.gnu.org>
Message-ID: <20110410-214813.sv707.6787@savannah.gnu.org>

Update of sr #107312 (project gnutls):

             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107312>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sun Apr 10 20:48:26 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 10 Apr 2011 18:48:26 +0000
Subject: [sr #107300] configure.in doesn't detect guile-devel pkg absence
In-Reply-To: <20100316-090002.sv7213.72787@savannah.gnu.org>
References: <20100309-210859.sv77719.90813@savannah.gnu.org>
	<20100315-091951.sv7213.61366@savannah.gnu.org>
	<20100316-014311.sv77719.79142@savannah.gnu.org>
	<20100316-090002.sv7213.72787@savannah.gnu.org>
Message-ID: <20110410-214826.sv707.60254@savannah.gnu.org>

Update of sr #107300 (project gnutls):

             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107300>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sun Apr 10 20:49:12 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 10 Apr 2011 18:49:12 +0000
Subject: [sr #106869] [2.6.6 darwin] duplicate symbols '___gmpz_abs' in
	'libguile_gnutls'
In-Reply-To: <20090718-044510.sv67508.44723@savannah.gnu.org>
References: <20090604-030050.sv67508.82037@savannah.gnu.org>
	<20090604-064139.sv15145.13955@savannah.gnu.org>
	<20090604-064809.sv15145.56805@savannah.gnu.org>
	<20090615-023832.sv67508.9215@savannah.gnu.org>
	<20090621-135017.sv15145.47097@savannah.gnu.org>
	<20090718-044510.sv67508.44723@savannah.gnu.org>
Message-ID: <20110410-214911.sv707.55742@savannah.gnu.org>

Update of sr #106869 (project gnutls):

             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?106869>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Sun Apr 10 20:49:35 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 10 Apr 2011 18:49:35 +0000
Subject: [sr #107634] Change to nettle breaks compatibility (2.11.7)
In-Reply-To: <20110322-195425.sv707.22504@savannah.gnu.org>
References: <20110322-165133.sv82170.13113@savannah.gnu.org>
	<20110322-195425.sv707.22504@savannah.gnu.org>
Message-ID: <20110410-214935.sv707.43824@savannah.gnu.org>

Update of sr #107634 (project gnutls):

             Open/Closed:                    Open => Closed                 


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107634>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From nisse at lysator.liu.se  Tue Apr 12 11:27:42 2011
From: nisse at lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=)
Date: Tue, 12 Apr 2011 11:27:42 +0200
Subject: different lib directories for gnutls and nettle
In-Reply-To: <4D97B452.9080100@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sun, 03 Apr 2011 01:42:10 +0200")
References: <437hbgql64.wl%bjg@gnu.org> <4D97B452.9080100@gnutls.org>
Message-ID: <nnd3kru8dt.fsf@stalhein.lysator.liu.se>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Indeed it seems nettle for some reason uses the /usr/lib64. Niels,
> is there really a reason for that? As I understand from the FHS[0]
> /usr/lib is the system library directory. /usr/lib64 and /usr/lib32
> might not even be there.

Sorry for the late reply. A bit down in the same document,
http://www.pathname.com/fhs/pub/fhs-2.3.html, it says

  /lib64 and /lib32 : 64/32-bit libraries (architecture dependent)
  
  The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place
  64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in
  /lib.

If you believe this, then it's wrong to install 64-bit libraries in lib.
And I believed so when I wrote this part of the nettle configure.ac...

But then it turned out that at least debian on x86_64 ignores this part
of the FHS, and puts the 64-bit libraries in lib, and 32-bit libraries
in lib32. Which seems to also be the freebsd way of doing it.

In the debian case, lib64 is a symlink to lib, so it doesn't matter for
a 64-bit builds (they will be installed in lib64, which is a symlink to
lib, which is tye right place), while a build with ./configure CC="gcc
-m32" && make && make install will install the 32-bit library files in
the wrong place.

I'm not sure what the right thing is. Is there any distribution which
actuallly does what the FHS says? If so, I guess configure needs to
check what directories exists, and install in lib$ABI whenever that
directory exists, otherwise in lib. I haven't got around to fixing that.

Regards,
/Niels

-- 
Niels M?ller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.



From INVALID.NOREPLY at gnu.org  Tue Apr 12 14:26:23 2011
From: INVALID.NOREPLY at gnu.org (Michael Hellwig)
Date: Tue, 12 Apr 2011 12:26:23 +0000
Subject: [sr #107660] gnutls update to 2.12 branch breaks programs in ARCH and
	Debian squeeze
Message-ID: <20110412-122623.sv82434.96453@savannah.gnu.org>

URL:
  <http://savannah.gnu.org/support/?107660>

                 Summary: gnutls update to 2.12 branch breaks programs in ARCH
and Debian squeeze
                 Project: GnuTLS
            Submitted by: mhellwig
            Submitted on: Tue 12 Apr 2011 12:26:19 PM GMT
                Category: None
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: GNU/Linux

    _______________________________________________________

Details:

I don't really have much more info than "before the update, things worked, now
they don't".

bugs at 
https://bugs.archlinux.org/task/23678
(note: in that bug somebody mentions that it also breaks claws-mail, not just
bitlbee)
http://bugs.bitlbee.org/bitlbee/ticket/779

at least in the case of bitlbee, I've tested that the problem goes away when I
downgrade to gnutls 2.10.5 or link the program against openssl instead.
Bitlbee developers also recommend linking against nss but when I do that, I
get another problem (although there the connection doesn't hang, it just dies
right away).




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107660>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Tue Apr 12 14:34:38 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Tue, 12 Apr 2011 12:34:38 +0000
Subject: [sr #107660] gnutls update to 2.12 branch breaks programs in ARCH and
	Debian squeeze
In-Reply-To: <20110412-122623.sv82434.96453@savannah.gnu.org>
References: <20110412-122623.sv82434.96453@savannah.gnu.org>
Message-ID: <20110412-153438.sv707.56854@savannah.gnu.org>

Update of sr #107660 (project gnutls):

                  Status:                    None => Need Info              
             Assigned to:                    None => nmav                   

    _______________________________________________________

Follow-up Comment #1:

Hello,
 If you revert the patch in unpatch.txt, do the issues go away?


(file #23212)
    _______________________________________________________

Additional Item Attachment:

File name: unpatch.txt                    Size:0 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107660>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Tue Apr 12 14:58:48 2011
From: INVALID.NOREPLY at gnu.org (Michael Hellwig)
Date: Tue, 12 Apr 2011 12:58:48 +0000
Subject: [sr #107660] gnutls update to 2.12 branch breaks programs in ARCH and
	Debian squeeze
In-Reply-To: <20110412-153438.sv707.56854@savannah.gnu.org>
References: <20110412-122623.sv82434.96453@savannah.gnu.org>
	<20110412-153438.sv707.56854@savannah.gnu.org>
Message-ID: <20110412-125848.sv82434.87468@savannah.gnu.org>

Follow-up Comment #2, sr #107660 (project gnutls):

indeed yes, at least for the bitlbee case. the claws-mail case was reported by
somebody else, can't test for that.

So hooray, reverting the patch fixes things. Does that mean gnutls has a
slight problem that will now be fixed? or that other software does and some
workaround broke due to that patch? Or .. other options?

thanks!

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107660>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From bjg at gnu.org  Tue Apr 12 15:31:36 2011
From: bjg at gnu.org (Brian Gough)
Date: Tue, 12 Apr 2011 14:31:36 +0100
Subject: different lib directories for gnutls and nettle
In-Reply-To: <nnd3kru8dt.fsf@stalhein.lysator.liu.se>
References: <437hbgql64.wl%bjg@gnu.org> <4D97B452.9080100@gnutls.org>
	<nnd3kru8dt.fsf@stalhein.lysator.liu.se>
Message-ID: <43y63fppdz.wl%bjg@gnu.org>

At Tue, 12 Apr 2011 11:27:42 +0200,
Niels M?ller wrote:
> I'm not sure what the right thing is. Is there any distribution which
> actuallly does what the FHS says? If so, I guess configure needs to
> check what directories exists, and install in lib$ABI whenever that
> directory exists, otherwise in lib. I haven't got around to fixing that.

Hi Niels. 

I don't know what is the correct interpretation of the FHS, but by
default all other autoconf'ed and GNU packages always use
libdir=$prefix/lib (with the --libdir option allowing it to be
overridden if someone wants to use lib64 or whatever).

So I'd recommend to use the autoconf default of $prefix/lib, as you
will be in the good company of hundreds of other packages that way.

The distributions already have their own ways of using --libdir on
autoconf'ed packages so you don't need to worry about it yourself.

-- 
Brian Gough




From INVALID.NOREPLY at gnu.org  Tue Apr 12 15:38:53 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Tue, 12 Apr 2011 13:38:53 +0000
Subject: [sr #107660] gnutls update to 2.12 branch breaks programs in ARCH and
	Debian squeeze
In-Reply-To: <20110412-125848.sv82434.87468@savannah.gnu.org>
References: <20110412-122623.sv82434.96453@savannah.gnu.org>
	<20110412-153438.sv707.56854@savannah.gnu.org>
	<20110412-125848.sv82434.87468@savannah.gnu.org>
Message-ID: <20110412-163853.sv707.39141@savannah.gnu.org>

Update of sr #107660 (project gnutls):

                  Status:               Need Info => Wont Do                

    _______________________________________________________

Follow-up Comment #3:

Unfortunately not :( I just wanted to test what was the issue. gnutls 2.12.0
changed the semantics of gnutls_transport_set_lowat() and the default value is
zero.

There are two solutions.
1. Quick fix. Programs that require another value must explicitly call:
gnutls_transport_set_lowat (session, 1);

after (gnutls_init()). 

2. Long-term fix. Because later versions of gnutls abolish the functionality
of using the system call select() to check for gnutls pending data, the
function
gnutls_record_check_pending() 
has to be used to achieve the same functionality.

regards,
Nikos


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107660>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Tue Apr 12 15:49:45 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Tue, 12 Apr 2011 13:49:45 +0000
Subject: [sr #107660] gnutls update to 2.12 branch breaks programs in ARCH and
	Debian squeeze
In-Reply-To: <20110412-164715.sv707.89667@savannah.gnu.org>
References: <20110412-122623.sv82434.96453@savannah.gnu.org>
	<20110412-153438.sv707.56854@savannah.gnu.org>
	<20110412-125848.sv82434.87468@savannah.gnu.org>
	<20110412-163853.sv707.39141@savannah.gnu.org>
	<20110412-134516.sv82434.5097@savannah.gnu.org>
	<20110412-164715.sv707.89667@savannah.gnu.org>
Message-ID: <20110412-164945.sv707.39713@savannah.gnu.org>

Follow-up Comment #6, sr #107660 (project gnutls):

If more information on how to use the gnutls_record_check_pending() is
required, here is our modification of gnutls-cli to use it:

http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=20e0e448a2f3685cc6244f7c052b32f3f0719f73


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107660>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Tue Apr 12 15:47:15 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Tue, 12 Apr 2011 13:47:15 +0000
Subject: [sr #107660] gnutls update to 2.12 branch breaks programs in ARCH and
	Debian squeeze
In-Reply-To: <20110412-134516.sv82434.5097@savannah.gnu.org>
References: <20110412-122623.sv82434.96453@savannah.gnu.org>
	<20110412-153438.sv707.56854@savannah.gnu.org>
	<20110412-125848.sv82434.87468@savannah.gnu.org>
	<20110412-163853.sv707.39141@savannah.gnu.org>
	<20110412-134516.sv82434.5097@savannah.gnu.org>
Message-ID: <20110412-164715.sv707.89667@savannah.gnu.org>

Follow-up Comment #5, sr #107660 (project gnutls):

Thank you. We could fix it in gnutls 2.12.x and restore the old default, but
we'll just postpone the inevitable for the next release that abolishes that
functionality. 

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107660>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Tue Apr 12 15:45:17 2011
From: INVALID.NOREPLY at gnu.org (Michael Hellwig)
Date: Tue, 12 Apr 2011 13:45:17 +0000
Subject: [sr #107660] gnutls update to 2.12 branch breaks programs in ARCH and
	Debian squeeze
In-Reply-To: <20110412-163853.sv707.39141@savannah.gnu.org>
References: <20110412-122623.sv82434.96453@savannah.gnu.org>
	<20110412-153438.sv707.56854@savannah.gnu.org>
	<20110412-125848.sv82434.87468@savannah.gnu.org>
	<20110412-163853.sv707.39141@savannah.gnu.org>
Message-ID: <20110412-134516.sv82434.5097@savannah.gnu.org>

Follow-up Comment #4, sr #107660 (project gnutls):

ok .. well I'll try and communicate that to the bitlbee people .. as for other
projects .. who knows. at least now you'll know what all those bugs will be
about ;)

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107660>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From nisse at lysator.liu.se  Tue Apr 12 16:48:21 2011
From: nisse at lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=)
Date: Tue, 12 Apr 2011 16:48:21 +0200
Subject: different lib directories for gnutls and nettle
In-Reply-To: <43y63fppdz.wl%bjg@gnu.org> (Brian Gough's message of "Tue, 12
	Apr 2011 14:31:36 +0100")
References: <437hbgql64.wl%bjg@gnu.org> <4D97B452.9080100@gnutls.org>
	<nnd3kru8dt.fsf@stalhein.lysator.liu.se> <43y63fppdz.wl%bjg@gnu.org>
Message-ID: <nn8vvfttje.fsf@stalhein.lysator.liu.se>

Brian Gough <bjg at gnu.org> writes:

> I don't know what is the correct interpretation of the FHS, but by
> default all other autoconf'ed and GNU packages always use
> libdir=$prefix/lib (with the --libdir option allowing it to be
> overridden if someone wants to use lib64 or whatever).

And the default is broken for multi-abi systems, since it means that a
plain ./configure && make && make install may well overwrite a working
library in /usr/local/lib with a library for a different ABI. With
autoconf defaults, this will happen, e.g., if you compile on Solaris (or
on some gnu/linux siystem which actually obeys the FHS), using a
compiler which by default generates 64-bit code).

Now, most packages are not aware of what ABI they are being compiled
for, but nettle is. It has to figure it out, in order to select the
right assembly files.

> The distributions already have their own ways of using --libdir on
> autoconf'ed packages so you don't need to worry about it yourself.

I don't worry so much for distributors. To use a sane libdir default is
intended to help people who compile nettle from source themselves,
rather than installing their distribution's nettle package.

I'd be happy to have autoconf solve this problem for me, but currently
it doesn't. Library installation is a bit complex, with various
workarounds. Another issue not currently solved by autoconf (nor by
nettle's build system) is w*ndows dlls, which should usually be
installed in bin rather than lib. I've heard that automake (or maybe it
was libtool) uses the workaround to install dlls in $libdir/../bin.
Which is really really ugly, but which appears to work most of the time.
Autoconf simply doesn't solve everything.

Finally: If the current hack doesn't work, I'd appreciate a complete bug
report. What system is it? Which library directories exists (incluing
symlinks)? Which directory is expected to hold libraries for which ABI?

Regards,
/Niels

-- 
Niels M?ller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.



From ludo at gnu.org  Tue Apr 12 23:37:29 2011
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 12 Apr 2011 23:37:29 +0200
Subject: Don't include <gcrypt.h> when not necessary
Message-ID: <8739lnw3qe.fsf@gnu.org>

Hello,

For the record I just pushed this patch, which allows compilation
without libgcrypt:

  http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_12_x&id=da7563294b63d006a15c8bdcbb3d6d4d87b72558

Thanks,
Ludo?.




From nmav at gnutls.org  Wed Apr 13 17:29:20 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 13 Apr 2011 17:29:20 +0200
Subject: Don't include <gcrypt.h> when not necessary
In-Reply-To: <8739lnw3qe.fsf@gnu.org>
References: <8739lnw3qe.fsf@gnu.org>
Message-ID: <4DA5C150.2070407@gnutls.org>

On 04/12/2011 11:37 PM, Ludovic Court?s wrote:
> Hello,
> 
> For the record I just pushed this patch, which allows compilation
> without libgcrypt:
>   http://git.savannah.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_12_x&id=da7563294b63d006a15c8bdcbb3d6d4d87b72558

Thanks. I've applied it to master as well.

regards,
Nikos



From bjg at gnu.org  Thu Apr 14 02:36:14 2011
From: bjg at gnu.org (Brian Gough)
Date: Thu, 14 Apr 2011 01:36:14 +0100
Subject: different lib directories for gnutls and nettle
In-Reply-To: <nn8vvfttje.fsf@stalhein.lysator.liu.se>
References: <437hbgql64.wl%bjg@gnu.org> <4D97B452.9080100@gnutls.org>
	<nnd3kru8dt.fsf@stalhein.lysator.liu.se>
	<43y63fppdz.wl%bjg@gnu.org>
	<nn8vvfttje.fsf@stalhein.lysator.liu.se>
Message-ID: <438vvdpt35.wl%bjg@gnu.org>

At Tue, 12 Apr 2011 16:48:21 +0200,
Niels M?ller wrote:
> 
> Finally: If the current hack doesn't work, I'd appreciate a complete bug
> report. What system is it? Which library directories exists (incluing
> symlinks)? Which directory is expected to hold libraries for which ABI?

Not actually a bug as such, but differing standards.  The GNU Coding
Standards specify lib/ as the default library install directory on any
system.  The FHS and GNU Coding Standards are different on this point.

Nettle should work better with other GNU packages if it follows the
GNU standards, as the assumption of lib/ as a default is a common one
in other configure scripts.  

For comparison the GMP library has ABI detection via configure but
keeps the library directory as lib/ by default.




From nisse at lysator.liu.se  Thu Apr 14 10:25:48 2011
From: nisse at lysator.liu.se (Niels =?iso-8859-1?Q?M=F6ller?=)
Date: Thu, 14 Apr 2011 10:25:48 +0200
Subject: different lib directories for gnutls and nettle
In-Reply-To: <438vvdpt35.wl%bjg@gnu.org> (Brian Gough's message of "Thu, 14
	Apr 2011 01:36:14 +0100")
References: <437hbgql64.wl%bjg@gnu.org> <4D97B452.9080100@gnutls.org>
	<nnd3kru8dt.fsf@stalhein.lysator.liu.se> <43y63fppdz.wl%bjg@gnu.org>
	<nn8vvfttje.fsf@stalhein.lysator.liu.se> <438vvdpt35.wl%bjg@gnu.org>
Message-ID: <nnsjtls0hf.fsf@stalhein.lysator.liu.se>

Brian Gough <bjg at gnu.org> writes:

> Nettle should work better with other GNU packages if it follows the
> GNU standards, as the assumption of lib/ as a default is a common one
> in other configure scripts.  

I don't change the default lightly, but I still think it's the right
thing to do when

1. The user has not provided --libdir explicitly.

2. One is building on a multi-abi system, which is a case where the
   autoconf default doesn't even try to do the right thing.

3. The autoconf default is known to be wrong.

> For comparison the GMP library has ABI detection via configure but
> keeps the library directory as lib/ by default.

I'm reasonably familiar with the gmp configure script. It's true that it
currently always uses lib/ as the default, regardless of ABI, but it's
ABI related hacks can also cause other nasty surprises. So it's a good
example to exhibit the complexity of the problem, but it's not currently
solving it.

As for linux on x86_64, it appears that debian (and derivatives, I
imagine) put 64-bit libraries in lib/, while the distributions with
roots in redhat (at least rhel 5 and fedora 14) and gentoo follow the
fhs conventions and put 32-bit libraries in lib/. So to do the right
thing, configure has to distinguish between these two cases. What a mess
(but just the type of mess configure.ac is intended to help sort out).

Regards,
/Niels

-- 
Niels M?ller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.



From nmav at gnutls.org  Thu Apr 14 10:55:33 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 14 Apr 2011 10:55:33 +0200
Subject: different lib directories for gnutls and nettle
In-Reply-To: <nnsjtls0hf.fsf@stalhein.lysator.liu.se>
References: <437hbgql64.wl%bjg@gnu.org> <4D97B452.9080100@gnutls.org>
	<nnd3kru8dt.fsf@stalhein.lysator.liu.se>
	<43y63fppdz.wl%bjg@gnu.org>
	<nn8vvfttje.fsf@stalhein.lysator.liu.se>
	<438vvdpt35.wl%bjg@gnu.org>
	<nnsjtls0hf.fsf@stalhein.lysator.liu.se>
Message-ID: <BANLkTi=aKxk9PP68Xr3DGsaa6+C0UjOCSA@mail.gmail.com>

On Thu, Apr 14, 2011 at 10:25 AM, Niels M?ller <nisse at lysator.liu.se> wrote:
>> Nettle should work better with other GNU packages if it follows the
>> GNU standards, as the assumption of lib/ as a default is a common one
>> in other configure scripts.
> I don't change the default lightly, but I still think it's the right
> thing to do when
> 1. The user has not provided --libdir explicitly.
> 2. One is building on a multi-abi system, which is a case where the
> ? autoconf default doesn't even try to do the right thing.
> 3. The autoconf default is known to be wrong.

I don't really find this a serious problem because libdir can be
provided by the one performing compilation and fix any issues,
anyway.

As a matter of policy though, I think the FHS way of
storing in /usr/lib 32-bit binaries, even if the default system compiler
outputs 64-bit binaries, is quite absurd, and looks like a relic from
the era that binary only programs came with 32-bit intel code only.
Systems like debian correctly for me do not follow this approach
because it has no benefit for the user of a multi-lib system and only
causes confusion, as programs in /usr/bin do not use libraries in
/usr/lib. What you call a multi-lib system
is actually a system with a native word size and a compatibility
mode with another (smaller) word size. Why one not using
the compatibility mode have an empty /usr/lib? This requirement
is intended only for the one distributing ancient 32-bit binaries and
I see no compelling reason for free software or open systems to
follow that by default.

regards,
Nikos



From tmraz at redhat.com  Thu Apr 14 11:05:12 2011
From: tmraz at redhat.com (Tomas Mraz)
Date: Thu, 14 Apr 2011 11:05:12 +0200
Subject: different lib directories for gnutls and nettle
In-Reply-To: <BANLkTi=aKxk9PP68Xr3DGsaa6+C0UjOCSA@mail.gmail.com>
References: <437hbgql64.wl%bjg@gnu.org> <4D97B452.9080100@gnutls.org>
	<nnd3kru8dt.fsf@stalhein.lysator.liu.se> <43y63fppdz.wl%bjg@gnu.org>
	<nn8vvfttje.fsf@stalhein.lysator.liu.se> <438vvdpt35.wl%bjg@gnu.org>
	<nnsjtls0hf.fsf@stalhein.lysator.liu.se>
	<BANLkTi=aKxk9PP68Xr3DGsaa6+C0UjOCSA@mail.gmail.com>
Message-ID: <1302771912.24643.4.camel@vespa.frost.loc>

On Thu, 2011-04-14 at 10:55 +0200, Nikos Mavrogiannopoulos wrote: 
> On Thu, Apr 14, 2011 at 10:25 AM, Niels M?ller <nisse at lysator.liu.se> wrote:
> >> Nettle should work better with other GNU packages if it follows the
> >> GNU standards, as the assumption of lib/ as a default is a common one
> >> in other configure scripts.
> > I don't change the default lightly, but I still think it's the right
> > thing to do when
> > 1. The user has not provided --libdir explicitly.
> > 2. One is building on a multi-abi system, which is a case where the
> >   autoconf default doesn't even try to do the right thing.
> > 3. The autoconf default is known to be wrong.
> 
> I don't really find this a serious problem because libdir can be
> provided by the one performing compilation and fix any issues,
> anyway.
> 
> As a matter of policy though, I think the FHS way of
> storing in /usr/lib 32-bit binaries, even if the default system compiler
> outputs 64-bit binaries, is quite absurd, and looks like a relic from
> the era that binary only programs came with 32-bit intel code only.
> Systems like debian correctly for me do not follow this approach
> because it has no benefit for the user of a multi-lib system and only
> causes confusion, as programs in /usr/bin do not use libraries in
> /usr/lib. What you call a multi-lib system
> is actually a system with a native word size and a compatibility
> mode with another (smaller) word size. Why one not using
> the compatibility mode have an empty /usr/lib? This requirement
> is intended only for the one distributing ancient 32-bit binaries and
> I see no compelling reason for free software or open systems to
> follow that by default.

There is one big compelling reason - the packages for 32-bit native
installation and 32bit compatibility on 64-bit native system are the
same. And that's the reason RPM based distros use lib for 32bit and
lib64 for 64bit libraries.

Nevertheless I think the upstream makefiles should use the autoconf
default and do not try to detect it as it makes more confusion if the
detection is not 100% correct.
-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb




From ametzler at downhill.at.eu.org  Sat Apr 16 17:54:55 2011
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 16 Apr 2011 17:54:55 +0200
Subject: Bug#623001: libgnutls26: fails to handshake on a number of
	sites (firefox works)
In-Reply-To: <20110416144822.10679.35723.reportbug@goiaba.horta>
References: <20110416144822.10679.35723.reportbug@goiaba.horta>
Message-ID: <20110416155455.GH2011@downhill.g.la>

On 2011-04-16 Gustavo Noronha Silva <kov at debian.org> wrote:
> Package: libgnutls26
> Version: 2.12.2-1
[...]
> I've been seeing this problem mostly in Epiphany - the web page
> renders with the layout totally broken because the CSS failed to
> download because of this issue. Some big sites like github.com are
> affected.
[...]
> The reason reported is 'Peer failed to perform TLS handshake'. Here's
> a test with gnutls-cli:

> 	kov at goiaba:~$ gnutls-cli d3nwyuy0nl342s.cloudfront.net
> 	Resolving 'd3nwyuy0nl342s.cloudfront.net'...
> 	Connecting to '204.246.175.60:443'...
> 	*** Fatal error: A TLS fatal alert has been received.
> 	*** Received alert [40]: Handshake failed
> 	*** Handshake has failed
> 	GnuTLS error: A TLS fatal alert has been received.
[...]
> ii  libgcrypt11               1.5.0~beta1-1  LGPL Crypto library - runtime libr
[...]

Hello,

thank you for taking the time to test the packages in experimental. I
can reproduce the bug.

For clarification it is not caused by libgcrypt11 from experimental,
libgnutls26 2.12.2-1 with stable libgcrypt11 also fails.  Attached
verbose log is not a lot more enlightening.

cu andreas
-------------- next part --------------
|<4>| REC[0x9ddaf60]: Allocating epoch #0
|<2>| ASSERT: gnutls_constate.c:695
|<4>| REC[0x9ddaf60]: Allocating epoch #1
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA256
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA256
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA256
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: RSA_AES_256_CBC_SHA256
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x9ddaf60]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<2>| EXT[0x9ddaf60]: Sending extension CERT TYPE (3 bytes)
|<2>| EXT[0x9ddaf60]: Sending extension SERVER NAME (34 bytes)
|<2>| EXT[0x9ddaf60]: Sending extension SAFE RENEGOTIATION (1 bytes)
|<2>| EXT[0x9ddaf60]: Sending extension SESSION TICKET (0 bytes)
|<2>| EXT[SIGA]: sent signature algo (4.2) DSA-SHA256
|<2>| EXT[SIGA]: sent signature algo (4.1) RSA-SHA256
|<2>| EXT[SIGA]: sent signature algo (2.1) RSA-SHA1
|<2>| EXT[SIGA]: sent signature algo (2.2) DSA-SHA1
|<2>| EXT[0x9ddaf60]: Sending extension SIGNATURE ALGORITHMS (10 bytes)
|<3>| HSK[0x9ddaf60]: CLIENT HELLO was sent [159 bytes]
|<6>| BUF[HSK]: Inserted 159 bytes of Data
|<7>| HWRITE: enqueued 159. Total 159 bytes.
|<7>| HWRITE FLUSH: 159 bytes in buffer.
|<4>| REC[0x9ddaf60]: Sending Packet[0] Handshake(22) with length: 159
|<7>| WRITE: enqueued 164 bytes for 0x4. Total 164 bytes.
|<4>| REC[0x9ddaf60]: Sent Packet[1] Handshake(22) with length: 164
|<7>| HWRITE: wrote 159 bytes, 0 bytes left.
|<7>| WRITE FLUSH: 164 bytes in buffer.
|<7>| WRITE: wrote 164 bytes, 0 bytes left.
|<7>| READ: Got 5 bytes from 0x4
|<7>| READ: read 5 bytes from 0x4
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[0x9ddaf60]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[0x9ddaf60]: Received Packet[0] Alert(21) with length: 2
|<7>| READ: Got 2 bytes from 0x4
|<7>| READ: read 2 bytes from 0x4
|<7>| RB: Have 5 bytes into buffer. Adding 2 bytes.
|<7>| RB: Requested 7 bytes
|<4>| REC[0x9ddaf60]: Decrypted Packet[0] Alert(21) with length: 2
|<4>| REC[0x9ddaf60]: Alert[2|40] - Handshake failed - was received
|<2>| ASSERT: gnutls_record.c:726
|<2>| ASSERT: gnutls_record.c:1122
|<2>| ASSERT: gnutls_handshake.c:2761
|<6>| BUF[HSK]: Cleared Data from buffer
*** Fatal error: A TLS fatal alert has been received.
|<4>| REC: Sending Alert[2|80] - Internal error
|<4>| REC[0x9ddaf60]: Sending Packet[1] Alert(21) with length: 2
|<7>| WRITE: enqueued 7 bytes for 0x4. Total 7 bytes.
|<7>| WRITE FLUSH: 7 bytes in buffer.
|<7>| WRITE: wrote 7 bytes, 0 bytes left.
|<4>| REC[0x9ddaf60]: Sent Packet[2] Alert(21) with length: 7
*** Handshake has failed
GnuTLS error: A TLS fatal alert has been received.
|<6>| BUF[HSK]: Cleared Data from buffer
|<4>| REC[0x9ddaf60]: Epoch #0 freed
|<4>| REC[0x9ddaf60]: Epoch #1 freed
Resolving 'd3nwyuy0nl342s.cloudfront.net'...
Connecting to '216.137.61.145:443'...
*** Received alert [40]: Handshake failed

From nmav at gnutls.org  Sat Apr 16 18:05:07 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 16 Apr 2011 18:05:07 +0200
Subject: Bug#623001: libgnutls26: fails to handshake on a number of sites
	(firefox works)
In-Reply-To: <20110416155455.GH2011@downhill.g.la>
References: <20110416144822.10679.35723.reportbug@goiaba.horta>
	<20110416155455.GH2011@downhill.g.la>
Message-ID: <4DA9BE33.8030405@gnutls.org>

On 04/16/2011 05:54 PM, Andreas Metzler wrote:

> thank you for taking the time to test the packages in experimental. I
> can reproduce the bug.
> 
> For clarification it is not caused by libgcrypt11 from experimental,
> libgnutls26 2.12.2-1 with stable libgcrypt11 also fails.  Attached
> verbose log is not a lot more enlightening.

d3nwyuy0nl342s.cloudfront.net seems to support only one ciphersuite.
That is ARCFOUR-128 with HMAC-MD5. I disabled HMAC-MD5 from the default
set in 2.12.0 because it is not really trusted as an HMAC any more.
If however this is widespread issue I'll reinstate HMAC-MD5 and
remove it when a real attack is known.

regards,
Nikos




From ametzler at downhill.at.eu.org  Sat Apr 16 19:19:49 2011
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 16 Apr 2011 19:19:49 +0200
Subject: AES-NI
Message-ID: <20110416171949.GI2011@downhill.g.la>

Hello,

watching gnutls-commits I have been wondering about
-------------------------------------------
 ** libgnutls: Added support for AES-NI if detected. Uses
  Andy Polyakov's AES-NI code.
-------------------------------------------

Isn't this something that belongs in the crypto backend? Gcrypt (1.5
beta) already supports it.

I am not critizing, just wondering whether I understand things
correctly.

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  Sat Apr 16 19:42:07 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 16 Apr 2011 19:42:07 +0200
Subject: AES-NI
In-Reply-To: <20110416171949.GI2011@downhill.g.la>
References: <20110416171949.GI2011@downhill.g.la>
Message-ID: <4DA9D4EF.1000506@gnutls.org>

On 04/16/2011 07:19 PM, Andreas Metzler wrote:

> watching gnutls-commits I have been wondering about 
> ------------------------------------------- ** libgnutls: Added
> support for AES-NI if detected. Uses Andy Polyakov's AES-NI code. 
> -------------------------------------------
> 
> Isn't this something that belongs in the crypto backend? Gcrypt (1.5 
> beta) already supports it. I am not critizing, just wondering whether
> I understand things correctly.

Indeed. Ideally this should have been handled in the cryptographic
back-end. However nettle (due to being very low level) doesn't have any
interface to override ciphers on run-time. Libgcrypt also doesn't have
such an interface, thus anyone wanting to contribute such optimized
code has to do within ifdefs in the existing code. For these two reasons
the run-time detection of cryptographic capabilities is kept in
gnutls[0]. That way and by keeping that code separate and independent,
we can use external contributions of optimized implementations quite
easily, even if the code is not under LGPL (but under some other
compatible license).


regards,
Nikos

[0]. I tried to sketch this architecture at:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=doc/gnutls-crypto-layers.png;h=f25c8a1d687e0bd0601bfbcebadd758a9d64886d;hb=HEAD



From kov at debian.org  Sat Apr 16 22:19:32 2011
From: kov at debian.org (Gustavo Noronha Silva)
Date: Sat, 16 Apr 2011 17:19:32 -0300
Subject: Bug#623001: libgnutls26: fails to handshake on a number of
	sites (firefox works)
In-Reply-To: <4DA9BE33.8030405@gnutls.org>
References: <20110416144822.10679.35723.reportbug@goiaba.horta>
	<20110416155455.GH2011@downhill.g.la> <4DA9BE33.8030405@gnutls.org>
Message-ID: <1302985186.2420.65.camel@couve.horta>

On Sat, 2011-04-16 at 18:05 +0200, Nikos Mavrogiannopoulos wrote:
> On 04/16/2011 05:54 PM, Andreas Metzler wrote:
> 
> > thank you for taking the time to test the packages in experimental. I
> > can reproduce the bug.
> > 
> > For clarification it is not caused by libgcrypt11 from experimental,
> > libgnutls26 2.12.2-1 with stable libgcrypt11 also fails.  Attached
> > verbose log is not a lot more enlightening.
> 
> d3nwyuy0nl342s.cloudfront.net seems to support only one ciphersuite.
> That is ARCFOUR-128 with HMAC-MD5. I disabled HMAC-MD5 from the default
> set in 2.12.0 because it is not really trusted as an HMAC any more.
> If however this is widespread issue I'll reinstate HMAC-MD5 and
> remove it when a real attack is known.

I've seen the issue in quite a few prominent web sites, though the only
one I have off the top of my mind currently is github, so I think
restoring HMAC-MD5 is probably wise for the time being, for
compatibility, indeed.

Cheers,

-- 
Gustavo Noronha Silva <kov at debian.org>
Debian Project




From simon at josefsson.org  Sun Apr 17 09:45:43 2011
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 17 Apr 2011 09:45:43 +0200
Subject: Bug#623001: libgnutls26: fails to handshake on a number of sites
	(firefox works)
In-Reply-To: <4DA9BE33.8030405@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sat, 16 Apr 2011 18:05:07 +0200")
References: <20110416144822.10679.35723.reportbug@goiaba.horta>
	<20110416155455.GH2011@downhill.g.la> <4DA9BE33.8030405@gnutls.org>
Message-ID: <878vv92ue0.fsf@latte.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> On 04/16/2011 05:54 PM, Andreas Metzler wrote:
>
>> thank you for taking the time to test the packages in experimental. I
>> can reproduce the bug.
>> 
>> For clarification it is not caused by libgcrypt11 from experimental,
>> libgnutls26 2.12.2-1 with stable libgcrypt11 also fails.  Attached
>> verbose log is not a lot more enlightening.
>
> d3nwyuy0nl342s.cloudfront.net seems to support only one ciphersuite.
> That is ARCFOUR-128 with HMAC-MD5. I disabled HMAC-MD5 from the default
> set in 2.12.0 because it is not really trusted as an HMAC any more.
> If however this is widespread issue I'll reinstate HMAC-MD5 and
> remove it when a real attack is known.

I thought there weren't any attacks on HMAC-MD5, have I missed anything?

/Simon



From nmav at gnutls.org  Sun Apr 17 10:06:20 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 17 Apr 2011 10:06:20 +0200
Subject: Bug#623001: libgnutls26: fails to handshake on a number of sites
	(firefox works)
In-Reply-To: <878vv92ue0.fsf@latte.josefsson.org>
References: <20110416144822.10679.35723.reportbug@goiaba.horta>	<20110416155455.GH2011@downhill.g.la>
	<4DA9BE33.8030405@gnutls.org> <878vv92ue0.fsf@latte.josefsson.org>
Message-ID: <4DAA9F7C.8040301@gnutls.org>

On 04/17/2011 09:45 AM, Simon Josefsson wrote:

>>> thank you for taking the time to test the packages in experimental. I
>>> can reproduce the bug.
>>>
>>> For clarification it is not caused by libgcrypt11 from experimental,
>>> libgnutls26 2.12.2-1 with stable libgcrypt11 also fails.  Attached
>>> verbose log is not a lot more enlightening.
>>
>> d3nwyuy0nl342s.cloudfront.net seems to support only one ciphersuite.
>> That is ARCFOUR-128 with HMAC-MD5. I disabled HMAC-MD5 from the default
>> set in 2.12.0 because it is not really trusted as an HMAC any more.
>> If however this is widespread issue I'll reinstate HMAC-MD5 and
>> remove it when a real attack is known.
> I thought there weren't any attacks on HMAC-MD5, have I missed anything?

That's what I say above. No real attacks exist although its security
is questioned (ECRYPT II report on algorithms and key sizes). The text
mentions: "The recent advances in the cryptanalysis of MD5 (see Section
10.3), and speci?cally HMAC-MD5 (e.g. [58, 143, 213, 83, 256]), suggest
that implementers should move away from HMAC-MD5 as soon as possible."

regards,
Nikos



From nmav at gnutls.org  Fri Apr 22 14:10:30 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 22 Apr 2011 14:10:30 +0200
Subject: gnutls 2.12.3
Message-ID: <4DB17036.2080504@gnutls.org>

Hello,
 I've just released gnutls 2.12.3.

What's New
==========
* libgnutls: Several minor bugfixes.

* libgnutls: Restored HMAC-MD5 for compatibility. Although considered
weak, several sites require it for connection. It is enabled for
"NORMAL" and "PERFORMANCE" priority strings.

* libgnutls: depend on libdl.

* libgnutls: gnutls_transport_set_global_errno() was deprecated.
Use your system's errno fascility or gnutls_transport_set_errno().

* gnutls-cli: Correction with usage of select to check for
pending data in gnutls sessions. It now uses
gnutls_record_check_pending(). Reported by Herbert J. Skuhra.

* tests: More fixes and updates for win32. Patches by LRN.

* libgnutls: Several files unnecessarily included <gcrypt.h>; this has
been fixed.

** API and ABI modifications:
gnutls_transport_set_global_errno: DEPRECATED

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

GnuTLS may be downloaded from one of the GNU mirror sites or directly
>From <ftp://ftp.gnu.org/gnu/gnutls/?.  The list of GNU mirrors can be
found at <http://www.gnu.org/prep/ftp.html> and a list of GnuTLS mirrors
can be found at <http://www.gnu.org/software/gnutls/download.html>.

Here are the BZIP2 compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.3.tar.bz2
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.3.tar.bz2

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.3.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.3.tar.bz2.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 Apr 23 11:12:25 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 23 Apr 2011 11:12:25 +0200
Subject: gnutls 2.99.1
Message-ID: <4DB297F9.3060809@gnutls.org>

Hello,

The GnuTLS 2.99.x branch is NOT what you want for your stable system.
It is intended for developers and experienced users.

The changes since the development release are:
* Version 2.99.1 (released 2011-04-23)

** libgnutls: Added support for AES-NI if detected. Uses
Andy Polyakov's AES-NI code.

* libgnutls: Restored HMAC-MD5 for compatibility. Although considered
weak, several sites require it for connection. It is enabled for
"NORMAL" and "PERFORMANCE" priority strings.

* libgnutls: depend on libdl.

** libgnutls-extra: Dropped support of LZO compression via liblzo.

** libgnutls: gnutls_transport_set_global_errno() was removed. This
function required GnuTLS to access system specific data, for no reason.
Use gnutls_transport_set_errno(), or your system's errno fascility
instead.

** libgnutls: Added gnutls_certificate_set_retrieve_function2()
to set a callback to retrieve a certificate. The certificate is
received in a format that requires no processing from gnutls thus
it is suitable when performance is required.

** API and ABI modifications:
gnutls_transport_set_global_errno: REMOVED
gnutls_certificate_set_retrieve_function2: ADDED


Here are the compressed sources:
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.99.1.tar.bz2
  ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-2.99.1.tar.bz2

Here is the OpenPGP signature:
  ftp://alpha.gnu.org/gnu/gnutls/gnutls-2.99.1.tar.bz2.sig
  ftp://ftp.gnutls.org/pub/gnutls/devel/gnutls-2.99.1.tar.bz2.sig

regards,
Nikos




From INVALID.NOREPLY at gnu.org  Sat Apr 23 15:50:03 2011
From: INVALID.NOREPLY at gnu.org (Volker Grabsch)
Date: Sat, 23 Apr 2011 13:50:03 +0000
Subject: [sr #107674] GnuTLS produces an invalid gnutls.pc pkg-config script
	(@LTLIBPAKCHOIS@)
Message-ID: <20110423-135002.sv74987.92287@savannah.gnu.org>

URL:
  <http://savannah.gnu.org/support/?107674>

                 Summary: GnuTLS produces an invalid gnutls.pc pkg-config
script (@LTLIBPAKCHOIS@)
                 Project: GnuTLS
            Submitted by: vog
            Submitted on: Sat 23 Apr 2011 01:50:02 PM GMT
                Category: None
                Priority: 5 - Normal
                Severity: 5 - Blocker
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: GNU/Linux

    _______________________________________________________

Details:

GnuTLS 2.12.3 produces an invalid "Libs.private" line in its gnutls.pc
pkg-config script:


Libs.private: @LTLIBPAKCHOIS@ -lgcrypt -lgpg-error


That bug makes it unusable for static linking. I was able to reproduce this on
a Debian/Squeeze system via the following configuration:


./configure --disable-nls --disable-guile --with-included-libtasn1
--with-included-libcfg --with-libgcrypt --without-lzo


The pakchois is _not_ installed here, but the ./configure output also doesn't
mention "pakchois" anywhere.

Maybe there is a bug in the pakchois detection?




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107674>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From ametzler at downhill.at.eu.org  Sun Apr 24 13:21:13 2011
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 24 Apr 2011 13:21:13 +0200
Subject: deprecated funtions without direct successor
Message-ID: <20110424112113.GA1977@downhill.g.la>

Hello,

I have test-built most of the gnutls-depending packages, checking for
build errors with 2.12. 

Afaict there are a couple of recently deprecated functions without
successor. Is this correct, do you have any pointer, suggestions?

gnutls_certificate_get_x509_cas (neon27, openldap)
gnutls_sign_callback_set (neon27)
gnutls_transport_set_lowat (curl, filezilla, gnustep-base,
libgwenhywfar, net6, openvas-libraries, samba4,
xfce4-mailwatch-plugin)

thanks, cu andreas



From nmav at gnutls.org  Sun Apr 24 23:33:48 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 24 Apr 2011 23:33:48 +0200
Subject: deprecated funtions without direct successor
In-Reply-To: <20110424112113.GA1977@downhill.g.la>
References: <20110424112113.GA1977@downhill.g.la>
Message-ID: <4DB4973C.4070501@gnutls.org>

On 04/24/2011 01:21 PM, Andreas Metzler wrote:
> Hello,
> 
> I have test-built most of the gnutls-depending packages, checking for
> build errors with 2.12. 
> Afaict there are a couple of recently deprecated functions without
> successor. Is this correct, do you have any pointer, suggestions?
> gnutls_certificate_get_x509_cas (neon27, openldap)

There is no direct successor to this function. It depended on internal
data that are already non-existing in 2.99.x. I'll try to check
those packages on how they use it, to see if there could be some
alternative way to achieve that functionality.

> gnutls_sign_callback_set (neon27)

The gnutls pkcs11 API. We have deprecated this API in favor of the
pkcs11 API but this callback will be present even in 3.0.0.

> gnutls_transport_set_lowat (curl, filezilla, gnustep-base,
> libgwenhywfar, net6, openvas-libraries, samba4,
> xfce4-mailwatch-plugin)

If they use set_lowat() with value of 0 then just removing
the call would do. If other value than zero is being
used then directions in
https://savannah.gnu.org/support/?107660
apply.

regards,
Nikos



From nmav at gnutls.org  Sun Apr 24 23:38:14 2011
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 24 Apr 2011 23:38:14 +0200
Subject: gnutls 2.99.1 drops LZO support
In-Reply-To: <87zkngwsgy.fsf@gnu.org>
References: <4DB297F9.3060809@gnutls.org> <87zkngwsgy.fsf@gnu.org>
Message-ID: <4DB49846.3010709@gnutls.org>

On 04/23/2011 11:47 PM, Ludovic Court?s wrote:
> Hello,
>> ** libgnutls-extra: Dropped support of LZO compression via liblzo.
> Out of curiosity, what were the reasons for this decision?

No reason to have it either. It was an experimental custom extension
that had no chance of becoming standard due to LZO being described only
by source code. There are better compression algorithms to use today,
but as it seems compression with TLS in general never took off.

regards,
Nikos



From INVALID.NOREPLY at gnu.org  Sun Apr 24 23:46:12 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Sun, 24 Apr 2011 21:46:12 +0000
Subject: [sr #107674] GnuTLS produces an invalid gnutls.pc pkg-config script
	(@LTLIBPAKCHOIS@)
In-Reply-To: <20110423-135002.sv74987.92287@savannah.gnu.org>
References: <20110423-135002.sv74987.92287@savannah.gnu.org>
Message-ID: <20110425-004612.sv707.7246@savannah.gnu.org>

Update of sr #107674 (project gnutls):

                  Status:                    None => Done                   
             Assigned to:                    None => nmav                   

    _______________________________________________________

Follow-up Comment #1:

Thank you for reporting that. I've committed a fix.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107674>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From derleader at abv.bg  Mon Apr 25 00:02:05 2011
From: derleader at abv.bg (derleader mail)
Date: Mon, 25 Apr 2011 01:02:05 +0300 (EEST)
Subject: Optimize GNUTLS for performance
Message-ID: <1141392392.950170.1303682525377.JavaMail.apache@mail22.abv.bg>

 
Hi,


 I'm interested is it possible to optimize GNUTLS for performance? 

Regards
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20110425/aa2032c0/attachment.htm>

From ludo at gnu.org  Mon Apr 25 16:11:04 2011
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Mon, 25 Apr 2011 16:11:04 +0200
Subject: gnutls 2.99.1 drops LZO support
In-Reply-To: <4DB49846.3010709@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sun, 24 Apr 2011 23:38:14 +0200")
References: <4DB297F9.3060809@gnutls.org> <87zkngwsgy.fsf@gnu.org>
	<4DB49846.3010709@gnutls.org>
Message-ID: <87sjt6l8uf.fsf@gnu.org>

Hi Nikos,

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> On 04/23/2011 11:47 PM, Ludovic Court?s wrote:
>> Hello,
>>> ** libgnutls-extra: Dropped support of LZO compression via liblzo.
>> Out of curiosity, what were the reasons for this decision?
>
> No reason to have it either.

It?s an interesting trade-off in the compression ratio vs. compression
time space.

> It was an experimental custom extension that had no chance of becoming
> standard due to LZO being described only by source code.

Like zlib used to be.  :-)

> There are better compression algorithms to use today, but as it seems
> compression with TLS in general never took off.

OK.

Thanks,
Ludo?.



From INVALID.NOREPLY at gnu.org  Mon Apr 25 19:52:08 2011
From: INVALID.NOREPLY at gnu.org (Dan Winship)
Date: Mon, 25 Apr 2011 17:52:08 +0000
Subject: [sr #107660] gnutls update to 2.12 branch breaks programs in ARCH and
	Debian squeeze
In-Reply-To: <20110412-164945.sv707.39713@savannah.gnu.org>
References: <20110412-122623.sv82434.96453@savannah.gnu.org>
	<20110412-153438.sv707.56854@savannah.gnu.org>
	<20110412-125848.sv82434.87468@savannah.gnu.org>
	<20110412-163853.sv707.39141@savannah.gnu.org>
	<20110412-134516.sv82434.5097@savannah.gnu.org>
	<20110412-164715.sv707.89667@savannah.gnu.org>
	<20110412-164945.sv707.39713@savannah.gnu.org>
Message-ID: <20110425-175208.sv73763.11918@savannah.gnu.org>

Follow-up Comment #7, sr #107660 (project gnutls):

Is it correct that gnutls_record_check_pending() only returns non-0 when there
is a complete TLS record buffered? ie, if gnutls_record_check_pending()
returns non-0, is it guaranteed that an immediately following call to
gnutls_record_recv() will not return GNUTLS_E_AGAIN?


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107660>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From INVALID.NOREPLY at gnu.org  Mon Apr 25 21:01:16 2011
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Mon, 25 Apr 2011 19:01:16 +0000
Subject: [sr #107660] gnutls update to 2.12 branch breaks programs in ARCH and
	Debian squeeze
In-Reply-To: <20110425-175208.sv73763.11918@savannah.gnu.org>
References: <20110412-122623.sv82434.96453@savannah.gnu.org>
	<20110412-153438.sv707.56854@savannah.gnu.org>
	<20110412-125848.sv82434.87468@savannah.gnu.org>
	<20110412-163853.sv707.39141@savannah.gnu.org>
	<20110412-134516.sv82434.5097@savannah.gnu.org>
	<20110412-164715.sv707.89667@savannah.gnu.org>
	<20110412-164945.sv707.39713@savannah.gnu.org>
	<20110425-175208.sv73763.11918@savannah.gnu.org>
Message-ID: <20110425-220116.sv707.16419@savannah.gnu.org>

Follow-up Comment #8, sr #107660 (project gnutls):

gnutls_record_check_pending() will return non-zero when there are data that
have not been read by the application. It might be less than a complete record
(i.e. 1 byte). If it is non-zero any access to gnutls_record_recv() will not
involve the network so it will never return GNUTLS_E_AGAIN.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?107660>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




From fweimer at bfk.de  Tue Apr 26 16:18:49 2011
From: fweimer at bfk.de (Florian Weimer)
Date: Tue, 26 Apr 2011 14:18:49 +0000
Subject: Bug#623001: libgnutls26: fails to handshake on a number of sites
	(firefox works)
In-Reply-To: <4DAA9F7C.8040301@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sun\, 17 Apr 2011 10\:06\:20 +0200")
References: <20110416144822.10679.35723.reportbug@goiaba.horta>
	<20110416155455.GH2011@downhill.g.la> <4DA9BE33.8030405@gnutls.org>
	<878vv92ue0.fsf@latte.josefsson.org> <4DAA9F7C.8040301@gnutls.org>
Message-ID: <82r58pf646.fsf@mid.bfk.de>

* Nikos Mavrogiannopoulos:

> That's what I say above. No real attacks exist although its security
> is questioned (ECRYPT II report on algorithms and key sizes). The text
> mentions: "The recent advances in the cryptanalysis of MD5 (see Section
> 10.3), and speci?cally HMAC-MD5 (e.g. [58, 143, 213, 83, 256]), suggest
> that implementers should move away from HMAC-MD5 as soon as possible."

Apparently, it's not yet possible.  And there have been claims tha
tthe MD5 attacks do not apply at all to HMAC-MD5.  The way HMAC-MD5 is
used in TLS does not appear to be very demanding, either (a commitment
scheme could be worse, for instance).

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra?e 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99



From ludo at gnu.org  Thu Apr 28 20:15:03 2011
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 28 Apr 2011 20:15:03 +0200
Subject: Test suite fixed for Guile 2.0.1
Message-ID: <871v0mfdjs.fsf@gnu.org>

Hello,

I just pushed this fix to 2.12 and ?master?:

  http://git.sv.gnu.org/cgit/gnutls.git/commit/?h=gnutls_2_12_x&id=ccbd77f6dc0b8440e7d80bddce2c8f950674eb46

It turns out that the unit tests under ?guile/tests? were relying on a
long-standing bug, which was fixed in Guile 2.0.1 [0].  With Guile 2.0.0
and 1.8.x, the tests would exit with 0 on success and 1 on failure; with
Guile 2.0.1, they would always exit with 1, which is what the above
commit fixes.

Consequently, using one of the GnuTLS tarball released to date with
Guile 2.0.1 will systematically result in tests failures under
?guile/tests?.

Thanks,
Ludo?.

[0] http://git.sv.gnu.org/cgit/guile.git/commit/?id=e309f3bf9ee910c4772353ca3ff95f6f4ef466b5




From ametzler at downhill.at.eu.org  Sat Apr 30 15:59:38 2011
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 30 Apr 2011 15:59:38 +0200
Subject: Two minor doc fixes
Message-ID: <20110430135938.GA1956@downhill.g.la>

Hello,

find attached two one-line patches for formatting/typo/grammar errors.

0001 for both master and gnutls_2_12_x
0002 only for gnutls_2_12_x (function is removed in master.)

thanks, cu andreas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-escape-dashes-in-manpage.patch
Type: text/x-diff
Size: 1383 bytes
Desc: not available
URL: </pipermail/attachments/20110430/a2921cb5/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Grammar-fix-allows-one-to.patch
Type: text/x-diff
Size: 896 bytes
Desc: not available
URL: </pipermail/attachments/20110430/a2921cb5/attachment-0001.patch>