From nmav at gnutls.org  Sun Jan  1 12:10:22 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 1 Jan 2012 13:10:22 +0200
Subject: gnutls for win32
In-Reply-To: <87aa68dfao.fsf@lifelogs.com>
References: <CAJU7zaKH0NTE7ko6u24gXy9WupsNw+CAvhMdVudzxpXvsY2vig@mail.gmail.com>
	<87aa68dfao.fsf@lifelogs.com>
Message-ID: <CAJU7zaLUNHr9zBWWja97Pv1cYz1EVQEufukXF2FiyQ04Lk-CiA@mail.gmail.com>

2011/12/31 Ted Zlatanov <tzz at lifelogs.com>:

> NM> Hello all and best wishes for new year,
> NM> ?I've put pre-built win32 dlls and the other gnutls applications for
> NM> 3.0.9 in [0]. I've managed to automate the procedure, so it could be
> NM> that next releases (at least the major ones) will have the
> NM> corresponding windows dlls released as well.
> NM> [0]. http://homes.esat.kuleuven.be/~nikos/gnutls-win32/
> Great news! ?That lets GNU Emacs use the latest GnuTLS on all the
> supported platforms.
> Currently we're in a feature freeze for the Emacs pretest, but after the
> next Emacs release we'll make GnuTLS 3.x required. ?That also lets us
> ensure that we're not fighting old, already-fixed bugs.
> Could the W32 releases go on the official GnuTLS site so we can point to
> them in the GNU Emacs installation notes? ?And could you, when able,
> publish the build script so developers can make their own W32 builds?

Hi Ted,
 The build script is on the repository (cross.mk). I'll see what's the
optimal release method of windows binaries.

regards,
Nikos



From eliz at gnu.org  Sun Jan  1 12:50:12 2012
From: eliz at gnu.org (Eli Zaretskii)
Date: Sun, 01 Jan 2012 06:50:12 -0500
Subject: gnutls for win32
In-Reply-To: <CAJU7zaLUNHr9zBWWja97Pv1cYz1EVQEufukXF2FiyQ04Lk-CiA@mail.gmail.com>
	(message from Nikos Mavrogiannopoulos on Sun, 1 Jan 2012 13:10:22
	+0200)
References: <CAJU7zaKH0NTE7ko6u24gXy9WupsNw+CAvhMdVudzxpXvsY2vig@mail.gmail.com>
	<87aa68dfao.fsf@lifelogs.com>
	<CAJU7zaLUNHr9zBWWja97Pv1cYz1EVQEufukXF2FiyQ04Lk-CiA@mail.gmail.com>
Message-ID: <E1RhJvY-0004l9-OX@fencepost.gnu.org>

> Date: Sun, 1 Jan 2012 13:10:22 +0200
> From: Nikos Mavrogiannopoulos <nmav at gnutls.org>
> Cc: gnutls-devel at gnu.org, emacs-devel at gnu.org
> 
> 2011/12/31 Ted Zlatanov <tzz at lifelogs.com>:
> 
> > NM> Hello all and best wishes for new year,
> > NM> ?I've put pre-built win32 dlls and the other gnutls applications for
> > NM> 3.0.9 in [0]. I've managed to automate the procedure, so it could be
> > NM> that next releases (at least the major ones) will have the
> > NM> corresponding windows dlls released as well.
> > NM> [0]. http://homes.esat.kuleuven.be/~nikos/gnutls-win32/
> > Great news! ?That lets GNU Emacs use the latest GnuTLS on all the
> > supported platforms.
> > Currently we're in a feature freeze for the Emacs pretest, but after the
> > next Emacs release we'll make GnuTLS 3.x required. ?That also lets us
> > ensure that we're not fighting old, already-fixed bugs.
> > Could the W32 releases go on the official GnuTLS site so we can point to
> > them in the GNU Emacs installation notes? ?And could you, when able,
> > publish the build script so developers can make their own W32 builds?
> 
> Hi Ted,
>  The build script is on the repository (cross.mk). I'll see what's the
> optimal release method of windows binaries.

FWIW, I've built GnuTLS 3.0.9 natively on Windows, using MinGW and
MSYS.  I will make the resulting binaries available shortly, as soon
as I'm done testing it with Emacs.

Note that currently Emacs cannot use GnuTLS 3.0.9 on Windows, because
of a couple of minor incompatibilities in Emacs itself.  I'm working
on a solution as we speak.



From rms at gnu.org  Sun Jan  1 23:32:50 2012
From: rms at gnu.org (Richard Stallman)
Date: Sun, 01 Jan 2012 17:32:50 -0500
Subject: gnutls for lose32
In-Reply-To: <E1RhJvY-0004l9-OX@fencepost.gnu.org> (message from Eli Zaretskii
	on Sun, 01 Jan 2012 06:50:12 -0500)
References: <CAJU7zaKH0NTE7ko6u24gXy9WupsNw+CAvhMdVudzxpXvsY2vig@mail.gmail.com>
	<87aa68dfao.fsf@lifelogs.com>
	<CAJU7zaLUNHr9zBWWja97Pv1cYz1EVQEufukXF2FiyQ04Lk-CiA@mail.gmail.com>
	<E1RhJvY-0004l9-OX@fencepost.gnu.org>
Message-ID: <E1RhTxS-0002hK-Ux@fencepost.gnu.org>

A reminder: please don't use the abbreviation "win" to refer to
Windows.  Please change that whenever you see it.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/



From eggert at cs.ucla.edu  Mon Jan  2 07:55:45 2012
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Sun, 01 Jan 2012 22:55:45 -0800
Subject: gnutls for lose32
In-Reply-To: <E1RhTxS-0002hK-Ux@fencepost.gnu.org>
References: <CAJU7zaKH0NTE7ko6u24gXy9WupsNw+CAvhMdVudzxpXvsY2vig@mail.gmail.com>
	<87aa68dfao.fsf@lifelogs.com>
	<CAJU7zaLUNHr9zBWWja97Pv1cYz1EVQEufukXF2FiyQ04Lk-CiA@mail.gmail.com>
	<E1RhJvY-0004l9-OX@fencepost.gnu.org>
	<E1RhTxS-0002hK-Ux@fencepost.gnu.org>
Message-ID: <4F0154F1.6000002@cs.ucla.edu>

On 01/01/12 14:32, Richard Stallman wrote:
> A reminder: please don't use the abbreviation "win" to refer to
> Windows.  Please change that whenever you see it.

Thanks for the reminder.  I looked in the Emacs source code
for instances of this problem, and proposed a patch to fix them
in Bug#10421.

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10421

There are some other instances that come from upstream code
in Gnulib; I'll propose fixes for them upstream.



From nmav at gnutls.org  Wed Jan  4 00:04:58 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 4 Jan 2012 01:04:58 +0200
Subject: Fwd: FSF fundraising drive
In-Reply-To: <201201032202.q03M25l4001424@freefriends.org>
References: <201201032202.q03M25l4001424@freefriends.org>
Message-ID: <CAJU7zaKunF7VfEecNc01b9uZ7dVNseADj2oXMCO3p_zSKuopNQ@mail.gmail.com>

---------- Forwarded message ----------
From: Karl Berry <karl at freefriends.org>
Date: Wed, Jan 4, 2012 at 12:02 AM
Subject: FSF fundraising drive
To: gnu-prog at gnu.org


The FSF is nearing the end of its current fundraising drive and all
support is welcome, as always. ?Of course, the more members and/or
donations, the more support for GNU infrastructure and free software
campaigns.

The direct url to join is http://www.fsf.org/join, or donate at
https://my.fsf.org/donate.

If you think it's appropriate, please forward this to your project
mailing list and/or specific friends you think would be interested. ?Or
if you'd like to join yourself, please go for it :). ?If you're already
a member, and in any case for your contributions to GNU, thanks very
much.

Happy hacking to all,
Karl



From nmav at gnutls.org  Wed Jan  4 19:26:17 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 04 Jan 2012 19:26:17 +0100
Subject: gnutls 3.0.10
Message-ID: <4F0499C9.5030603@gnutls.org>

Hello,
 I've just released gnutls 3.0.10. This release adds support 
for random-art images which display a drawing representing the 
public key's fingerprint, fixes several open issues for ms-windows 
support, and other fixes.


* Version 3.0.10 (released 2012-01-04)

** gnutls-cli/serv: Set don't fragment bit in DTLS sessions
in Linux as well as in BSD.

** gnutls-cli: Fixed reading from windows terminals.

** libgnutls: When GNUTLS_OPENPGP_FMT_BASE64 is specified
the stream is assumed to be base64 encoded (previously
the encoding was auto-detected). This avoids a decoding
issue in windows systems.

** libgnutls: Corrected ciphersuite GNUTLS_ECDHE_PSK_AES_256_CBC_SHA384

** libgnutls: Added ciphersuites: GNUTLS_PSK_WITH_AES_256_GCM_SHA384
and GNUTLS_DHE_PSK_WITH_AES_256_GCM_SHA384.

** libgnutls: Added function gnutls_random_art() to convert
fingerprints to images (currently ascii-art).

** libgnutls: Corrected bug in DSA private key parsing, which
prevented the verification of the key.

** API and ABI modifications:
gnutls_random_art: Added



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 XZ compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.10.tar.xz
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.10.tar.xz
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.10.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.10.tar.xz.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.10.tar.xz.sig
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.10.tar.xz.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 ludo at gnu.org  Thu Jan  5 14:22:23 2012
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 05 Jan 2012 14:22:23 +0100
Subject: =?utf-8?B?4oCcbWFrZSBkaXN04oCd?= fails on =?utf-8?B?4oCYbWFzdGVy?=
	=?utf-8?B?4oCZ?=
Message-ID: <87d3aycmi8.fsf@gnu.org>

Hi,

?make dist? appears to be failing on ?master? (from
<http://hydra.nixos.org/build/1722988/>):

  rm -f en at quot.gmo && /nix/store/x9792w5bv44jf9127nbjlsxswziinxrd-gettext-0.18.1.1/bin/msgfmt -c --statistics --verbose -o en at quot.gmo en at quot.po
  en at quot.po: 292 translated messages.
  make[4]: Entering directory `/tmp/nix-build-n7bzdxkpbh2fsl67r0ypscxpjih7ylkm-gnutls-tarball-0pre38718fe94ae05a81a2acc437dd3bf24af0173143.drv-0/git-export/po'
  File cs.po does not exist. If you are a translator, you can create it through 'msginit'.
  make[4]: *** [cs.po-create] Error 1
  make[4]: Leaving directory `/tmp/nix-build-n7bzdxkpbh2fsl67r0ypscxpjih7ylkm-gnutls-tarball-0pre38718fe94ae05a81a2acc437dd3bf24af0173143.drv-0/git-export/po'

Ideas?

Thanks,
Ludo?.



From INVALID.NOREPLY at gnu.org  Fri Jan  6 19:49:30 2012
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Fri, 06 Jan 2012 18:49:30 +0000
Subject: [sr #107929] gnutls_record_get_direction() can return the wrong
	direction after an interrupted gnutls_record_send()
Message-ID: <20120106-184929.sv0.31741@savannah.gnu.org>

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

                 Summary: gnutls_record_get_direction() can return the wrong
direction after an interrupted gnutls_record_send()
                 Project: GnuTLS
            Submitted by: None
            Submitted on: Fri 06 Jan 2012 06:49:29 PM UTC
                Category: Core library
                Priority: 5 - Normal
                Severity: 4 - Important
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: philip.allison at smoothwall.net
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: GNU/Linux

    _______________________________________________________

Details:

I have noticed some odd behaviour when moving an application from GnuTLS 2.10
to 3.0.  Specifically, when using non-blocking sockets,
gnutls_record_get_direction() can return 0 (i.e. read) after an interrupted
call to gnutls_record_send(), in cases where the peer isn't trying to send any
data.

Unless I change our server application code to ignore the return from
gnutls_record_get_direction() except during handshakes, and assume the
direction will always be 0 after an interrupted recv and 1 after an
interrupted send, data transfer between the client and server can hang with
both peers waiting for input.  The client is a web browser, Firefox, and so is
unlikely to be the culprit.

A very quick glance at the current HEAD of master (git grep
internals.direction) turns up no code where the direction is ever set to 1! 
The last code looking like "internals.direction = 1" was removed by commit
a209eced7ce4fc698d27d16e3403441b452d9c0e.




    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Fri Jan  6 20:05:49 2012
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Fri, 06 Jan 2012 19:05:49 +0000
Subject: [sr #107929] gnutls_record_get_direction() can return the wrong
	direction after an interrupted gnutls_record_send()
In-Reply-To: <20120106-184929.sv0.31741@savannah.gnu.org>
References: <20120106-184929.sv0.31741@savannah.gnu.org>
Message-ID: <20120106-210549.sv707.73804@savannah.gnu.org>

Update of sr #107929 (project gnutls):

                  Status:                    None => In Progress            
             Assigned to:                    None => nmav                   

    _______________________________________________________

Follow-up Comment #1:

Nice catch thank you. Does the following patch fixes the issue you notice?

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


    _______________________________________________________

Reply to this item at:

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

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




From nmav at gnutls.org  Fri Jan  6 20:31:42 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 06 Jan 2012 20:31:42 +0100
Subject: =?UTF-8?B?4oCcbWFrZSBkaXN04oCdIGZhaWxzIG9uIOKAmG1hc3RlcuKAmQ==?=
In-Reply-To: <87d3aycmi8.fsf@gnu.org>
References: <87d3aycmi8.fsf@gnu.org>
Message-ID: <4F074C1E.9060403@gnutls.org>

On 01/05/2012 02:22 PM, Ludovic Court?s wrote:

> Hi,
> 
> ?make dist? appears to be failing on ?master? (from
> <http://hydra.nixos.org/build/1722988/>):
>   rm -f en at quot.gmo && /nix/store/x9792w5bv44jf9127nbjlsxswziinxrd-gettext-0.18.1.1/bin/msgfmt -c --statistics --verbose -o en at quot.gmo en at quot.po
>   en at quot.po: 292 translated messages.
>   make[4]: Entering directory `/tmp/nix-build-n7bzdxkpbh2fsl67r0ypscxpjih7ylkm-gnutls-tarball-0pre38718fe94ae05a81a2acc437dd3bf24af0173143.drv-0/git-export/po'
>   File cs.po does not exist. If you are a translator, you can create it through 'msginit'.
>   make[4]: *** [cs.po-create] Error 1
>   make[4]: Leaving directory `/tmp/nix-build-n7bzdxkpbh2fsl67r0ypscxpjih7ylkm-gnutls-tarball-0pre38718fe94ae05a81a2acc437dd3bf24af0173143.drv-0/git-export/po'

Hi Ludo,
 Just figured out. Shouldn't make autoreconf fix that?

regards,
NIkos



From nmav at gnutls.org  Fri Jan  6 20:54:19 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 06 Jan 2012 20:54:19 +0100
Subject: gnutls 3.0.11
Message-ID: <4F07516B.8050907@gnutls.org>

Hello,
 I've just released gnutls 3.0.11. This release fixes a
timing attack possible in the DTLS code (report and 
patch by Nadhem Alfardan and Kenny Paterson).


* Version 3.0.11 (released 2012-01-06)

** libgnutls: Corrected functionality of
gnutls_record_get_direction(). Reported by Philip Allison.

** libgnutls: Provide less timing information when decoding
TLS/DTLS record packets. Patch by Nadhem Alfardan.

** 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 XZ compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.11.tar.xz
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.11.tar.xz
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.11.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.11.tar.xz.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.11.tar.xz.sig
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.11.tar.xz.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  Fri Jan  6 21:40:20 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 06 Jan 2012 21:40:20 +0100
Subject: gnutls 2.12.15
Message-ID: <4F075C34.4070309@gnutls.org>

Hello,
 I've just released gnutls 2.12.15. This is a bugfix
release on the 2.12.x branch.

Version 2.12.15 (released 2011-01-06)

** libgnutls: Disable signature algorithms that are not supported
for client certificate verification. Reported by Florian Weimer.

** libgnutls: Optimized DH generation process (ported from 3.0.x)

** 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.15.tar.bz2
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.15.tar.bz2

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.15.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.15.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 INVALID.NOREPLY at gnu.org  Fri Jan  6 21:37:19 2012
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Fri, 06 Jan 2012 20:37:19 +0000
Subject: [sr #107929] gnutls_record_get_direction() can return the wrong
	direction after an interrupted gnutls_record_send()
In-Reply-To: <20120106-210549.sv707.73804@savannah.gnu.org>
References: <20120106-184929.sv0.31741@savannah.gnu.org>
	<20120106-210549.sv707.73804@savannah.gnu.org>
Message-ID: <20120106-203719.sv0.5322@savannah.gnu.org>

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

Yes, this seems to help a lot.  :)

I added a new debug statement to the server, printed whenever
record_get_direction returned 0 after an interrupted write, or 1 after an
interrupted read.  The statement was printed every time the session hung, and
it was always after an interrupted write.

With this patch, things seem to work well again :)  It's hard to be 100% sure,
since I couldn't always reproduce the issue, but I haven't yet managed to
trigger a failure since applying the patch.

    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Fri Jan  6 21:46:39 2012
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Fri, 06 Jan 2012 20:46:39 +0000
Subject: [sr #107929] gnutls_record_get_direction() can return the wrong
	direction after an interrupted gnutls_record_send()
In-Reply-To: <20120106-203719.sv0.5322@savannah.gnu.org>
References: <20120106-184929.sv0.31741@savannah.gnu.org>
	<20120106-210549.sv707.73804@savannah.gnu.org>
	<20120106-203719.sv0.5322@savannah.gnu.org>
Message-ID: <20120106-224639.sv707.18544@savannah.gnu.org>

Update of sr #107929 (project gnutls):

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

    _______________________________________________________

Follow-up Comment #3:

Thanks for testing. It uses the same method as gnutls 2.10.x to report the
direction so I don't think it would have any issue. I've released 3.0.11
including this patch.

    _______________________________________________________

Reply to this item at:

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

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




From nmav at gnutls.org  Fri Jan  6 22:00:59 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 06 Jan 2012 22:00:59 +0100
Subject: gnutls 2.12.16
Message-ID: <4F07610B.1090601@gnutls.org>

Hello,
 I've just released gnutls 2.12.16. It seems 2.12.15 was missing
an important fix that is included in this release. 

Version 2.12.16 (released 2011-01-06)

** libgnutls: Corrected functionality of
gnutls_record_get_direction(). Reported by Philip Allison.

** 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.16.tar.bz2
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.16.tar.bz2

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.16.tar.bz2.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.16.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 ml at smtp.fakessh.eu  Sat Jan  7 01:16:39 2012
From: ml at smtp.fakessh.eu (ml)
Date: Sat, 07 Jan 2012 01:16:39 +0100
Subject: gnutls 2.12.16
In-Reply-To: <4F07610B.1090601@gnutls.org>
References: <4F07610B.1090601@gnutls.org>
Message-ID: <cdb8e57ef23e348249a06469927ca4ff@roundcube.fakessh.eu>

Le 2012-01-06 22:00, Nikos Mavrogiannopoulos a ?crit?:
> Hello,
>  I've just released gnutls 2.12.16. It seems 2.12.15 was missing
> an important fix that is included in this release.
>
> Version 2.12.16 (released 2011-01-06)
>
> ** libgnutls: Corrected functionality of
> gnutls_record_get_direction(). Reported by Philip Allison.
>
> ** 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.16.tar.bz2
>   http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.16.tar.bz2
>
> Here are OpenPGP detached signatures signed using key 0x96865171:
>
>   ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.12.16.tar.bz2.sig
>   http://ftp.gnu.org/gnu/gnutls/gnutls-2.12.16.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
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at gnu.org
> https://lists.gnu.org/mailman/listinfo/gnutls-devel


I built the rpm of the last release for centos thank you for your great 
work
http://ns.fakessh.eu/rpms/gnutls-2.12.16-1.el5.src.rpm

work fine for me


-- 
  http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7
  gpg --keyserver pgp.mit.edu --recv-key 092164A7

  http://urlshort.eu fakessh @
  http://gplus.to/sshfake
  http://gplus.to/sshswilting
  http://gplus.to/john.swilting



From eliz at gnu.org  Sat Jan  7 14:41:07 2012
From: eliz at gnu.org (Eli Zaretskii)
Date: Sat, 07 Jan 2012 15:41:07 +0200
Subject: Building GnuTLS 3.0.9 on MS-Windows
Message-ID: <83ty47fx58.fsf@gnu.org>

About a week ago, I've built GnuTLS 3.0.9 on MS-Windows using MinGW
GCC-based development environment and MSYS shell and tools (the latter
are needed for having Bash and related programs necessary to run Unix
shell scripts such as `configure' and `libtool').

This message is a report on the problems I found.  Some of them might
be Windows-specific, but I think that at least some are not.

I see that versions 3.0.10 and 3.0.11 were released since then.
Therefore, it could be that some of the problems below are already
fixed.  (I've read the announcements, but the changes and bugfixes
they cited didn't seem to be related to any of the problems below.)

Here's the description of the problems I bumped into.

Problem #1: Compilation fails in lib/accelerated/x86:

     make[4]: Entering directory `/d/usr/eli/utils/gnutls-3.0.9/lib/accelerated/x86'
     /bin/sh ../../../libtool  --tag=CC --tag=CC  --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../..  -I./../../../gl -I./../../../gl -I./../../includes -I./../../includes -I./../../ -I./../ -I./../../minitasn1 -I/d/usr/include     -DASM_X86_32 -DASM_X86 -g -O2 -MT sha-padlock.lo -MD -MP -MF .deps/sha-padlock.Tpo -c -o sha-padlock.lo sha-padlock.c
     libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../.. -I./../../../gl -I./../../../gl -I./../../includes -I./../../includes -I./../../ -I./../ -I./../../minitasn1 -I/d/usr/include -DASM_X86_32 -DASM_X86 -g -O2 -MT sha-padlock.lo -MD -MP -MF .deps/sha-padlock.Tpo -c sha-padlock.c  -DDLL_EXPORT -DPIC -o .libs/sha-padlock.o
     sha-padlock.c:24:24: gnutls_int.h: No such file or directory
     sha-padlock.c:25:29: gnutls_hash_int.h: No such file or directory
     sha-padlock.c:26:27: gnutls_errors.h: No such file or directory
     In file included from ./aes-padlock.h:5,
		      from sha-padlock.c:30:
     ./aes-x86.h:24: error: syntax error before "size_t"
     ./aes-x86.h:28: error: syntax error before "size_t"

   followed by many more error messages.

   This happens because no -I flag points to the ../../../lib
   directory, where the headers live.

   I solved this by adding -I$(top_builddir)/lib to DEFAULT_INCLUDES
   in .../x86/Makefile.in:

     DEFAULT_INCLUDES = -I. at am__isrc@ -I$(top_builddir) -I$(top_builddir)/lib

   (The actual change should probably be to AM_CPPFLAGS in
   Makefile.am, but I didn't have Automake installed to do that.)

Problem #2: Creation of libgnutlsxx.la produces a warning:

     make[1]: Entering directory `/d/usr/eli/utils/gnutls-3.0.9/lib'
     /bin/sh ../libtool  --tag=CXX   --mode=link g++ -I./includes -I./includes -g -O2 -no-undefined -version-info 28:0:0 -Wl,--version-script=./libgnutlsxx.map  -o libgnutlsxx.la -rpath /d/usr/lib libgnutlsxx_la-gnutlsxx.lo libgnutls.la

     *** Warning: This system can not link to static lib archive libgnutls.la.
     *** I have the capability to make that library automatically link in when
     *** you link to this library.  But I can only do this if you have a
     *** shared version of the library, which you do not appear to have.
     Creating library file: .libs/libgnutlsxx.dll.a

   followed by a gazillion of "undefined reference" errors.

   My analysis of this was that it is impossible to build both static
   and dynamic libraries on Windows in the same build.  If that is
   true, then the `configure' script should be modified to not try
   that by default; the default should probably build only the dynamic
   libraries.

   In any case, configuring with

     ./configure --build=i686-pc-mingw32 --prefix=/d/usr --disable-shared

   succeeds and produces a static library libgnutls.a (but not before
   bumping into a couple of more problems, described below).

Problem #3: The linker fails in src/:

       CC     udp-serv.o
     udp-serv.c: In function `udp_server':
     udp-serv.c:107: warning: implicit declaration of function `usleep'
       CC     common.o
       CC     p11common.o
       CCLD   gnutls-serv.exe
     udp-serv.o(.text+0x417): In function `udp_server':
     d:/usr/eli/utils/gnutls-3.0.9/src/udp-serv.c:107: undefined reference to `usleep'

   This is because there's no `usleep' on Windows in the standard
   libraries.  I solved this by adding an implementation of `usleep'
   to udp_serv.c, which is the only source file that needs it.

   Let me know if you want me to send a patch with that
   implementation.

Problem #4: Linker fails in src/:

       CC     serv.o
     serv.c: In function `human_addr':
     serv.c:620: warning: implicit declaration of function `getnameinfo'
     serv.c: In function `listen_socket':
     serv.c:697: warning: implicit declaration of function `getaddrinfo'
     serv.c:776: warning: implicit declaration of function `freeaddrinfo'
       CC     common.o
       CC     p11common.o
       CCLD   gnutls-serv.exe
     serv.o(.text+0x369): In function `human_addr':
     d:/usr/eli/utils/gnutls-3.0.9/src/serv.c:620: undefined reference to `getnameinfo'
     serv.o(.text+0x3cb):d:/usr/eli/utils/gnutls-3.0.9/src/serv.c:633: undefined reference to `getnameinfo'
     serv.o(.text+0x617): In function `listen_socket':
     d:/usr/eli/utils/gnutls-3.0.9/src/serv.c:697: undefined reference to `getaddrinfo'
     serv.o(.text+0x7ce):d:/usr/eli/utils/gnutls-3.0.9/src/serv.c:776: undefined reference to `freeaddrinfo'

   This happens because the prototypes of getnameinfo and getaddrinfo
   (actually, their #define's to w32 API functions) in ws2tcpip.h are
   not visible in w32api headers unless _WIN32_WINNT >= 0x0501.  (The
   fallback implementation provided by MS in wspapi.h is not available
   for MinGW.)

   My solution was to set _WIN32_WINNT on the Make command line:

     make DEFS='-DHAVE_CONFIG_H -D_WIN32_WINNT=0x0501'

   However, I believe that the build on Windows should set
   _WIN32_WINNT by default, since that's the only way to build GnuTLS
   with MinGW, AFAICS.

Problem #5: Compilation of doc/printlist.c fails:

     make[4]: Entering directory `/d/usr/eli/utils/gnutls-3.0.9/doc'
     gcc -std=gnu99 -g -O2 -I/d/usr/include   printlist.c   -o printlist
     printlist.c:21:20: config.h: No such file or directory
     printlist.c:25:27: gnutls/gnutls.h: No such file or directory
     printlist.c:26:25: gnutls/x509.h: No such file or directory
     printlist.c:27:28: gnutls/openpgp.h: No such file or directory
     printlist.c: In function `main_texinfo':
     printlist.c:49: error: `gnutls_kx_algorithm_t' undeclared (first use in this function)
     printlist.c:49: error: (Each undeclared identifier is reported only once
     printlist.c:49: error: for each function it appears in.)
     printlist.c:49: error: syntax error before "kx"
     printlist.c:50: error: `gnutls_cipher_algorithm_t' undeclared (first use in this function)
     printlist.c:51: error: `gnutls_mac_algorithm_t' undeclared (first use in this function)
     printlist.c:52: error: `gnutls_protocol_t' undeclared (first use in this function)
     printlist.c:58: warning: implicit declaration of function `gnutls_cipher_suite_info'

   and many more similar errors.

   The reason is that doc/Makefile.in used a literal "printlist"
   without $(EXEEXT), and therefore Make invokes default rules to
   build programs.  My solution was to edit Makefile.in to add the
   missing $(EXEEXT).

Problem #6: Failure to compile crywrap:

     Making all in crywrap
     make[3]: Entering directory `/d/usr/eli/utils/gnutls-3.0.9/src/crywrap'
       CC     crywrap.o
     crywrap.c:36:17: grp.h: No such file or directory
     crywrap.c:40:17: pwd.h: No such file or directory
     crywrap.c:49:22: sys/wait.h: No such file or directory
     crywrap.c:50:20: syslog.h: No such file or directory
     In file included from crywrap.c:59:
     crywrap.h:66: error: syntax error before "in_port_t"
     crywrap.h:66: warning: no semicolon at end of struct or union
     crywrap.h:66: warning: no semicolon at end of struct or union
     crywrap.h:68: error: syntax error before '}' token
     crywrap.h:68: warning: type defaults to `int' in declaration of `rpl_listen'
     crywrap.h:68: error: 'rpl_listen' redeclared as different kind of symbol
     ./../../gl/sys/socket.h:775: error: previous declaration of 'rpl_listen' was here
     crywrap.h:68: error: 'rpl_listen' redeclared as different kind of symbol
     ./../../gl/sys/socket.h:775: error: previous declaration of 'rpl_listen' was here

   and many more similar errors.

   Crywrap is completely non-portable to Windows and cannot possibly
   compile with MinGW.  I think the Windows build should simply skip
   it, as it is an non-essential component of GnuTLS.

The rest of the problems are related to the test suite.

Problem #7: "make check" fails in `tests' while compiling test
programs:

     make[2]: Entering directory `/d/usr/eli/utils/gnutls-3.0.9/tests'
     /bin/sh ../libtool  --tag=CC   --mode=link gcc -std=gnu99   -g -O2 -no-install
     -o mini-deflate.exe mini-deflate.o ../lib/libgnutls.la ../gl/libgnu.la libutils.la  -lws2_32
     libtool: link: gcc -std=gnu99 -g -O2 -o mini-deflate.exe mini-deflate.o  ../lib/.libs/libgnutls.a -L/d/usr/lib -lnettle -lhogweed /d/usr/lib/libgmp.dll.a -lz -Ld:/usr/lib /d/usr/lib/libp11-kit.dll.a ../gl/.libs/libgnu.a /d/usr/lib/libintl.dll.a /d/usr/lib/libiconv.dll.a ./.libs/libutils.a -lws2_32 -L/d/usr/lib -L/d/usr/lib
     ./.libs/libutils.a(utils.o)(.text+0x2b): In function `fail':
     d:/usr/eli/utils/gnutls-3.0.9/tests/utils.c:51: undefined reference to `rpl_vsnprintf'
     ./.libs/libutils.a(utils.o)(.text+0x9b): In function `success':
     d:/usr/eli/utils/gnutls-3.0.9/tests/utils.c:66: undefined reference to `rpl_vsnprintf'
     collect2: ld returned 1 exit status
     make[2]: *** [mini-deflate.exe] Error 1
     make[2]: Leaving directory `/d/usr/eli/utils/gnutls-3.0.9/tests'
     make[1]: *** [check-am] Error 2
     make[1]: Leaving directory `/d/usr/eli/utils/gnutls-3.0.9/tests'
     make: *** [check-recursive] Error 1

   This happens because tests/Makefile.in does not add libgnu.a after
   libutils.a, which obviously needs it, at least on systems whose
   vsnprintf is replaced by gnulib's one.  My solution was to add the
   missing library:

     LDADD = ../lib/libgnutls.la \
	     ../gl/libgnu.la \
	     libutils.la \
	     ../gl/libgnu.la \       <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
	     $(LTLIBGCRYPT)	\
	     $(LIBSOCKET) $(INET_NTOP_LIB) $(INET_PTON_LIB)

Problem #8: Compilation of tests/openpgp-auth2.c fails:

       CC     openpgp-auth2.o
     openpgp-auth2.c:36:22: sys/wait.h: No such file or directory
     openpgp-auth2.c: In function `doit':
     openpgp-auth2.c:82: warning: implicit declaration of function `socketpair'
     openpgp-auth2.c:86: warning: implicit declaration of function `alloca'
     openpgp-auth2.c:96: warning: implicit declaration of function `fork'
     openpgp-auth2.c:232: warning: implicit declaration of function `wait'
     openpgp-auth2.c:239: warning: implicit declaration of function `WIFEXITED'
     openpgp-auth2.c:241: warning: implicit declaration of function `WEXITSTATUS'
     openpgp-auth2.c:244: warning: implicit declaration of function `WIFSIGNALED'
     openpgp-auth2.c:245: warning: implicit declaration of function `WTERMSIG'
     make[2]: *** [openpgp-auth2.o] Error 1
     make[2]: Leaving directory `/d/usr/eli/utils/gnutls-3.0.9/tests'
     make[1]: *** [check-am] Error 2
     make[1]: Leaving directory `/d/usr/eli/utils/gnutls-3.0.9/tests'
     make: *** [check-recursive] Error 1

   This test program cannot be built on Windows, as it uses facilities that
   are not available (fork, wait, WTERMSIG etc.).  This test should be
   skipped on MS-Windows.

Problem #9: Compilation of tests/slow/gendh.c fails:

     make  gendh.exe keygen.exe cipher-test.exe
     make[1]: Entering directory `/d/usr/eli/utils/gnutls-3.0.9/tests/slow'
     gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../..  -I../../lib/includes -I../../lib/includes -I../../tests/ -I/d/usr/include   -g -O2 -MT gendh.o -MD -MP -MF .deps/gendh.Tpo -c -o gendh.o gendh.c
     gendh.c:29:19: utils.h: No such file or directory
     gendh.c: In function `doit':
     gendh.c:34: error: `gnutls_dh_params_t' undeclared (first use in this function)
     gendh.c:34: error: (Each undeclared identifier is reported only once
     gendh.c:34: error: for each function it appears in.)
     gendh.c:34: error: syntax error before "dh_params"
     gendh.c:37: warning: implicit declaration of function `gnutls_global_init'
     gendh.c:39: warning: implicit declaration of function `fail'
     gendh.c:41: warning: implicit declaration of function `gnutls_dh_params_init'
     gendh.c:41: error: `dh_params' undeclared (first use in this function)
     gendh.c:44: warning: implicit declaration of function `gnutls_dh_params_generate2'
     gendh.c:47: warning: implicit declaration of function `success'
     make[1]: *** [gendh.o] Error 1
     make[1]: Leaving directory `/d/usr/eli/utils/gnutls-3.0.9/tests/slow'
     make: *** [check-am] Error 2

   This happens because GCC, at least on Windows, doesn't like
   trailing slashes in the directories mention in the -I switch.
   Solution: remove the slash:

     AM_CPPFLAGS = \
	     -I$(top_srcdir)/lib/includes		\
	     -I$(top_builddir)/lib/includes \
	     -I$(top_srcdir)/tests/  <<<<<<<<<<<<<<<<<<<

Lastly, there were several warning messages that, although they seem
harmless, are perhaps an evidence that some Windows-specific cleanups
are needed; I think a clean build without warnings goes a long way
towards building user's confidence that the build is successful.

Here are these warnings:

       CCLD   gnutls-serv.exe
     Info: resolving _nettle_arcfour_crypt by linking to __imp__nettle_arcfour_crypt (auto-import)

(there were a lot of these in many places).  I understand that this
means the linker resolved a function by linking against a DLL, but
perhaps some compiler or linker switch could prevent these warnings
from being emitted in the first place.

Another group of warnings looked like this:

       CCLD   libexamples.la
     libtool: link: warning: `-no-install' is ignored for i686-pc-mingw32
     libtool: link: warning: assuming `-no-fast-install' instead

   and many similar ones.

   Only by digging deep inside libtool did I understand that this is
   probably harmless, as Windows indeed does not support -no-install.
   But I think the build should avoid using -no-install on Windows by
   default.

This is all.  Hope this will be useful.

Last, but certainly not least: thank you for developing and
maintaining GnuTLS!



From eliz at gnu.org  Sat Jan  7 14:42:04 2012
From: eliz at gnu.org (Eli Zaretskii)
Date: Sat, 07 Jan 2012 15:42:04 +0200
Subject: Building GnuTLS 3.0.9 on MS-Windows
Message-ID: <83sjjrfx3n.fsf@gnu.org>

Forgot to tell: please CC me on responses, as I'm not subscribed to
this list.

TIA



From rich at kde.org  Sat Jan  7 22:11:00 2012
From: rich at kde.org (Richard Moore)
Date: Sat, 7 Jan 2012 21:11:00 +0000
Subject: gnutls_x509_crt_print omits AIA extension
Message-ID: <CAMp7mVtFjZUmPFvtNsq75oCRwpeHN9R_2xUcJAcVcyCy4Rfm7Q@mail.gmail.com>

In the course of evaluating gnutls vs. openssl, I've spotted that
gnutls_x509_crt_print fails to display the AIA extension. Unknown
extensions are displayed properly (hexdump), so it's not simply that
the code doesn't understand it. This can be reproduced using the
supplied certtool:

certtool --infile gmail.pem --certificate-info

Just grab the cert from any valid site and you'll find the extension.
Compare the output with:

openssl x509 -text -in gmail.pem

(both the above commands were run using the pem of the gmail certificate).

Cheers

Rich.



From nmav at gnutls.org  Sun Jan  8 11:03:43 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 08 Jan 2012 11:03:43 +0100
Subject: gnutls_x509_crt_print omits AIA extension
In-Reply-To: <CAMp7mVtFjZUmPFvtNsq75oCRwpeHN9R_2xUcJAcVcyCy4Rfm7Q@mail.gmail.com>
References: <CAMp7mVtFjZUmPFvtNsq75oCRwpeHN9R_2xUcJAcVcyCy4Rfm7Q@mail.gmail.com>
Message-ID: <4F0969FF.2050003@gnutls.org>

On 01/07/2012 10:11 PM, Richard Moore wrote:

> In the course of evaluating gnutls vs. openssl, I've spotted that
> gnutls_x509_crt_print fails to display the AIA extension. Unknown
> extensions are displayed properly (hexdump), so it's not simply that
> the code doesn't understand it. This can be reproduced using the
> supplied certtool:
> certtool --infile gmail.pem --certificate-info
> Just grab the cert from any valid site and you'll find the extension.
> Compare the output with:
> openssl x509 -text -in gmail.pem
> (both the above commands were run using the pem of the gmail certificate).


Which version of gnutls did you test? I just tested and the provided information
are the same.

regards,
Nikos



From nmav at gnutls.org  Sun Jan  8 11:48:01 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 08 Jan 2012 11:48:01 +0100
Subject: Building GnuTLS 3.0.9 on MS-Windows
In-Reply-To: <83ty47fx58.fsf@gnu.org>
References: <83ty47fx58.fsf@gnu.org>
Message-ID: <4F097461.1070007@gnutls.org>

On 01/07/2012 02:41 PM, Eli Zaretskii wrote:

> About a week ago, I've built GnuTLS 3.0.9 on MS-Windows using MinGW 
> GCC-based development environment and MSYS shell and tools (the
> latter are needed for having Bash and related programs necessary to
> run Unix shell scripts such as `configure' and `libtool'). This
> message is a report on the problems I found.  Some of them might

> be Windows-specific, but I think that at least some are not.


Hi Eli, thanks for the information.

> Problem #1: Compilation fails in lib/accelerated/x86:
> 
> make[4]: Entering directory
> `/d/usr/eli/utils/gnutls-3.0.9/lib/accelerated/x86' /bin/sh
> ../../../libtool  --tag=CC --tag=CC  --mode=compile gcc -std=gnu99
> -DHAVE_CONFIG_H -I. -I../../..  -I./../../../gl -I./../../../gl
> -I./../../includes -I./../../includes -I./../../ -I./../
> -I./../../minitasn1 -I/d/usr/include     -DASM_X86_32 -DASM_X86 -g
> -O2 -MT sha-padlock.lo -MD -MP -MF .deps/sha-padlock.Tpo -c -o
> sha-padlock.lo sha-padlock.c libtool: compile:  gcc -std=gnu99
> -DHAVE_CONFIG_H -I. -I../../.. -I./../../../gl -I./../../../gl
> -I./../../includes -I./../../includes -I./../../ -I./../
> -I./../../minitasn1 -I/d/usr/include -DASM_X86_32 -DASM_X86 -g -O2
> -MT sha-padlock.lo -MD -MP -MF .deps/sha-padlock.Tpo -c sha-padlock.c
> -DDLL_EXPORT -DPIC -o .libs/sha-padlock.o sha-padlock.c:24:24:
> gnutls_int.h: No such file or directory sha-padlock.c:25:29:
> gnutls_hash_int.h: No such file or directory sha-padlock.c:26:27:
> gnutls_errors.h: No such file or directory In file included from
> ./aes-padlock.h:5, from sha-padlock.c:30: ./aes-x86.h:24: error:
> syntax error before "size_t" ./aes-x86.h:28: error: syntax error
> before "size_t" followed by many more error messages.
> This happens because no -I flag points to the ../../../lib
> directory, where the headers live.


I see there is however a "-I./../../", isn't ../../ the same as ../../../lib in your build?

> My analysis of this was that it is impossible to build both static 
> and dynamic libraries on Windows in the same build.  If that is true,
> then the `configure' script should be modified to not try that by
> default; the default should probably build only the dynamic 
> libraries. In any case, configuring with ./configure
> --build=i686-pc-mingw32 --prefix=/d/usr --disable-shared succeeds and
> produces a static library libgnutls.a (but not before bumping into a
> couple of more problems, described below).


According to libtool documentation this should have been done by libtool.

"By default, this macro turns on shared libraries if they are
 available, and also enables static libraries if they don't
 conflict with the shared libraries."

Thus it looks like a libtool bug. However I'd suggest you use the alternative
option of building a shared libgnutls instead so you can replace it in
case of important security fixes (e.g. now the one with DTLS).

> Problem #3: The linker fails in src/: CC     udp-serv.o udp-serv.c:
> In function `udp_server': udp-serv.c:107: warning: implicit
> declaration of function `usleep' CC     common.o CC     p11common.o 
> CCLD   gnutls-serv.exe udp-serv.o(.text+0x417): In function
> `udp_server': d:/usr/eli/utils/gnutls-3.0.9/src/udp-serv.c:107:
> undefined reference to `usleep'


I'll add the gnulib usleep module for that. 

> Problem #4: Linker fails in src/:
> 
> CC     serv.o serv.c: In function `human_addr': serv.c:620: warning:
> implicit declaration of function `getnameinfo' serv.c: In function
> `listen_socket': serv.c:697: warning: implicit declaration of
> function `getaddrinfo' serv.c:776: warning: implicit declaration of
> function `freeaddrinfo' CC     common.o CC     p11common.o CCLD
> gnutls-serv.exe serv.o(.text+0x369): In function `human_addr': 
> d:/usr/eli/utils/gnutls-3.0.9/src/serv.c:620: undefined reference to
> `getnameinfo' 
> serv.o(.text+0x3cb):d:/usr/eli/utils/gnutls-3.0.9/src/serv.c:633:
> undefined reference to `getnameinfo' serv.o(.text+0x617): In function
> `listen_socket': d:/usr/eli/utils/gnutls-3.0.9/src/serv.c:697:
> undefined reference to `getaddrinfo' 
> serv.o(.text+0x7ce):d:/usr/eli/utils/gnutls-3.0.9/src/serv.c:776:
> undefined reference to `freeaddrinfo'
> 
> This happens because the prototypes of getnameinfo and getaddrinfo 
> (actually, their #define's to w32 API functions) in ws2tcpip.h are 
> not visible in w32api headers unless _WIN32_WINNT >= 0x0501.  (The 
> fallback implementation provided by MS in wspapi.h is not available 
> for MinGW.) My solution was to set _WIN32_WINNT on the Make command
> line: make DEFS='-DHAVE_CONFIG_H -D_WIN32_WINNT=0x0501' However, I
> believe that the build on Windows should set _WIN32_WINNT by default,
> since that's the only way to build GnuTLS with MinGW, AFAICS.



I've added the gnulib module getaddrinfo that contains those functions. 
It uses a different way (through GetProcAddress) to find those functions 
in windows but should be equivalent.

> Problem #5: Compilation of doc/printlist.c fails:

...

> and many more similar errors.
> The reason is that doc/Makefile.in used a literal "printlist" without
> $(EXEEXT), and therefore Make invokes default rules to build
> programs.  My solution was to edit Makefile.in to add the missing
> $(EXEEXT).


It looks like an automake bug then. Anyway I've disable this build
(already in 3.0.11) for windows so this should e ok.

> Problem #6: Failure to compile crywrap:
> 
[...]

> 

> and many more similar errors.
> 
> Crywrap is completely non-portable to Windows and cannot possibly 
> compile with MinGW.  I think the Windows build should simply skip it,
> as it is an non-essential component of GnuTLS.


Indeed. It is no longer compiled in 3.0.11 for windows.

> The rest of the problems are related to the test suite.
> Problem #7: "make check" fails in `tests' while compiling test 
> programs:


You should try 3.0.11 because not only tests were fixed but also
some internal library fixes (for openpgp) were done to make it work
in windows.

> This happens because tests/Makefile.in does not add libgnu.a after 
> libutils.a, which obviously needs it, at least on systems whose 
> vsnprintf is replaced by gnulib's one.  My solution was to add the 
> missing library:
> LDADD = ../lib/libgnutls.la \ ../gl/libgnu.la \ libutils.la \ 

> ../gl/libgnu.la \       <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 

> $(LTLIBGCRYPT)	\ $(LIBSOCKET) $(INET_NTOP_LIB) $(INET_PTON_LIB)

I've solved that and should be ok in 3.0.11 in a similar way.

> Problem #8: Compilation of tests/openpgp-auth2.c fails:

Indeed, it is now skipped in windows.

> Problem #9: Compilation of tests/slow/gendh.c fails:
> 
> This happens because GCC, at least on Windows, doesn't like trailing
> slashes in the directories mention in the -I switch. Solution: remove
> the slash:
> 
> AM_CPPFLAGS = \ -I$(top_srcdir)/lib/includes		\ 
> -I$(top_builddir)/lib/includes \ -I$(top_srcdir)/tests/
> <<<<<<<<<<<<<<<<<<<


Done.

> CCLD   gnutls-serv.exe Info: resolving _nettle_arcfour_crypt by
> linking to __imp__nettle_arcfour_crypt (auto-import)
> (there were a lot of these in many places).  I understand that this 
> means the linker resolved a function by linking against a DLL, but 
> perhaps some compiler or linker switch could prevent these warnings 
> from being emitted in the first place.


I don't know what this warning means or does. How would you fix it?

> Another group of warnings looked like this:
> CCLD   libexamples.la libtool: link: warning: `-no-install' is
> ignored for i686-pc-mingw32 libtool: link: warning: assuming
> `-no-fast-install' instead

...
> Only by digging deep inside libtool did I understand that this is 
> probably harmless, as Windows indeed does not support -no-install. 
> But I think the build should avoid using -no-install on Windows by 
> default.

This one I don't know if it is correct to remove it. I think that 
Libtool shouldn't emit this warning if no-install is ignored for the 
windows platform. Otherwise we'll have to know which platforms support
it or not, and because we don't want to care about it is the reason we 
use libtool anyway :)

> This is all.  Hope this will be useful.


Thank you for this information. I've updated the git with your suggested fixes.


regards,
Nikos




From rich at kde.org  Sun Jan  8 11:57:05 2012
From: rich at kde.org (Richard Moore)
Date: Sun, 8 Jan 2012 10:57:05 +0000
Subject: gnutls_x509_crt_print omits AIA extension
In-Reply-To: <4F0969FF.2050003@gnutls.org>
References: <CAMp7mVtFjZUmPFvtNsq75oCRwpeHN9R_2xUcJAcVcyCy4Rfm7Q@mail.gmail.com>
	<4F0969FF.2050003@gnutls.org>
Message-ID: <CAMp7mVuZmuCTXwVnE=viE9VZUqyXTtFOkE00Q=72GuvCRjG2Vg@mail.gmail.com>

On Sun, Jan 8, 2012 at 10:03 AM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> On 01/07/2012 10:11 PM, Richard Moore wrote:
>
>> In the course of evaluating gnutls vs. openssl, I've spotted that
>> gnutls_x509_crt_print fails to display the AIA extension. Unknown
>> extensions are displayed properly (hexdump), so it's not simply that
>> the code doesn't understand it. This can be reproduced using the
>> supplied certtool:
>> certtool --infile gmail.pem --certificate-info
>> Just grab the cert from any valid site and you'll find the extension.
>> Compare the output with:
>> openssl x509 -text -in gmail.pem
>> (both the above commands were run using the pem of the gmail certificate).
>
>
> Which version of gnutls did you test? I just tested and the provided information
> are the same.

I'm using version 3.0.3 from suse 12.1 (package name is
gnutls-3.0.3-5.1.2.x86_64).
Here's the extensions section from cert tool for gmail's cert:

       Extensions:
                Basic Constraints (critical):
                        Certificate Authority (CA): FALSE
                CRL Distribution points (not critical):
                        URI: http://crl.thawte.com/ThawteSGCCA.crl
                Key Purpose (not critical):
                        TLS WWW Server.
                        TLS WWW Client.
                        2.16.840.1.113730.4.1
                Unknown extension 1.3.6.1.5.5.7.1.1 (not critical):
                        ASCII:
0d0"..+.....0...http://ocsp.thawte.com0>..+.....0..2http://www.thawte.com/repository/Thawte_SGC_CA.crt
                        Hexdump:
3064302206082b060105050730018616687474703a2f2f6f6373702e7468617774652e636f6d303e06082b060105050730028632687474703a2f2f7777772e7468617774652e636f6d2f7265706f7369746f72792f5468617774655f5347435f43412e637274

Here's the equivalent from openssl:

       X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.thawte.com/ThawteSGCCA.crl

            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client
Authentication, Netscape Server Gated Crypto
            Authority Information Access:
                OCSP - URI:http://ocsp.thawte.com
                CA Issuers -
URI:http://www.thawte.com/repository/Thawte_SGC_CA.crt

Regards

Rich.







>
> regards,
> Nikos



From rich at kde.org  Sun Jan  8 11:58:46 2012
From: rich at kde.org (Richard Moore)
Date: Sun, 8 Jan 2012 10:58:46 +0000
Subject: gnutls_x509_crt_print omits AIA extension
In-Reply-To: <CAMp7mVuZmuCTXwVnE=viE9VZUqyXTtFOkE00Q=72GuvCRjG2Vg@mail.gmail.com>
References: <CAMp7mVtFjZUmPFvtNsq75oCRwpeHN9R_2xUcJAcVcyCy4Rfm7Q@mail.gmail.com>
	<4F0969FF.2050003@gnutls.org>
	<CAMp7mVuZmuCTXwVnE=viE9VZUqyXTtFOkE00Q=72GuvCRjG2Vg@mail.gmail.com>
Message-ID: <CAMp7mVugw4Kja6R2EEmAV=rdh7ky4zo44aauiy33hR8xo7nPdQ@mail.gmail.com>

On Sun, Jan 8, 2012 at 10:57 AM, Richard Moore <rich at kde.org> wrote:
> On Sun, Jan 8, 2012 at 10:03 AM, Nikos Mavrogiannopoulos
> <nmav at gnutls.org> wrote:
>> On 01/07/2012 10:11 PM, Richard Moore wrote:
>>
>>> In the course of evaluating gnutls vs. openssl, I've spotted that
>>> gnutls_x509_crt_print fails to display the AIA extension. Unknown
>>> extensions are displayed properly (hexdump), so it's not simply that
>>> the code doesn't understand it. This can be reproduced using the
>>> supplied certtool:
>>> certtool --infile gmail.pem --certificate-info
>>> Just grab the cert from any valid site and you'll find the extension.
>>> Compare the output with:
>>> openssl x509 -text -in gmail.pem
>>> (both the above commands were run using the pem of the gmail certificate).
>>
>>
>> Which version of gnutls did you test? I just tested and the provided information
>> are the same.
>
> I'm using version 3.0.3 from suse 12.1 (package name is
> gnutls-3.0.3-5.1.2.x86_64).
> Here's the extensions section from cert tool for gmail's cert:
>
> ? ? ? Extensions:
> ? ? ? ? ? ? ? ?Basic Constraints (critical):
> ? ? ? ? ? ? ? ? ? ? ? ?Certificate Authority (CA): FALSE
> ? ? ? ? ? ? ? ?CRL Distribution points (not critical):
> ? ? ? ? ? ? ? ? ? ? ? ?URI: http://crl.thawte.com/ThawteSGCCA.crl
> ? ? ? ? ? ? ? ?Key Purpose (not critical):
> ? ? ? ? ? ? ? ? ? ? ? ?TLS WWW Server.
> ? ? ? ? ? ? ? ? ? ? ? ?TLS WWW Client.
> ? ? ? ? ? ? ? ? ? ? ? ?2.16.840.1.113730.4.1
> ? ? ? ? ? ? ? ?Unknown extension 1.3.6.1.5.5.7.1.1 (not critical):
> ? ? ? ? ? ? ? ? ? ? ? ?ASCII:
> 0d0"..+.....0...http://ocsp.thawte.com0>..+.....0..2http://www.thawte.com/repository/Thawte_SGC_CA.crt
> ? ? ? ? ? ? ? ? ? ? ? ?Hexdump:
> 3064302206082b060105050730018616687474703a2f2f6f6373702e7468617774652e636f6d303e06082b060105050730028632687474703a2f2f7777772e7468617774652e636f6d2f7265706f7369746f72792f5468617774655f5347435f43412e637274
>
> Here's the equivalent from openssl:
>
> ? ? ? X509v3 extensions:
> ? ? ? ? ? ?X509v3 Basic Constraints: critical
> ? ? ? ? ? ? ? ?CA:FALSE
> ? ? ? ? ? ?X509v3 CRL Distribution Points:
>
> ? ? ? ? ? ? ? ?Full Name:
> ? ? ? ? ? ? ? ? ?URI:http://crl.thawte.com/ThawteSGCCA.crl
>
> ? ? ? ? ? ?X509v3 Extended Key Usage:
> ? ? ? ? ? ? ? ?TLS Web Server Authentication, TLS Web Client
> Authentication, Netscape Server Gated Crypto
> ? ? ? ? ? ?Authority Information Access:
> ? ? ? ? ? ? ? ?OCSP - URI:http://ocsp.thawte.com
> ? ? ? ? ? ? ? ?CA Issuers -
> URI:http://www.thawte.com/repository/Thawte_SGC_CA.crt
>

Ah looking again, I can see that the AIA extension has been treated as
unknown (I'd assumed the unknown one would be the logo extension that
quite a few cert seem to have these days). I guess this version just
doesn't support AIA properly.

Rich.



> Regards
>
> Rich.
>
>
>
>
>
>
>
>>
>> regards,
>> Nikos



From eliz at gnu.org  Sun Jan  8 12:12:36 2012
From: eliz at gnu.org (Eli Zaretskii)
Date: Sun, 08 Jan 2012 06:12:36 -0500
Subject: Building GnuTLS 3.0.9 on MS-Windows
In-Reply-To: <4F097461.1070007@gnutls.org> (message from Nikos
	Mavrogiannopoulos on Sun, 08 Jan 2012 11:48:01 +0100)
References: <83ty47fx58.fsf@gnu.org> <4F097461.1070007@gnutls.org>
Message-ID: <E1Rjqg0-0004FV-JZ@fencepost.gnu.org>

> Date: Sun, 08 Jan 2012 11:48:01 +0100
> From: Nikos Mavrogiannopoulos <nmav at gnutls.org>
> CC: gnutls-devel at gnu.org
> 
> Hi Eli, thanks for the information.

You are welcome.

> > This happens because no -I flag points to the ../../../lib
> > directory, where the headers live.
> 
> 
> I see there is however a "-I./../../", isn't ../../ the same as ../../../lib in your build?

Yes, it is.  It sounds like I reached the wrong conclusion.  the real
reason is the same as for one of the other problems: the trailing
slash in "-I./../../".  So probably removing that slash will do the
trick.

> > My analysis of this was that it is impossible to build both static 
> > and dynamic libraries on Windows in the same build.  If that is true,
> > then the `configure' script should be modified to not try that by
> > default; the default should probably build only the dynamic 
> > libraries. In any case, configuring with ./configure
> > --build=i686-pc-mingw32 --prefix=/d/usr --disable-shared succeeds and
> > produces a static library libgnutls.a (but not before bumping into a
> > couple of more problems, described below).
> 
> 
> According to libtool documentation this should have been done by libtool.
> 
> "By default, this macro turns on shared libraries if they are
>  available, and also enables static libraries if they don't
>  conflict with the shared libraries."
> 
> Thus it looks like a libtool bug. However I'd suggest you use the alternative
> option of building a shared libgnutls instead so you can replace it in
> case of important security fixes (e.g. now the one with DTLS).

Sorry, I'm not following: which "alternative option"?

> > Problem #3: The linker fails in src/: CC     udp-serv.o udp-serv.c:
> > In function `udp_server': udp-serv.c:107: warning: implicit
> > declaration of function `usleep' CC     common.o CC     p11common.o 
> > CCLD   gnutls-serv.exe udp-serv.o(.text+0x417): In function
> > `udp_server': d:/usr/eli/utils/gnutls-3.0.9/src/udp-serv.c:107:
> > undefined reference to `usleep'
> 
> 
> I'll add the gnulib usleep module for that. 

That one is currently useless: it has a 1-sec granularity.  I will
take this up with gnulib folks, then.

> You should try 3.0.11 because not only tests were fixed but also
> some internal library fixes (for openpgp) were done to make it work
> in windows.

OK.  But it sounds like trying 3.0.12, when it is available, would be
even better, as it is supposed to include a few other fixes you
mentioned above.

> > CCLD   gnutls-serv.exe Info: resolving _nettle_arcfour_crypt by
> > linking to __imp__nettle_arcfour_crypt (auto-import)
> > (there were a lot of these in many places).  I understand that this 
> > means the linker resolved a function by linking against a DLL, but 
> > perhaps some compiler or linker switch could prevent these warnings 
> > from being emitted in the first place.
> 
> 
> I don't know what this warning means or does. How would you fix it?

I don't know.  I will try to find out and get back to you.

> Thank you for this information. I've updated the git with your suggested fixes.

Thanks!



From nmav at gnutls.org  Sun Jan  8 12:45:44 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 08 Jan 2012 12:45:44 +0100
Subject: gnutls_x509_crt_print omits AIA extension
In-Reply-To: <CAMp7mVugw4Kja6R2EEmAV=rdh7ky4zo44aauiy33hR8xo7nPdQ@mail.gmail.com>
References: <CAMp7mVtFjZUmPFvtNsq75oCRwpeHN9R_2xUcJAcVcyCy4Rfm7Q@mail.gmail.com>	<4F0969FF.2050003@gnutls.org>	<CAMp7mVuZmuCTXwVnE=viE9VZUqyXTtFOkE00Q=72GuvCRjG2Vg@mail.gmail.com>
	<CAMp7mVugw4Kja6R2EEmAV=rdh7ky4zo44aauiy33hR8xo7nPdQ@mail.gmail.com>
Message-ID: <4F0981E8.6080206@gnutls.org>

On 01/08/2012 11:58 AM, Richard Moore wrote:


> Ah looking again, I can see that the AIA extension has been treated as
> unknown (I'd assumed the unknown one would be the logo extension that
> quite a few cert seem to have these days). I guess this version just
> doesn't support AIA properly.


Indeed. It was added in 3.0.4!

regards,
Nikos



From simon at josefsson.org  Sun Jan  8 13:30:25 2012
From: simon at josefsson.org (Simon Josefsson)
Date: Sun, 08 Jan 2012 13:30:25 +0100
Subject: implicit declaration of function 'scm_c_issue_deprecation_warning'
In-Reply-To: <20111217150555.GA3682@downhill.g.la> (Andreas Metzler's message
	of "Sat, 17 Dec 2011 16:05:55 +0100")
References: <20111217150555.GA3682@downhill.g.la>
Message-ID: <87pqeubcm6.fsf@latte.josefsson.org>

Ludo, do you have any idea?  By the function name, it looks like this
was somehow intended, but I'm not sure what the origin of the problem
is.  Maybe the guile stuff still use the non-string based priority
functions?

/Simon

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

> Hello,
>
> building 3.0.x triggers an implicit-function-declaration warning in
> the guile code. (The respective warning is present in 3.0.0 to 3.0.9)
>
> -----------------------------------------
> make[5]: Entering directory `/tmp/GNUTLS/gnutls-3.0.9/guile/src'
> \
> #       source='core.c' object='guile_gnutls_v_2_la-core.lo' libtool=yes 
> /bin/bash ../../libtool --tag=CC --mode=compile gcc -std=gnu99
> -DHAVE_CONFIG_H -I. -I../..  -I../../lib/includes -I../../lib/includes
> -I../../extra/includes -I../.. -I.  -Wno-strict-prototypes -I../../gl
> -I../../gl -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Wformat-security -Werror=format-security -Wall -c -o
> guile_gnutls_v_2_la-core.lo `test -f 'core.c' || echo './'`core.c
> libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H
> -I. -I../.. -I../../lib/includes -I../../lib/includes
> -I../../extra/includes -I../.. -I. -Wno-strict-prototypes -I../../gl
> -I../../gl -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Wformat-security -Werror=format-security -Wall -c core.c -fPIC -DPIC
> -o .libs/guile_gnutls_v_2_la-core.o
> In file included from core.c:506:0:
> priorities.i.c: In function 'scm_gnutls_set_session_cipher_priority_x':
> priorities.i.c:11:3: warning: implicit declaration of function
> scm_c_issue_deprecation_warning' [-Wimplicit-function-declaration]
> -----------------------------------------
>
> cu andreas



From ludo at gnu.org  Sun Jan  8 16:38:16 2012
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Sun, 08 Jan 2012 16:38:16 +0100
Subject: implicit declaration of function 'scm_c_issue_deprecation_warning'
In-Reply-To: <87pqeubcm6.fsf@latte.josefsson.org> (Simon Josefsson's message
	of "Sun, 08 Jan 2012 13:30:25 +0100")
References: <20111217150555.GA3682@downhill.g.la>
	<87pqeubcm6.fsf@latte.josefsson.org>
Message-ID: <87d3auxl07.fsf@gnu.org>

Hello and happy new year!  :-)

Simon Josefsson <simon at josefsson.org> skribis:

> Ludo, do you have any idea?  By the function name, it looks like this
> was somehow intended, but I'm not sure what the origin of the problem
> is.  Maybe the guile stuff still use the non-string based priority
> functions?

The intention is to emit a deprecation warning (using Guile?s mechanism)
when a non-string priority function is used.

>> priorities.i.c: In function 'scm_gnutls_set_session_cipher_priority_x':
>> priorities.i.c:11:3: warning: implicit declaration of function
>> scm_c_issue_deprecation_warning' [-Wimplicit-function-declaration]

In Guile 1.8 (IIRC), that function is not always declared in public
headers, although it?s actually available.  Which Guile version is it?
Is it compiled with --disable-deprecated?

Thanks,
Ludo?.



From ludo at gnu.org  Sun Jan  8 16:46:49 2012
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Sun, 08 Jan 2012 16:46:49 +0100
Subject: =?utf-8?B?4oCcbWFrZSBkaXN04oCd?= fails on =?utf-8?B?4oCYbWFz?=
	=?utf-8?B?dGVy4oCZ?=
In-Reply-To: <4F074C1E.9060403@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Fri, 06 Jan 2012 20:31:42 +0100")
References: <87d3aycmi8.fsf@gnu.org> <4F074C1E.9060403@gnutls.org>
Message-ID: <8762gmxkly.fsf@gnu.org>

Hi Nikos,

Nikos Mavrogiannopoulos <nmav at gnutls.org> skribis:

> On 01/05/2012 02:22 PM, Ludovic Court?s wrote:
>
>> Hi,
>> 
>> ?make dist? appears to be failing on ?master? (from
>> <http://hydra.nixos.org/build/1722988/>):
>>   rm -f en at quot.gmo && /nix/store/x9792w5bv44jf9127nbjlsxswziinxrd-gettext-0.18.1.1/bin/msgfmt -c --statistics --verbose -o en at quot.gmo en at quot.po
>>   en at quot.po: 292 translated messages.
>>   make[4]: Entering directory `/tmp/nix-build-n7bzdxkpbh2fsl67r0ypscxpjih7ylkm-gnutls-tarball-0pre38718fe94ae05a81a2acc437dd3bf24af0173143.drv-0/git-export/po'
>>   File cs.po does not exist. If you are a translator, you can create it through 'msginit'.
>>   make[4]: *** [cs.po-create] Error 1
>>   make[4]: Leaving directory `/tmp/nix-build-n7bzdxkpbh2fsl67r0ypscxpjih7ylkm-gnutls-tarball-0pre38718fe94ae05a81a2acc437dd3bf24af0173143.drv-0/git-export/po'
>
> Hi Ludo,
>  Just figured out.

Seems the problem is still here: <http://hydra.nixos.org/build/1782567>.

> Shouldn't make autoreconf fix that?

On Hydra builds start from a fresh checkout and do the full bootstrap
procedure, which should work.

Thanks,
Ludo?.



From ametzler at downhill.at.eu.org  Sun Jan  8 17:31:35 2012
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sun, 8 Jan 2012 17:31:35 +0100
Subject: implicit declaration of function 'scm_c_issue_deprecation_warning'
In-Reply-To: <87d3auxl07.fsf@gnu.org>
References: <20111217150555.GA3682@downhill.g.la>
	<87pqeubcm6.fsf@latte.josefsson.org> <87d3auxl07.fsf@gnu.org>
Message-ID: <20120108163135.GD2039@downhill.g.la>

On 2012-01-08 Ludovic Court?s <ludo at gnu.org> wrote:
> Simon Josefsson <simon at josefsson.org> skribis:
>> Andreas Metzler
[...]
>>> priorities.i.c: In function 'scm_gnutls_set_session_cipher_priority_x':
>>> priorities.i.c:11:3: warning: implicit declaration of function
>>> scm_c_issue_deprecation_warning' [-Wimplicit-function-declaration]

> In Guile 1.8 (IIRC), that function is not always declared in public
> headers, although it?s actually available.  Which Guile version is it?
> Is it compiled with --disable-deprecated?

Hello,
guile 1.8.8, neither --disable-deprecated nor --ensable-deprecated is
set when building the Debian guile-1.8 package.
https://buildd.debian.org/status/fetch.php?pkg=deprec&arch=i386&ver=1.8.8%2B1-7&stamp=1320890206
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  Sun Jan  8 22:06:13 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 08 Jan 2012 22:06:13 +0100
Subject: =?UTF-8?B?4oCcbWFrZSBkaXN04oCdIGZhaWxzIG9uIOKAmG1hc3RlcuKAmQ==?=
In-Reply-To: <8762gmxkly.fsf@gnu.org>
References: <87d3aycmi8.fsf@gnu.org> <4F074C1E.9060403@gnutls.org>
	<8762gmxkly.fsf@gnu.org>
Message-ID: <4F0A0545.3040501@gnutls.org>

On 01/08/2012 04:46 PM, Ludovic Court?s wrote:


>>> ?make dist? appears to be failing on ?master? (from
>>> <http://hydra.nixos.org/build/1722988/>):
>>>   rm -f en at quot.gmo && /nix/store/x9792w5bv44jf9127nbjlsxswziinxrd-gettext-0.18.1.1/bin/msgfmt -c --statistics --verbose -o en at quot.gmo en at quot.po
>>>   en at quot.po: 292 translated messages.
>>>   make[4]: Entering directory `/tmp/nix-build-n7bzdxkpbh2fsl67r0ypscxpjih7ylkm-gnutls-tarball-0pre38718fe94ae05a81a2acc437dd3bf24af0173143.drv-0/git-export/po'
>>>   File cs.po does not exist. If you are a translator, you can create it through 'msginit'.
>>>   make[4]: *** [cs.po-create] Error 1
>>>   make[4]: Leaving directory `/tmp/nix-build-n7bzdxkpbh2fsl67r0ypscxpjih7ylkm-gnutls-tarball-0pre38718fe94ae05a81a2acc437dd3bf24af0173143.drv-0/git-export/po'
>> Hi Ludo,
>>  Just figured out.
> Seems the problem is still here: <http://hydra.nixos.org/build/1782567>.
>> Shouldn't make autoreconf fix that?
> On Hydra builds start from a fresh checkout and do the full bootstrap
> procedure, which should work.


What do you do for bootstrapping? I just tried on a clean clone and it
compiles fine.

regards,
Nikos



From nmav at gnutls.org  Sun Jan  8 22:19:19 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 08 Jan 2012 22:19:19 +0100
Subject: Building GnuTLS 3.0.9 on MS-Windows
In-Reply-To: <E1Rjqg0-0004FV-JZ@fencepost.gnu.org>
References: <83ty47fx58.fsf@gnu.org> <4F097461.1070007@gnutls.org>
	<E1Rjqg0-0004FV-JZ@fencepost.gnu.org>
Message-ID: <4F0A0857.6030009@gnutls.org>

On 01/08/2012 12:12 PM, Eli Zaretskii wrote:


>>> My analysis of this was that it is impossible to build both static 
>>> and dynamic libraries on Windows in the same build.  If that is true,
>>> then the `configure' script should be modified to not try that by
>>> default; the default should probably build only the dynamic 
>>> libraries. In any case, configuring with ./configure
>>> --build=i686-pc-mingw32 --prefix=/d/usr --disable-shared succeeds and
>>> produces a static library libgnutls.a (but not before bumping into a
>>> couple of more problems, described below).
[...]
>> Thus it looks like a libtool bug. However I'd suggest you use the alternative
>> option of building a shared libgnutls instead so you can replace it in
>> case of important security fixes (e.g. now the one with DTLS).
> Sorry, I'm not following: which "alternative option"?


Hello,
 I meant using --disable-static and --enable-shared instead.

regards,
Nikos



From ludo at gnu.org  Sun Jan  8 22:30:56 2012
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Sun, 08 Jan 2012 22:30:56 +0100
Subject: =?utf-8?B?4oCcbWFrZSBkaXN04oCd?= fails on =?utf-8?B?4oCYbWFz?=
	=?utf-8?B?dGVy4oCZ?=
In-Reply-To: <4F0A0545.3040501@gnutls.org> (Nikos Mavrogiannopoulos's message
	of "Sun, 08 Jan 2012 22:06:13 +0100")
References: <87d3aycmi8.fsf@gnu.org> <4F074C1E.9060403@gnutls.org>
	<8762gmxkly.fsf@gnu.org> <4F0A0545.3040501@gnutls.org>
Message-ID: <87vcolq3u7.fsf@gnu.org>

Hi Nikos,

Nikos Mavrogiannopoulos <nmav at gnutls.org> skribis:

> On 01/08/2012 04:46 PM, Ludovic Court?s wrote:
>
>
>>>> ?make dist? appears to be failing on ?master? (from
>>>> <http://hydra.nixos.org/build/1722988/>):
>>>>   rm -f en at quot.gmo && /nix/store/x9792w5bv44jf9127nbjlsxswziinxrd-gettext-0.18.1.1/bin/msgfmt -c --statistics --verbose -o en at quot.gmo en at quot.po
>>>>   en at quot.po: 292 translated messages.
>>>>   make[4]: Entering directory `/tmp/nix-build-n7bzdxkpbh2fsl67r0ypscxpjih7ylkm-gnutls-tarball-0pre38718fe94ae05a81a2acc437dd3bf24af0173143.drv-0/git-export/po'
>>>>   File cs.po does not exist. If you are a translator, you can create it through 'msginit'.
>>>>   make[4]: *** [cs.po-create] Error 1
>>>>   make[4]: Leaving directory `/tmp/nix-build-n7bzdxkpbh2fsl67r0ypscxpjih7ylkm-gnutls-tarball-0pre38718fe94ae05a81a2acc437dd3bf24af0173143.drv-0/git-export/po'
>>> Hi Ludo,
>>>  Just figured out.
>> Seems the problem is still here: <http://hydra.nixos.org/build/1782567>.
>>> Shouldn't make autoreconf fix that?
>> On Hydra builds start from a fresh checkout and do the full bootstrap
>> procedure, which should work.
>
>
> What do you do for bootstrapping? I just tried on a clean clone and it
> compiles fine.

  autoreconf -vfi && \
  ./configure --disable-static --disable-dependency-tracking \
    --prefix=/tmp/xxx --with-lzo \
    --with-libtasn1-prefix=/nix/store/cam03zw4zic4dai01xyhj9i48brydddg-libtasn1-2.12 \
    --enable-guile --enable-gtk-doc && \
  make && \   # <- fails here
  make dist

Thanks,
Ludo?.



From eliz at gnu.org  Mon Jan  9 04:49:10 2012
From: eliz at gnu.org (Eli Zaretskii)
Date: Mon, 09 Jan 2012 05:49:10 +0200
Subject: Building GnuTLS 3.0.9 on MS-Windows
In-Reply-To: <4F0A0857.6030009@gnutls.org>
References: <83ty47fx58.fsf@gnu.org> <4F097461.1070007@gnutls.org>
	<E1Rjqg0-0004FV-JZ@fencepost.gnu.org> <4F0A0857.6030009@gnutls.org>
Message-ID: <83wr91eds9.fsf@gnu.org>

> Date: Sun, 08 Jan 2012 22:19:19 +0100
> From: Nikos Mavrogiannopoulos <nmav at gnutls.org>
> CC: gnutls-devel at gnu.org
> 
> On 01/08/2012 12:12 PM, Eli Zaretskii wrote:
> 
> 
> >>> My analysis of this was that it is impossible to build both static 
> >>> and dynamic libraries on Windows in the same build.  If that is true,
> >>> then the `configure' script should be modified to not try that by
> >>> default; the default should probably build only the dynamic 
> >>> libraries. In any case, configuring with ./configure
> >>> --build=i686-pc-mingw32 --prefix=/d/usr --disable-shared succeeds and
> >>> produces a static library libgnutls.a (but not before bumping into a
> >>> couple of more problems, described below).
> [...]
> >> Thus it looks like a libtool bug. However I'd suggest you use the alternative
> >> option of building a shared libgnutls instead so you can replace it in
> >> case of important security fixes (e.g. now the one with DTLS).
> > Sorry, I'm not following: which "alternative option"?
> 
> 
> Hello,
>  I meant using --disable-static and --enable-shared instead.

Ah, yes.  That's what I did, eventually.

Thanks.

Btw, other packages do succeed building both versions of the libraries
in the same build, so perhaps this isn't a libtool problem after all.
Maybe the order of building the various libraries should be modified?



From nmav at gnutls.org  Mon Jan  9 11:00:46 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 9 Jan 2012 11:00:46 +0100
Subject: =?UTF-8?B?UmU6IOKAnG1ha2UgZGlzdOKAnSBmYWlscyBvbiDigJhtYXN0ZXLigJk=?=
In-Reply-To: <87vcolq3u7.fsf@gnu.org>
References: <87d3aycmi8.fsf@gnu.org> <4F074C1E.9060403@gnutls.org>
	<8762gmxkly.fsf@gnu.org> <4F0A0545.3040501@gnutls.org>
	<87vcolq3u7.fsf@gnu.org>
Message-ID: <CAJU7zaKg=Yp_kKerbHs3bgpNoN_V9cxJCOSm6Ls9PBysEEdrMQ@mail.gmail.com>

On Sun, Jan 8, 2012 at 10:30 PM, Ludovic Court?s <ludo at gnu.org> wrote:
>> What do you do for bootstrapping? I just tried on a clean clone and it
>> compiles fine.
> ?autoreconf -vfi && \

Please use "make autoreconf"!

It's not the same :)

regards,
Nikos



From nmav at gnutls.org  Mon Jan  9 13:55:13 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 9 Jan 2012 13:55:13 +0100
Subject: Building GnuTLS 3.0.9 on MS-Windows
In-Reply-To: <83wr91eds9.fsf@gnu.org>
References: <83ty47fx58.fsf@gnu.org> <4F097461.1070007@gnutls.org>
	<E1Rjqg0-0004FV-JZ@fencepost.gnu.org> <4F0A0857.6030009@gnutls.org>
	<83wr91eds9.fsf@gnu.org>
Message-ID: <CAJU7zaLk54=7DZhT9Au0+xLAX6LM7gwvbpJBi5orzwfmKo7Rmw@mail.gmail.com>

On Mon, Jan 9, 2012 at 4:49 AM, Eli Zaretskii <eliz at gnu.org> wrote:
>> Hello,
>> ?I meant using --disable-static and --enable-shared instead.
> Ah, yes. ?That's what I did, eventually.
> Thanks.
> Btw, other packages do succeed building both versions of the libraries
> in the same build, so perhaps this isn't a libtool problem after all.
> Maybe the order of building the various libraries should be modified?

I don't know why is that issue you see. I see no similar issue with
the mingw64 [0] environment (for cross-compilation from linux), so
I cannot really debug it.

regards,
Nikos

[0]. http://mingw-w64.sourceforge.net/



From rebus at seznam.cz  Mon Jan  9 22:28:16 2012
From: rebus at seznam.cz (=?us-ascii?Q?Michal=20Ambroz?=)
Date: Mon, 09 Jan 2012 22:28:16 +0100 (CET)
Subject: =?us-ascii?Q?Buffer=20Overflow=20in=20gnutls=5Fpk=2Ec=2F=5Fgnutls=5Fpkcs1=5Frsa=5Fdecrypt?=
Message-ID: <85562.25207.53750-31238-106124278-1326144496@seznam.cz>

Hello,

As a result of bug in openvas-libraries I hit buffer overflow condition in gnutls.

This code in gnutls (gnutls_pk.c:220) will overwrite the stack because the
function trusts that the declared size of the pk_params.params will be bigger
than the size of parameters from the configured pkcs11 key:

209 _gnutls_pkcs1_rsa_decrypt (gnutls_datum_t * plaintext,
210                            const gnutls_datum_t * ciphertext,
211                            bigint_t * params, unsigned params_len,
212                            unsigned btype)
213 {
214   unsigned int k, i;
215   int ret;
216   size_t esize, mod_bits;
217   gnutls_pk_params_st pk_params;
218 
219   for (i = 0; i < params_len; i++)
220     pk_params.params[i] = params[i];
221   pk_params.params_nr = params_len;
222

On the GnuTLS side I would recommed to either:
1) log an error and exit gracefully if calling params_len is greater than the struct size
2) log an error and limit the for cycle with the min(params_len, sizeof(pk_params.params) ) 
to ensure that the buffer will not get overwritten with broken or intentionally crafted data.


Best regards
Michal Ambroz



From rebus at seznam.cz  Mon Jan  9 22:22:34 2012
From: rebus at seznam.cz (=?us-ascii?Q?Michal=20Ambroz?=)
Date: Mon, 09 Jan 2012 22:22:34 +0100 (CET)
Subject: =?us-ascii?Q?make=20check=20finished=20with=20errors?=
Message-ID: <85559.25207.53750-31093-377285841-1326144154@seznam.cz>

Hello,
my make check for version 2.12.16 finished with errors. 
===================================
22 of 45 tests failed
Please report to bug-gnutls at gnu.org
===================================

Attached is a log.

Best regards
Michal Ambroz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make_check.log.gz
Type: application/x-gzip
Size: 11489 bytes
Desc: not available
URL: </pipermail/attachments/20120109/3314e30c/attachment.bin>

From nmav at gnutls.org  Mon Jan  9 23:44:10 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 09 Jan 2012 23:44:10 +0100
Subject: make check finished with errors
In-Reply-To: <85559.25207.53750-31093-377285841-1326144154@seznam.cz>
References: <85559.25207.53750-31093-377285841-1326144154@seznam.cz>
Message-ID: <4F0B6DBA.1090803@gnutls.org>

On 01/09/2012 10:22 PM, Michal Ambroz wrote:

> Hello,
> my make check for version 2.12.16 finished with errors. 
> ===================================
> 22 of 45 tests failed
> Please report to bug-gnutls at gnu.org
> ===================================
> Attached is a log.


Hello,
 There is a particular version of gcc that micompiles libtasn1
and the errors seen look similar to yours. Could you try with
--with-included-libtasn1 flag?

regards,
Nikos



From nmav at gnutls.org  Mon Jan  9 23:50:44 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 09 Jan 2012 23:50:44 +0100
Subject: Buffer Overflow in gnutls_pk.c/_gnutls_pkcs1_rsa_decrypt
In-Reply-To: <85562.25207.53750-31238-106124278-1326144496@seznam.cz>
References: <85562.25207.53750-31238-106124278-1326144496@seznam.cz>
Message-ID: <4F0B6F44.4020006@gnutls.org>

On 01/09/2012 10:28 PM, Michal Ambroz wrote:

> Hello,
> As a result of bug in openvas-libraries I hit buffer overflow
> condition in gnutls. This code in gnutls (gnutls_pk.c:220) will
> overwrite the stack because the function trusts that the declared
> size of the pk_params.params will be bigger than the size of
> parameters from the configured pkcs11 key:


Hello,
 I would be curious on how you reached the buffer overflow. This is an
internal function and its input is controlled by its callers.

> 2) log an error and limit the for cycle with the min(params_len,
> sizeof(pk_params.params) )

> to ensure that the buffer will not get overwritten with broken or
> intentionally crafted data.


Although having a sanity check there is useful, how could intentionally 
crafted data reach that point?

regards,
Nikos



From rebus at seznam.cz  Tue Jan 10 01:44:10 2012
From: rebus at seznam.cz (=?us-ascii?Q?Michal=20Ambroz?=)
Date: Tue, 10 Jan 2012 01:44:10 +0100 (CET)
Subject: =?us-ascii?Q?Re=3A=20Re=3A=20Buffer=20Overflow=20in=20gnutls=5Fpk=2Ec=2F=5Fgnutls=5Fpkcs1=5Frsa=5Fdecrypt?=
In-Reply-To: <4F0B6F44.4020006@gnutls.org>
Message-ID: <85577.25207.53750-8823-2093852056-1326156249@seznam.cz>

Hi Nikos,
more info on https://bugzilla.redhat.com/show_bug.cgi?id=747167

<  I would be curious on how you reached the buffer overflow. This is an
< internal function and its input is controlled by its callers.
Server gets there by calling gnutls_handshake when new client connects.

I was hunting this one for quite some time.
It works like that:
1) The code is/was wrongly used in openvas-libraries - use after free condition.
During the inicialization of the gnutls credentials the code in openvas-library loaded private key from file, 
initialized credentials then freed the memory of pk structure (which is obviously wrong).
2) when new socket connection is initialized the function gnutls_handshake is called
3) this calls the _gnutls_pkcs1_rsa_decrypt


It seems that on other operating systems/versions this race condition is hidden. Between inicialization and
use there is usually not enough time to overwrite the data in the memory of former PK so nobody notices.

In Fedora 16 it nearly always wins the race condition. tls_cred.pkey.key.509.params_size gets usually set with some high value and it smashes whole stack so it is flagrantly visible.

The fact that it doesn't demonstrate in other operating systems/versions doesn't mean it is not there and can't be exploited.

Let's say I am hacker and I am up to exploit such the code. 
I would try to go in this direction:
1) spray the heap with my shell code somehow (maybe there is some memory leak in parent, maybe there is some string formatting issue ....)
2) call the gnutls_handshake ( by opening new connection )
3) _gnutls_pkcs1_rsa_decrypt will copy the data to the stack and overwrite the return pointer to jump to the buffer
4) params buffer would contain shell code to execute, or heap will contain the code to execute

I know it seem's bit contrieved but look ... in this trace it has overwritten the return pointer with address 0, so why not some other address:
gdb --args openvassd -f -p 9391
> set follow-fork-mode child
> run

Program received signal SIGSEGV, Segmentation fault.
0x4caba11c in _gnutls_pkcs1_rsa_decrypt (plaintext=0x0, ciphertext=0xabd79c8,
params=
    0xabd7968, params_len=0, btype=0) at gnutls_pk.c:220
220     pk_params.params[i] = params[i];
(gdb) where
#0  0x4caba11c in _gnutls_pkcs1_rsa_decrypt (plaintext=0x0,
ciphertext=0xabd79c8, 
    params=0xabd7968, params_len=0, btype=0) at gnutls_pk.c:220
#1  0x00000000 in ?? ()

Best regards
Michal Ambroz



< ------------ P?vodn? zpr?va ------------
< Od: Nikos Mavrogiannopoulos <nmav at gnutls.org>
< P?edm?t: Re: Buffer Overflow in gnutls_pk.c/_gnutls_pkcs1_rsa_decrypt
< Datum: 09.1.2012 23:46:47
< ----------------------------------------
< On 01/09/2012 10:28 PM, Michal Ambroz wrote:
< 
< > Hello,
< > As a result of bug in openvas-libraries I hit buffer overflow
< > condition in gnutls. This code in gnutls (gnutls_pk.c:220) will
< > overwrite the stack because the function trusts that the declared
< > size of the pk_params.params will be bigger than the size of
< > parameters from the configured pkcs11 key:
< 
< 
< Hello,
<  I would be curious on how you reached the buffer overflow. This is an
< internal function and its input is controlled by its callers.
< 
< > 2) log an error and limit the for cycle with the min(params_len,
< > sizeof(pk_params.params) )
< 
< > to ensure that the buffer will not get overwritten with broken or
< > intentionally crafted data.
< 
< 
< Although having a sanity check there is useful, how could intentionally 
< crafted data reach that point?
< 
< regards,
< Nikos
< 
< 
< 



From branko at majic.rs  Tue Jan 10 09:45:31 2012
From: branko at majic.rs (=?UTF-8?Q?=D0=91=D1=80=D0=B0=D0=BD=D0=BA=D0=BE_=D0=9C=D0=B0=D1=98?= =?UTF-8?Q?=D0=B8=D1=9B?=)
Date: Tue, 10 Jan 2012 09:45:31 +0100
Subject: FOSDEM 2012, Hardware Security and Cryptography, Call for Papers
Message-ID: <e3a147688a81f24200f5a665a37f95e4@majic.rs>

AKA "Protect your privates!"

FOSDEM 2012 will [1] take place in Brussels, the heart of EU. In 2012,
as almost all EU countries have either ongoing rollouts of national eID
cards or are planning it, many people will find yet another smartcard
in their wallet. Cards that don't contain virtual credit but private
keys and certificates that can be used for many purposes in the online
world. FOSS has an important role in the overall eID infrastructure,
either on the server side inside Apache's mod_ssl, on the client
computer inside Firefox as OpenSC PKCS#11 module or hidden in the
infrastructure, issuing the certificates from an EJBCA server, which is
administered over SSH.

Security in the online world matters and one the most common tools for
it is cryptography and PKI. The chain is as strong as its weakest link
and for PKI, the security of private keys matters. The integrated and
widespread nature of PKI implementation makes it difficult to get it
perfect, but one must not stop trying.

Do you develop software that can do HTTPS queries? Can it use keys and
certificates on a smart card? Does your service use RSA keys for
signing? Can it work with hardware keys? Are you interested in
protecting your private keys like Three Letter Organizations or do you
want to roll your own proper PKI with a smaller than five or six digit
budget? How can we make cryptographic hardware Just Work with any
application that uses crypto? The devroom is the place to share
experiences and learn.

This is a call for talks and presentations that will take place in the
Security devroom at FOSDEM 2012.

Security / hardware crytpo devroom will take place on Saturday,
04.02.2012. The exact room still hasn't been specified by the
organisers. The workshop should take place on Sunday, 05.02.2012, and
should include demonstration and hacking sessions. The expected
audience will range from crypto library developers to desktop GUI
creators, from hardware driver makers to business software providers.
Two main themes are cross-application (hardware) interoperability and
user awareness/education, but if you have anything interesting to share
that deals with security or cryptography, don't be bounded by the main
topic. Don't be limited with a traditional "presentation and questions"
format, hands-on workshop format is also welcome.

HOWTO:

1. Subscribe to security-devroom at lists.fosdem.org [2]

2. Send a short talk description, its duration, your bio/affiliation
and contact information to the list and/or add it directly to the
OpenSC wiki [3].

   a) There are 5 up to 1 hour slots (with 10 minutes for Q&A and 5
   minutes for organizational time included, so 45 minutes max for a
   talk)

   b) You don't have to fill the entire slot, 30 minute slots with
   ~20+5+5 minutes format are also OK

   c) FOSDEM is for FOSS developers, keep this in mind when planning
   your talk.

3. The deadline for submissions is 20.01.2012 23:00 UTC

4. The final schedule for the day will be fixed no later than
25.01.2012

5. If there will be more submissions than there are time slots, then:

   a) you may be asked to jam your presentation into a shorter (20
   minutes) format

   b) the final list will be fixed by subscribers of
   security-devroom at lists.fosdem.org list

Please forward this announcement to any relevant FOSS project mailing
lists you're subscribed to.

[1]  https://fosdem.org/2012/
[2]  https://lists.fosdem.org/mailman/listinfo/security-devroom
[3]  https://www.opensc-project.org/opensc/wiki/FOSDEM2012

-- 

Branko Majic
Jabber: branko at majic.rs
Please use only Free formats when sending attachments to me.

?????? ?????
?????: branko at majic.rs
????? ??? ?? ??????? ?????? ????????? ? ????????? ?????????.



From nmav at gnutls.org  Tue Jan 10 10:49:22 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 10 Jan 2012 10:49:22 +0100
Subject: Buffer Overflow in gnutls_pk.c/_gnutls_pkcs1_rsa_decrypt
In-Reply-To: <85577.25207.53750-8823-2093852056-1326156249@seznam.cz>
References: <4F0B6F44.4020006@gnutls.org>
	<85577.25207.53750-8823-2093852056-1326156249@seznam.cz>
Message-ID: <CAJU7zaLckyTJMgKNJYOvsc4=QCvTp7wCDhARC7BpWY7N+DJ0XQ@mail.gmail.com>

2012/1/10 Michal Ambroz <rebus at seznam.cz>:
> Hi Nikos,
> more info on https://bugzilla.redhat.com/show_bug.cgi?id=747167
> < ?I would be curious on how you reached the buffer overflow. This is an
> < internal function and its input is controlled by its callers.
> Server gets there by calling gnutls_handshake when new client connects.
> I was hunting this one for quite some time.
> It works like that:
> 1) The code is/was wrongly used in openvas-libraries - use after free condition.
> During the inicialization of the gnutls credentials the code in openvas-library loaded private key from file,
> initialized credentials then freed the memory of pk structure (which is obviously wrong).
> 2) when new socket connection is initialized the function gnutls_handshake is called
> 3) this calls the _gnutls_pkcs1_rsa_decrypt
> It seems that on other operating systems/versions this race condition is hidden. Between inicialization and
> use there is usually not enough time to overwrite the data in the memory of former PK so nobody notices.
> In Fedora 16 it nearly always wins the race condition. tls_cred.pkey.key.509.params_size gets usually set with some high value and it smashes whole stack so it is flagrantly visible.
> The fact that it doesn't demonstrate in other operating systems/versions doesn't mean it is not there and can't be exploited.

Of course such issues are important, but except for sanity checks
gnutls can't really help if the memory of a program is corrupt. Sanity
checks might warn you or prevent a crash, but a malicious memory
modification would be able to overcome them. Think as an extreme
example a function that accepts a function pointer as a parameter. No
sanity checks would prevent a pointer to point to malicious code in
the heap.

For the specific issue, I've added a check in gnutls 2.12.x branch for
the size of the parameters.

regards,
Nikos



From yarosla at gmail.com  Tue Jan 10 11:44:30 2012
From: yarosla at gmail.com (Yaroslav)
Date: Tue, 10 Jan 2012 14:44:30 +0400
Subject: GNUTLS handshake errors and memory leaks (ECDHE related?)
Message-ID: <CACNYQ9HA9CWXLB--+rAxMpY8Pf5WZpRZA5BrGZoACEFkX8F2SA@mail.gmail.com>

Hi!

I have added SSL support to my web server (nxweb) using GNUTLS. The server
has asynchronous architecture (based on epoll), where 4 threads run almost
independently accepting and servicing client http connections. Therefore I
am using GNUTLS in non-blocking mode.

Platform: Ubuntu 11.10, x64, 4-core CPU.
Linked with latest GNUTLS 3.0.11.

Most of the time everything works fine. Benchmarks show significant speed
advantage over nginx (which is build on OpenSSL). But sometimes there are
handshake errors and also memory leaks, which might be bound to those
errors.

I am attaching full valgrind log. Here are some excerpts:

% valgrind --leak-check=full --show-reachable=yes
dist/Debug/GNU-Linux-x86/nxweb
...
2012-01-10 13:46:51 [28704:0x71b9700]: gnutls handshake error -24 fatal=1
2012-01-10 13:47:25 [28704:0x71b9700]: gnutls handshake error -110 fatal=1
2012-01-10 13:47:25 [28704:0x71b9700]: gnutls handshake error -10 fatal=1
...
==28704== 47,952 bytes in 999 blocks are definitely lost in loss record 11
of 11
==28704==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
==28704==    by 0x5F28908: __gmp_default_allocate (in
/usr/lib/libgmp.so.10.0.1)
==28704==    by 0x5F3CF39: __gmpz_mul (in /usr/lib/libgmp.so.10.0.1)
==28704==    by 0x50ED444: ecc_projective_check_point
(ecc_projective_check_point.c:60)
==28704==    by 0x50E692A: _wrap_nettle_pk_derive (pk.c:144)
==28704==    by 0x50CD4A2: calc_ecdh_key (ecdh_common.c:64)
==28704==    by 0x50CD569: _gnutls_proc_ecdh_common_client_kx
(ecdh_common.c:124)
==28704==    by 0x50615E6: _gnutls_recv_client_kx_message (gnutls_kx.c:549)
==28704==    by 0x505ED25: _gnutls_handshake_server
(gnutls_handshake.c:2801)
==28704==    by 0x505F622: gnutls_handshake (gnutls_handshake.c:2368)
==28704==    by 0x4088FD: do_handshake (nxd_ssl_socket.c:158)
==28704==    by 0x408A62: handshake_stub_is_do_write (nxd_ssl_socket.c:188)

There are also other leaks related to gnutls_dh_params_generate2 and some
error messages related to gnutls_certificate_set_x509_key_file but those
are of less importance to me as they happen only once on server startup.

The log has been collected while running apache-bench (ab) on the
client-side. Here is the log:

% ab -c 100 -n 1000 'https://test.domain.ru:8056/benchmark'
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking test.domain.ru (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
SSL handshake failed (5).
SSL handshake failed (5).
SSL handshake failed (5).
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        nxweb/3.0.0-dev
Server Hostname:        test.domain.ru
Server Port:            8056
SSL/TLS Protocol:       TLSv1/SSLv3,ECDHE-RSA-AES256-SHA,2048,256

Document Path:          /benchmark
Document Length:        20 bytes

Concurrency Level:      100
Time taken for tests:   159.929 seconds
Complete requests:      1000
Failed requests:        3
   (Connect: 0, Receive: 0, Length: 3, Exceptions: 0)
Write errors:           0
Total transferred:      164505 bytes
HTML transferred:       19940 bytes
Requests per second:    6.25 [#/sec] (mean)
Time per request:       15992.885 [ms] (mean)
Time per request:       159.929 [ms] (mean, across all concurrent requests)
Transfer rate:          1.00 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0 13464 1915.7  13581   16479
Processing:   115 2526 1904.2   2416   15897
Waiting:      115 2487 1758.1   2411   15785
Total:      15870 15989 212.0  15912   16645


The problems might be related to ECDHE algorithm. There were no handshake
errors when 'PERFORMANCE:%SERVER_PRECEDENCE' priority string was used.
There were no handshake errors when using GNUTLS 2.10.5 (from Ubuntu repo)
-- I switched to 3.0 version as it supports significantly faster ECDHE
algorithm, to be on par with nginx/openssl.

And there seemed to be no such leaks when there were no handshake erros.

And, yes, I do call gnutls_deinit(session) when closing every connection
regardless of errors on it. I am ready to provide full source code (I plan
to publish it soon as it is open source).

Regards,

Yaroslav Stavnichiy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120110/4bd9b598/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: valgrind_log_120110-2.log
Type: text/x-log
Size: 31668 bytes
Desc: not available
URL: </pipermail/attachments/20120110/4bd9b598/attachment.bin>

From yarosla at gmail.com  Tue Jan 10 13:56:53 2012
From: yarosla at gmail.com (Yaroslav)
Date: Tue, 10 Jan 2012 16:56:53 +0400
Subject: GNUTLS handshake errors and memory leaks (ECDHE related?)
In-Reply-To: <CACNYQ9HA9CWXLB--+rAxMpY8Pf5WZpRZA5BrGZoACEFkX8F2SA@mail.gmail.com>
References: <CACNYQ9HA9CWXLB--+rAxMpY8Pf5WZpRZA5BrGZoACEFkX8F2SA@mail.gmail.com>
Message-ID: <CACNYQ9EC26tyJtsFmec+5iyjkptkdd0DdTLAMvO-yYLUQjFk6Q@mail.gmail.com>

I've run valgrind against gnutls-serv and collected very similar results.
See logs (ab & gnutls-serv) attached.

==29724== 18,720 bytes in 390 blocks are definitely lost in loss record 67
of 70
==29724==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
==29724==    by 0x5B03908: __gmp_default_allocate (in
/usr/lib/libgmp.so.10.0.1)
==29724==    by 0x5B17F39: __gmpz_mul (in /usr/lib/libgmp.so.10.0.1)
==29724==    by 0x4EE5444: ecc_projective_check_point
(ecc_projective_check_point.c:60)
==29724==    by 0x4EDE92A: _wrap_nettle_pk_derive (pk.c:144)
==29724==    by 0x4EC54A2: calc_ecdh_key (ecdh_common.c:64)
==29724==    by 0x4EC5569: _gnutls_proc_ecdh_common_client_kx
(ecdh_common.c:124)
==29724==    by 0x4E595E6: _gnutls_recv_client_kx_message (gnutls_kx.c:549)
==29724==    by 0x4E56D25: _gnutls_handshake_server
(gnutls_handshake.c:2801)
==29724==    by 0x4E57622: gnutls_handshake (gnutls_handshake.c:2368)
==29724==    by 0x405A99: main (serv.c:1270)


On Tue, Jan 10, 2012 at 2:44 PM, Yaroslav <yarosla at gmail.com> wrote:

> Hi!
>
> I have added SSL support to my web server (nxweb) using GNUTLS. The server
> has asynchronous architecture (based on epoll), where 4 threads run almost
> independently accepting and servicing client http connections. Therefore I
> am using GNUTLS in non-blocking mode.
>
> Platform: Ubuntu 11.10, x64, 4-core CPU.
> Linked with latest GNUTLS 3.0.11.
>
> Most of the time everything works fine. Benchmarks show significant speed
> advantage over nginx (which is build on OpenSSL). But sometimes there are
> handshake errors and also memory leaks, which might be bound to those
> errors.
>
> I am attaching full valgrind log. Here are some excerpts:
>
> % valgrind --leak-check=full --show-reachable=yes
> dist/Debug/GNU-Linux-x86/nxweb
> ...
> 2012-01-10 13:46:51 [28704:0x71b9700]: gnutls handshake error -24 fatal=1
> 2012-01-10 13:47:25 [28704:0x71b9700]: gnutls handshake error -110 fatal=1
> 2012-01-10 13:47:25 [28704:0x71b9700]: gnutls handshake error -10 fatal=1
> ...
> ==28704== 47,952 bytes in 999 blocks are definitely lost in loss record 11
> of 11
> ==28704==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
> ==28704==    by 0x5F28908: __gmp_default_allocate (in
> /usr/lib/libgmp.so.10.0.1)
> ==28704==    by 0x5F3CF39: __gmpz_mul (in /usr/lib/libgmp.so.10.0.1)
> ==28704==    by 0x50ED444: ecc_projective_check_point
> (ecc_projective_check_point.c:60)
> ==28704==    by 0x50E692A: _wrap_nettle_pk_derive (pk.c:144)
> ==28704==    by 0x50CD4A2: calc_ecdh_key (ecdh_common.c:64)
> ==28704==    by 0x50CD569: _gnutls_proc_ecdh_common_client_kx
> (ecdh_common.c:124)
> ==28704==    by 0x50615E6: _gnutls_recv_client_kx_message (gnutls_kx.c:549)
> ==28704==    by 0x505ED25: _gnutls_handshake_server
> (gnutls_handshake.c:2801)
> ==28704==    by 0x505F622: gnutls_handshake (gnutls_handshake.c:2368)
> ==28704==    by 0x4088FD: do_handshake (nxd_ssl_socket.c:158)
> ==28704==    by 0x408A62: handshake_stub_is_do_write (nxd_ssl_socket.c:188)
>
> There are also other leaks related to gnutls_dh_params_generate2 and some
> error messages related to gnutls_certificate_set_x509_key_file but those
> are of less importance to me as they happen only once on server startup.
>
> The log has been collected while running apache-bench (ab) on the
> client-side. Here is the log:
>
> % ab -c 100 -n 1000 'https://test.domain.ru:8056/benchmark'
> This is ApacheBench, Version 2.3 <$Revision: 655654 $>
> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
> Licensed to The Apache Software Foundation, http://www.apache.org/
>
> Benchmarking test.domain.ru (be patient)
> Completed 100 requests
> Completed 200 requests
> Completed 300 requests
> Completed 400 requests
> Completed 500 requests
> Completed 600 requests
> Completed 700 requests
> SSL handshake failed (5).
> SSL handshake failed (5).
> SSL handshake failed (5).
> Completed 800 requests
> Completed 900 requests
> Completed 1000 requests
> Finished 1000 requests
>
>
> Server Software:        nxweb/3.0.0-dev
> Server Hostname:        test.domain.ru
> Server Port:            8056
> SSL/TLS Protocol:       TLSv1/SSLv3,ECDHE-RSA-AES256-SHA,2048,256
>
> Document Path:          /benchmark
> Document Length:        20 bytes
>
> Concurrency Level:      100
> Time taken for tests:   159.929 seconds
> Complete requests:      1000
> Failed requests:        3
>    (Connect: 0, Receive: 0, Length: 3, Exceptions: 0)
> Write errors:           0
> Total transferred:      164505 bytes
> HTML transferred:       19940 bytes
> Requests per second:    6.25 [#/sec] (mean)
> Time per request:       15992.885 [ms] (mean)
> Time per request:       159.929 [ms] (mean, across all concurrent requests)
> Transfer rate:          1.00 [Kbytes/sec] received
>
> Connection Times (ms)
>               min  mean[+/-sd] median   max
> Connect:        0 13464 1915.7  13581   16479
> Processing:   115 2526 1904.2   2416   15897
> Waiting:      115 2487 1758.1   2411   15785
> Total:      15870 15989 212.0  15912   16645
>
>
> The problems might be related to ECDHE algorithm. There were no handshake
> errors when 'PERFORMANCE:%SERVER_PRECEDENCE' priority string was used.
> There were no handshake errors when using GNUTLS 2.10.5 (from Ubuntu repo)
> -- I switched to 3.0 version as it supports significantly faster ECDHE
> algorithm, to be on par with nginx/openssl.
>
> And there seemed to be no such leaks when there were no handshake erros.
>
> And, yes, I do call gnutls_deinit(session) when closing every connection
> regardless of errors on it. I am ready to provide full source code (I plan
> to publish it soon as it is open source).
>
> Regards,
>
> Yaroslav Stavnichiy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120110/2d987415/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: valgrind_log_120110-3-gnutls-serv.log
Type: text/x-log
Size: 43558 bytes
Desc: not available
URL: </pipermail/attachments/20120110/2d987415/attachment.bin>

From yarosla at gmail.com  Tue Jan 10 14:13:57 2012
From: yarosla at gmail.com (Yaroslav)
Date: Tue, 10 Jan 2012 17:13:57 +0400
Subject: GNUTLS handshake errors and memory leaks (ECDHE related?)
In-Reply-To: <CACNYQ9EC26tyJtsFmec+5iyjkptkdd0DdTLAMvO-yYLUQjFk6Q@mail.gmail.com>
References: <CACNYQ9HA9CWXLB--+rAxMpY8Pf5WZpRZA5BrGZoACEFkX8F2SA@mail.gmail.com>
	<CACNYQ9EC26tyJtsFmec+5iyjkptkdd0DdTLAMvO-yYLUQjFk6Q@mail.gmail.com>
Message-ID: <CACNYQ9H4UgmiPYMKhjHDN3+bqv0KeJ=-LZ4D0-PvmGPxPYih=A@mail.gmail.com>

Yet another log attached. This time gnutls-serv with --priority
'NORMAL:-ECDHE-RSA'.

SSL/TLS Protocol: TLSv1/SSLv3,DHE-RSA-AES256-SHA,2048,256

Still some handshake errors but no related memory leaks. Some minor leaks
still present.

On Tue, Jan 10, 2012 at 4:56 PM, Yaroslav <yarosla at gmail.com> wrote:

> I've run valgrind against gnutls-serv and collected very similar results.
> See logs (ab & gnutls-serv) attached.
>
> ==29724== 18,720 bytes in 390 blocks are definitely lost in loss record 67
> of 70
> ==29724==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
> ==29724==    by 0x5B03908: __gmp_default_allocate (in
> /usr/lib/libgmp.so.10.0.1)
> ==29724==    by 0x5B17F39: __gmpz_mul (in /usr/lib/libgmp.so.10.0.1)
> ==29724==    by 0x4EE5444: ecc_projective_check_point
> (ecc_projective_check_point.c:60)
> ==29724==    by 0x4EDE92A: _wrap_nettle_pk_derive (pk.c:144)
> ==29724==    by 0x4EC54A2: calc_ecdh_key (ecdh_common.c:64)
> ==29724==    by 0x4EC5569: _gnutls_proc_ecdh_common_client_kx
> (ecdh_common.c:124)
> ==29724==    by 0x4E595E6: _gnutls_recv_client_kx_message (gnutls_kx.c:549)
> ==29724==    by 0x4E56D25: _gnutls_handshake_server
> (gnutls_handshake.c:2801)
> ==29724==    by 0x4E57622: gnutls_handshake (gnutls_handshake.c:2368)
> ==29724==    by 0x405A99: main (serv.c:1270)
>
>
> On Tue, Jan 10, 2012 at 2:44 PM, Yaroslav <yarosla at gmail.com> wrote:
>
>> Hi!
>>
>> I have added SSL support to my web server (nxweb) using GNUTLS. The
>> server has asynchronous architecture (based on epoll), where 4 threads run
>> almost independently accepting and servicing client http connections.
>> Therefore I am using GNUTLS in non-blocking mode.
>>
>> Platform: Ubuntu 11.10, x64, 4-core CPU.
>> Linked with latest GNUTLS 3.0.11.
>>
>> Most of the time everything works fine. Benchmarks show significant speed
>> advantage over nginx (which is build on OpenSSL). But sometimes there are
>> handshake errors and also memory leaks, which might be bound to those
>> errors.
>>
>> I am attaching full valgrind log. Here are some excerpts:
>>
>> % valgrind --leak-check=full --show-reachable=yes
>> dist/Debug/GNU-Linux-x86/nxweb
>> ...
>> 2012-01-10 13:46:51 [28704:0x71b9700]: gnutls handshake error -24 fatal=1
>> 2012-01-10 13:47:25 [28704:0x71b9700]: gnutls handshake error -110 fatal=1
>> 2012-01-10 13:47:25 [28704:0x71b9700]: gnutls handshake error -10 fatal=1
>> ...
>> ==28704== 47,952 bytes in 999 blocks are definitely lost in loss record
>> 11 of 11
>> ==28704==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
>> ==28704==    by 0x5F28908: __gmp_default_allocate (in
>> /usr/lib/libgmp.so.10.0.1)
>> ==28704==    by 0x5F3CF39: __gmpz_mul (in /usr/lib/libgmp.so.10.0.1)
>> ==28704==    by 0x50ED444: ecc_projective_check_point
>> (ecc_projective_check_point.c:60)
>> ==28704==    by 0x50E692A: _wrap_nettle_pk_derive (pk.c:144)
>> ==28704==    by 0x50CD4A2: calc_ecdh_key (ecdh_common.c:64)
>> ==28704==    by 0x50CD569: _gnutls_proc_ecdh_common_client_kx
>> (ecdh_common.c:124)
>> ==28704==    by 0x50615E6: _gnutls_recv_client_kx_message
>> (gnutls_kx.c:549)
>> ==28704==    by 0x505ED25: _gnutls_handshake_server
>> (gnutls_handshake.c:2801)
>> ==28704==    by 0x505F622: gnutls_handshake (gnutls_handshake.c:2368)
>> ==28704==    by 0x4088FD: do_handshake (nxd_ssl_socket.c:158)
>> ==28704==    by 0x408A62: handshake_stub_is_do_write
>> (nxd_ssl_socket.c:188)
>>
>> There are also other leaks related to gnutls_dh_params_generate2 and some
>> error messages related to gnutls_certificate_set_x509_key_file but those
>> are of less importance to me as they happen only once on server startup.
>>
>> The log has been collected while running apache-bench (ab) on the
>> client-side. Here is the log:
>>
>> % ab -c 100 -n 1000 'https://test.domain.ru:8056/benchmark'
>> This is ApacheBench, Version 2.3 <$Revision: 655654 $>
>> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
>> Licensed to The Apache Software Foundation, http://www.apache.org/
>>
>> Benchmarking test.domain.ru (be patient)
>> Completed 100 requests
>> Completed 200 requests
>> Completed 300 requests
>> Completed 400 requests
>> Completed 500 requests
>> Completed 600 requests
>> Completed 700 requests
>> SSL handshake failed (5).
>> SSL handshake failed (5).
>> SSL handshake failed (5).
>> Completed 800 requests
>> Completed 900 requests
>> Completed 1000 requests
>> Finished 1000 requests
>>
>>
>> Server Software:        nxweb/3.0.0-dev
>> Server Hostname:        test.domain.ru
>> Server Port:            8056
>> SSL/TLS Protocol:       TLSv1/SSLv3,ECDHE-RSA-AES256-SHA,2048,256
>>
>> Document Path:          /benchmark
>> Document Length:        20 bytes
>>
>> Concurrency Level:      100
>> Time taken for tests:   159.929 seconds
>> Complete requests:      1000
>> Failed requests:        3
>>    (Connect: 0, Receive: 0, Length: 3, Exceptions: 0)
>> Write errors:           0
>> Total transferred:      164505 bytes
>> HTML transferred:       19940 bytes
>> Requests per second:    6.25 [#/sec] (mean)
>> Time per request:       15992.885 [ms] (mean)
>> Time per request:       159.929 [ms] (mean, across all concurrent
>> requests)
>> Transfer rate:          1.00 [Kbytes/sec] received
>>
>> Connection Times (ms)
>>               min  mean[+/-sd] median   max
>> Connect:        0 13464 1915.7  13581   16479
>> Processing:   115 2526 1904.2   2416   15897
>> Waiting:      115 2487 1758.1   2411   15785
>> Total:      15870 15989 212.0  15912   16645
>>
>>
>> The problems might be related to ECDHE algorithm. There were no handshake
>> errors when 'PERFORMANCE:%SERVER_PRECEDENCE' priority string was used.
>> There were no handshake errors when using GNUTLS 2.10.5 (from Ubuntu repo)
>> -- I switched to 3.0 version as it supports significantly faster ECDHE
>> algorithm, to be on par with nginx/openssl.
>>
>> And there seemed to be no such leaks when there were no handshake erros.
>>
>> And, yes, I do call gnutls_deinit(session) when closing every connection
>> regardless of errors on it. I am ready to provide full source code (I plan
>> to publish it soon as it is open source).
>>
>> Regards,
>>
>> Yaroslav Stavnichiy
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120110/6f934abc/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: valgrind_log_120110-gnutls-serv-2.log
Type: text/x-log
Size: 57609 bytes
Desc: not available
URL: </pipermail/attachments/20120110/6f934abc/attachment.bin>

From nmav at gnutls.org  Tue Jan 10 14:35:55 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 10 Jan 2012 14:35:55 +0100
Subject: GNUTLS handshake errors and memory leaks (ECDHE related?)
In-Reply-To: <CACNYQ9HA9CWXLB--+rAxMpY8Pf5WZpRZA5BrGZoACEFkX8F2SA@mail.gmail.com>
References: <CACNYQ9HA9CWXLB--+rAxMpY8Pf5WZpRZA5BrGZoACEFkX8F2SA@mail.gmail.com>
Message-ID: <CAJU7zaKo6vYOsq-Gc0=v=5K3ptBu=VbkYJ6ewf1E71NhcM_q9w@mail.gmail.com>

On Tue, Jan 10, 2012 at 11:44 AM, Yaroslav <yarosla at gmail.com> wrote:
> Hi!
> I have added SSL support to my web server (nxweb) using GNUTLS. The server
> has asynchronous architecture (based on epoll), where 4 threads run almost
> independently accepting and servicing client http connections. Therefore I
> am using GNUTLS in non-blocking mode.
> Platform: Ubuntu 11.10, x64, 4-core CPU.
> Linked with latest GNUTLS 3.0.11.
> Most of the time everything works fine. Benchmarks show significant speed
> advantage over nginx (which is build on OpenSSL). But sometimes there are
> handshake errors and also memory leaks, which might be bound to those
> errors.

Hello Yaroslav,
 Reply inline.

> I am attaching full valgrind log. Here are some excerpts:
> % valgrind --leak-check=full --show-reachable=yes
> dist/Debug/GNU-Linux-x86/nxweb
> ...
> 2012-01-10 13:47:25 [28704:0x71b9700]: gnutls handshake error -110 fatal=1

This error is GNUTLS_E_PREMATURE_TERMINATION and is returned if the
client does not properly terminate the session (using a closure alert
message) and instead terminates the tcp connection. GnuTLS reports it
as an error, but you could ignore it, if premature termination attacks
are not an issue.

> 2012-01-10 13:47:25 [28704:0x71b9700]: gnutls handshake error -10 fatal=1
This is GNUTLS_E_INVALID_SESSION. It might be returned when trying to
send or received from a session that is already terminated or
invalidated for a reason (if you could set a log level of 2 and set
the log function I could provide more details on the reason). It might
also be a good idea to use gnutls_strerror() to convert the numeric
errors to strings.

> 2012-01-10 13:46:51 [28704:0x71b9700]: gnutls handshake error -24 fatal=1

This is GNUTLS_E_DECRYPTION_FAILED. This is pretty strange to happen.
Could you provide more information with a log level of 2?

> ==28704== 47,952 bytes in 999 blocks are definitely lost in loss record 11
> of 11
> ==28704== ? ?at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
> ==28704== ? ?by 0x5F28908: __gmp_default_allocate (in
> /usr/lib/libgmp.so.10.0.1)
> ==28704== ? ?by 0x5F3CF39: __gmpz_mul (in /usr/lib/libgmp.so.10.0.1)
> ==28704== ? ?by 0x50ED444: ecc_projective_check_point
> (ecc_projective_check_point.c:60)

It seems there is an issue in ecc_project_check_point. Could you try
the attached patch?

> There are also other leaks related to?gnutls_dh_params_generate2 and some

Those should have been fixed in the repository.

> error messages related to gnutls_certificate_set_x509_key_file?but those are
> of less importance to me as they happen only once on server startup.

I'll check about gnutls_certificate_set_x509_key_file() later.

> The problems might be related to ECDHE algorithm. There were no handshake
> errors when 'PERFORMANCE:%SERVER_PRECEDENCE' priority string was used.

With which string did you see the errors? Do you know which
ciphersuite was negotiated? (gnutls_cipher_suite_get_name)

> And there seemed to be no such leaks when there were no handshake erros.

btw. from the logs I see that the version of libtasn1 you have doesn't
compile well with
the gcc you have. You can use the included libtasn1 to avoid the
valgrind warnings.

I would be interested on your results in performance. Do you use a CPU
with AES-NI or padlock for the tests?

regards,
Nikos
-------------- next part --------------
diff --git a/lib/nettle/ecc_projective_check_point.c b/lib/nettle/ecc_projective_check_point.c
index 42abeea..5649779 100644
--- a/lib/nettle/ecc_projective_check_point.c
+++ b/lib/nettle/ecc_projective_check_point.c
@@ -42,17 +42,17 @@ int ecc_projective_check_point (ecc_point * P, mpz_t b, mpz_t modulus)
     if (P == NULL || b == NULL || modulus == NULL)
 	return -1;
 
-    if ((err = mp_init_multi (&t1, &t2, &t3, NULL)) != 0)
-      {
-	  return err;
-      }
-
     if (mpz_cmp_ui (P->z, 1) != 0)
       {
 	  gnutls_assert ();
 	  return -1;
       }
 
+    if ((err = mp_init_multi (&t1, &t2, &t3, NULL)) != 0)
+      {
+	  return err;
+      }
+
     /* t1 = Z * Z */
     mpz_mul (t1, P->y, P->y);
     mpz_mod (t1, t1, modulus);	/* t1 = y^2 */
@@ -95,12 +95,16 @@ int ecc_projective_check_point (ecc_point * P, mpz_t b, mpz_t modulus)
 
     if (mpz_cmp_ui (t1, 0) != 0)
       {
-	  return -1;
+	  err = -1;
       }
     else
       {
-	  return 0;
+	  err = 0;
       }
+
+    mp_clear_multi(&t1, &t2, &t3, NULL);
+    
+    return err;
 }
 
 #endif

From yarosla at gmail.com  Tue Jan 10 15:03:01 2012
From: yarosla at gmail.com (Yaroslav)
Date: Tue, 10 Jan 2012 18:03:01 +0400
Subject: GNUTLS handshake errors and memory leaks (ECDHE related?)
In-Reply-To: <CAJU7zaKo6vYOsq-Gc0=v=5K3ptBu=VbkYJ6ewf1E71NhcM_q9w@mail.gmail.com>
References: <CACNYQ9HA9CWXLB--+rAxMpY8Pf5WZpRZA5BrGZoACEFkX8F2SA@mail.gmail.com>
	<CAJU7zaKo6vYOsq-Gc0=v=5K3ptBu=VbkYJ6ewf1E71NhcM_q9w@mail.gmail.com>
Message-ID: <CACNYQ9H4uN+GT61RV9LJ7QOok+EO6pXBZV-usUGRjYk0DmkAsg@mail.gmail.com>

On Tue, Jan 10, 2012 at 5:35 PM, Nikos Mavrogiannopoulos <nmav at gnutls.org>wrote:

> On Tue, Jan 10, 2012 at 11:44 AM, Yaroslav <yarosla at gmail.com> wrote:
> > Hi!
> > I have added SSL support to my web server (nxweb) using GNUTLS. The
> server
> > has asynchronous architecture (based on epoll), where 4 threads run
> almost
> > independently accepting and servicing client http connections. Therefore
> I
> > am using GNUTLS in non-blocking mode.
> > Platform: Ubuntu 11.10, x64, 4-core CPU.
> > Linked with latest GNUTLS 3.0.11.
> > Most of the time everything works fine. Benchmarks show significant speed
> > advantage over nginx (which is build on OpenSSL). But sometimes there are
> > handshake errors and also memory leaks, which might be bound to those
> > errors.
>
> Hello Yaroslav,
>  Reply inline.
>
> > I am attaching full valgrind log. Here are some excerpts:
> > % valgrind --leak-check=full --show-reachable=yes
> > dist/Debug/GNU-Linux-x86/nxweb
> > ...
> > 2012-01-10 13:47:25 [28704:0x71b9700]: gnutls handshake error -110
> fatal=1
>
> This error is GNUTLS_E_PREMATURE_TERMINATION and is returned if the
> client does not properly terminate the session (using a closure alert
> message) and instead terminates the tcp connection. GnuTLS reports it
> as an error, but you could ignore it, if premature termination attacks
> are not an issue.
>
> > 2012-01-10 13:47:25 [28704:0x71b9700]: gnutls handshake error -10 fatal=1
> This is GNUTLS_E_INVALID_SESSION. It might be returned when trying to
> send or received from a session that is already terminated or
> invalidated for a reason (if you could set a log level of 2 and set
> the log function I could provide more details on the reason). It might
> also be a good idea to use gnutls_strerror() to convert the numeric
> errors to strings.
>
> > 2012-01-10 13:46:51 [28704:0x71b9700]: gnutls handshake error -24 fatal=1
>
> This is GNUTLS_E_DECRYPTION_FAILED. This is pretty strange to happen.
> Could you provide more information with a log level of 2?
>
> > ==28704== 47,952 bytes in 999 blocks are definitely lost in loss record
> 11
> > of 11
> > ==28704==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
> > ==28704==    by 0x5F28908: __gmp_default_allocate (in
> > /usr/lib/libgmp.so.10.0.1)
> > ==28704==    by 0x5F3CF39: __gmpz_mul (in /usr/lib/libgmp.so.10.0.1)
> > ==28704==    by 0x50ED444: ecc_projective_check_point
> > (ecc_projective_check_point.c:60)
>
> It seems there is an issue in ecc_project_check_point. Could you try
> the attached patch?
>
> > There are also other leaks related to gnutls_dh_params_generate2 and some
>
> Those should have been fixed in the repository.
>
> > error messages related to gnutls_certificate_set_x509_key_file but those
> are
> > of less importance to me as they happen only once on server startup.
>
> I'll check about gnutls_certificate_set_x509_key_file() later.
>
> > The problems might be related to ECDHE algorithm. There were no handshake
> > errors when 'PERFORMANCE:%SERVER_PRECEDENCE' priority string was used.
>
> With which string did you see the errors? Do you know which
> ciphersuite was negotiated? (gnutls_cipher_suite_get_name)
>
>
I used priority string: NORMAL:+VERS-TLS-ALL:+COMP-ALL

According to ab log:
SSL/TLS Protocol: TLSv1/SSLv3,ECDHE-RSA-AES256-SHA,2048,256



> > And there seemed to be no such leaks when there were no handshake erros.
>
> btw. from the logs I see that the version of libtasn1 you have doesn't
> compile well with
> the gcc you have. You can use the included libtasn1 to avoid the
> valgrind warnings.
>

libtasn1 is installed in my Ubuntu and there seems to be quite a lot of
software that depends on it. Is there a way to configure gnutls to use
included libtasn1 when I already have libtasn1 on my system?


>
> I would be interested on your results in performance. Do you use a CPU
> with AES-NI or padlock for the tests?
>

Not sure about this. I have Intel Q6700 processor. The spec (
http://ark.intel.com/products/30790/Intel-Core2-Quad-Processor-Q6700-(8M-Cache-2_66-GHz-1066-MHz-FSB))
says: "AES New Instructions: No".

I am going to publish the benchmarks with new version of nxweb. It's not
quite ready yet.

I am going to check and reply about the patch and the log levels in
separate email as soon as I can.

Yaroslav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120110/5ab0253a/attachment.htm>

From nmav at gnutls.org  Tue Jan 10 15:14:58 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 10 Jan 2012 15:14:58 +0100
Subject: GNUTLS handshake errors and memory leaks (ECDHE related?)
In-Reply-To: <CACNYQ9H4uN+GT61RV9LJ7QOok+EO6pXBZV-usUGRjYk0DmkAsg@mail.gmail.com>
References: <CACNYQ9HA9CWXLB--+rAxMpY8Pf5WZpRZA5BrGZoACEFkX8F2SA@mail.gmail.com>
	<CAJU7zaKo6vYOsq-Gc0=v=5K3ptBu=VbkYJ6ewf1E71NhcM_q9w@mail.gmail.com>
	<CACNYQ9H4uN+GT61RV9LJ7QOok+EO6pXBZV-usUGRjYk0DmkAsg@mail.gmail.com>
Message-ID: <CAJU7zaJikh81FcMHqz5hOTtoXdxuNwnN96ruFD5dNHSrmFgXcw@mail.gmail.com>

On Tue, Jan 10, 2012 at 3:03 PM, Yaroslav <yarosla at gmail.com> wrote:

>> btw. from the logs I see that the version of libtasn1 you have doesn't
>> compile well with
>> the gcc you have. You can use the included libtasn1 to avoid the
>> valgrind warnings.
> libtasn1 is installed in my Ubuntu and there seems to be quite a lot of
> software that depends on it. Is there a way to configure gnutls to use
> included libtasn1 when I already have libtasn1 on my system?

Use --with-included-libtasn1 when configuring gnutls. That way it will
ignore the installed version.

> Not sure about this.?I have Intel Q6700?processor. The spec
> (http://ark.intel.com/products/30790/Intel-Core2-Quad-Processor-Q6700-(8M-Cache-2_66-GHz-1066-MHz-FSB))
> says: "AES New Instructions: No".

It doesn't seem to have them. You can always check in realtime with
"cat /proc/cpuinfo". If aes is in your flags.

regards,
Nikos



From yarosla at gmail.com  Tue Jan 10 15:41:20 2012
From: yarosla at gmail.com (Yaroslav)
Date: Tue, 10 Jan 2012 18:41:20 +0400
Subject: GNUTLS handshake errors and memory leaks (ECDHE related?)
In-Reply-To: <CAJU7zaJikh81FcMHqz5hOTtoXdxuNwnN96ruFD5dNHSrmFgXcw@mail.gmail.com>
References: <CACNYQ9HA9CWXLB--+rAxMpY8Pf5WZpRZA5BrGZoACEFkX8F2SA@mail.gmail.com>
	<CAJU7zaKo6vYOsq-Gc0=v=5K3ptBu=VbkYJ6ewf1E71NhcM_q9w@mail.gmail.com>
	<CACNYQ9H4uN+GT61RV9LJ7QOok+EO6pXBZV-usUGRjYk0DmkAsg@mail.gmail.com>
	<CAJU7zaJikh81FcMHqz5hOTtoXdxuNwnN96ruFD5dNHSrmFgXcw@mail.gmail.com>
Message-ID: <CACNYQ9GoLg+Lm0=CrbFDUNt_3pFmfEw4U9OeksF+-9zSunOrrQ@mail.gmail.com>

Great! After applying the patch handshake leaks seem to be gone. Logs
attached.

One more note about errors. gnutls handshake errors -24 appear one by one
and seem to correspond to ab errors. Errors -10 and -110 appear in a bunch
right after ab finishes. It might be specific to how ab works. It could
have opened more connections than it should for example. I will further
investigate with log level 2.

On Tue, Jan 10, 2012 at 6:14 PM, Nikos Mavrogiannopoulos <nmav at gnutls.org>wrote:

> On Tue, Jan 10, 2012 at 3:03 PM, Yaroslav <yarosla at gmail.com> wrote:
>
> >> btw. from the logs I see that the version of libtasn1 you have doesn't
> >> compile well with
> >> the gcc you have. You can use the included libtasn1 to avoid the
> >> valgrind warnings.
> > libtasn1 is installed in my Ubuntu and there seems to be quite a lot of
> > software that depends on it. Is there a way to configure gnutls to use
> > included libtasn1 when I already have libtasn1 on my system?
>
> Use --with-included-libtasn1 when configuring gnutls. That way it will
> ignore the installed version.
>
> > Not sure about this. I have Intel Q6700 processor. The spec
> > (
> http://ark.intel.com/products/30790/Intel-Core2-Quad-Processor-Q6700-(8M-Cache-2_66-GHz-1066-MHz-FSB)
> )
> > says: "AES New Instructions: No".
>
> It doesn't seem to have them. You can always check in realtime with
> "cat /proc/cpuinfo". If aes is in your flags.
>
> regards,
> Nikos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120110/10d5e123/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: valgrind_log_120110-5.log
Type: text/x-log
Size: 27164 bytes
Desc: not available
URL: </pipermail/attachments/20120110/10d5e123/attachment.bin>

From yarosla at gmail.com  Tue Jan 10 23:26:01 2012
From: yarosla at gmail.com (Yaroslav)
Date: Wed, 11 Jan 2012 02:26:01 +0400
Subject: GNUTLS handshake errors and memory leaks (ECDHE related?)
In-Reply-To: <CAJU7zaJikh81FcMHqz5hOTtoXdxuNwnN96ruFD5dNHSrmFgXcw@mail.gmail.com>
References: <CACNYQ9HA9CWXLB--+rAxMpY8Pf5WZpRZA5BrGZoACEFkX8F2SA@mail.gmail.com>
	<CAJU7zaKo6vYOsq-Gc0=v=5K3ptBu=VbkYJ6ewf1E71NhcM_q9w@mail.gmail.com>
	<CACNYQ9H4uN+GT61RV9LJ7QOok+EO6pXBZV-usUGRjYk0DmkAsg@mail.gmail.com>
	<CAJU7zaJikh81FcMHqz5hOTtoXdxuNwnN96ruFD5dNHSrmFgXcw@mail.gmail.com>
Message-ID: <CACNYQ9HAcAew1=picege9QeCysEL9dPpCwekmfkCsGGgoh+qRA@mail.gmail.com>

After rebuilding gnutls with included libtasn1 and applying the patch these
are the only errors/warnings left:

==27777== HEAP SUMMARY:
==27777==     in use at exit: 336 bytes in 4 blocks
==27777==   total heap usage: 3,611,146 allocs, 3,611,142 frees,
488,917,755 bytes allocated
==27777==
==27777== 8 bytes in 1 blocks are definitely lost in loss record 1 of 4
==27777==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
==27777==    by 0x5D22908: __gmp_default_allocate (in
/usr/lib/libgmp.so.10.0.1)
==27777==    by 0x5D33DA7: __gmpz_init (in /usr/lib/libgmp.so.10.0.1)
==27777==    by 0x50F22DF: wrap_nettle_generate_group (mpi.c:424)
==27777==    by 0x5071FA0: gnutls_dh_params_generate2
(gnutls_dh_primes.c:191)
==27777==    by 0x4086C3: nxd_ssl_socket_init_server_parameters
(nxd_ssl_socket.c:102)
==27777==    by 0x4036BF: nxweb_listen (http_server.c:369)
==27777==    by 0x411397: main (main.c:36)
==27777==
==27777== 8 bytes in 1 blocks are definitely lost in loss record 2 of 4
==27777==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
==27777==    by 0x5D22908: __gmp_default_allocate (in
/usr/lib/libgmp.so.10.0.1)
==27777==    by 0x5D33DA7: __gmpz_init (in /usr/lib/libgmp.so.10.0.1)
==27777==    by 0x50F22E8: wrap_nettle_generate_group (mpi.c:425)
==27777==    by 0x5071FA0: gnutls_dh_params_generate2
(gnutls_dh_primes.c:191)
==27777==    by 0x4086C3: nxd_ssl_socket_init_server_parameters
(nxd_ssl_socket.c:102)
==27777==    by 0x4036BF: nxweb_listen (http_server.c:369)
==27777==    by 0x411397: main (main.c:36)
==27777==
==27777== 160 bytes in 1 blocks are definitely lost in loss record 3 of 4
==27777==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
==27777==    by 0x5D22908: __gmp_default_allocate (in
/usr/lib/libgmp.so.10.0.1)
==27777==    by 0x5D33E00: __gmpz_init2 (in /usr/lib/libgmp.so.10.0.1)
==27777==    by 0x50F20C0: wrap_nettle_mpi_new (mpi.c:97)
==27777==    by 0x50F22AB: wrap_nettle_generate_group (mpi.c:587)
==27777==    by 0x5071FA0: gnutls_dh_params_generate2
(gnutls_dh_primes.c:191)
==27777==    by 0x4086C3: nxd_ssl_socket_init_server_parameters
(nxd_ssl_socket.c:102)
==27777==    by 0x4036BF: nxweb_listen (http_server.c:369)
==27777==    by 0x411397: main (main.c:36)
==27777==
==27777== 160 bytes in 1 blocks are definitely lost in loss record 4 of 4
==27777==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
==27777==    by 0x5D22908: __gmp_default_allocate (in
/usr/lib/libgmp.so.10.0.1)
==27777==    by 0x5D33E00: __gmpz_init2 (in /usr/lib/libgmp.so.10.0.1)
==27777==    by 0x50F20C0: wrap_nettle_mpi_new (mpi.c:97)
==27777==    by 0x50F22C0: wrap_nettle_generate_group (mpi.c:597)
==27777==    by 0x5071FA0: gnutls_dh_params_generate2
(gnutls_dh_primes.c:191)
==27777==    by 0x4086C3: nxd_ssl_socket_init_server_parameters
(nxd_ssl_socket.c:102)
==27777==    by 0x4036BF: nxweb_listen (http_server.c:369)
==27777==    by 0x411397: main (main.c:36)
==27777==
==27777== LEAK SUMMARY:
==27777==    definitely lost: 336 bytes in 4 blocks
==27777==    indirectly lost: 0 bytes in 0 blocks
==27777==      possibly lost: 0 bytes in 0 blocks
==27777==    still reachable: 0 bytes in 0 blocks
==27777==         suppressed: 0 bytes in 0 blocks

Not really critical but still not completely clean. All related
to gnutls_dh_params_generate2().

On server startup I do the following (for each SSL listening port):

  gnutls_certificate_allocate_credentials(x509_cred);
  gnutls_certificate_set_x509_key_file(*x509_cred, cert_file, key_file,
GNUTLS_X509_FMT_PEM);
  int bits=gnutls_sec_param_to_pk_bits(GNUTLS_PK_DH, GNUTLS_SEC_PARAM_LOW);
  gnutls_dh_params_init(dh_params);
  gnutls_dh_params_generate2(*dh_params, bits);
  gnutls_priority_init(priority_cache, NXWEB_SSL_PRIORITIES, 0);
  gnutls_certificate_set_dh_params(*x509_cred, *dh_params);
  gnutls_session_ticket_key_generate(session_ticket_key);

And on server shutdown I do the following (for each SSL listening port):

  gnutls_certificate_free_credentials(x509_cred);
  gnutls_dh_params_deinit(dh_params);
  gnutls_priority_deinit(priority_cache);
  gnutls_free(session_ticket_key->data);

Yaroslav

On Tue, Jan 10, 2012 at 6:14 PM, Nikos Mavrogiannopoulos <nmav at gnutls.org>wrote:

> On Tue, Jan 10, 2012 at 3:03 PM, Yaroslav <yarosla at gmail.com> wrote:
>
> >> btw. from the logs I see that the version of libtasn1 you have doesn't
> >> compile well with
> >> the gcc you have. You can use the included libtasn1 to avoid the
> >> valgrind warnings.
> > libtasn1 is installed in my Ubuntu and there seems to be quite a lot of
> > software that depends on it. Is there a way to configure gnutls to use
> > included libtasn1 when I already have libtasn1 on my system?
>
> Use --with-included-libtasn1 when configuring gnutls. That way it will
> ignore the installed version.
>
> > Not sure about this. I have Intel Q6700 processor. The spec
> > (
> http://ark.intel.com/products/30790/Intel-Core2-Quad-Processor-Q6700-(8M-Cache-2_66-GHz-1066-MHz-FSB)
> )
> > says: "AES New Instructions: No".
>
> It doesn't seem to have them. You can always check in realtime with
> "cat /proc/cpuinfo". If aes is in your flags.
>
> regards,
> Nikos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120111/249cd942/attachment.htm>

From INVALID.NOREPLY at gnu.org  Thu Jan 12 18:22:52 2012
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Thu, 12 Jan 2012 17:22:52 +0000
Subject: [sr #107932] Cannot initialise AES-256-PGP-CFB cipher support in
	GnuTLS 3
Message-ID: <20120112-172251.sv0.16476@savannah.gnu.org>

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

                 Summary: Cannot initialise AES-256-PGP-CFB cipher support in
GnuTLS 3
                 Project: GnuTLS
            Submitted by: None
            Submitted on: Thu 12 Jan 2012 05:22:51 PM UTC
                Category: None
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: philip.allison at smoothwall.net
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: GNU/Linux

    _______________________________________________________

Details:

Hullo,

I am having problems trying to initialise a cipher handle for AES-256-PGP-CFB
using GnuTLS 3.0.11 and keep getting an error string of "The request is
invalid" when calling gnutls_cipher_init.  I'm aware that GnuTLS 3 has been
migrated away from gcrypt to nettle, so I went looking in the docs for nettle,
and found no mention of any support for ciphers in CFB mode.  This led me to
dig further into the GnuTLS source to see if the CFB ciphers were actually
implemented.

As far as I can tell, there are two ways in which a cipher can be implemented:
either a specific accelerated implementation is registered using
*_cipher_register during global initialisation, or _gnutls_cipher_init falls
through to the "generic" cipher ops, which eventually falls through to
wrap_nettle_cipher_init in lib/nettle/cipher.c.  The latter function doesn't
have cases to handle any of the *-PGP-CFB ciphers, so if I am correct, these
ciphers are completely unavailable in GnuTLS as I have compiled it.

Is this correct, and how should I go about using these ciphers with GnuTLS 3? 
I am trying to drop my code's explicit dependency on gcrypt, since GnuTLS
itself no longer depends on it.

Note also that AES-256-PGP-CFB does appear in the output of
gnutls_cipher_list, but from looking at the code, that just iterates over the
list of defined ciphers - which does not guarantee an implementation exists
for any particular cipher in the list.




    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Thu Jan 12 19:32:34 2012
From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos)
Date: Thu, 12 Jan 2012 18:32:34 +0000
Subject: [sr #107932] Cannot initialise AES-256-PGP-CFB cipher support in
	GnuTLS 3
In-Reply-To: <20120112-172251.sv0.16476@savannah.gnu.org>
References: <20120112-172251.sv0.16476@savannah.gnu.org>
Message-ID: <20120112-203233.sv707.22651@savannah.gnu.org>

Update of sr #107932 (project gnutls):

                Category:                    None => Core library           
                  Status:                    None => Wont Do                
             Assigned to:                    None => nmav                   

    _______________________________________________________

Follow-up Comment #1:

Hello,
 You are right. This cipher is not supported in GnuTLS 3 and there no plans to
add it anytime soon (because it is not needed for TLS). Those ciphers are
listed to read the cipher on encrypted openpgp packets, and is currently
unused. 

I'll modify gnutls_cipher_list in order not to print those.

Unfortunately I have to tag this as wont fix.



    _______________________________________________________

Reply to this item at:

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

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




From eliz at gnu.org  Thu Jan 12 21:19:24 2012
From: eliz at gnu.org (Eli Zaretskii)
Date: Thu, 12 Jan 2012 22:19:24 +0200
Subject: Building GnuTLS 3.0.9 on MS-Windows
In-Reply-To: <4F097461.1070007@gnutls.org>
References: <83ty47fx58.fsf@gnu.org> <4F097461.1070007@gnutls.org>
Message-ID: <837h0wllmb.fsf@gnu.org>

> Date: Sun, 08 Jan 2012 11:48:01 +0100
> From: Nikos Mavrogiannopoulos <nmav at gnutls.org>
> CC: gnutls-devel at gnu.org
> 
> > Problem #3: The linker fails in src/: CC     udp-serv.o udp-serv.c:
> > In function `udp_server': udp-serv.c:107: warning: implicit
> > declaration of function `usleep' CC     common.o CC     p11common.o 
> > CCLD   gnutls-serv.exe udp-serv.o(.text+0x417): In function
> > `udp_server': d:/usr/eli/utils/gnutls-3.0.9/src/udp-serv.c:107:
> > undefined reference to `usleep'
> 
> 
> I'll add the gnulib usleep module for that. 

On second thought, would it be possible to use the nanosleep module
from gnulib instead?  That one does have a non-trivial implementation
for MS-Windows that supports sub-millisecond sleep periods.



From nmav at gnutls.org  Fri Jan 13 00:24:39 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 13 Jan 2012 00:24:39 +0100
Subject: Building GnuTLS 3.0.9 on MS-Windows
In-Reply-To: <837h0wllmb.fsf@gnu.org>
References: <83ty47fx58.fsf@gnu.org> <4F097461.1070007@gnutls.org>
	<837h0wllmb.fsf@gnu.org>
Message-ID: <4F0F6BB7.3090308@gnutls.org>

On 01/12/2012 09:19 PM, Eli Zaretskii wrote:


>> I'll add the gnulib usleep module for that. 
> On second thought, would it be possible to use the nanosleep module
> from gnulib instead?  That one does have a non-trivial implementation
> for MS-Windows that supports sub-millisecond sleep periods.


That sleep is not really important in udp-serv. I'll remove it
completely. It is quite strange though that gnulib doesn't use
Sleep() in windows to emulate usleep, better than plain sleep
at least.

regards,
Nikos



From eliz at gnu.org  Fri Jan 13 08:35:27 2012
From: eliz at gnu.org (Eli Zaretskii)
Date: Fri, 13 Jan 2012 09:35:27 +0200
Subject: Building GnuTLS 3.0.9 on MS-Windows
In-Reply-To: <4F0F6BB7.3090308@gnutls.org>
References: <83ty47fx58.fsf@gnu.org> <4F097461.1070007@gnutls.org>
	<837h0wllmb.fsf@gnu.org> <4F0F6BB7.3090308@gnutls.org>
Message-ID: <8339bkkqbk.fsf@gnu.org>

> Date: Fri, 13 Jan 2012 00:24:39 +0100
> From: Nikos Mavrogiannopoulos <nmav at gnutls.org>
> CC: gnutls-devel at gnu.org
> 
> On 01/12/2012 09:19 PM, Eli Zaretskii wrote:
> 
> 
> >> I'll add the gnulib usleep module for that. 
> > On second thought, would it be possible to use the nanosleep module
> > from gnulib instead?  That one does have a non-trivial implementation
> > for MS-Windows that supports sub-millisecond sleep periods.
> 
> 
> That sleep is not really important in udp-serv. I'll remove it
> completely.

That will of course solve the whole issue cleanly ;-)
Thanks.

> It is quite strange though that gnulib doesn't use Sleep() in
> windows to emulate usleep, better than plain sleep at least.

True.  However, calling `Sleep' would not solve the problem in this
case, since it has 10-msec granularity, and will not sleep at all if
called with an argument less than that.  udp-serv wanted to sleep for
100 microseconds, so to my eyes of someone who knows absolutely
nothing about the reason for that delay, this looked like `Sleep' will
not solve the problem.



From pipping at lavabit.com  Sun Jan 15 13:10:59 2012
From: pipping at lavabit.com (Elias Pipping)
Date: Sun, 15 Jan 2012 13:10:59 +0100
Subject: [PATCH] tests/ecdsa/ecdsa and out-of-source builds
Message-ID: <87zkdp9ne4.fsf@lavabit.com>

Hi,

I've attached a patch to fix the following problem

  make[3]: Entering directory `<build>/tests/ecdsa'
  <source>/tests/ecdsa/ecdsa: line 85: bad-key.pem: No such file or directory
  certtool didn't detect a bad ECDSA key.
  FAIL: ecdsa

with gnutls 3.0.11 (or the current git HEAD) and <build> != <source>.


Best regards,

Elias Pipping

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnutls-vpath-test.patch
Type: text/x-patch
Size: 568 bytes
Desc: fix
URL: </pipermail/attachments/20120115/f6d5b00f/attachment.bin>

From simon at josefsson.org  Mon Jan 16 20:32:27 2012
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 16 Jan 2012 20:32:27 +0100
Subject: [PATCH] tests/ecdsa/ecdsa and out-of-source builds
In-Reply-To: <87zkdp9ne4.fsf@lavabit.com> (Elias Pipping's message of "Sun, 15
	Jan 2012 13:10:59 +0100")
References: <87zkdp9ne4.fsf@lavabit.com>
Message-ID: <87r4yzl9ys.fsf@latte.josefsson.org>

Elias Pipping <pipping at lavabit.com> writes:

> Hi,
>
> I've attached a patch to fix the following problem
>
>   make[3]: Entering directory `<build>/tests/ecdsa'
>   <source>/tests/ecdsa/ecdsa: line 85: bad-key.pem: No such file or directory
>   certtool didn't detect a bad ECDSA key.
>   FAIL: ecdsa
>
> with gnutls 3.0.11 (or the current git HEAD) and <build> != <source>.

Applied, thank you!

/Simon



From simon at josefsson.org  Mon Jan 16 21:23:34 2012
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 16 Jan 2012 21:23:34 +0100
Subject: make distcheck failure in gnutls-guile 'ERROR: no code for module
	(gnutls)'
Message-ID: <87ipkbl7ll.fsf@latte.josefsson.org>

Hi Ludo,

I'm getting the error below on 'make distcheck'.  Any ideas?  There
haven't been any significant changes in the guile/ sub-directory for
quite a while, so I'm puzzled what triggered this.

Thanks,
Simon

make[4]: Nothing to be done for `check-am'.
make[4]: Leaving directory `/home/jas/src/gnutls-ocsp/gnutls-3.0.11/_build/guile/src'
make[3]: Leaving directory `/home/jas/src/gnutls-ocsp/gnutls-3.0.11/_build/guile/src'
Making check in tests
make[3]: Entering directory `/home/jas/src/gnutls-ocsp/gnutls-3.0.11/_build/guile/tests'
make  check-TESTS
make[4]: Entering directory `/home/jas/src/gnutls-ocsp/gnutls-3.0.11/_build/guile/tests'
ERROR: no code for module (gnutls)
FAIL: anonymous-auth.scm
ERROR: no code for module (gnutls)
FAIL: session-record-port.scm
ERROR: no code for module (gnutls)
FAIL: pkcs-import-export.scm
ERROR: no code for module (gnutls)
FAIL: errors.scm
ERROR: no code for module (gnutls)
FAIL: x509-certificates.scm
ERROR: no code for module (gnutls)
FAIL: x509-auth.scm
ERROR: no code for module (gnutls)
FAIL: priorities.scm
ERROR: no code for module (gnutls)
FAIL: openpgp-keys.scm
ERROR: no code for module (gnutls)
FAIL: openpgp-keyring.scm
ERROR: no code for module (gnutls)
FAIL: openpgp-auth.scm
ERROR: no code for module (gnutls)
FAIL: srp-base64.scm
===================================
11 of 11 tests failed
Please report to bug-gnutls at gnu.org
===================================
make[4]: *** [check-TESTS] Error 1



From ludo at gnu.org  Tue Jan 17 00:10:28 2012
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 17 Jan 2012 00:10:28 +0100
Subject: make distcheck failure in gnutls-guile 'ERROR: no code for module
	(gnutls)'
In-Reply-To: <87ipkbl7ll.fsf@latte.josefsson.org> (Simon Josefsson's message
	of "Mon, 16 Jan 2012 21:23:34 +0100")
References: <87ipkbl7ll.fsf@latte.josefsson.org>
Message-ID: <87pqej1bx7.fsf@gnu.org>

Hi Simon,

Simon Josefsson <simon at josefsson.org> skribis:

> I'm getting the error below on 'make distcheck'.  Any ideas?  There
> haven't been any significant changes in the guile/ sub-directory for
> quite a while, so I'm puzzled what triggered this.

Can you try:

  $ ./pre-inst-guile
  guile> (use-modules (gnutls))

Most likely guile-gnutls.so fails to be loaded for some reason?e.g.,
unresolved symbols.

Thanks,
Ludo?.



From yarosla at gmail.com  Tue Jan 17 01:10:50 2012
From: yarosla at gmail.com (Yaroslav)
Date: Tue, 17 Jan 2012 04:10:50 +0400
Subject: httpress benchmark utility now supports SSL via GNUTLS
Message-ID: <CACNYQ9FDCdiTLRu=W=BCW8kCELJzqxArr_5SFvamGn02BAEatA@mail.gmail.com>

Hi,

I thought this might be interesting for some people on this list.

I'd like to announce addition of SSL support to httpress:
https://bitbucket.org/yarosla/httpress/

Compared to ApacheBench and siege httpress offers greatly improved
performance. As well as precise cipher suite selection via command line
option.

Yaroslav Stavnichiy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120117/e14e730c/attachment.htm>

From nmav at gnutls.org  Tue Jan 17 15:16:34 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 17 Jan 2012 15:16:34 +0100
Subject: httpress benchmark utility now supports SSL via GNUTLS
In-Reply-To: <CACNYQ9FDCdiTLRu=W=BCW8kCELJzqxArr_5SFvamGn02BAEatA@mail.gmail.com>
References: <CACNYQ9FDCdiTLRu=W=BCW8kCELJzqxArr_5SFvamGn02BAEatA@mail.gmail.com>
Message-ID: <CAJU7zaJHMX5icNyMZxygGDAoHe8gHT2ZxkmtR95HctAw+s29MA@mail.gmail.com>

On Tue, Jan 17, 2012 at 1:10 AM, Yaroslav <yarosla at gmail.com> wrote:
> Hi,
> I thought this might be interesting for some people on this list.
> I'd like to announce addition of SSL support to
> httpress:?https://bitbucket.org/yarosla/httpress/
> Compared to ApacheBench and siege httpress offers greatly improved
> performance. As well as precise cipher suite selection via command line
> option.

Interesting. Did you notice differences in the web servers performance
comparison by using operations in parallel in httpress?

regards,
Nikos



From simon at josefsson.org  Tue Jan 17 16:12:40 2012
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 17 Jan 2012 16:12:40 +0100
Subject: make distcheck failure in gnutls-guile 'ERROR: no code for module
	(gnutls)'
In-Reply-To: <87pqej1bx7.fsf@gnu.org> ("Ludovic
	\=\?iso-8859-1\?Q\?Court\=E8s\?\=
	\=\?iso-8859-1\?Q\?\=22's\?\= message of "Tue, 17
	Jan 2012 00:10:28 +0100")
References: <87ipkbl7ll.fsf@latte.josefsson.org> <87pqej1bx7.fsf@gnu.org>
Message-ID: <87aa5mnz13.fsf@latte.josefsson.org>

ludo at gnu.org (Ludovic Court?s) writes:

> Hi Simon,
>
> Simon Josefsson <simon at josefsson.org> skribis:
>
>> I'm getting the error below on 'make distcheck'.  Any ideas?  There
>> haven't been any significant changes in the guile/ sub-directory for
>> quite a while, so I'm puzzled what triggered this.
>
> Can you try:
>
>   $ ./pre-inst-guile
>   guile> (use-modules (gnutls))
>
> Most likely guile-gnutls.so fails to be loaded for some reason?e.g.,
> unresolved symbols.

That works fine.  It is only when I run 'make distcheck' the problem
happens.  'make check' works.  Is there any way to make the code print
some more debugging information to allow me to pin-point the problem?
Right now it says:

ERROR: no code for module (gnutls)
FAIL: anonymous-auth.scm

/Simon



From yarosla at gmail.com  Tue Jan 17 18:58:42 2012
From: yarosla at gmail.com (Yaroslav)
Date: Tue, 17 Jan 2012 21:58:42 +0400
Subject: httpress benchmark utility now supports SSL via GNUTLS
In-Reply-To: <CAJU7zaJHMX5icNyMZxygGDAoHe8gHT2ZxkmtR95HctAw+s29MA@mail.gmail.com>
References: <CACNYQ9FDCdiTLRu=W=BCW8kCELJzqxArr_5SFvamGn02BAEatA@mail.gmail.com>
	<CAJU7zaJHMX5icNyMZxygGDAoHe8gHT2ZxkmtR95HctAw+s29MA@mail.gmail.com>
Message-ID: <CACNYQ9H69xNO+aL3DqYKRcrprXPaXFXvLCgQoZfUJuOkDWu8_w@mail.gmail.com>

The difference is huge. Here are some results.

Running tests against nxweb server, minimal c handler '<p>Hello,
world!</p>' (20 bytes).
Ubuntu 11.10 x64, 4 core CPU without AES-NI support.

Testing cipher suite:
ab info: TLSv1/SSLv3,ECDHE-RSA-AES256-SHA,2048,256
httpress info: ECDHE_RSA_AES_256_CBC_SHA1
- Key Exchange: ECDHE-RSA
- Ephemeral ECDH using curve SECP256R1
- Protocol: TLS1.0
- Certificate Type: X.509
- Compression: NULL
- Cipher: AES-256-CBC
- MAC: SHA1

Non-keep-alive:

ab -c 100 -n 6000
result: 380 rps

httpress -c100 -n6000 -t4 -z
'NORMAL:-CIPHER-ALL:+AES-256-CBC:-VERS-TLS-ALL:+VERS-TLS1.0'
result: 490 rps

siege -c 100 -r 60 (setup cipher via siegerc: ECDHE-RSA-AES256-SHA)
result: 500 rps

Keep-alive:

ab -c 100 -n 60000 -k
result: 22 000 rps

httpress -c100 -n6000 -t4 -z
'NORMAL:-CIPHER-ALL:+AES-256-CBC:-VERS-TLS-ALL:+VERS-TLS1.0'
result: 42 000 rps

siege -c 100 -r 600 (setup cipher via siegerc: ECDHE-RSA-AES256-SHA)
result: unable to complete the test due to excessive failures; tried to
test against nginx - same result

Plain http test (non-keep-alive):

siege -c 100 -r 1000
result: 11 000 rps

ab -c 100 -n 100000
result: 16 000 rps

httpress -c 100 -n 100000 -t4
result: 44 000 rps

Plain http test (keep-alive):

siege -c 100 -r 4000
result: 25 000 rps

ab -c 100 -n 400000 -k
result: 71 000 rps

httpress -c 100 -n 1000000 -t4 -k
result: 180 000 rps


On Tue, Jan 17, 2012 at 6:16 PM, Nikos Mavrogiannopoulos <nmav at gnutls.org>wrote:

> On Tue, Jan 17, 2012 at 1:10 AM, Yaroslav <yarosla at gmail.com> wrote:
> > Hi,
> > I thought this might be interesting for some people on this list.
> > I'd like to announce addition of SSL support to
> > httpress: https://bitbucket.org/yarosla/httpress/
> > Compared to ApacheBench and siege httpress offers greatly improved
> > performance. As well as precise cipher suite selection via command line
> > option.
>
> Interesting. Did you notice differences in the web servers performance
> comparison by using operations in parallel in httpress?
>
> regards,
> Nikos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120117/1104ee73/attachment.htm>

From ludo at gnu.org  Tue Jan 17 23:11:11 2012
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 17 Jan 2012 23:11:11 +0100
Subject: make distcheck failure in gnutls-guile 'ERROR: no code for module
	(gnutls)'
In-Reply-To: <87aa5mnz13.fsf@latte.josefsson.org> (Simon Josefsson's message
	of "Tue, 17 Jan 2012 16:12:40 +0100")
References: <87ipkbl7ll.fsf@latte.josefsson.org> <87pqej1bx7.fsf@gnu.org>
	<87aa5mnz13.fsf@latte.josefsson.org>
Message-ID: <877h0q0ykg.fsf@gnu.org>

Hi,

Simon Josefsson <simon at josefsson.org> skribis:

> ludo at gnu.org (Ludovic Court?s) writes:
>
>> Hi Simon,
>>
>> Simon Josefsson <simon at josefsson.org> skribis:
>>
>>> I'm getting the error below on 'make distcheck'.  Any ideas?  There
>>> haven't been any significant changes in the guile/ sub-directory for
>>> quite a while, so I'm puzzled what triggered this.
>>
>> Can you try:
>>
>>   $ ./pre-inst-guile
>>   guile> (use-modules (gnutls))
>>
>> Most likely guile-gnutls.so fails to be loaded for some reason?e.g.,
>> unresolved symbols.
>
> That works fine.  It is only when I run 'make distcheck' the problem
> happens.  'make check' works.  Is there any way to make the code print
> some more debugging information to allow me to pin-point the problem?
> Right now it says:
>
> ERROR: no code for module (gnutls)
> FAIL: anonymous-auth.scm

That?s another $(builddir) != $(srcdir) issue.  Can you check whether
f02628b3c9577e9a5a1fcaa87bdd2759fbd7011c fixes the problem?

The regression was introduced in
9d31ac4504a6cbaa1cf701efed301961f4ad5359, which changed
modules/gnutls.scm to be generated, and thus in $builddir instead of
$srcdir.

Sorry about that!

Ludo?.



From simon at josefsson.org  Wed Jan 18 11:58:22 2012
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 18 Jan 2012 11:58:22 +0100
Subject: make distcheck failure in gnutls-guile 'ERROR: no code for module
	(gnutls)'
In-Reply-To: <877h0q0ykg.fsf@gnu.org> ("Ludovic
	\=\?iso-8859-1\?Q\?Court\=E8s\?\=
	\=\?iso-8859-1\?Q\?\=22's\?\= message of "Tue, 17
	Jan 2012 23:11:11 +0100")
References: <87ipkbl7ll.fsf@latte.josefsson.org> <87pqej1bx7.fsf@gnu.org>
	<87aa5mnz13.fsf@latte.josefsson.org> <877h0q0ykg.fsf@gnu.org>
Message-ID: <877h0p8egh.fsf@latte.josefsson.org>

ludo at gnu.org (Ludovic Court?s) writes:

> Hi,
>
> Simon Josefsson <simon at josefsson.org> skribis:
>
>> ludo at gnu.org (Ludovic Court?s) writes:
>>
>>> Hi Simon,
>>>
>>> Simon Josefsson <simon at josefsson.org> skribis:
>>>
>>>> I'm getting the error below on 'make distcheck'.  Any ideas?  There
>>>> haven't been any significant changes in the guile/ sub-directory for
>>>> quite a while, so I'm puzzled what triggered this.
>>>
>>> Can you try:
>>>
>>>   $ ./pre-inst-guile
>>>   guile> (use-modules (gnutls))
>>>
>>> Most likely guile-gnutls.so fails to be loaded for some reason?e.g.,
>>> unresolved symbols.
>>
>> That works fine.  It is only when I run 'make distcheck' the problem
>> happens.  'make check' works.  Is there any way to make the code print
>> some more debugging information to allow me to pin-point the problem?
>> Right now it says:
>>
>> ERROR: no code for module (gnutls)
>> FAIL: anonymous-auth.scm
>
> That?s another $(builddir) != $(srcdir) issue.  Can you check whether
> f02628b3c9577e9a5a1fcaa87bdd2759fbd7011c fixes the problem?

Now I get a different error message:

make[4]: Entering directory `/home/jas/src/gnutls/gnutls-3.0.11/_build/guile/tests'
ERROR: In procedure dynamic-link:
ERROR: file: "/home/jas/src/gnutls/gnutls-3.0.11/_build/../guile/src/guile-gnutls-v-2", message: "file not found"
FAIL: anonymous-auth.scm

With the patch below 'make distcheck' continues.  Reading gnutls.scm, it
seems like the right thing to me, but please confirm.

diff --git a/guile/pre-inst-guile.in b/guile/pre-inst-guile.in
index cd74e32..9dd409d 100644
--- a/guile/pre-inst-guile.in
+++ b/guile/pre-inst-guile.in
@@ -24,7 +24,7 @@ GUILE_LOAD_PATH="@abs_top_srcdir@/guile/modules:$GUILE_LOAD_PATH"
 GUILE_LOAD_PATH="@abs_top_builddir@/guile/modules:$GUILE_LOAD_PATH"
 export GUILE_LOAD_PATH
 
-GNUTLS_GUILE_EXTENSION_DIR="@abs_top_srcdir@/guile/src"
+GNUTLS_GUILE_EXTENSION_DIR="@abs_top_builddir@/guile/src"
 export GNUTLS_GUILE_EXTENSION_DIR
 
 exec @abs_top_builddir@/libtool --mode=execute		                    \

/Simon



From ludo at gnu.org  Wed Jan 18 21:16:35 2012
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 18 Jan 2012 21:16:35 +0100
Subject: make distcheck failure in gnutls-guile 'ERROR: no code for module
	(gnutls)'
In-Reply-To: <877h0p8egh.fsf@latte.josefsson.org> (Simon Josefsson's message
	of "Wed, 18 Jan 2012 11:58:22 +0100")
References: <87ipkbl7ll.fsf@latte.josefsson.org> <87pqej1bx7.fsf@gnu.org>
	<87aa5mnz13.fsf@latte.josefsson.org> <877h0q0ykg.fsf@gnu.org>
	<877h0p8egh.fsf@latte.josefsson.org>
Message-ID: <8739bcwyu4.fsf@gnu.org>

Hi Simon,

Simon Josefsson <simon at josefsson.org> skribis:

> Now I get a different error message:
>
> make[4]: Entering directory `/home/jas/src/gnutls/gnutls-3.0.11/_build/guile/tests'
> ERROR: In procedure dynamic-link:
> ERROR: file: "/home/jas/src/gnutls/gnutls-3.0.11/_build/../guile/src/guile-gnutls-v-2", message: "file not found"
> FAIL: anonymous-auth.scm
>
> With the patch below 'make distcheck' continues.  Reading gnutls.scm, it
> seems like the right thing to me, but please confirm.

I confirm it?s the right thing.  Thanks, and sorry for the mess!

Ludo?.



From simon at josefsson.org  Thu Jan 19 10:42:36 2012
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 19 Jan 2012 10:42:36 +0100
Subject: make distcheck failure in gnutls-guile 'ERROR: no code for module
	(gnutls)'
In-Reply-To: <8739bcwyu4.fsf@gnu.org> ("Ludovic
	\=\?iso-8859-1\?Q\?Court\=E8s\?\=
	\=\?iso-8859-1\?Q\?\=22's\?\= message of "Wed, 18
	Jan 2012 21:16:35 +0100")
References: <87ipkbl7ll.fsf@latte.josefsson.org> <87pqej1bx7.fsf@gnu.org>
	<87aa5mnz13.fsf@latte.josefsson.org> <877h0q0ykg.fsf@gnu.org>
	<877h0p8egh.fsf@latte.josefsson.org> <8739bcwyu4.fsf@gnu.org>
Message-ID: <8739bc6nar.fsf@latte.josefsson.org>

ludo at gnu.org (Ludovic Court?s) writes:

>> With the patch below 'make distcheck' continues.  Reading gnutls.scm, it
>> seems like the right thing to me, but please confirm.
>
> I confirm it?s the right thing.  Thanks, and sorry for the mess!

Thanks, I've installed the patch.  However it still doesn't work, now
one of the tests fails (see make check output below).  The test looks
quite simple to me, but I can't seem to get a backtrace?

jas at latte:~/src/gnutls/guile master$ ./pre-inst-guile 
guile> (use-modules (gnutls)
             (gnutls build tests))
guile> (run-test
    (lambda ()
      (let ((s (make-session connection-end/server)))
        (catch 'gnutls-error
          (lambda ()
            (handshake s))
          (lambda (key err function . currently-unused)
            (and (eq? key 'gnutls-error)
                 err
                 (string? (error->string err))
                 (eq? function 'handshake)))))))
jas at latte:~/src/gnutls/guile master$ echo $?
1
jas at latte:~/src/gnutls/guile master$ 

/Simon

jas at latte:~/src/gnutls master$ make -C guile/tests/ check
make: Entering directory `/home/jas/src/gnutls/guile/tests'
make  check-TESTS
make[1]: Entering directory `/home/jas/src/gnutls/guile/tests'
PASS: anonymous-auth.scm

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.

Some deprecated features have been used.  Set the environment
variable GUILE_WARN_DEPRECATED to "detailed" and rerun the
program to get more information.  Set it to "no" to suppress
this message.
PASS: session-record-port.scm
PASS: pkcs-import-export.scm
FAIL: errors.scm
PASS: x509-certificates.scm
...



From grothoff at in.tum.de  Thu Jan 19 18:29:09 2012
From: grothoff at in.tum.de (Christian Grothoff)
Date: Thu, 19 Jan 2012 18:29:09 +0100
Subject: SSL handshake fails between libcurl and libgnutls/MHD
Message-ID: <4F1852E5.8000904@in.tum.de>

Dear all,

After a recent update of libcurl / libgnutls on my Debian unstable 
system, the fully automated tests of GNU libmicrohttpd for HTTPS started 
to fail.  These tests start an HTTPS server using libgnutls and GNU 
libmicrohttpd and then try downloading a site using libcurl.

Here is the key output:
$ cd libmicrohttpd/src/testcurl/https/; make check
curl version: libcurl/7.23.1 GnuTLS/2.12.14 zlib/1.2.3.4 libidn/1.23 
librtmp/2.3
# ...
curl_easy_perform failed: `SSL connect error'
Error: received handshake message out of context
Error (code: 4294967295)
FAIL: mhds_session_info_test

(this is not the only test that suddenly started to fail).

One of our tests also provokes a failure by selecting incompatible 
versions of the SSL protocol.  With older versions, that test produces ONCE:

curl version: libcurl/7.21.3 GnuTLS/2.8.6 zlib/1.2.3.4 libidn/1.18
curl_easy_perform failed: `SSL connect error'
Error: received handshake message out of context

With the latest version, the two lines are repeated several times (and 
the test now fails).


My guess right now is that there must have been some incompatible (!) 
protocol change in gnutls with itself (!?) or a significant change in 
how libcurl uses gnutls (i.e. change of supported ciphers, certificate 
checking, etc.).

I've not yet had the time to investigate which revision exactly 
introduced the problem; however, I've seen it on several systems now, so 
it is pretty real.  I suspect this is an unintended bug; however, if 
there was a change in how one should use the curl or gnutls APIs, I'd 
really appreciate some hints :-).

I'm collecting information about the bug in our bugtracker at
https://gnunet.org/bugs/view.php?id=2086

Help would be very welcome.


Happy hacking!

Christian



From simon at josefsson.org  Thu Jan 19 18:55:29 2012
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 19 Jan 2012 18:55:29 +0100
Subject: SSL handshake fails between libcurl and libgnutls/MHD
In-Reply-To: <4F1852E5.8000904@in.tum.de> (Christian Grothoff's message of
	"Thu, 19 Jan 2012 18:29:09 +0100")
References: <4F1852E5.8000904@in.tum.de>
Message-ID: <87d3af4lwu.fsf@latte.josefsson.org>

Christian Grothoff <grothoff at in.tum.de> writes:

> Dear all,
>
> After a recent update of libcurl / libgnutls on my Debian unstable
> system, the fully automated tests of GNU libmicrohttpd for HTTPS
> started to fail.  These tests start an HTTPS server using libgnutls
> and GNU libmicrohttpd and then try downloading a site using libcurl.
>
> Here is the key output:
> $ cd libmicrohttpd/src/testcurl/https/; make check
> curl version: libcurl/7.23.1 GnuTLS/2.12.14 zlib/1.2.3.4 libidn/1.23
> librtmp/2.3
> # ...
> curl_easy_perform failed: `SSL connect error'
> Error: received handshake message out of context
> Error (code: 4294967295)
> FAIL: mhds_session_info_test
>
> (this is not the only test that suddenly started to fail).
>
> One of our tests also provokes a failure by selecting incompatible
> versions of the SSL protocol.  With older versions, that test produces
> ONCE:
>
> curl version: libcurl/7.21.3 GnuTLS/2.8.6 zlib/1.2.3.4 libidn/1.18
> curl_easy_perform failed: `SSL connect error'
> Error: received handshake message out of context
>
> With the latest version, the two lines are repeated several times (and
> the test now fails).
>
>
> My guess right now is that there must have been some incompatible (!)
> protocol change in gnutls with itself (!?) or a significant change in
> how libcurl uses gnutls (i.e. change of supported ciphers, certificate
> checking, etc.).
>
> I've not yet had the time to investigate which revision exactly
> introduced the problem; however, I've seen it on several systems now,
> so it is pretty real.  I suspect this is an unintended bug; however,
> if there was a change in how one should use the curl or gnutls APIs,
> I'd really appreciate some hints :-).
>
> I'm collecting information about the bug in our bugtracker at
> https://gnunet.org/bugs/view.php?id=2086
>
> Help would be very welcome.

I don't recognize any GnuTLS errors above, so before I can help I need
some backtrace or debug info pointing towards where a GnuTLS function
returns an error now but didn't before.  The 'SSL connect error' seems
pretty fundamental, so chances are that it is something simple.

/Simon



From nmav at gnutls.org  Thu Jan 19 20:24:27 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 19 Jan 2012 20:24:27 +0100
Subject: SSL handshake fails between libcurl and libgnutls/MHD
In-Reply-To: <4F1852E5.8000904@in.tum.de>
References: <4F1852E5.8000904@in.tum.de>
Message-ID: <4F186DEB.2080605@gnutls.org>

On 01/19/2012 06:29 PM, Christian Grothoff wrote:

> Dear all,
> 
> After a recent update of libcurl / libgnutls on my Debian unstable
> system, the fully automated tests of GNU libmicrohttpd for HTTPS started
> to fail.  These tests start an HTTPS server using libgnutls and GNU
> libmicrohttpd and then try downloading a site using libcurl.
> Here is the key output:
> $ cd libmicrohttpd/src/testcurl/https/; make check
> curl version: libcurl/7.23.1 GnuTLS/2.12.14 zlib/1.2.3.4 libidn/1.23
> librtmp/2.3
> # ...
> curl_easy_perform failed: `SSL connect error'
> Error: received handshake message out of context
> Error (code: 4294967295)
> FAIL: mhds_session_info_test


Hello,
 The only fundamental that changed between 2.10 and 2.12 is the default
value of lowat to 0. If you were using select() to check for data in
gnutls' buffers you need to check [0]. If this is not your issue I'd
suggest to verify that what you experience persists with 2.12.16 (the
latest in 2.12), and then report again with more information (gnutls
errors codes and/or tcpdump info), as Simon already noted.

[0]. https://savannah.gnu.org/support/?107660#comment3

regards,
Nikos




From ludo at gnu.org  Thu Jan 19 23:32:21 2012
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Thu, 19 Jan 2012 23:32:21 +0100
Subject: make distcheck failure in gnutls-guile 'ERROR: no code for module
	(gnutls)'
In-Reply-To: <8739bc6nar.fsf@latte.josefsson.org> (Simon Josefsson's message
	of "Thu, 19 Jan 2012 10:42:36 +0100")
References: <87ipkbl7ll.fsf@latte.josefsson.org> <87pqej1bx7.fsf@gnu.org>
	<87aa5mnz13.fsf@latte.josefsson.org> <877h0q0ykg.fsf@gnu.org>
	<877h0p8egh.fsf@latte.josefsson.org> <8739bcwyu4.fsf@gnu.org>
	<8739bc6nar.fsf@latte.josefsson.org>
Message-ID: <877h0nqq6i.fsf@gnu.org>

Hi Simon,

Simon Josefsson <simon at josefsson.org> skribis:

> Thanks, I've installed the patch.  However it still doesn't work, now
> one of the tests fails (see make check output below).  The test looks
> quite simple to me, but I can't seem to get a backtrace?
>
> jas at latte:~/src/gnutls/guile master$ ./pre-inst-guile 
> guile> (use-modules (gnutls)
>              (gnutls build tests))
> guile> (run-test
>     (lambda ()
>       (let ((s (make-session connection-end/server)))
>         (catch 'gnutls-error
>           (lambda ()
>             (handshake s))
>           (lambda (key err function . currently-unused)
>             (and (eq? key 'gnutls-error)
>                  err
>                  (string? (error->string err))
>                  (eq? function 'handshake)))))))

Can you try just the ?let? expression?  (?run-test? swallows any
exceptions and calls (exit 1).)

Thanks,
Ludo?.



From daniel at haxx.se  Thu Jan 19 23:40:44 2012
From: daniel at haxx.se (Daniel Stenberg)
Date: Thu, 19 Jan 2012 23:40:44 +0100 (CET)
Subject: SSL handshake fails between libcurl and libgnutls/MHD
In-Reply-To: <4F1852E5.8000904@in.tum.de>
References: <4F1852E5.8000904@in.tum.de>
Message-ID: <alpine.DEB.2.00.1201192337140.28518@tvnag.unkk.fr>

On Thu, 19 Jan 2012, Christian Grothoff wrote:

> One of our tests also provokes a failure by selecting incompatible versions 
> of the SSL protocol.  With older versions, that test produces ONCE:
>
> curl version: libcurl/7.21.3 GnuTLS/2.8.6 zlib/1.2.3.4 libidn/1.18
> curl_easy_perform failed: `SSL connect error'
> Error: received handshake message out of context
>
> With the latest version, the two lines are repeated several times (and the 
> test now fails).

Can you try with only changing libcurl OR gnutls to see which change that 
introduces the problem?

> My guess right now is that there must have been some incompatible (!) 
> protocol change in gnutls with itself (!?) or a significant change in how 
> libcurl uses gnutls (i.e. change of supported ciphers, certificate checking, 
> etc.).

I know GnuTLS has changed default crypto backend which probably implies some 
amount of changes. libcurl has not changed the GnuTLS-layer code in any 
significant way in a long time AFAICS. Although I don't think that a bug 
necessarily needs a significant change to occur...

I've not seen or heard anyone else report about similar problems with 
libcurl+gnutls...

-- 

  / daniel.haxx.se



From simon at josefsson.org  Fri Jan 20 12:56:21 2012
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 20 Jan 2012 12:56:21 +0100
Subject: make distcheck failure in gnutls-guile 'ERROR: no code for module
	(gnutls)'
In-Reply-To: <877h0nqq6i.fsf@gnu.org> ("Ludovic
	\=\?iso-8859-1\?Q\?Court\=E8s\?\=
	\=\?iso-8859-1\?Q\?\=22's\?\= message of "Thu, 19
	Jan 2012 23:32:21 +0100")
References: <87ipkbl7ll.fsf@latte.josefsson.org> <87pqej1bx7.fsf@gnu.org>
	<87aa5mnz13.fsf@latte.josefsson.org> <877h0q0ykg.fsf@gnu.org>
	<877h0p8egh.fsf@latte.josefsson.org> <8739bcwyu4.fsf@gnu.org>
	<8739bc6nar.fsf@latte.josefsson.org> <877h0nqq6i.fsf@gnu.org>
Message-ID: <87ty3q1tay.fsf@latte.josefsson.org>

ludo at gnu.org (Ludovic Court?s) writes:

> Hi Simon,
>
> Simon Josefsson <simon at josefsson.org> skribis:
>
>> Thanks, I've installed the patch.  However it still doesn't work, now
>> one of the tests fails (see make check output below).  The test looks
>> quite simple to me, but I can't seem to get a backtrace?
>>
>> jas at latte:~/src/gnutls/guile master$ ./pre-inst-guile 
>> guile> (use-modules (gnutls)
>>              (gnutls build tests))
>> guile> (run-test
>>     (lambda ()
>>       (let ((s (make-session connection-end/server)))
>>         (catch 'gnutls-error
>>           (lambda ()
>>             (handshake s))
>>           (lambda (key err function . currently-unused)
>>             (and (eq? key 'gnutls-error)
>>                  err
>>                  (string? (error->string err))
>>                  (eq? function 'handshake)))))))
>
> Can you try just the ?let? expression?  (?run-test? swallows any
> exceptions and calls (exit 1).)

It just fails:

jas at latte:~/src/gnutls/guile master$ ./pre-inst-guile 
guile> (use-modules (gnutls) (gnutls build tests))
guile> (let ((s (make-session connection-end/server)))
        (catch 'gnutls-error
          (lambda ()
            (handshake s))
          (lambda (key err function . currently-unused)
            (and (eq? key 'gnutls-error)
                 err
                 (string? (error->string err))
                 (eq? function 'handshake)))))
#f
guile> 

Evaluation handshake gives some more information, but I'm not sure what
to do about it:

guile> (let ((s (make-session connection-end/server)))
(handshake s))

Backtrace:
In standard input:
  11: 0* (let* ((s (make-session connection-end/server))) (handshake s))
  12: 1  [handshake #<session 7f74e209aaa0>]

standard input:12:1: In procedure handshake in expression (handshake s):
standard input:12:1: unhandled-exception: gnutls-error #f handshake
ABORT: (misc-error)
guile> 

/Simon



From simon at josefsson.org  Fri Jan 20 14:36:58 2012
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 20 Jan 2012 14:36:58 +0100
Subject: GnuTLS 3.0.12
Message-ID: <874nvq1on9.fsf@latte.josefsson.org>

This release adds OCSP functionality to GnuTLS, and some other fixes.

* Version 3.0.12 (released 2012-01-20)

** libgnutls: Added OCSP support.
There is a new header file gnutls/ocsp.h and a set of new functions
under the gnutls_ocsp namespace.  Currently the functionality provided
is to parse and extract information from OCSP requests/responses, to
generate OCSP requests and to verify OCSP responses.  See the manual
for more information.  Run ./configure with --disable-ocsp to build
GnuTLS without OCSP support.

This work was sponsored by Smoothwall <http://smoothwall.net/>.

** ocsptool: Added new command line tool.
The tool can parse OCSP request/responses, generate OCSP requests and
verify OCSP responses.  See the manual for more information.

** certtool: --outder option now works for private
and public keys as well.

** libgnutls: Added error code GNUTLS_E_NO_PRIORITIES_WERE_SET
to warn when no or insufficient priorities were set.

** libgnutls: Corrected an alignment issue in ECDH
key generation which prevented some keys from being
correctly aligned in rare circumstances.

** libgnutls: Corrected memory leaks in DH parameter
generation and ecc_projective_check_point().

** libgnutls: Added gnutls_x509_dn_oid_name() to 
return a descriptive name of a DN OID.

** API and ABI modifications:
gnutls_pubkey_encrypt_data: Added
gnutls_x509_dn_oid_name: Added
gnutls_session_resumption_requested: Added
gnutls/ocsp.h: Added new header file.
gnutls_ocsp_print_formats_t: Added new type.
gnutls_ocsp_resp_status_t: Added new type.
gnutls_ocsp_cert_status_t: Added new type.
gnutls_x509_crl_reason_t: Added new type.
gnutls_ocsp_req_add_cert: Added.
gnutls_ocsp_req_add_cert_id: Added.
gnutls_ocsp_req_deinit: Added.
gnutls_ocsp_req_export: Added.
gnutls_ocsp_req_get_cert_id: Added.
gnutls_ocsp_req_get_extension: Added.
gnutls_ocsp_req_get_nonce: Added.
gnutls_ocsp_req_get_version: Added.
gnutls_ocsp_req_import: Added.
gnutls_ocsp_req_init: Added.
gnutls_ocsp_req_print: Added.
gnutls_ocsp_req_randomize_nonce: Added.
gnutls_ocsp_req_set_extension: Added.
gnutls_ocsp_req_set_nonce: Added.
gnutls_ocsp_resp_deinit: Added.
gnutls_ocsp_resp_export: Added.
gnutls_ocsp_resp_get_certs: Added.
gnutls_ocsp_resp_get_extension: Added.
gnutls_ocsp_resp_get_nonce: Added.
gnutls_ocsp_resp_get_produced: Added.
gnutls_ocsp_resp_get_responder: Added.
gnutls_ocsp_resp_get_response: Added.
gnutls_ocsp_resp_get_signature: Added.
gnutls_ocsp_resp_get_signature_algorithm: Added.
gnutls_ocsp_resp_get_single: Added.
gnutls_ocsp_resp_get_status: Added.
gnutls_ocsp_resp_get_version: Added.
gnutls_ocsp_resp_import: Added.
gnutls_ocsp_resp_init: Added.
gnutls_ocsp_resp_print: Added.
gnutls_ocsp_resp_verify: Added.

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 XZ compressed sources:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.12.tar.xz
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.12.tar.xz
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.12.tar.xz

Here are OpenPGP detached signatures signed using key 0xB565716F:

  ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.12.tar.xz.sig
  http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.12.tar.xz.sig
  ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.12.tar.xz.sig

pub   1280R/B565716F 2002-05-05 [expires: 2013-05-10]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <simon at josefsson.org>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2013-05-10]

Happy hacking,
Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 424 bytes
Desc: not available
URL: </pipermail/attachments/20120120/c7efbdf6/attachment.pgp>

From simon at josefsson.org  Fri Jan 20 15:04:58 2012
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 20 Jan 2012 15:04:58 +0100
Subject: clang analysis on GnuTLS
Message-ID: <87obtyzcz9.fsf@latte.josefsson.org>

I've run clang's static analyser on GnuTLS 3.0.12, and put the report
online:

https://www.gnu.org/software/gnutls/clang/

It is simple to re-generate (rules in cfg.mk) so I hope to run this
regulary from now on.

/Simon



From a.radke at arcor.de  Fri Jan 20 20:19:37 2012
From: a.radke at arcor.de (Andreas Radke)
Date: Fri, 20 Jan 2012 20:19:37 +0100
Subject: GnuTLS 3.0.12
In-Reply-To: <874nvq1on9.fsf@latte.josefsson.org>
References: <874nvq1on9.fsf@latte.josefsson.org>
Message-ID: <20120120201937.32e13027@workstation64.home>

Parallel build is broken here with this release:

make[5]: Entering directory `/build/src/gnutls-3.0.12/doc'
ENUMS=`grep '^@c ' enums.texi | sed 's/@c //g' | sort`; \
STR=""; \
for i in $ENUMS; do \
	STR="$STR\nENUMS += enums/$i"; \
done; \
grep -v -e '^ENUMS += ' ./Makefile.am | \
	perl -p -e "s,^ENUMS =,ENUMS =$STR," > tmp-compare-makefile; \
diff -u ./Makefile.am tmp-compare-makefile
make[5]: Entering directory `/build/src/gnutls-3.0.12/doc'
ENUMS=`grep '^@c ' enums.texi | sed 's/@c //g' | sort`; \
STR=""; \
for i in $ENUMS; do \
	STR="$STR\nENUMS += enums/$i"; \
done; \
grep -v -e '^ENUMS += ' ./Makefile.am | \
	perl -p -e "s,^ENUMS =,ENUMS =$STR," > tmp-compare-makefile; \
diff -u ./Makefile.am tmp-compare-makefile
--- ./Makefile.am	2012-01-20 12:55:19.000000000 +0000
+++ tmp-compare-makefile	2012-01-20 19:16:32.000000000 +0000
@@ -1,350 +0,0 @@
-## Process this file with automake to produce Makefile.in
-# Copyright (C) 2000-2012 Free Software Foundation, Inc.

...

-else !HAVE_GUILE
-
-core.c.texi:
-	echo "(Guile not available, documentation not generated.)" > $@
-
-endif !HAVE_GUILE
make[5]: *** [compare-makefile] Error 1
make[5]: *** [compare-makefile] Error 1
make[5]: Leaving directory `/build/src/gnutls-3.0.12/doc'
make[5]: Leaving directory `/build/src/gnutls-3.0.12/doc'
make[4]: *** [enums/gnutls_alert_description_t] Error 2
make[4]: *** Waiting for unfinished jobs....
make[4]: *** [enums/gnutls_alert_level_t] Error 2

...

-core.c.texi:
-	echo "(Guile not available, documentation not generated.)" > $@
-
-endif !HAVE_GUILE
make[5]: Entering directory `/build/src/gnutls-3.0.12/doc'
ENUMS=`grep '^@c ' enums.texi | sed 's/@c //g' | sort`; \
STR=""; \
for i in $ENUMS; do \
	STR="$STR\nENUMS += enums/$i"; \
done; \
grep -v -e '^ENUMS += ' ./Makefile.am | \
	perl -p -e "s,^ENUMS =,ENUMS =$STR," > tmp-compare-makefile; \
diff -u ./Makefile.am tmp-compare-makefile
make[5]: *** [compare-makefile] Error 1
make[5]: Leaving directory `/build/src/gnutls-3.0.12/doc'
make[4]: *** [enums/gnutls_certificate_import_flags] Error 2
--- ./Makefile.am	2012-01-20 12:55:19.000000000 +0000


-Andy
ArchLinux



From ludo at gnu.org  Fri Jan 20 22:57:54 2012
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Fri, 20 Jan 2012 22:57:54 +0100
Subject: make distcheck failure in gnutls-guile 'ERROR: no code for module
	(gnutls)'
In-Reply-To: <87ty3q1tay.fsf@latte.josefsson.org> (Simon Josefsson's message
	of "Fri, 20 Jan 2012 12:56:21 +0100")
References: <87ipkbl7ll.fsf@latte.josefsson.org> <87pqej1bx7.fsf@gnu.org>
	<87aa5mnz13.fsf@latte.josefsson.org> <877h0q0ykg.fsf@gnu.org>
	<877h0p8egh.fsf@latte.josefsson.org> <8739bcwyu4.fsf@gnu.org>
	<8739bc6nar.fsf@latte.josefsson.org> <877h0nqq6i.fsf@gnu.org>
	<87ty3q1tay.fsf@latte.josefsson.org>
Message-ID: <87pqeehw9p.fsf@gnu.org>

Hello,

Simon Josefsson <simon at josefsson.org> skribis:

> guile> (let ((s (make-session connection-end/server)))
> (handshake s))
>
> Backtrace:
> In standard input:
>   11: 0* (let* ((s (make-session connection-end/server))) (handshake s))
>   12: 1  [handshake #<session 7f74e209aaa0>]
>
> standard input:12:1: In procedure handshake in expression (handshake s):
> standard input:12:1: unhandled-exception: gnutls-error #f handshake
> ABORT: (misc-error)

Ooh, here ERR is #f, instead of being an error value.  That?s presumably
because gnutls_handshake returned an error value that the GnuTLS
bindings don?t know about (see comment in ?guile/src/errors.c?.)

Commit 1c59226bb239aa563d02b6ea8ed285de006e3b31 updates the list of
error codes known to the Guile bindings, which solves the problem.

The proper solution would be to automatically extract the list of error
codes from gnutls.h.in, but I felt too busy today.  :-)

Thanks,
Ludo?.



From guido at trentalancia.com  Fri Jan 20 20:31:50 2012
From: guido at trentalancia.com (Guido Trentalancia)
Date: Fri, 20 Jan 2012 20:31:50 +0100
Subject: gnutls-3.0.12: guile tests: FAIL: errors.scm
Message-ID: <1327087910.2385.6.camel@vortex>

Hello.

I found 1 failed test and the possible usage of deprecated guile
functions.

make  check-TESTS
make[1]: Entering directory `/usr/src/gnutls-3.0.12/guile/tests'
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
PASS: anonymous-auth.scm
`set-session-certificate-type-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-kx-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-protocol-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-cipher-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-mac-priority!'is deprecated, use `set-session-priorities!' instead
`uniform-vector-write' is deprecated. Use `put-bytevector' from
`(rnrs io ports)' instead.
`set-session-certificate-type-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-kx-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-protocol-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-cipher-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-mac-priority!'is deprecated, use `set-session-priorities!' instead
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
PASS: session-record-port.scm
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
PASS: pkcs-import-export.scm
FAIL: errors.scm
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
PASS: x509-certificates.scm
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
`set-session-certificate-type-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-kx-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-protocol-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-cipher-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-mac-priority!'is deprecated, use `set-session-priorities!' instead
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
`set-session-certificate-type-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-kx-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-protocol-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-cipher-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-mac-priority!'is deprecated, use `set-session-priorities!' instead
PASS: x509-auth.scm
PASS: priorities.scm
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
PASS: openpgp-keys.scm
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
PASS: openpgp-keyring.scm
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
PASS: openpgp-auth.scm
PASS: srp-base64.scm
===================================
1 of 11 tests failed
Please report to bug-gnutls at gnu.org
===================================
make[1]: *** [check-TESTS] Error 1
make[1]: Leaving directory `/usr/src/gnutls-3.0.12/guile/tests'
make: *** [check-am] Error 2
make  check-TESTS
make[1]: Entering directory `/usr/src/gnutls-3.0.12/guile/tests'
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
PASS: anonymous-auth.scm
`set-session-certificate-type-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-kx-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-protocol-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-cipher-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-mac-priority!'is deprecated, use `set-session-priorities!' instead
`uniform-vector-write' is deprecated. Use `put-bytevector' from
`(rnrs io ports)' instead.
`set-session-certificate-type-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-kx-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-protocol-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-cipher-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-mac-priority!'is deprecated, use `set-session-priorities!' instead
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
PASS: session-record-port.scm
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
PASS: pkcs-import-export.scm
FAIL: errors.scm
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
PASS: x509-certificates.scm
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
`set-session-certificate-type-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-kx-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-protocol-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-cipher-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-mac-priority!'is deprecated, use `set-session-priorities!' instead
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
`set-session-certificate-type-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-kx-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-protocol-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-cipher-priority!'is deprecated, use `set-session-priorities!' instead
`set-session-mac-priority!'is deprecated, use `set-session-priorities!' instead
PASS: x509-auth.scm
PASS: priorities.scm
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
PASS: openpgp-keys.scm
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
PASS: openpgp-keyring.scm
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
`uniform-vector-read!' is deprecated. Use `get-bytevector-n!' from
`(rnrs io ports)' instead.
PASS: openpgp-auth.scm
PASS: srp-base64.scm
===================================
1 of 11 tests failed
Please report to bug-gnutls at gnu.org
===================================
make[1]: *** [check-TESTS] Error 1
make[1]: Leaving directory `/usr/src/gnutls-3.0.12/guile/tests'
make: *** [check-am] Error 2

-- 
This email and any attachments are intended only for the person to which
this email is addressed and may contain confidential and/or privileged
information.  If you received this email in error, please do not
disclose the contents to anyone, but notify the sender immediately and
delete this email (and any attachments) from your system.




From ktk at enterprise.bidmc.harvard.edu  Fri Jan 20 21:34:06 2012
From: ktk at enterprise.bidmc.harvard.edu (Kris Karas)
Date: Fri, 20 Jan 2012 15:34:06 -0500
Subject: Parallel make failure with gnutls-3.0.12
Message-ID: <4F19CFBE.6080708@enterprise.bidmc.harvard.edu>

Greetings,

A bug was introduced into gnutls-3.0.12 in the logic that creates the 
"gnutls-3.0.12/doc/enums/" directory and its dependents, specifically 
when "make" is run in parallel (e.g. "make -j10").

What is happening is this:  For each file in ./doc/enums/ that gets 
created, the make creates a temporary file called 
"tmp-compare-makefile", runs "diff" against that file and Makefile.am, 
then removes the file.  However, no interlocking takes place to ensure 
that only one instance of "make" accesses the same file at once.  With a 
parallel build, one make is removing the file while another make is 
creating/diffing it, with predictable results.  Here's a typical snippit 
of the output of a parallel make (in this case, "make -j10"):

	rm -f tmp-compare-makefile
	make[4]: [enums/gnutls_certificate_print_formats_t] Error 1 (ignored)
	./scripts/split-texi.pl enums enum<  enums.texi
	make[5]: Leaving directory `/tmp/gnutls-3.0.12/doc'
	diff: tmp-compare-makefile: No such file or directory
	mkdir enums
	make[5]: *** [compare-makefile] Error 2


Best regards,
Kris Karas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120120/588a2b76/attachment.htm>

From ametzler at downhill.at.eu.org  Sat Jan 21 09:39:53 2012
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 21 Jan 2012 09:39:53 +0100
Subject: gnutls-3.0.12: guile tests: FAIL: errors.scm
In-Reply-To: <1327087910.2385.6.camel@vortex>
References: <1327087910.2385.6.camel@vortex>
Message-ID: <20120121083953.GA2032@downhill.g.la>

On 2012-01-20 Guido Trentalancia <guido at trentalancia.com> wrote:
> Hello.

> I found 1 failed test and the possible usage of deprecated guile
> functions.

> make  check-TESTS
[...]
> FAIL: errors.scm
[...]

The test failure is fixed in GIT
1c59226bb239aa563d02b6ea8ed285de006e3b31, see
http://news.gmane.org/find-root.php?message_id=%3c87pqeehw9p.fsf%40gnu.org%3e
cu andreas



From ametzler at downhill.at.eu.org  Sat Jan 21 10:36:06 2012
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Sat, 21 Jan 2012 10:36:06 +0100
Subject: GnuTLS 3.0.12
In-Reply-To: <874nvq1on9.fsf@latte.josefsson.org>
References: <874nvq1on9.fsf@latte.josefsson.org>
Message-ID: <20120121093606.GB2032@downhill.g.la>

On 2012-01-20 Simon Josefsson <simon at josefsson.org> wrote:
> * Version 3.0.12 (released 2012-01-20)

> ** libgnutls: Added OCSP support.
> There is a new header file gnutls/ocsp.h and a set of new functions
> under the gnutls_ocsp namespace.  Currently the functionality provided
> is to parse and extract information from OCSP requests/responses, to
> generate OCSP requests and to verify OCSP responses.  See the manual
> for more information.  Run ./configure with --disable-ocsp to build
> GnuTLS without OCSP support.

> This work was sponsored by Smoothwall <http://smoothwall.net/>.

> ** ocsptool: Added new command line tool.
> The tool can parse OCSP request/responses, generate OCSP requests and
> verify OCSP responses.  See the manual for more information.
[...]

Hello,

find attached a minimal manpage for ocsptool. This is a trivial
enhancement. I have just sanitized help2man's output without copying
the examples from the info manual.

cu andreas
-------------- next part --------------
.TH ocsptool "1" "January 2012"
.SH NAME
ocsptool \- commandline OCSP application
.SH DESCRIPTION
This is a program that can parse and print information about OCSP
requests/responses, generate requests and verify responses. 
.SH OPTIONS
\fB\-e\fR, \fB\-\-verify\-response\fR
Verify response.
.TP
\fB\-i\fR, \fB\-\-request\-info\fR
Print information on a OCSP request.
.TP
\fB\-j\fR, \fB\-\-response\-info\fR
Print information on a OCSP response.
.TP
\fB\-q\fR, \fB\-\-generate\-request\fR
Generate a OCSP request.
.TP
\fB\-\-no\-nonce\fR
don't add nonce to OCSP request.
.TP
\fB\-\-load\-issuer\fR FILE
read issuer certificate from FILE.
.TP
\fB\-\-load\-cert\fR FILE
read certificate to check from FILE.
.TP
\fB\-\-load\-trust\fR FILE
read OCSP trust anchors from FILE.
.TP
\fB\-\-load\-signer\fR FILE
read OCSP response signer from FILE.
.TP
\fB\-\-inder\fR
Use DER format for input certificates.
.TP
\fB\-Q\fR, \fB\-\-load\-request\fR FILE
read DER encoded OCSP request from
FILE.
.TP
\fB\-S\fR, \fB\-\-load\-response\fR FILE
read DER encoded OCSP response from
FILE.
.TP
\fB\-\-outfile\fR FILE
Output file.
.TP
\fB\-\-infile\fR FILE
Input file.
.TP
\fB\-V\fR, \fB\-\-verbose\fR
More verbose output.
.TP
\fB\-d\fR, \fB\-\-debug\fR integer
Enable debugging
.TP
\fB\-v\fR, \fB\-\-version\fR
prints the program's version number
.TP
\fB\-h\fR, \fB\-\-help\fR
shows this help text
.SH AUTHOR
ocsptool was written by Simon Josefsson.
.SH "SEE ALSO"
The full documentation for
.B ocsptool
is maintained as a Texinfo manual.  If the
.B info
and
.B ocsptool
programs are properly installed at your site, the command
.IP
.B info gnutls
.PP
should give you access to the complete manual.

From nmav at gnutls.org  Sat Jan 21 20:34:44 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 21 Jan 2012 20:34:44 +0100
Subject: Parallel make failure with gnutls-3.0.12
In-Reply-To: <4F19CFBE.6080708@enterprise.bidmc.harvard.edu>
References: <4F19CFBE.6080708@enterprise.bidmc.harvard.edu>
Message-ID: <4F1B1354.4010803@gnutls.org>

On 01/20/2012 09:34 PM, Kris Karas wrote:

> Greetings,
> 
> A bug was introduced into gnutls-3.0.12 in the logic that creates the
> "gnutls-3.0.12/doc/enums/" directory and its dependents, specifically
> when "make" is run in parallel (e.g. "make -j10").


Hello,
 Would applying this patch fix the parallel builds in your case?

regards,
Nikos

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: </pipermail/attachments/20120121/27d92db4/attachment.txt>

From eliz at gnu.org  Sat Jan 21 22:19:17 2012
From: eliz at gnu.org (Eli Zaretskii)
Date: Sat, 21 Jan 2012 23:19:17 +0200
Subject: Parallel make failure with gnutls-3.0.12
In-Reply-To: <4F1B1354.4010803@gnutls.org>
References: <4F19CFBE.6080708@enterprise.bidmc.harvard.edu>
	<4F1B1354.4010803@gnutls.org>
Message-ID: <83lip03ga2.fsf@gnu.org>

> Date: Sat, 21 Jan 2012 20:34:44 +0100
> From: Nikos Mavrogiannopoulos <nmav at gnutls.org>
> Cc: GnuTLS development list <gnutls-devel at gnu.org>
> 
>  Would applying this patch fix the parallel builds in your case?
> [...]
> --- a/doc/Makefile.am
> +++ b/doc/Makefile.am
> @@ -297,6 +297,8 @@ ENUMS += enums/gnutls_x509_subject_alt_name_t
>  gnutls_TEXINFOS += $(ENUMS)
>  DISTCLEANFILES += $(ENUMS)
>  
> +.NOTPARALLEL: $(ENUMS) enums.texi
> +
>  $(ENUMS): enums.texi
>  	$(MAKE) compare-makefile
>  	-mkdir enums

".NOTPARALLEL" is specific to GNU Make.



From nmav at gnutls.org  Sat Jan 21 23:21:20 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 21 Jan 2012 23:21:20 +0100
Subject: Parallel make failure with gnutls-3.0.12
In-Reply-To: <83lip03ga2.fsf@gnu.org>
References: <4F19CFBE.6080708@enterprise.bidmc.harvard.edu>
	<4F1B1354.4010803@gnutls.org> <83lip03ga2.fsf@gnu.org>
Message-ID: <CAJU7zaJBtMLRf_fwAB8aZLahwD72S=gZ+doHFCFH3THV_dD=og@mail.gmail.com>

On Sat, Jan 21, 2012 at 10:19 PM, Eli Zaretskii <eliz at gnu.org> wrote:

>> +.NOTPARALLEL: $(ENUMS) enums.texi
>> +
>> ?$(ENUMS): enums.texi
>> ? ? ? $(MAKE) compare-makefile
>> ? ? ? -mkdir enums
> ".NOTPARALLEL" is specific to GNU Make.

Isn't parallel building also GNU make specific? :) Otherwise do you
know a portable way for that?

regards,
Nikos



From eliz at gnu.org  Sun Jan 22 07:01:20 2012
From: eliz at gnu.org (Eli Zaretskii)
Date: Sun, 22 Jan 2012 01:01:20 -0500
Subject: Parallel make failure with gnutls-3.0.12
In-Reply-To: <CAJU7zaJBtMLRf_fwAB8aZLahwD72S=gZ+doHFCFH3THV_dD=og@mail.gmail.com>
	(message from Nikos Mavrogiannopoulos on Sat, 21 Jan 2012 23:21:20
	+0100)
References: <4F19CFBE.6080708@enterprise.bidmc.harvard.edu>
	<4F1B1354.4010803@gnutls.org> <83lip03ga2.fsf@gnu.org>
	<CAJU7zaJBtMLRf_fwAB8aZLahwD72S=gZ+doHFCFH3THV_dD=og@mail.gmail.com>
Message-ID: <E1RoqUS-0004Yx-Gq@fencepost.gnu.org>

> Date: Sat, 21 Jan 2012 23:21:20 +0100
> From: Nikos Mavrogiannopoulos <nmav at gnutls.org>
> Cc: ktk at enterprise.bidmc.harvard.edu, a.radke at arcor.de, gnutls-devel at gnu.org
> 
> On Sat, Jan 21, 2012 at 10:19 PM, Eli Zaretskii <eliz at gnu.org> wrote:
> 
> >> +.NOTPARALLEL: $(ENUMS) enums.texi
> >> +
> >> ?$(ENUMS): enums.texi
> >> ? ? ? $(MAKE) compare-makefile
> >> ? ? ? -mkdir enums
> > ".NOTPARALLEL" is specific to GNU Make.
> 
> Isn't parallel building also GNU make specific? :)

No.  At least Sun's make can do parallel builds as well.

> Otherwise do you know a portable way for that?

Well, I don't really understand the compare-makefile trick.  What is
its purpose, exactly?  It seems to have no side effects except,
potentially, the exit status returned by Diff, but if the exit status
is the sole purpose, I don't see how that status is being used.

Anyway, one solution would be to change this:

	$(MAKE) compare-makefile

into this:

     $(MAKE) compare-makefile ARG=$@

and in the compare-makefile target change each occurrence of tmp-$@
into tmp-$@.$(ARG) or some such, thus using a different temporary file
for each member of $(ENUMS).

But it is better to fix the $(ENUMS) target rule in the first place.
The split-texi.pl script generates all the files in $(ENUMS) in one
go, right?  If so, that rule needs to be run only once, while as
things are set up now, we tell Make that _each_ file in $(ENUMS) is to
be generated _independently_ from enums.texi, which is not what you
want.

Would something like the below do the job better?

$(ENUMS): stamp_enums

stamp_enums: enums.texi
	$(MAKE) compare-makefile
	-mkdir enums
	$(srcdir)/scripts/split-texi.pl enums enum < enums.texi
	echo $@ > $@

Am I missing something?



From nmav at gnutls.org  Sun Jan 22 12:32:29 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 22 Jan 2012 12:32:29 +0100
Subject: Parallel make failure with gnutls-3.0.12
In-Reply-To: <E1RoqUS-0004Yx-Gq@fencepost.gnu.org>
References: <4F19CFBE.6080708@enterprise.bidmc.harvard.edu>	<4F1B1354.4010803@gnutls.org>	<83lip03ga2.fsf@gnu.org>
	<CAJU7zaJBtMLRf_fwAB8aZLahwD72S=gZ+doHFCFH3THV_dD=og@mail.gmail.com>
	<E1RoqUS-0004Yx-Gq@fencepost.gnu.org>
Message-ID: <4F1BF3CD.2050405@gnutls.org>

On 01/22/2012 07:01 AM, Eli Zaretskii wrote:


>> Isn't parallel building also GNU make specific? :)
> No.  At least Sun's make can do parallel builds as well.
>> Otherwise do you know a portable way for that?
> Well, I don't really understand the compare-makefile trick.  What is
> its purpose, exactly?  It seems to have no side effects except,
> potentially, the exit status returned by Diff, but if the exit status
> is the sole purpose, I don't see how that status is being used.
> Anyway, one solution would be to change this:


You are correct. I've adopted this version.

regards,
Nikos



From grothoff at in.tum.de  Mon Jan 23 13:58:08 2012
From: grothoff at in.tum.de (Christian Grothoff)
Date: Mon, 23 Jan 2012 13:58:08 +0100
Subject: [libmicrohttpd] SSL handshake fails between libcurl
	and	libgnutls/MHD
In-Reply-To: <alpine.DEB.2.00.1201192337140.28518@tvnag.unkk.fr>
References: <4F1852E5.8000904@in.tum.de>
	<alpine.DEB.2.00.1201192337140.28518@tvnag.unkk.fr>
Message-ID: <4F1D5960.1030200@in.tum.de>

Ok, so here is what I know now:

1) the bug is not in libmicrohttpd or libgnutls as updating/downgrading 
these libraries does not change the appearance or non-appearance of the bug

2) The more verbose form of the output (VERBOSE in curl) is:

* About to connect() to 127.0.0.1 port 42433 (#0)
* Trying 127.0.0.1... * connected
* found 153 certificates in /etc/ssl/certs/ca-certificates.crt
* gnutls_handshake() failed: No supported cipher suites have been found.
* Closing connection #0
* SSL connect error
curl_easy_perform failed: `SSL connect error'
Error: received handshake message out of context
Error (code: 4294967295)


3) However, the bug is not because I pick specific ciphers; I can 
specify (in GNUtls/OpenSSL-syntax, depending on where) that "all" (or 
"export") ciphers are allowed for server & client; the bug is specific 
to me specifying the use of SSL3 with curl using CURL_SSLVERSION_SSL3, 
with TLS1 the problem does not arise.

4) It is not a bug with the Debian package; compiling 7.23.1 by hand 
produces the same issue as the Debian package.

5) The bug is not present in curl 7.22.0 but DOES occur in 7.23.0 and 
7.23.1.


I've compiled all of those cURL versions using
./configure --with-gnutls=/usr --prefix=/home/grothoff/ --without-ssl


For the time being, I'm still collecting information about the bug in 
our bugtracker at https://gnunet.org/bugs/view.php?id=2086

Happy hacking,

Christian


On 01/19/2012 11:40 PM, Daniel Stenberg wrote:
> On Thu, 19 Jan 2012, Christian Grothoff wrote:
>
>> One of our tests also provokes a failure by selecting incompatible
>> versions of the SSL protocol. With older versions, that test produces
>> ONCE:
>>
>> curl version: libcurl/7.21.3 GnuTLS/2.8.6 zlib/1.2.3.4 libidn/1.18
>> curl_easy_perform failed: `SSL connect error'
>> Error: received handshake message out of context
>>
>> With the latest version, the two lines are repeated several times (and
>> the test now fails).
>
> Can you try with only changing libcurl OR gnutls to see which change
> that introduces the problem?
>
>> My guess right now is that there must have been some incompatible (!)
>> protocol change in gnutls with itself (!?) or a significant change in
>> how libcurl uses gnutls (i.e. change of supported ciphers, certificate
>> checking, etc.).
>
> I know GnuTLS has changed default crypto backend which probably implies
> some amount of changes. libcurl has not changed the GnuTLS-layer code in
> any significant way in a long time AFAICS. Although I don't think that a
> bug necessarily needs a significant change to occur...
>
> I've not seen or heard anyone else report about similar problems with
> libcurl+gnutls...
>



From daniel at haxx.se  Mon Jan 23 14:06:10 2012
From: daniel at haxx.se (Daniel Stenberg)
Date: Mon, 23 Jan 2012 14:06:10 +0100 (CET)
Subject: [libmicrohttpd] SSL handshake fails between libcurl and
	libgnutls/MHD
In-Reply-To: <4F1D5960.1030200@in.tum.de>
References: <4F1852E5.8000904@in.tum.de>
	<alpine.DEB.2.00.1201192337140.28518@tvnag.unkk.fr>
	<4F1D5960.1030200@in.tum.de>
Message-ID: <alpine.DEB.2.00.1201231402270.1473@tvnag.unkk.fr>

On Mon, 23 Jan 2012, Christian Grothoff wrote:

> 5) The bug is not present in curl 7.22.0 but DOES occur in 7.23.0 and 
> 7.23.1.

That certainly narrows it down quite significantly. I checked the changes done 
to the GnuTLS code in libcurl between those two versions:

$ git log --oneline curl-7_22_0..curl-7_23_0 gtls.c
a873b95 gtls_connect_step1: remove use of deprecated functions
f5bb370 gtls.c: gnutls_transport_set_global_errno() deprecated in version 2.12.3
8036da8 gtls: only call gnutls_transport_set_lowat with <gnutls-2.12.0

... while it isn't completely unimaginable that the bug is due to a change in 
a different source module I think these three commits are the prime suspects.

We only had a total of 210 commits in curl between 7.22.0 and 7.23.0 so 
bisecting shouldn't be too time consuming if the procedure to get the bug to 
appear isn't too slow.

-- 

  / daniel.haxx.se



From simon at josefsson.org  Mon Jan 23 19:08:45 2012
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 23 Jan 2012 19:08:45 +0100
Subject: GnuTLS 3.0.12
In-Reply-To: <20120121093606.GB2032@downhill.g.la> (Andreas Metzler's message
	of "Sat, 21 Jan 2012 10:36:06 +0100")
References: <874nvq1on9.fsf@latte.josefsson.org>
	<20120121093606.GB2032@downhill.g.la>
Message-ID: <87r4yq70lu.fsf@latte.josefsson.org>

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

> On 2012-01-20 Simon Josefsson <simon at josefsson.org> wrote:
>> * Version 3.0.12 (released 2012-01-20)
>
>> ** libgnutls: Added OCSP support.
>> There is a new header file gnutls/ocsp.h and a set of new functions
>> under the gnutls_ocsp namespace.  Currently the functionality provided
>> is to parse and extract information from OCSP requests/responses, to
>> generate OCSP requests and to verify OCSP responses.  See the manual
>> for more information.  Run ./configure with --disable-ocsp to build
>> GnuTLS without OCSP support.
>
>> This work was sponsored by Smoothwall <http://smoothwall.net/>.
>
>> ** ocsptool: Added new command line tool.
>> The tool can parse OCSP request/responses, generate OCSP requests and
>> verify OCSP responses.  See the manual for more information.
> [...]
>
> Hello,
>
> find attached a minimal manpage for ocsptool. This is a trivial
> enhancement. I have just sanitized help2man's output without copying
> the examples from the info manual.

Thank you.  Nikos is reworking the command line parameter handling to
use GNU AutoOpt instead, and then we'll have auto-generated man pages.
This is already (partially) installed in master.  So I think we'll go
with that approach for the ocsptool manpage as well.

/Simon



From simon at josefsson.org  Mon Jan 23 19:11:48 2012
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 23 Jan 2012 19:11:48 +0100
Subject: make distcheck failure in gnutls-guile 'ERROR: no code for module
	(gnutls)'
In-Reply-To: <87pqeehw9p.fsf@gnu.org> ("Ludovic
	\=\?iso-8859-1\?Q\?Court\=E8s\?\=
	\=\?iso-8859-1\?Q\?\=22's\?\= message of "Fri, 20
	Jan 2012 22:57:54 +0100")
References: <87ipkbl7ll.fsf@latte.josefsson.org> <87pqej1bx7.fsf@gnu.org>
	<87aa5mnz13.fsf@latte.josefsson.org> <877h0q0ykg.fsf@gnu.org>
	<877h0p8egh.fsf@latte.josefsson.org> <8739bcwyu4.fsf@gnu.org>
	<8739bc6nar.fsf@latte.josefsson.org> <877h0nqq6i.fsf@gnu.org>
	<87ty3q1tay.fsf@latte.josefsson.org> <87pqeehw9p.fsf@gnu.org>
Message-ID: <87mx9e70gr.fsf@latte.josefsson.org>

ludo at gnu.org (Ludovic Court?s) writes:

> Hello,
>
> Simon Josefsson <simon at josefsson.org> skribis:
>
>> guile> (let ((s (make-session connection-end/server)))
>> (handshake s))
>>
>> Backtrace:
>> In standard input:
>>   11: 0* (let* ((s (make-session connection-end/server))) (handshake s))
>>   12: 1  [handshake #<session 7f74e209aaa0>]
>>
>> standard input:12:1: In procedure handshake in expression (handshake s):
>> standard input:12:1: unhandled-exception: gnutls-error #f handshake
>> ABORT: (misc-error)
>
> Ooh, here ERR is #f, instead of being an error value.  That?s presumably
> because gnutls_handshake returned an error value that the GnuTLS
> bindings don?t know about (see comment in ?guile/src/errors.c?.)
>
> Commit 1c59226bb239aa563d02b6ea8ed285de006e3b31 updates the list of
> error codes known to the Guile bindings, which solves the problem.
>
> The proper solution would be to automatically extract the list of error
> codes from gnutls.h.in, but I felt too busy today.  :-)

Thank you!  We can look at automating this later on.

/Simon



From ametzler at downhill.at.eu.org  Mon Jan 23 19:24:23 2012
From: ametzler at downhill.at.eu.org (Andreas Metzler)
Date: Mon, 23 Jan 2012 19:24:23 +0100
Subject: GnuTLS 3.0.12
In-Reply-To: <87r4yq70lu.fsf@latte.josefsson.org>
References: <874nvq1on9.fsf@latte.josefsson.org>
	<20120121093606.GB2032@downhill.g.la>
	<87r4yq70lu.fsf@latte.josefsson.org>
Message-ID: <20120123182423.GA7820@downhill.g.la>

On 2012-01-23 Simon Josefsson <simon at josefsson.org> wrote:
> Andreas Metzler <ametzler at downhill.at.eu.org> writes:
[...]
> > find attached a minimal manpage for ocsptool. This is a trivial
> > enhancement. I have just sanitized help2man's output without copying
> > the examples from the info manual.

> Thank you.  Nikos is reworking the command line parameter handling to
> use GNU AutoOpt instead, and then we'll have auto-generated man pages.
> This is already (partially) installed in master.  So I think we'll go
> with that approach for the ocsptool manpage as well.

Nice. Having a manpage which is automatically kept up to date is great
news.

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 ktk at enterprise.bidmc.harvard.edu  Mon Jan 23 19:55:37 2012
From: ktk at enterprise.bidmc.harvard.edu (Kris Karas)
Date: Mon, 23 Jan 2012 13:55:37 -0500
Subject: Parallel make failure with gnutls-3.0.12
In-Reply-To: <4F1BF3CD.2050405@gnutls.org>
References: <4F19CFBE.6080708@enterprise.bidmc.harvard.edu>	<4F1B1354.4010803@gnutls.org>	<83lip03ga2.fsf@gnu.org>
	<CAJU7zaJBtMLRf_fwAB8aZLahwD72S=gZ+doHFCFH3THV_dD=og@mail.gmail.com>
	<E1RoqUS-0004Yx-Gq@fencepost.gnu.org> <4F1BF3CD.2050405@gnutls.org>
Message-ID: <4F1DAD29.2050503@enterprise.bidmc.harvard.edu>

Nikos Mavrogiannopoulos wrote:
> On 01/22/2012 07:01 AM, Eli Zaretskii wrote:
> >  Anyway, one solution would be to change this:
> You are correct. I've adopted this version.

For what it's worth, I tried the stamp-enums trick in the makefile, and 
the parallel build worked just fine.  So you can consider the fix 
"acked" by the initial reporter.

Thanks!  :-)

Kris Karas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120123/51baec3f/attachment.htm>

From daniel at haxx.se  Mon Jan 23 22:18:30 2012
From: daniel at haxx.se (Daniel Stenberg)
Date: Mon, 23 Jan 2012 22:18:30 +0100 (CET)
Subject: [libmicrohttpd] SSL handshake fails between libcurl and
	libgnutls/MHD
In-Reply-To: <alpine.DEB.2.00.1201231402270.1473@tvnag.unkk.fr>
References: <4F1852E5.8000904@in.tum.de>
	<alpine.DEB.2.00.1201192337140.28518@tvnag.unkk.fr>
	<4F1D5960.1030200@in.tum.de>
	<alpine.DEB.2.00.1201231402270.1473@tvnag.unkk.fr>
Message-ID: <alpine.DEB.2.00.1201232213540.24579@tvnag.unkk.fr>

On Mon, 23 Jan 2012, Daniel Stenberg wrote:

> We only had a total of 210 commits in curl between 7.22.0 and 7.23.0 so 
> bisecting shouldn't be too time consuming if the procedure to get the bug to 
> appear isn't too slow.

Ok, so my bisecting identified the attached commit as the offender. If I 
revert this change the libmicrohttpd test seems to run correctly again.

I would appreciate if someone else helped me verify this.

If it indeed is so, then I would appreciate a comment from someone fluent in 
in the GnuTLS API who can tell me why this change is wrong! The change was an 
attempt to stop using the GnuTLS deprecated API.

-- 

  / daniel.haxx.se
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gtls-problematic-commit.patch
Type: text/x-diff
Size: 2348 bytes
Desc: 
URL: </pipermail/attachments/20120123/b30cf629/attachment.patch>

From nmav at gnutls.org  Mon Jan 23 23:05:43 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 23 Jan 2012 23:05:43 +0100
Subject: [libmicrohttpd] SSL handshake fails between libcurl and
	libgnutls/MHD
In-Reply-To: <alpine.DEB.2.00.1201232213540.24579@tvnag.unkk.fr>
References: <4F1852E5.8000904@in.tum.de>	<alpine.DEB.2.00.1201192337140.28518@tvnag.unkk.fr>	<4F1D5960.1030200@in.tum.de>	<alpine.DEB.2.00.1201231402270.1473@tvnag.unkk.fr>
	<alpine.DEB.2.00.1201232213540.24579@tvnag.unkk.fr>
Message-ID: <4F1DD9B7.8000103@gnutls.org>

On 01/23/2012 10:18 PM, Daniel Stenberg wrote:

> On Mon, 23 Jan 2012, Daniel Stenberg wrote:
> 
>> We only had a total of 210 commits in curl between 7.22.0 and 7.23.0
>> so bisecting shouldn't be too time consuming if the procedure to get
>> the bug to appear isn't too slow.
> 
> Ok, so my bisecting identified the attached commit as the offender. If I
> revert this change the libmicrohttpd test seems to run correctly again.
> 
> I would appreciate if someone else helped me verify this.

It doesn't look right. I'd change "-VERS-TLS-ALL:+VERS-SSL3.0" with
"NORMAL:-VERS-TLS-ALL:+VERS-SSL3.0".

However your priority string seem quite radical. You only allow SSL 3.0.
If you care about interoperability I'd suggest a string similar to
http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html
but even then you have issues like being vulnerable to the "beast" attack.

regards,
Nikos

btw. gnutls 3.0.12 added a check for gnutls_priority_set_direct() to
fail if given a string that adds no actual priorities (like the above).



From daniel at haxx.se  Mon Jan 23 23:14:44 2012
From: daniel at haxx.se (Daniel Stenberg)
Date: Mon, 23 Jan 2012 23:14:44 +0100 (CET)
Subject: [libmicrohttpd] SSL handshake fails between libcurl and
	libgnutls/MHD
In-Reply-To: <4F1DD9B7.8000103@gnutls.org>
References: <4F1852E5.8000904@in.tum.de>
	<alpine.DEB.2.00.1201192337140.28518@tvnag.unkk.fr>
	<4F1D5960.1030200@in.tum.de>
	<alpine.DEB.2.00.1201231402270.1473@tvnag.unkk.fr>
	<alpine.DEB.2.00.1201232213540.24579@tvnag.unkk.fr>
	<4F1DD9B7.8000103@gnutls.org>
Message-ID: <alpine.DEB.2.00.1201232303140.24579@tvnag.unkk.fr>

On Mon, 23 Jan 2012, Nikos Mavrogiannopoulos wrote:

> It doesn't look right. I'd change "-VERS-TLS-ALL:+VERS-SSL3.0" with 
> "NORMAL:-VERS-TLS-ALL:+VERS-SSL3.0".
>
> However your priority string seem quite radical. You only allow SSL 3.0.

That particular logic is only running when SSL 3.0 is explicitly asked for.

> If you care about interoperability I'd suggest a string similar to 
> http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html 
> but even then you have issues like being vulnerable to the "beast" attack.

I'm sorry but I'm not very familiar with SSL at a detailed protocol level. Can 
you please tell me how I can ask GnuTLS to use SSL 3.0 _without_ being 
vulnerable to something like the "beast" attack?

> btw. gnutls 3.0.12 added a check for gnutls_priority_set_direct() to fail if 
> given a string that adds no actual priorities (like the above).

Can I just mention that even after your correction I simply don't understand 
the string (and I even thought I copied the string I used from the gnutls 
manual) and it makes me slightly frustrated that the API makes it *that* easy 
to slip in a mistake that makes the application vulnerable to security 
problems. I have read the priority string section of the manual but I must be 
equipped with lesser brain cells than the humans that chapter is aimed for.

I realize creating APIs for ignorant users like me is hard and I certainly 
appreciate that more recent versions will reject very obvious stupidities...

-- 

  / daniel.haxx.se



From nmav at gnutls.org  Mon Jan 23 23:51:00 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 23 Jan 2012 23:51:00 +0100
Subject: [libmicrohttpd] SSL handshake fails between libcurl and
	libgnutls/MHD
In-Reply-To: <alpine.DEB.2.00.1201232303140.24579@tvnag.unkk.fr>
References: <4F1852E5.8000904@in.tum.de>
	<alpine.DEB.2.00.1201192337140.28518@tvnag.unkk.fr>
	<4F1D5960.1030200@in.tum.de>
	<alpine.DEB.2.00.1201231402270.1473@tvnag.unkk.fr>
	<alpine.DEB.2.00.1201232213540.24579@tvnag.unkk.fr>
	<4F1DD9B7.8000103@gnutls.org>
	<alpine.DEB.2.00.1201232303140.24579@tvnag.unkk.fr>
Message-ID: <4F1DE454.50200@gnutls.org>

On 01/23/2012 11:14 PM, Daniel Stenberg wrote:

>> If you care about interoperability I'd suggest a string similar to

>> http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html
>> but even then you have issues like being vulnerable to the "beast"
>> attack.
> I'm sorry but I'm not very familiar with SSL at a detailed protocol
> level. Can you please tell me how I can ask GnuTLS to use SSL 3.0
> _without_ being vulnerable to something like the "beast" attack?


You cannot. SSL 3.0 and TLS 1.0 are vulnerable to this attack. TLS 1.1
and later versions aren't. There are hacks to mitigate the impact (only
on the outgoing packets), but were removed from gnutls once TLS 1.1 was
introduced (because they were causing issues with old servers).

>> btw. gnutls 3.0.12 added a check for gnutls_priority_set_direct() to
>> fail if given a string that adds no actual priorities (like the above).
> Can I just mention that even after your correction I simply don't
> understand the string (and I even thought I copied the string I used
> from the gnutls manual) 


Which string?

> and it makes me slightly frustrated that the API
> makes it *that* easy to slip in a mistake that makes the application
> vulnerable to security problems. I have read the priority string section
> of the manual but I must be equipped with lesser brain cells than the
> humans that chapter is aimed for.


Could you point me what was not clear to you? That way it would be
easier for me to elaborate or rewrite parts.

 

regards,
Nikos



From christian at grothoff.org  Mon Jan 23 23:53:04 2012
From: christian at grothoff.org (Christian Grothoff)
Date: Mon, 23 Jan 2012 23:53:04 +0100
Subject: [libmicrohttpd] SSL handshake fails between libcurl and
	libgnutls/MHD
In-Reply-To: <alpine.DEB.2.00.1201232303140.24579@tvnag.unkk.fr>
References: <4F1852E5.8000904@in.tum.de>	<alpine.DEB.2.00.1201192337140.28518@tvnag.unkk.fr>	<4F1D5960.1030200@in.tum.de>	<alpine.DEB.2.00.1201231402270.1473@tvnag.unkk.fr>	<alpine.DEB.2.00.1201232213540.24579@tvnag.unkk.fr>	<4F1DD9B7.8000103@gnutls.org>
	<alpine.DEB.2.00.1201232303140.24579@tvnag.unkk.fr>
Message-ID: <4F1DE4D0.4060203@grothoff.org>

On 01/23/2012 11:14 PM, Daniel Stenberg wrote:
> On Mon, 23 Jan 2012, Nikos Mavrogiannopoulos wrote:
>
>> It doesn't look right. I'd change "-VERS-TLS-ALL:+VERS-SSL3.0" with
>> "NORMAL:-VERS-TLS-ALL:+VERS-SSL3.0".
>>
>> However your priority string seem quite radical. You only allow SSL 3.0.
>
> That particular logic is only running when SSL 3.0 is explicitly asked for.

Hehe.  That's what I get for testing rarely used code paths ;-).  Note 
that this was done in testcases, not in code that I would expect to use 
in production ;-).

>> If you care about interoperability I'd suggest a string similar to
>> http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html
>> but even then you have issues like being vulnerable to the "beast"
>> attack.
>
> I'm sorry but I'm not very familiar with SSL at a detailed protocol
> level. Can you please tell me how I can ask GnuTLS to use SSL 3.0
> _without_ being vulnerable to something like the "beast" attack?

Even if you could mitigate such attacks, I'm not sure you should.  For 
example, suppose disabling a cipher would achieve the trick.  However, 
you might then disable the only cipher that might work with SSLv3, so 
suddenly SSLv3 connections that used to work would stop to work.

If the user needs that kind of fine-grained control over ciphers, he 
should set the respective GnuTLS options directly by hand and not just 
tell you something like "SSLv3-please".  There, "DEFAULTS" is fine.  The 
fact that SSLv3 is vulnerable is not something libcurl can be expected 
to fix IMO.  After all, do you really want to modify libcurl each time 
someone makes some cryptographic progress on some cipher, causing some 
people to change their mind as to which cihpers are secure?

MHD simply leaves the complete choice to the client.  Here, your API 
doesn't allow this, so the only sane choice you have in my book is 
'default'.  If the GnuTLS 'default' for SSLv3 is vulnerable, that would 
not be libcurl's fault in my book (and in fact, in this case I am also 
not advocating that GnuTLS should change anything here either at this 
time).

I assume that you're changing your string as per Nikos's suggestion and 
I strongly suspect that this will resolve this issue.


Happy hacking!

Christian



From nmav at gnutls.org  Tue Jan 24 00:07:48 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 24 Jan 2012 00:07:48 +0100
Subject: [libmicrohttpd] SSL handshake fails between libcurl and
	libgnutls/MHD
In-Reply-To: <4F1DE454.50200@gnutls.org>
References: <4F1852E5.8000904@in.tum.de>
	<alpine.DEB.2.00.1201192337140.28518@tvnag.unkk.fr>
	<4F1D5960.1030200@in.tum.de>
	<alpine.DEB.2.00.1201231402270.1473@tvnag.unkk.fr>
	<alpine.DEB.2.00.1201232213540.24579@tvnag.unkk.fr>
	<4F1DD9B7.8000103@gnutls.org>
	<alpine.DEB.2.00.1201232303140.24579@tvnag.unkk.fr>
	<4F1DE454.50200@gnutls.org>
Message-ID: <4F1DE844.6070703@gnutls.org>

On 01/23/2012 11:51 PM, Nikos Mavrogiannopoulos wrote:


> You cannot. SSL 3.0 and TLS 1.0 are vulnerable to this attack. TLS 1.1
> and later versions aren't. There are hacks to mitigate the impact (only
> on the outgoing packets), but were removed from gnutls once TLS 1.1 was
> introduced (because they were causing issues with old servers).


Note however that the combination of the cipher ARCFOUR with SSL 3.0 and
TLS 1.0 is not vulnerable to these attacks. Thus a string to use when
SSL 3.0 is required could be
"NORMAL:-VERS-TLS-ALL:+VERS-SSL3.0:-CIPHER-ALL:+ARCFOUR-128".

regards,
Nikos




From daniel at haxx.se  Tue Jan 24 00:03:57 2012
From: daniel at haxx.se (Daniel Stenberg)
Date: Tue, 24 Jan 2012 00:03:57 +0100 (CET)
Subject: [libmicrohttpd] SSL handshake fails between libcurl and
	libgnutls/MHD
In-Reply-To: <4F1DE454.50200@gnutls.org>
References: <4F1852E5.8000904@in.tum.de>
	<alpine.DEB.2.00.1201192337140.28518@tvnag.unkk.fr>
	<4F1D5960.1030200@in.tum.de>
	<alpine.DEB.2.00.1201231402270.1473@tvnag.unkk.fr>
	<alpine.DEB.2.00.1201232213540.24579@tvnag.unkk.fr>
	<4F1DD9B7.8000103@gnutls.org>
	<alpine.DEB.2.00.1201232303140.24579@tvnag.unkk.fr>
	<4F1DE454.50200@gnutls.org>
Message-ID: <alpine.DEB.2.00.1201232347390.24579@tvnag.unkk.fr>

On Mon, 23 Jan 2012, Nikos Mavrogiannopoulos wrote:

>> please tell me how I can ask GnuTLS to use SSL 3.0 _without_ being 
>> vulnerable to something like the "beast" attack?
>
> You cannot. SSL 3.0 and TLS 1.0 are vulnerable to this attack. TLS 1.1 and 
> later versions aren't. There are hacks to mitigate the impact (only on the 
> outgoing packets), but were removed from gnutls once TLS 1.1 was introduced 
> (because they were causing issues with old servers).

Ah, ok then I understand it better. I thought you still had that ability for 
those who'd still use one of the older SSL versions.

I've corrected the used string now in libcurl and it will be included in the 
upcoming release that is due to ship within 24 hours.

>> I have read the priority string section of the manual but I must be 
>> equipped with lesser brain cells than the humans that chapter is aimed for.
>
> Could you point me what was not clear to you? That way it would be easier 
> for me to elaborate or rewrite parts.

It's not easy to tell what makes documentation hard to read or to understand. 
That syntax format is very large and probably very competent, but all I wanted 
was to find a string that would tell gnutls to use (or prefer) SSL3 and I 
thought I did. Sorry for not being able to describe it better.

-- 

  / daniel.haxx.se



From daniel at haxx.se  Tue Jan 24 00:06:09 2012
From: daniel at haxx.se (Daniel Stenberg)
Date: Tue, 24 Jan 2012 00:06:09 +0100 (CET)
Subject: [libmicrohttpd] SSL handshake fails between libcurl and
	libgnutls/MHD
In-Reply-To: <4F1DE844.6070703@gnutls.org>
References: <4F1852E5.8000904@in.tum.de>
	<alpine.DEB.2.00.1201192337140.28518@tvnag.unkk.fr>
	<4F1D5960.1030200@in.tum.de>
	<alpine.DEB.2.00.1201231402270.1473@tvnag.unkk.fr>
	<alpine.DEB.2.00.1201232213540.24579@tvnag.unkk.fr>
	<4F1DD9B7.8000103@gnutls.org>
	<alpine.DEB.2.00.1201232303140.24579@tvnag.unkk.fr>
	<4F1DE454.50200@gnutls.org> <4F1DE844.6070703@gnutls.org>
Message-ID: <alpine.DEB.2.00.1201240004520.24579@tvnag.unkk.fr>

On Tue, 24 Jan 2012, Nikos Mavrogiannopoulos wrote:

> Note however that the combination of the cipher ARCFOUR with SSL 3.0 and TLS 
> 1.0 is not vulnerable to these attacks. Thus a string to use when SSL 3.0 is 
> required could be 
> "NORMAL:-VERS-TLS-ALL:+VERS-SSL3.0:-CIPHER-ALL:+ARCFOUR-128".

Is ARCFOUR more likely to work with old/buggy servers than the "hacks" you 
mentioned?

-- 

  / daniel.haxx.se



From nmav at gnutls.org  Tue Jan 24 00:23:26 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 24 Jan 2012 00:23:26 +0100
Subject: [libmicrohttpd] SSL handshake fails between libcurl and
	libgnutls/MHD
In-Reply-To: <alpine.DEB.2.00.1201240004520.24579@tvnag.unkk.fr>
References: <4F1852E5.8000904@in.tum.de>
	<alpine.DEB.2.00.1201192337140.28518@tvnag.unkk.fr>
	<4F1D5960.1030200@in.tum.de>
	<alpine.DEB.2.00.1201231402270.1473@tvnag.unkk.fr>
	<alpine.DEB.2.00.1201232213540.24579@tvnag.unkk.fr>
	<4F1DD9B7.8000103@gnutls.org>
	<alpine.DEB.2.00.1201232303140.24579@tvnag.unkk.fr>
	<4F1DE454.50200@gnutls.org> <4F1DE844.6070703@gnutls.org>
	<alpine.DEB.2.00.1201240004520.24579@tvnag.unkk.fr>
Message-ID: <4F1DEBEE.5090001@gnutls.org>

On 01/24/2012 12:06 AM, Daniel Stenberg wrote:

> On Tue, 24 Jan 2012, Nikos Mavrogiannopoulos wrote:
> 
>> Note however that the combination of the cipher ARCFOUR with SSL 3.0
>> and TLS 1.0 is not vulnerable to these attacks. Thus a string to use
>> when SSL 3.0 is required could be
>> "NORMAL:-VERS-TLS-ALL:+VERS-SSL3.0:-CIPHER-ALL:+ARCFOUR-128".
> Is ARCFOUR more likely to work with old/buggy servers than the "hacks"
> you mentioned?

I can only speculate because I haven't really tested it. Given that this
is a string for legacy servers, and SSL 3.0 originally only supported
ARCFOUR and 3DES, you could have an issue with servers that only support
3DES. I've not seen such a server so far (although I've seen many
servers that only support ARCFOUR).

regards,
Nikos



From daniel at haxx.se  Tue Jan 24 08:39:46 2012
From: daniel at haxx.se (Daniel Stenberg)
Date: Tue, 24 Jan 2012 08:39:46 +0100 (CET)
Subject: [libmicrohttpd] SSL handshake fails between libcurl and
	libgnutls/MHD
In-Reply-To: <4F1DEBEE.5090001@gnutls.org>
References: <4F1852E5.8000904@in.tum.de>
	<alpine.DEB.2.00.1201192337140.28518@tvnag.unkk.fr>
	<4F1D5960.1030200@in.tum.de>
	<alpine.DEB.2.00.1201231402270.1473@tvnag.unkk.fr>
	<alpine.DEB.2.00.1201232213540.24579@tvnag.unkk.fr>
	<4F1DD9B7.8000103@gnutls.org>
	<alpine.DEB.2.00.1201232303140.24579@tvnag.unkk.fr>
	<4F1DE454.50200@gnutls.org> <4F1DE844.6070703@gnutls.org>
	<alpine.DEB.2.00.1201240004520.24579@tvnag.unkk.fr>
	<4F1DEBEE.5090001@gnutls.org>
Message-ID: <alpine.DEB.2.00.1201240839150.31415@tvnag.unkk.fr>

On Tue, 24 Jan 2012, Nikos Mavrogiannopoulos wrote:

> I can only speculate because I haven't really tested it.

Thanks a lot for your help Nikos, much appreciated!

--

  / daniel.haxx.se



From code at funwithsoftware.org  Tue Jan 24 20:21:50 2012
From: code at funwithsoftware.org (Patrick Pelletier)
Date: Tue, 24 Jan 2012 11:21:50 -0800
Subject: suggested doc & comment improvements for gnutls
In-Reply-To: <CAJU7zaJ83tGuFRgRu0z8q9JV8SPs984g8n0rCwS97un+F3Rdow@mail.gmail.com>
References: <2FF568D6-F418-424F-93EC-985ECC7E7D94@funwithsoftware.org>
	<CAJU7zaJ83tGuFRgRu0z8q9JV8SPs984g8n0rCwS97un+F3Rdow@mail.gmail.com>
Message-ID: <FAF5601F-8B3A-4DDD-9463-1C173D66BB19@funwithsoftware.org>

On Dec 28, 2011, at 5:57 AM, Nikos Mavrogiannopoulos wrote:

> Very nice work thank you! I've applied your patch through github,  
> but sending
> the output files of format-patch is also ok (and even better).

I have a new round of doc fixes I'd like to submit.  Some typos again,  
and I also noticed a lot of comments which still referenced gcrypt, as  
well as a comment which mentions extra.h, which I believe no longer  
exists.

I've attempted to use "git format-patch" this time.  I've just  
attached the output file created by "git format-patch" as an  
attachment to this message.  I get the impression I'm not really  
supposed to use it this way, and should instead be using "git send- 
email", but I was a bit overwhelmed by the options of "git send- 
email", and my initial experiments with it didn't work the way I  
expected it would.

(Sorry for my lack of competence with git-format-patch/git-send- 
email.  I've been using git at work for years, but I've never used its  
email features before, and as with other aspects of git, the learning  
curve is a bit steep.)

Thanks,

--Patrick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-up-some-typos-and-obsolete-comments.patch
Type: application/octet-stream
Size: 6113 bytes
Desc: not available
URL: </pipermail/attachments/20120124/2382e9ce/attachment.obj>
-------------- next part --------------


From nmav at gnutls.org  Tue Jan 24 21:45:28 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 24 Jan 2012 21:45:28 +0100
Subject: suggested doc & comment improvements for gnutls
In-Reply-To: <FAF5601F-8B3A-4DDD-9463-1C173D66BB19@funwithsoftware.org>
References: <2FF568D6-F418-424F-93EC-985ECC7E7D94@funwithsoftware.org>	<CAJU7zaJ83tGuFRgRu0z8q9JV8SPs984g8n0rCwS97un+F3Rdow@mail.gmail.com>
	<FAF5601F-8B3A-4DDD-9463-1C173D66BB19@funwithsoftware.org>
Message-ID: <4F1F1868.3040903@gnutls.org>

On 01/24/2012 08:21 PM, Patrick Pelletier wrote:


>> Very nice work thank you! I've applied your patch through github, but
>> sending
>> the output files of format-patch is also ok (and even better).
> I have a new round of doc fixes I'd like to submit.  Some typos again,
> and I also noticed a lot of comments which still referenced gcrypt, as
> well as a comment which mentions extra.h, which I believe no longer exists.


Thanks, applied!

> I've attempted to use "git format-patch" this time.  I've just attached
> the output file created by "git format-patch" as an attachment to this
> message.  I get the impression I'm not really supposed to use it this
> way, and should instead be using "git send-email", but I was a bit
> overwhelmed by the options of "git send-email", and my initial
> experiments with it didn't work the way I expected it would.


No, git send-email is not needed, unlike the lkml :)

regards,
Nikos



From ludo at gnu.org  Wed Jan 25 00:07:48 2012
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 25 Jan 2012 00:07:48 +0100
Subject: make distcheck failure in gnutls-guile 'ERROR: no code for module
	(gnutls)'
In-Reply-To: <87mx9e70gr.fsf@latte.josefsson.org> (Simon Josefsson's message
	of "Mon, 23 Jan 2012 19:11:48 +0100")
References: <87ipkbl7ll.fsf@latte.josefsson.org> <87pqej1bx7.fsf@gnu.org>
	<87aa5mnz13.fsf@latte.josefsson.org> <877h0q0ykg.fsf@gnu.org>
	<877h0p8egh.fsf@latte.josefsson.org> <8739bcwyu4.fsf@gnu.org>
	<8739bc6nar.fsf@latte.josefsson.org> <877h0nqq6i.fsf@gnu.org>
	<87ty3q1tay.fsf@latte.josefsson.org> <87pqeehw9p.fsf@gnu.org>
	<87mx9e70gr.fsf@latte.josefsson.org>
Message-ID: <87ty3kog1n.fsf@gnu.org>

Hi Simon,

Simon Josefsson <simon at josefsson.org> skribis:

> ludo at gnu.org (Ludovic Court?s) writes:

[...]

>> Ooh, here ERR is #f, instead of being an error value.  That?s presumably
>> because gnutls_handshake returned an error value that the GnuTLS
>> bindings don?t know about (see comment in ?guile/src/errors.c?.)
>>
>> Commit 1c59226bb239aa563d02b6ea8ed285de006e3b31 updates the list of
>> error codes known to the Guile bindings, which solves the problem.
>>
>> The proper solution would be to automatically extract the list of error
>> codes from gnutls.h.in, but I felt too busy today.  :-)
>
> Thank you!  We can look at automating this later on.

OTOH, error codes are part of the API, so one could argue that doing it
manual forces one to know what?s going on.

Thanks,
Ludo?.



From rebus at seznam.cz  Wed Jan 25 01:49:54 2012
From: rebus at seznam.cz (=?us-ascii?Q?Michal=20Ambroz?=)
Date: Wed, 25 Jan 2012 01:49:54 +0100 (CET)
Subject: =?us-ascii?Q?Re=3A=20Re=3A=20Re=3A=20Buffer=20Overflow=20in=20gnutls=5Fpk=2Ec=2F=5Fgnutls=5Fpkcs1=5Frsa=5Fdecrypt?=
In-Reply-To: <CAJU7zaLckyTJMgKNJYOvsc4=QCvTp7wCDhARC7BpWY7N+DJ0XQ@mail.gmail.com>
Message-ID: <86747.20911.48408-15343-1353180308-1327452593@seznam.cz>

Hello Nikos,
after all it actually was a "feature" of gnutls 2.12.0-2.12.10.
The function gnutls_certificate_set_x509_key() used to copy data in v2.10, but 2.12 started
copying pointers only.  Apparently, 2.12.10+ has reverted this behavoiur.

Best regards
Michal Ambroz

< ------------ P?vodn? zpr?va ------------
< Od: Nikos Mavrogiannopoulos <nmav at gnutls.org>
< P?edm?t: Re: Re: Buffer Overflow in gnutls_pk.c/_gnutls_pkcs1_rsa_decrypt
< Datum: 10.1.2012 10:51:43
< ----------------------------------------
< 2012/1/10 Michal Ambroz <rebus at seznam.cz>:
< > Hi Nikos,
< > more info on https://bugzilla.redhat.com/show_bug.cgi?id=747167
< > < ?I would be curious on how you reached the buffer overflow. This is an
< > < internal function and its input is controlled by its callers.
< > Server gets there by calling gnutls_handshake when new client connects.
< > I was hunting this one for quite some time.
< > It works like that:
< > 1) The code is/was wrongly used in openvas-libraries - use after free
< condition.
< > During the inicialization of the gnutls credentials the code in
< openvas-library loaded private key from file,
< > initialized credentials then freed the memory of pk structure (which is
< obviously wrong).
< > 2) when new socket connection is initialized the function gnutls_handshake is
< called
< > 3) this calls the _gnutls_pkcs1_rsa_decrypt
< > It seems that on other operating systems/versions this race condition is
< hidden. Between inicialization and
< > use there is usually not enough time to overwrite the data in the memory of
< former PK so nobody notices.
< > In Fedora 16 it nearly always wins the race condition.
< tls_cred.pkey.key.509.params_size gets usually set with some high value and it
< smashes whole stack so it is flagrantly visible.
< > The fact that it doesn't demonstrate in other operating systems/versions
< doesn't mean it is not there and can't be exploited.
< 
< Of course such issues are important, but except for sanity checks
< gnutls can't really help if the memory of a program is corrupt. Sanity
< checks might warn you or prevent a crash, but a malicious memory
< modification would be able to overcome them. Think as an extreme
< example a function that accepts a function pointer as a parameter. No
< sanity checks would prevent a pointer to point to malicious code in
< the heap.
< 
< For the specific issue, I've added a check in gnutls 2.12.x branch for
< the size of the parameters.
< 
< regards,
< Nikos
< 
< 
< 



From simon at josefsson.org  Wed Jan 25 10:04:41 2012
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 25 Jan 2012 10:04:41 +0100
Subject: make distcheck failure in gnutls-guile 'ERROR: no code for module
	(gnutls)'
In-Reply-To: <87ty3kog1n.fsf@gnu.org> ("Ludovic
	\=\?iso-8859-1\?Q\?Court\=E8s\?\=
	\=\?iso-8859-1\?Q\?\=22's\?\= message of "Wed, 25
	Jan 2012 00:07:48 +0100")
References: <87ipkbl7ll.fsf@latte.josefsson.org> <87pqej1bx7.fsf@gnu.org>
	<87aa5mnz13.fsf@latte.josefsson.org> <877h0q0ykg.fsf@gnu.org>
	<877h0p8egh.fsf@latte.josefsson.org> <8739bcwyu4.fsf@gnu.org>
	<8739bc6nar.fsf@latte.josefsson.org> <877h0nqq6i.fsf@gnu.org>
	<87ty3q1tay.fsf@latte.josefsson.org> <87pqeehw9p.fsf@gnu.org>
	<87mx9e70gr.fsf@latte.josefsson.org> <87ty3kog1n.fsf@gnu.org>
Message-ID: <8762g02lw6.fsf@latte.josefsson.org>

ludo at gnu.org (Ludovic Court?s) writes:

> Hi Simon,
>
> Simon Josefsson <simon at josefsson.org> skribis:
>
>> ludo at gnu.org (Ludovic Court?s) writes:
>
> [...]
>
>>> Ooh, here ERR is #f, instead of being an error value.  That?s presumably
>>> because gnutls_handshake returned an error value that the GnuTLS
>>> bindings don?t know about (see comment in ?guile/src/errors.c?.)
>>>
>>> Commit 1c59226bb239aa563d02b6ea8ed285de006e3b31 updates the list of
>>> error codes known to the Guile bindings, which solves the problem.
>>>
>>> The proper solution would be to automatically extract the list of error
>>> codes from gnutls.h.in, but I felt too busy today.  :-)
>>
>> Thank you!  We can look at automating this later on.
>
> OTOH, error codes are part of the API, so one could argue that doing it
> manual forces one to know what?s going on.

Will the guile self-checks fail for any new error code, or does it only
fail if the new error code is actually returned when running the rest of
the guile self checks?  I think we have added error codes befor without
noticing this.

/Simon



From ludo at gnu.org  Wed Jan 25 21:44:38 2012
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Wed, 25 Jan 2012 21:44:38 +0100
Subject: make distcheck failure in gnutls-guile 'ERROR: no code for module
	(gnutls)'
In-Reply-To: <8762g02lw6.fsf@latte.josefsson.org> (Simon Josefsson's message
	of "Wed, 25 Jan 2012 10:04:41 +0100")
References: <87ipkbl7ll.fsf@latte.josefsson.org> <87pqej1bx7.fsf@gnu.org>
	<87aa5mnz13.fsf@latte.josefsson.org> <877h0q0ykg.fsf@gnu.org>
	<877h0p8egh.fsf@latte.josefsson.org> <8739bcwyu4.fsf@gnu.org>
	<8739bc6nar.fsf@latte.josefsson.org> <877h0nqq6i.fsf@gnu.org>
	<87ty3q1tay.fsf@latte.josefsson.org> <87pqeehw9p.fsf@gnu.org>
	<87mx9e70gr.fsf@latte.josefsson.org> <87ty3kog1n.fsf@gnu.org>
	<8762g02lw6.fsf@latte.josefsson.org>
Message-ID: <87sjj3h5qh.fsf@gnu.org>

Hello,

Simon Josefsson <simon at josefsson.org> skribis:

> Will the guile self-checks fail for any new error code, or does it only
> fail if the new error code is actually returned when running the rest of
> the guile self checks?  I think we have added error codes befor without
> noticing this.

Right, that?s because few error codes are actually checked in the test
suite, and errors.scm checks only that of ?handshake?, which led to this
failure.

Thanks,
Ludo?.



From INVALID.NOREPLY at gnu.org  Fri Jan 27 00:29:13 2012
From: INVALID.NOREPLY at gnu.org (Jack Lloyd)
Date: Thu, 26 Jan 2012 23:29:13 +0000
Subject: [sr #107940] ECDH key exchange fails if leading zeros are present
Message-ID: <20120126-232912.sv50355.25250@savannah.gnu.org>

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

                 Summary: ECDH key exchange fails if leading zeros are present
                 Project: GnuTLS
            Submitted by: randombit
            Submitted on: Thu 26 Jan 2012 11:29:12 PM GMT
                Category: Core library
                Priority: 5 - Normal
                Severity: 3 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: None

    _______________________________________________________

Details:

Unlike TLS's DHE exchange method, which strips leading zeros from the shared
secret, ECDH preserves them in the premaster secret (RFC 4492 sec 5.10
"leading zeros found in this octet string MUST NOT be truncated"). It seems
that GnuTLS 3.0.11 follows the lead of DH exchange and strips them, so anytime
the ECDH exchange results in a Z value which has a leading 0 byte the
handshake will fail in the finished step because the two sides will end up
with different master secrets.




    _______________________________________________________

Reply to this item at:

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

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




From INVALID.NOREPLY at gnu.org  Fri Jan 27 10:15:17 2012
From: INVALID.NOREPLY at gnu.org (anonymous)
Date: Fri, 27 Jan 2012 09:15:17 +0000
Subject: [sr #107940] ECDH key exchange fails if leading zeros are present
In-Reply-To: <20120126-232912.sv50355.25250@savannah.gnu.org>
References: <20120126-232912.sv50355.25250@savannah.gnu.org>
Message-ID: <20120127-091516.sv0.98133@savannah.gnu.org>

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

Hello,
 Please try gnutls 3.0.12 (the latest release) which contains a fix for this
issue.


    _______________________________________________________

Reply to this item at:

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

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




From yarosla at gmail.com  Fri Jan 27 19:39:25 2012
From: yarosla at gmail.com (Yaroslav)
Date: Fri, 27 Jan 2012 22:39:25 +0400
Subject: NXWEB 3.0 is out (adds SSL, http proxy, and even better performance)
Message-ID: <CACNYQ9FCYf7Zjj5MQczJjapSJges+ut_aamYenen=9m=bNAG5A@mail.gmail.com>

NXWEB v3 has been completely rewritten ground up. It now has totally new
architecture with pluggable pipe components.

New features:
- SSL support (via GNUTLS)
- HTTP proxy support (with keep-alive connection pools)
- Worker thread pool dynamic scaling
- Sendfile module now has memory cache for small files (all configurable)

I am happy to inform that performance has also substantially improved (see
benchmarks at project page).

Yaroslav Stavnichiy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120127/0e850014/attachment.htm>

From nmav at gnutls.org  Fri Jan 27 20:36:41 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 27 Jan 2012 20:36:41 +0100
Subject: NXWEB 3.0 is out (adds SSL, http proxy,
	and even better performance)
In-Reply-To: <CACNYQ9FCYf7Zjj5MQczJjapSJges+ut_aamYenen=9m=bNAG5A@mail.gmail.com>
References: <CACNYQ9FCYf7Zjj5MQczJjapSJges+ut_aamYenen=9m=bNAG5A@mail.gmail.com>
Message-ID: <4F22FCC9.2020009@gnutls.org>

On 01/27/2012 07:39 PM, Yaroslav wrote:

> NXWEB v3 has been completely rewritten ground up. It now has totally 
> new architecture with pluggable pipe components. New features: - SSL 
> support (via GNUTLS) - HTTP proxy support (with keep-alive connection
> pools) - Worker thread pool dynamic scaling - Sendfile module now has
> memory cache for small files (all configurable) I am happy to inform
> that performance has also substantially improved (see benchmarks at
> project page).


Thanks for the benchmarks Yaroslav. As I understand the combination of
nxweb+gnutls allows for 10-18% more transactions per second comparing to
nginx+openssl. That is for the ECDHE_RSA_AES_256_CBC_SHA1 ciphersuite
and the SECP-256R1 curve.

The part of this difference that is due to gnutls should be mainly
because of the usage of libtomcrypt's elliptic curve code and gmp for
bignum arithmetic.

For the context the benchmarks are available at:
https://bitbucket.org/yarosla/nxweb/wiki/Benchmarks

regards,
Nikos



From yarosla at gmail.com  Fri Jan 27 20:52:40 2012
From: yarosla at gmail.com (Yaroslav)
Date: Fri, 27 Jan 2012 23:52:40 +0400
Subject: NXWEB 3.0 is out (adds SSL, http proxy,
	and even better performance)
In-Reply-To: <4F22FCC9.2020009@gnutls.org>
References: <CACNYQ9FCYf7Zjj5MQczJjapSJges+ut_aamYenen=9m=bNAG5A@mail.gmail.com>
	<4F22FCC9.2020009@gnutls.org>
Message-ID: <CACNYQ9FaDsLYt2aheHwcnMz+oPFHRyXmDgTfQJKdO1QtFe0bKg@mail.gmail.com>

I'd be happy if somene could do independent benchmarks of nxweb on
different hardware. So that we know for sure that it is all true :)

On Fri, Jan 27, 2012 at 11:36 PM, Nikos Mavrogiannopoulos
<nmav at gnutls.org>wrote:

> On 01/27/2012 07:39 PM, Yaroslav wrote:
>
> > NXWEB v3 has been completely rewritten ground up. It now has totally
> > new architecture with pluggable pipe components. New features: - SSL
> > support (via GNUTLS) - HTTP proxy support (with keep-alive connection
> > pools) - Worker thread pool dynamic scaling - Sendfile module now has
> > memory cache for small files (all configurable) I am happy to inform
> > that performance has also substantially improved (see benchmarks at
> > project page).
>
>
> Thanks for the benchmarks Yaroslav. As I understand the combination of
> nxweb+gnutls allows for 10-18% more transactions per second comparing to
> nginx+openssl. That is for the ECDHE_RSA_AES_256_CBC_SHA1 ciphersuite
> and the SECP-256R1 curve.
>
> The part of this difference that is due to gnutls should be mainly
> because of the usage of libtomcrypt's elliptic curve code and gmp for
> bignum arithmetic.
>
> For the context the benchmarks are available at:
> https://bitbucket.org/yarosla/nxweb/wiki/Benchmarks
>
> regards,
> Nikos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120127/7eff6ec0/attachment.htm>

From nmav at gnutls.org  Sat Jan 28 14:09:26 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 28 Jan 2012 14:09:26 +0100
Subject: rfc: verify-ssh
Message-ID: <4F23F386.8010308@gnutls.org>

Hello,
 I've added two new functions gnutls_verify_stored_pubkey() and
gnutls_store_pubkey() [0], that allow for an SSH-style authentication.
That is they allow to trust public keys from certificates associated
with a hostname and a service, based on whether they have been seen before.

This by itself is not really much, but using it in a hybrid model where
certificates are verified using the trusted certificate list _and_ the
known public keys, it would increase security overall, as a compromise
of a CA would not be enough to perform man-in-the-middle.

Comments on the idea and the implementation are welcome.

regards,
Nikos

[0].
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=lib/verify-ssh.c;h=8d6562f705a76ae7f4be4304b433f2aec4191e26;hb=HEAD



From keycpu at gmail.com  Sun Jan 29 18:27:30 2012
From: keycpu at gmail.com (key jing)
Date: Sun, 29 Jan 2012 17:27:30 +0000 (UTC)
Subject: Invitation to connect on LinkedIn
Message-ID: <177893216.11056875.1327858050443.JavaMail.app@ela4-bed80.prod>

LinkedIn
------------



I'd like to add you to my professional network on LinkedIn.

- key

key jing
Student at RMUTK
Thailand

Confirm that you know key jing:
https://www.linkedin.com/e/-m7b7h2-gy0ced1k-2c/isd/5703692691/IJPesdNe/?hs=false&tok=0kcPp52WInIl41

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-m7b7h2-gy0ced1k-2c/uvqnofIoH5kN6Hy45VzhaSIocEhqtg/goo/bug-gnutls%40gnu%2Eorg/20061/I1984588178_1/?hs=false&tok=1-sNjeFnwnIl41

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20120129/a25c11b3/attachment.htm>

From s_buckhe at cs.uni-kl.de  Mon Jan 30 06:31:07 2012
From: s_buckhe at cs.uni-kl.de (Sean Buckheister)
Date: Mon, 30 Jan 2012 06:31:07 +0100
Subject: Authenticating with OpenPGP certificates with primary keys marked
	S2K_GNU_EXT fails
Message-ID: <4F262B1B.8090807@cs.uni-kl.de>

Hello,

today I stumbled across a (from my point of view) major problem with
OpenPGP certificate handling: it doesn't work when a certificate has no
private keying material in it's primary key.

Apparently, the ability to read such keys was added to the library in
late 2008 [0], but only the loader was touched. Loading such a key fails
when used for TLS authentication, even when there is at least one
unencrypted, active subkey with Sign/Authenticate capabilities.

I managed to narrow the problem down to the privkey-copy operation that
stores a user-supplied private key into a certificate credentials
structure. To copy that private key, it is first exported from it's
internal representation, then reloaded into a new and distinct internal
representation attached to the credentials struct. The exporter however
does not correctly export the primary key the loader once found, and
thus the next loader will fail to load the key.

The codepath that leads to this in my case is

gnutls_certificate_set_openpgp_key
gnutls_privkey_import_openpgp (... GNUTLS_PRIVKEY_IMPORT_COPY)
_gnutls_openpgp_privkey_cpy

This method does the export/importing. Export works, import doesn't:

gnutls_openpgp_privkey_import
cdk_kbnode_read_from_mem
cdk_keydb_get_keyblock
cdk_pkt_read

This will find an exported CDK_PKT_SECRET_SUBKEY packet, but with wrong S2K.

read_secret_subkey
read_secret_key

This finally fails, reading the S2K. Somehow the packet gets shortened
by two bytes during export. This is due to the exporter not knowing
about S2K_GNU_EXT, telling it how long one of those S2Ks is fixes the
problem nicely. A patch that does this (three lines in total, but about
a day worth of digging through code) is attached.


-- Sean


[0] http://lists.gnu.org/archive/html/gnutls-devel/2008-08/msg00005.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s2k.patch
Type: text/x-patch
Size: 432 bytes
Desc: not available
URL: </pipermail/attachments/20120130/2016b1af/attachment.bin>

From tzz at lifelogs.com  Mon Jan 30 14:12:00 2012
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Mon, 30 Jan 2012 08:12:00 -0500
Subject: gnutls for win32
References: <CAJU7zaKH0NTE7ko6u24gXy9WupsNw+CAvhMdVudzxpXvsY2vig@mail.gmail.com>
	<87aa68dfao.fsf@lifelogs.com>
	<CAJU7zaLUNHr9zBWWja97Pv1cYz1EVQEufukXF2FiyQ04Lk-CiA@mail.gmail.com>
Message-ID: <87k44949nj.fsf@lifelogs.com>

On Sun, 1 Jan 2012 13:10:22 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: 

NM>  The build script is on the repository (cross.mk). I'll see what's the
NM> optimal release method of windows binaries.

I'd like to set up a BuildBot to produce the GnuTLS W32 binaries, which
you can host yourself or I can host.

Either way, it would produce official binaries for W32, since setting up
a build environment is very hard on that platform for most users.  Then
you can publish these binaries and other projects (notably Emacs) can
point to them.

Let me know what you think...
Ted




From nmav at gnutls.org  Mon Jan 30 22:07:17 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 30 Jan 2012 22:07:17 +0100
Subject: Authenticating with OpenPGP certificates with primary keys marked
	S2K_GNU_EXT fails
In-Reply-To: <4F262B1B.8090807@cs.uni-kl.de>
References: <4F262B1B.8090807@cs.uni-kl.de>
Message-ID: <4F270685.8080707@gnutls.org>

On 01/30/2012 06:31 AM, Sean Buckheister wrote:

> Hello,
> 
> today I stumbled across a (from my point of view) major problem with
> OpenPGP certificate handling: it doesn't work when a certificate has no
> private keying material in it's primary key.
> 
> Apparently, the ability to read such keys was added to the library in
> late 2008 [0], but only the loader was touched. Loading such a key fails
> when used for TLS authentication, even when there is at least one
> unencrypted, active subkey with Sign/Authenticate capabilities.
[...]
> This finally fails, reading the S2K. Somehow the packet gets shortened

> by two bytes during export. This is due to the exporter not knowing

> about S2K_GNU_EXT, telling it how long one of those S2Ks is fixes the
> problem nicely. A patch that does this (three lines in total, but about
> a day worth of digging through code) is attached.


Thank you! The patch has been applied.


Nikos



From nmav at gnutls.org  Mon Jan 30 22:10:57 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 30 Jan 2012 22:10:57 +0100
Subject: gnutls for win32
In-Reply-To: <87k44949nj.fsf@lifelogs.com>
References: <CAJU7zaKH0NTE7ko6u24gXy9WupsNw+CAvhMdVudzxpXvsY2vig@mail.gmail.com>	<87aa68dfao.fsf@lifelogs.com>	<CAJU7zaLUNHr9zBWWja97Pv1cYz1EVQEufukXF2FiyQ04Lk-CiA@mail.gmail.com>
	<87k44949nj.fsf@lifelogs.com>
Message-ID: <4F270761.1000709@gnutls.org>

On 01/30/2012 02:12 PM, Ted Zlatanov wrote:

> On Sun, 1 Jan 2012 13:10:22 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: 
> 
> NM>  The build script is on the repository (cross.mk). I'll see what's the
> NM> optimal release method of windows binaries.
> 
> I'd like to set up a BuildBot to produce the GnuTLS W32 binaries, which
> you can host yourself or I can host.
> Either way, it would produce official binaries for W32, since setting up
> a build environment is very hard on that platform for most users.  Then
> you can publish these binaries and other projects (notably Emacs) can
> point to them.


Hello Ted,
 I'd prefer if you host it and we can refer to it from the download
page. I'd like to avoid hosting because although I can make the
binaries, I have no easy way of testing them.

regards,
Nikos



From dkg at fifthhorseman.net  Tue Jan 31 16:24:16 2012
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 31 Jan 2012 10:24:16 -0500
Subject: rfc: verify-ssh
In-Reply-To: <4F23F386.8010308@gnutls.org>
References: <4F23F386.8010308@gnutls.org>
Message-ID: <4F2807A0.1050705@fifthhorseman.net>

On 01/28/2012 08:09 AM, Nikos Mavrogiannopoulos wrote:
> Hello,
>  I've added two new functions gnutls_verify_stored_pubkey() and
> gnutls_store_pubkey() [0], that allow for an SSH-style authentication.
> That is they allow to trust public keys from certificates associated
> with a hostname and a service, based on whether they have been seen before.
> 
> This by itself is not really much, but using it in a hybrid model where
> certificates are verified using the trusted certificate list _and_ the
> known public keys, it would increase security overall, as a compromise
> of a CA would not be enough to perform man-in-the-middle.

sounds like this is potentially a good toolkit for implementing public
key pinning, which is currently being discussed on websec:

 https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

Is this the intent?  If so, should we consider including expiration
dates in the format in question, or having a way to store a digest in
place of the raw pubkey, if we haven't seen the pubkey itself yet?

Can you explain the difference between the intended use of "application"
and "service" parameters in gnutls_store_pubkey, find_stored_pubkey, and
gnutls_verify_stored_pubkey ?

The linear file storage mechanism probably won't scale well for
implementations that deal with many many such keys over time (e.g. a web
browser).  Any thoughts about how to offer such a mechanism in a way
that scales better?

Thanks for working on this, i think it's an important piece of the puzzle.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20120131/53f0cb77/attachment.pgp>

From ludo at gnu.org  Tue Jan 31 17:27:18 2012
From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=)
Date: Tue, 31 Jan 2012 17:27:18 +0100
Subject: Tests and TCP ports
Message-ID: <87d39zhm6x.fsf@gnu.org>

Hello,

Some of the tests work by connecting to localhost on some TCP port, and
then exchanging over that connection.  These tests typically fail when
the port cannot be listened, like:

  make[3]: Entering directory `/tmp/nix-build-1i4rvwc1v6vky76vplykl9z3qz220zlz-gnutls-3.0.11.drv-0/gnutls-3.0.11/tests/dsa'
  building check-TESTS
  Checking various DSA key sizes
  Checking DSA-1024 with TLS 1.0
  *** Fatal error: A TLS fatal alert has been received.
  *** Handshake has failed
  GnuTLS error: A TLS fatal alert has been received.
  Failure: Failed connection to a server with DSA 1024 key and TLS 1.0!
  FAIL: testdsa

This is particularly a problem on Hydra where several builds may be
running in parallel, and trying to access the same TCP port.

Possible solutions include:

  - Using Unix domain sockets, though the path name limitation doesn?t
    play well with the long $builddir that Nix uses (as above.)

  - Trying several port numbers until one succeeds, the difficulty being
    that the port number has to be communicated to the child somehow.

  - Avoiding sockets entirely, by using ?gnutls_transport_set_ptr? & co.
    This doesn?t help for tests written as shell scripts, though.
    (Perhaps these could be translated in Guile, which makes writing
    tests easy while not compromising on expressive power.)

WDYT?

Thanks,
Ludo?.