From nmav at gnutls.org  Tue Apr  1 09:49:44 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 1 Apr 2014 09:49:44 +0200
Subject: [gnutls-help] 2.x 3.x API compatibility
In-Reply-To: <20140331120027.8552377df4cbf8d9cda424ca@cognitivedissonance.ca>
References: <20140331120027.8552377df4cbf8d9cda424ca@cognitivedissonance.ca>
Message-ID: <CAJU7zaLqtitPWaFBA33-WCM6fGTYYa5kjGXG4eoGZYjtAXcBbA@mail.gmail.com>

On Mon, Mar 31, 2014 at 6:00 PM, MK <mk at cognitivedissonance.ca> wrote:
> I've been developing an application which uses GnuTLS  against 3.x
> versions.   However, on one of my target platforms the last version
> which builds successfully is 3.0.x -- I'm looking into this further
> today, but it is small ARM device so checking builds is slow (the
> problem was previously reported WRT to 3.2 by someone else,
> http://lists.gnutls.org/pipermail/gnutls-help/2013-December/003288.html
> ).

Hello,
 You are linking with an older libnettle than the one required.

> I.e., I can't use the latest 3.2 which includes the fix for Advisory
> GNUTLS-SA-2014-2, so I must fall back on the git version of
> 2.12.
>
> I have a recollection from when I began this several years ago
> regarding backward compatibility issues with 3.x, but it seems
> that according to this:
>
> http://upstream-tracker.org/versions/gnutls.html
>
> Going back to 2.12 should be okay.  Is that correct?
> I realized after sending the last email it might seem I am talking
> about forward compatibility, and maybe I am depending on how I proceed
> (but I don't expect anyone else to be concerned with the issue in that
> case).

A program developed for 2.12.x will be forward compatible with 3.x, for any x
now. However, you'll have to use much more verbose code for common cases,
and you can see that by comparing the simple examples in the documentation.
As code base GnuTLS 2.12.x is unsupported though.

regards,
Nikos


From birarda at highfidelity.io  Thu Apr  3 00:01:54 2014
From: birarda at highfidelity.io (Stephen Birarda)
Date: Wed, 2 Apr 2014 15:01:54 -0700
Subject: [gnutls-help] Stuck handshake using DTLS 1.2
Message-ID: <etPan.533c88d2.4e6afb66.811@birarda.hifi>

I have a client and server that I?m attempting to complete a handshake with.

The client connects to the server and initiates the handshake. The server detects it does not have an existing session with the client and then sends a cookie back to the client. I see the client receive the 44 byte message in my pull function, but after receiving the cookie it never sends a packet back to the server via subsequent calls to gnutls_handshake().

Here?s the client log:

[DEBUG] [2014-04-02?12:16:13?-0700] [67118:5953] [audio-mixer] Pushing a message of size 271 to 127.0.0.1:40103?
[DEBUG] [2014-04-02?12:16:13?-0700] [67118:5953] [audio-mixer] Received no data on call to readDatagram?
[DEBUG] [2014-04-02?12:16:13?-0700] [67118:5953] [audio-mixer] GnuTLS handshake return is -28?
[DEBUG] [2014-04-02?12:16:13?-0700] [67118:5953] [audio-mixer] Direction return is 0?
[DEBUG] [2014-04-02?12:16:14?-0700] [67118:5953] [audio-mixer] 0?
[DEBUG] [2014-04-02?12:16:14?-0700] [67118:5953] [audio-mixer] Received 44 on DTLS socket from 127.0.0.1:40103?
[DEBUG] [2014-04-02?12:16:14?-0700] [67118:5953] [audio-mixer] Received no data on call to readDatagram?
[DEBUG] [2014-04-02?12:16:14?-0700] [67118:5953] [audio-mixer] GnuTLS handshake return is -28?
[DEBUG] [2014-04-02?12:16:14?-0700] [67118:5953] [audio-mixer] Direction return is 0?
[DEBUG] [2014-04-02?12:16:15?-0700] [67118:5953] [audio-mixer] 0?
[DEBUG] [2014-04-02?12:16:15?-0700] [67118:5953] [audio-mixer] Received no data on call to readDatagram?
[DEBUG] [2014-04-02?12:16:15?-0700] [67118:5953] [audio-mixer] GnuTLS handshake return is -28?
[DEBUG] [2014-04-02?12:16:15?-0700] [67118:5953] [audio-mixer] Direction return is 0?
[DEBUG] [2014-04-02?12:16:16?-0700] [67118:5953] [audio-mixer] 0?
[DEBUG] [2014-04-02?12:16:16?-0700] [67118:5953] [audio-mixer] Received no data on call to readDatagram?
[DEBUG] [2014-04-02?12:16:16?-0700] [67118:5953] [audio-mixer] GnuTLS handshake return is -28?
[DEBUG] [2014-04-02?12:16:16?-0700] [67118:5953] [audio-mixer] Direction return is 0?

All the server indicates is that it is sending out the cookie.

[DEBUG] [2014-04-02?12:16:13?-0700] [67085:5660] Pushing a message of size 44 to 127.0.0.1:57809?

What do I need to do to get the client to continue the handshake after receiving the cookie?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140402/c17a7986/attachment.html>

From birarda at highfidelity.io  Wed Apr  2 21:24:27 2014
From: birarda at highfidelity.io (Stephen Birarda)
Date: Wed, 2 Apr 2014 12:24:27 -0700
Subject: [gnutls-help] Stuck handshake using DTLS 1.2
Message-ID: <etPan.533c63eb.7fdcc233.811@birarda.hifi>

I have a client and server that I?m attempting to complete a handshake with.

The client connects to the server and initiates the handshake. The server detects it does not have an existing session with the client and then sends a cookie back to the client. I see the client receive the 44 byte message in my pull function, but after receiving the cookie it never sends a packet back to the server via subsequent calls to gnutls_handshake().

Here?s the client log:

[DEBUG] [2014-04-02 12:16:13 -0700] [67118:5953] [audio-mixer] Pushing a message of size 271 to 127.0.0.1:40103?
[DEBUG] [2014-04-02 12:16:13 -0700] [67118:5953] [audio-mixer] Received no data on call to readDatagram?
[DEBUG] [2014-04-02 12:16:13 -0700] [67118:5953] [audio-mixer] GnuTLS handshake return is -28?
[DEBUG] [2014-04-02 12:16:13 -0700] [67118:5953] [audio-mixer] Direction return is 0?
[DEBUG] [2014-04-02 12:16:14 -0700] [67118:5953] [audio-mixer] 0?
[DEBUG] [2014-04-02 12:16:14 -0700] [67118:5953] [audio-mixer] Received 44 on DTLS socket from 127.0.0.1:40103?
[DEBUG] [2014-04-02 12:16:14 -0700] [67118:5953] [audio-mixer] Received no data on call to readDatagram?
[DEBUG] [2014-04-02 12:16:14 -0700] [67118:5953] [audio-mixer] GnuTLS handshake return is -28?
[DEBUG] [2014-04-02 12:16:14 -0700] [67118:5953] [audio-mixer] Direction return is 0?
[DEBUG] [2014-04-02 12:16:15 -0700] [67118:5953] [audio-mixer] 0?
[DEBUG] [2014-04-02 12:16:15 -0700] [67118:5953] [audio-mixer] Received no data on call to readDatagram?
[DEBUG] [2014-04-02 12:16:15 -0700] [67118:5953] [audio-mixer] GnuTLS handshake return is -28?
[DEBUG] [2014-04-02 12:16:15 -0700] [67118:5953] [audio-mixer] Direction return is 0?
[DEBUG] [2014-04-02 12:16:16 -0700] [67118:5953] [audio-mixer] 0?
[DEBUG] [2014-04-02 12:16:16 -0700] [67118:5953] [audio-mixer] Received no data on call to readDatagram?
[DEBUG] [2014-04-02 12:16:16 -0700] [67118:5953] [audio-mixer] GnuTLS handshake return is -28?
[DEBUG] [2014-04-02 12:16:16 -0700] [67118:5953] [audio-mixer] Direction return is 0?

All the server indicates is that it is sending out the cookie.

[DEBUG] [2014-04-02 12:16:13 -0700] [67085:5660] Pushing a message of size 44 to 127.0.0.1:57809?

What do I need to do to get the client to continue the handshake after receiving the cookie?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140402/ff6c1cb0/attachment-0001.html>

From nmav at gnutls.org  Thu Apr  3 09:36:16 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 3 Apr 2014 09:36:16 +0200
Subject: [gnutls-help] Stuck handshake using DTLS 1.2
In-Reply-To: <etPan.533c88d2.4e6afb66.811@birarda.hifi>
References: <etPan.533c88d2.4e6afb66.811@birarda.hifi>
Message-ID: <CAJU7za+8JPacWQkbFgYpYs68HM9Bo631SSY77RfBF=pi0tRGfw@mail.gmail.com>

On Thu, Apr 3, 2014 at 12:01 AM, Stephen Birarda
<birarda at highfidelity.io> wrote:
> I have a client and server that I'm attempting to complete a handshake with.
> The client connects to the server and initiates the handshake. The server
> detects it does not have an existing session with the client and then sends
> a cookie back to the client. I see the client receive the 44 byte message in
> my pull function, but after receiving the cookie it never sends a packet
> back to the server via subsequent calls to gnutls_handshake().
> Here's the client log:
> [DEBUG] [2014-04-02 12:16:13 -0700] [67118:5953] [audio-mixer] Pushing a
> message of size 271 to 127.0.0.1:40103

Unfortunately that's not very informative. You should enable debugging
log in the
gnutls library to have some reasonable information on what's going on.
The easiest
would be to try connecting with gnutls-cli -d 6 or more.

regards,
Nikos


From birarda at highfidelity.io  Fri Apr  4 19:42:52 2014
From: birarda at highfidelity.io (Stephen Birarda)
Date: Fri, 4 Apr 2014 10:42:52 -0700
Subject: [gnutls-help] DTLS Handshaking with multiple clients
Message-ID: <etPan.533eef1c.2ae8944a.12b@birarda.hifi>

Adding DTLS to an event driven server-client architecture. I have Qt signal me when there is data to read on the DTLS socket and then hand that off to gnutls when appropriate.

In the process of handshaking with a client, if the server is expecting another packet from the client it tries to pull from the socket again during the handshake process. When there are multiple clients connecting simultaneously, sometimes this causes the server to drop a handshake packet from another client on the floor, since the pull looks at the sending sockaddr and sees that it does not match the expected sender for the session.

Is there any way to work around this more gracefully other than simply letting the dropped handshake timeout and re-attempt 10 seconds later (or whatever the handshake timeout may be set to)??
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140404/e712da5b/attachment.html>

From night at nist.gov  Fri Apr  4 20:49:05 2014
From: night at nist.gov (Stephen Nightingale)
Date: Fri, 4 Apr 2014 14:49:05 -0400
Subject: [gnutls-help] Server supplied Certificate in Handshake
Message-ID: <533EFEA1.3060306@nist.gov>

I am running GnuTLS 3.1.16 as both client and server, with a python-gnutls
wrapper extended to check for DANE certificate uses, here:
https://www.had-pilot.com/dane/danelaw.html.

The GnuTLS server is running all 0xx and 1xx DANE certificate uses, serving
a single end certificate per use. It runs 24/7 robustly.  It can only
be configured to take a single end certificate for the server handshake.
When presented with a concatenation of PEM certs, it will send only the
end cert in the server side handshake. This is curious, because the GnuTLS
client will retrieve the full cert chain in communication with, e.g.,
the TLSlite server.

I tried this with gnutls-cli and gnutls-serve, configuring the server with
a concatenated PEM chain, with the same result: only the end cert is
delivered to the client.

Has this issue been fixed in subsequent versions of GnuTLS?  Are there plans
to fix it?

Cheers,

Stephen Nightingale, NIST.




From nmav at gnutls.org  Fri Apr  4 22:26:33 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 04 Apr 2014 22:26:33 +0200
Subject: [gnutls-help] Server supplied Certificate in Handshake
In-Reply-To: <533EFEA1.3060306@nist.gov>
References: <533EFEA1.3060306@nist.gov>
Message-ID: <1396643193.4061.4.camel@nomad.lan>

On Fri, 2014-04-04 at 14:49 -0400, Stephen Nightingale wrote:
> I am running GnuTLS 3.1.16 as both client and server, with a python-gnutls
> wrapper extended to check for DANE certificate uses, here:
> https://www.had-pilot.com/dane/danelaw.html.
> 
> The GnuTLS server is running all 0xx and 1xx DANE certificate uses, serving
> a single end certificate per use. It runs 24/7 robustly.  It can only
> be configured to take a single end certificate for the server handshake.
> When presented with a concatenation of PEM certs, it will send only the
> end cert in the server side handshake. This is curious, because the GnuTLS
> client will retrieve the full cert chain in communication with, e.g.,
> the TLSlite server.
> 
> I tried this with gnutls-cli and gnutls-serve, configuring the server with
> a concatenated PEM chain, with the same result: only the end cert is
> delivered to the client.
> 
> Has this issue been fixed in subsequent versions of GnuTLS?  Are there plans
> to fix it?

If that's the case then it's a bug, but by trying 3.1.22 by setting a
correct chain in gnutls-serv, I see in gnutls-cli "- Got a certificate
list of 3 certificates."

regards,
Nikos




From nmav at gnutls.org  Fri Apr  4 22:28:34 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 04 Apr 2014 22:28:34 +0200
Subject: [gnutls-help] DTLS Handshaking with multiple clients
In-Reply-To: <etPan.533eef1c.2ae8944a.12b@birarda.hifi>
References: <etPan.533eef1c.2ae8944a.12b@birarda.hifi>
Message-ID: <1396643314.4061.6.camel@nomad.lan>

On Fri, 2014-04-04 at 10:42 -0700, Stephen Birarda wrote:
> Adding DTLS to an event driven server-client architecture. I have Qt
> signal me when there is data to read on the DTLS socket and then hand
> that off to gnutls when appropriate.
> In the process of handshaking with a client, if the server is
> expecting another packet from the client it tries to pull from the
> socket again during the handshake process. When there are multiple
> clients connecting simultaneously, sometimes this causes the server to
> drop a handshake packet from another client on the floor, since the
> pull looks at the sending sockaddr and sees that it does not match the
> expected sender for the session.

Most probably you'll need a multiplexer in the read function that will
cache and send the appropriate data to the appropriate session. I
haven't really thought whether that could be easily made part of gnutls.
If you have any nice suggestion let me know.

regards,
Nikos





From jens.lechtenboerger at fsfe.org  Sun Apr  6 12:24:25 2014
From: jens.lechtenboerger at fsfe.org (Jens Lechtenboerger)
Date: Sun, 06 Apr 2014 12:24:25 +0200
Subject: [gnutls-help] Certificate pinning with gnutls-cli
Message-ID: <86lhvizrfq.fsf@informationelle-selbstbestimmung-im-internet.de>

Dear GnuTLS users,

I?m using gnutls-cli to pin certificates for various applications
that don?t perform proper certificate checking themselves, in
particular GNU Emacs and K-9 Mail.  I described my approach in three
blog posts, the most recent one presenting a pinning TLS tunnel:
https://blogs.fsfe.org/jens.lechtenboerger/?p=230

Please have a look if you are interested.  Feedback is highly
appreciated.

Best wishes
Jens


From nmav at gnutls.org  Mon Apr  7 21:58:33 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 07 Apr 2014 21:58:33 +0200
Subject: [gnutls-help] gnutls 3.2.13
Message-ID: <1396900713.21845.2.camel@nomad.lan>

Hello,
 I've just released gnutls 3.2.13. This is a bugfix release on the
current stable branch.

* Version 3.2.13 (released 2014-04-07)

** libgnutls: gnutls_openpgp_keyring_import will no longer fail silently
if there are no base64 data. Report and patch by Ramkumar Chinchani.

** libgnutls: gnutls_record_send is now safe to be called under DTLS when
in corked mode.

** libgnutls: Ciphersuites that use the SHA256 or SHA384 MACs are
only available in TLS 1.0 as SSL 3.0 doesn't specify parameters for
these algorithms.

** libgnutls: Changed the behaviour in wildcard acceptance in certificates.
Wildcards are only accepted when there are more than two domain components
after the wildcard. This drops support for the permissive RFC2818 wildcards
and adds more conservative support based on the suggestions in RFC6125. Suggested 
by Jeffrey Walton.

** certtool: When no password is provided to export a PKCS #8 keys, do
not encrypt by default. This reverts to the certtool behavior of gnutls
3.0. The previous behavior of encrypting using an empty password can be
replicating using the new parameter --empty-password.

** p11tool: Avoid dual initialization of the PKCS #11 subsystem when
the --provider option is given.

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


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

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

Here are the XZ and LZIP compressed sources:

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

Here are OpenPGP detached signatures signed using key 0x96865171:

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

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

regards,
Nikos





From nmav at gnutls.org  Mon Apr  7 21:57:17 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 07 Apr 2014 21:57:17 +0200
Subject: [gnutls-help] gnutls 3.1.23
Message-ID: <1396900637.21845.0.camel@nomad.lan>

Hello,
 I've just released gnutls 3.1.23. This is a bug fix release on the old
stable branch.


* Version 3.1.23 (released 2014-04-07)

** libgnutls: Ciphersuites that use the SHA256 or SHA384 MACs are
only available in TLS 1.0 as SSL 3.0 doesn't specify parameters for
these algorithms.

** libgnutls: gnutls_record_send is now safe to be called under DTLS when
in corked mode.

** libgnutls: Changed the behaviour in wildcard acceptance in certificates.
Wildcards are only accepted when there are more than two domain components
after the wildcard. This drops support for the permissive RFC2818 wildcards
and adds more conservative support based on the suggestions in RFC6125. Suggested 
by Jeffrey Walton.

** certtool: When no password is provided to export a PKCS #8 keys, do
not encrypt by default. This reverts to the certtool behavior of gnutls
3.0. The previous behavior of encrypting using an empty password can be
replicating using the new parameter --empty-password.

** p11tool: Avoid dual initialization of the PKCS #11 subsystem when
the --provider option is given.

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


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

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

Here are the XZ and LZIP compressed sources:

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

Here are OpenPGP detached signatures signed using key 0x96865171:

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

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

regards,
Nikos




From olaf at zaplinski.de  Wed Apr  9 16:55:40 2014
From: olaf at zaplinski.de (Olaf Zaplinski)
Date: Wed, 09 Apr 2014 16:55:40 +0200
Subject: [gnutls-help] need help with SNI
Message-ID: <4cd300b1b475f74845e41ff906ac7301@mail.zaplinski.de>

Hi all,

I have a problem with SNI.

I have 3 name based vhosts with GnuTLS.

jne.example.com runs with a certificate *.example.com from CA #1
alice.example.net runs with certificate alice.example.net from CA #2
bob.example.com runs with certificate bob.example.com from CA #2

In fact, joe is my (Debian) default host with config file
/etc/apache2/sites-available/default-tls

The two first hosts work fine, but host bob presents the certificate 
from joe. It works because this certificate is a wildcard one, but I 
would like to know why GnuTLS refuses to present the certificate that I 
had configured.

Olaf


From jomat+gnutls at jmt.gr  Wed Apr  9 19:58:10 2014
From: jomat+gnutls at jmt.gr (Johannes Matheis)
Date: Wed, 09 Apr 2014 17:58:10 +0000
Subject: [gnutls-help]  need help with SNI
In-Reply-To: <4cd300b1b475f74845e41ff906ac7301@mail.zaplinski.de>
References: <4cd300b1b475f74845e41ff906ac7301@mail.zaplinski.de>
Message-ID: <1397065836-turnsole-75934@leto.j.dn42>

Hi,

Excerpts from Olaf Zaplinski's message of 2014-04-09 14:55:40 +0000:
> It works because this certificate is a wildcard one, but I 
> would like to know why GnuTLS refuses to present the certificate that I 
> had configured.

Could you please paste how you configured your Apache (I assume it is apache).

Here's my SNI-vhost-config I use for several different domains as a reference:
https://0.jmt.gr/?17e9ffa4a7c3210b#y1ubsvgNrz2EngxN49gf0Y6cGS1vvTgM/JsNnwUHP8U=

bye,
Johannes


From dkg at fifthhorseman.net  Wed Apr  9 23:31:25 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 09 Apr 2014 17:31:25 -0400
Subject: [gnutls-help] need help with SNI
In-Reply-To: <4cd300b1b475f74845e41ff906ac7301@mail.zaplinski.de>
References: <4cd300b1b475f74845e41ff906ac7301@mail.zaplinski.de>
Message-ID: <5345BC2D.3000108@fifthhorseman.net>

On 04/09/2014 10:55 AM, Olaf Zaplinski wrote:
> I have a problem with SNI.
> 
> I have 3 name based vhosts with GnuTLS.


I think you're stalking about apache with mod_gnutls.

I'm sending this response to mod_gnutls-devel at lists.gnutls.org since
that's a better place for apache-related mod_gnutls questions.  please
follow up there.

> jne.example.com runs with a certificate *.example.com from CA #1
> alice.example.net runs with certificate alice.example.net from CA #2
> bob.example.com runs with certificate bob.example.com from CA #2
> 
> In fact, joe is my (Debian) default host with config file
> /etc/apache2/sites-available/default-tls
> 
> The two first hosts work fine, but host bob presents the certificate
> from joe. It works because this certificate is a wildcard one, but I
> would like to know why GnuTLS refuses to present the certificate that I
> had configured.

can you be more specific about apache, mod_gnutls, and your
configuration?  it would help to know:

 * version information (of apache, of gnutls, of mod_gnutls)

 * concrete configuration file excerpts that you think might be relevant.

it does sound like there might be an SNI matching issue that we could
tighten up (presumably we'd want to take the most-specific match
possible, rather than the first-matching cert).

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140409/6936ea43/attachment.sig>

From olaf at zaplinski.de  Wed Apr  9 23:39:36 2014
From: olaf at zaplinski.de (Olaf Zaplinski)
Date: Wed, 09 Apr 2014 23:39:36 +0200
Subject: [gnutls-help] need help with SNI
In-Reply-To: <1397065836-turnsole-75934@leto.j.dn42>
References: <4cd300b1b475f74845e41ff906ac7301@mail.zaplinski.de>
 <1397065836-turnsole-75934@leto.j.dn42>
Message-ID: <5345BE18.1030002@zaplinski.de>

Am 09.04.2014 19:58, schrieb Johannes Matheis:
> Hi,
>
> Excerpts from Olaf Zaplinski's message of 2014-04-09 14:55:40 +0000:
>> It works because this certificate is a wildcard one, but I
>> would like to know why GnuTLS refuses to present the certificate that I
>> had configured.
>
> Could you please paste how you configured your Apache (I assume it is apache).

Here it is, nothing special:

https://0.jmt.gr/?4d9b07a686545531#fMZ3M2aQ1fPk87BVQNICFgwo3giEBCtIt55lNvFRg4k=

Olaf


From olaf at zaplinski.de  Wed Apr  9 23:47:35 2014
From: olaf at zaplinski.de (Olaf Zaplinski)
Date: Wed, 09 Apr 2014 23:47:35 +0200
Subject: [gnutls-help] need help with SNI
In-Reply-To: <5345BC2D.3000108@fifthhorseman.net>
References: <4cd300b1b475f74845e41ff906ac7301@mail.zaplinski.de>
 <5345BC2D.3000108@fifthhorseman.net>
Message-ID: <5345BFF7.40109@zaplinski.de>

Am 09.04.2014 23:31, schrieb Daniel Kahn Gillmor:
> On 04/09/2014 10:55 AM, Olaf Zaplinski wrote:
>> I have a problem with SNI.
>>
>> I have 3 name based vhosts with GnuTLS.
>
>
> I think you're stalking about apache with mod_gnutls.

Correct.

> I'm sending this response to mod_gnutls-devel at lists.gnutls.org since
> that's a better place for apache-related mod_gnutls questions.  please
> follow up there.

OK. But I will keep this list on CC, ok?

> it does sound like there might be an SNI matching issue that we could
> tighten up (presumably we'd want to take the most-specific match
> possible, rather than the first-matching cert).

I found a blog mentioning that GnuTLS has problems with subjectAltName:

http://jan-krueger.net/development/mod_gnutls-and-startssl-level-1-certificates-the-problem-and-solution

Sounds like my problem: GnuTLS chooses the "wrong" certificate.

Olaf


From dkg at fifthhorseman.net  Thu Apr 10 00:20:21 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 09 Apr 2014 18:20:21 -0400
Subject: [gnutls-help] need help with SNI
In-Reply-To: <5345BFF7.40109@zaplinski.de>
References: <4cd300b1b475f74845e41ff906ac7301@mail.zaplinski.de>
 <5345BC2D.3000108@fifthhorseman.net> <5345BFF7.40109@zaplinski.de>
Message-ID: <5345C7A5.6000302@fifthhorseman.net>

On 04/09/2014 05:47 PM, Olaf Zaplinski wrote:
> I found a blog mentioning that GnuTLS has problems with subjectAltName:
> 
> http://jan-krueger.net/development/mod_gnutls-and-startssl-level-1-certificates-the-problem-and-solution

that blog post is from more than three years ago.  It may not reflect
the version of mod_gnutls you're using today.

what version of apache are you running?

what version of gnutls are you running?

what version of mod_gnutls are you running?

Your earlier message to gnutls-help provides this link:

 https://0.jmt.gr/?4d9b07a686545531#fMZ3M2aQ1fPk87BVQNICFgwo3giEBCtIt55lNvFRg4k=

this is a zerobin site, certified by CACert, sending
Strict-Transport-Security headers.

For people without the CACert root CA in their trust store, even if they
make a temporary allowance for the guest cert, the STS header will cause
the browser to reject the connection with no user clickthrough allowed.

zerobin also needs javascript, so falling back to wget
--no-check-certificate doesn't produce anything a human can understand.

I don't want this to turn into a discussion about the relative merits of
CACert or the CA cartel or javascript or supposedly-ephemeral data, but
my point is if you want people on the internet to help figure things
out, making it easier for them to see the data they need to see to
understand the situation is probably a good idea.

if there are redacted configs that you're willing to publish, it is
helpful to include them directly in your e-mail response.

thanks,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140409/3f95ea3c/attachment.sig>

From mvoteiza at udel.edu  Thu Apr 10 01:45:44 2014
From: mvoteiza at udel.edu (Mark Oteiza)
Date: Wed, 09 Apr 2014 19:45:44 -0400
Subject: [gnutls-help] new EC cert: Received alert [51]: Decrypt error
Message-ID: <87txa22hjr.fsf@holos.localdomain>


Hi,

I generated a new EC client certificate to use with IRC.  I can use it with
s_client, but gnutls-cli fails

gnutls 3.2.13
openssl 1.0.1.g

Here's what I've done:

$ openssl ecparam -name secp521r1 -genkey -out key
$ ls
key
$ openssl req -nodes -newkey ec:key -x509 -days 730 -out cert
$ ls
cert  key  privkey.pem
$ cat cert privkey.pem > foo.pem

$ openssl s_client -connect chat.freenode.net:7000 -state -debug
  -no_ssl2 -ign_eof -CAfile /etc/ssl/certs/ca-certificates.crt
  -cert ./foo.pem
CONNECTED(00000003)
depth=2 C = US, ST = UT, L = Salt Lake City, O = The USERTRUST Network,
OU = http://www.usertrust.com, CN = UTN-USERFirst-Hardware
verify return:1
depth=1 C = FR, O = GANDI SAS, CN = Gandi Standard SSL CA
verify return:1
depth=0 OU = Domain Control Validated, OU = Gandi Standard Wildcard SSL,
CN = *.freenode.net
verify return:1
---
Server certificate
<SNIP>
---
No client certificate CA names sent
---
SSL handshake has read 4007 bytes and written 1520 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
<SNIP>
    Compression: 1 (zlib compression)
    Start Time: 1397085510
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
:dickson.freenode.net NOTICE * :*** Looking up your hostname...
# WORKS!

$ gnutls --x509cafile /etc/ssl/certs/ca-certificates.crt --x509certfile
  cert --x509keyfile ./key -p 7000 chat.freenode.net
Processed 167 CA certificate(s).
Processed 1 client X.509 certificates...
Resolving 'chat.freenode.net'...
Connecting to '185.30.166.38:7000'...
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
<SNIP>
- Certificate[1] info:
<SNIP>
- Status: The certificate is trusted.
- Server did not send us any trusted authorities names.
- Successfully sent 1 certificate(s) to server.
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [51]: Decrypt error
*** Handshake has failed
GnuTLS error: A TLS fatal alert has been received.

I attached the full debug output from gnutls-cli.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: log
URL: </pipermail/attachments/20140409/f98c0f2c/attachment-0001.ksh>
-------------- next part --------------

Mark Oteiza

From olaf at zaplinski.de  Thu Apr 10 09:53:28 2014
From: olaf at zaplinski.de (Olaf Zaplinski)
Date: Thu, 10 Apr 2014 09:53:28 +0200
Subject: [gnutls-help]
 =?utf-8?q?=5Bmod=5Fgnutls-devel=5D__need_help_with_?=
 =?utf-8?q?SNI?=
In-Reply-To: <53463BD4.5020501@gmx.net>
References: <4cd300b1b475f74845e41ff906ac7301@mail.zaplinski.de>
 <5345BC2D.3000108@fifthhorseman.net> <5345BFF7.40109@zaplinski.de>
 <53463BD4.5020501@gmx.net>
Message-ID: <b5fc5a5e16f54c9ff987f7f0ea8639d4@mail.zaplinski.de>

Am 2014-04-10 08:36, schrieb Benny Baumann:

> Could you please check if you can install the latest mod_gnutls from
> trunk? Some issues with VHosts were fixed with 0.6 but being
> bleeding-edge might be worth a try.

I could try that, but meanwhile I have found that the wildard 
certificate is the reason. When I disable it, everything is fine.

Cheers
Olaf


From nmav at gnutls.org  Thu Apr 10 12:08:05 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 10 Apr 2014 12:08:05 +0200
Subject: [gnutls-help] new EC cert: Received alert [51]: Decrypt error
In-Reply-To: <87txa22hjr.fsf@holos.localdomain>
References: <87txa22hjr.fsf@holos.localdomain>
Message-ID: <CAJU7za+bSq8Yu7ODz69JxLWiDf5fzJ9SNzrNij9=ynKpfSy4Ow@mail.gmail.com>

On Thu, Apr 10, 2014 at 1:45 AM, Mark Oteiza <mvoteiza at udel.edu> wrote:
>
> Hi,
> I generated a new EC client certificate to use with IRC.  I can use it with
> s_client, but gnutls-cli fails

I don't believe it works with s_client. Possible s_client doesn't send
your key. See below.

> $ openssl ecparam -name secp521r1 -genkey -out key

Here you generate a key and place it in key.

> $ openssl req -nodes -newkey ec:key -x509 -days 730 -out cert

Here you generate another key, and a certificate for that key in cert.

I wouldn't expect any program to work with that combination. GnuTLS
should have warned about the key mismatch though.

regards,
Nikos


From BenBE1987 at gmx.net  Thu Apr 10 08:36:04 2014
From: BenBE1987 at gmx.net (Benny Baumann)
Date: Thu, 10 Apr 2014 08:36:04 +0200
Subject: [gnutls-help] [mod_gnutls-devel]  need help with SNI
In-Reply-To: <5345BFF7.40109@zaplinski.de>
References: <4cd300b1b475f74845e41ff906ac7301@mail.zaplinski.de>
 <5345BC2D.3000108@fifthhorseman.net> <5345BFF7.40109@zaplinski.de>
Message-ID: <53463BD4.5020501@gmx.net>

Hi Olaf,

Am 09.04.2014 23:47, schrieb Olaf Zaplinski:
> Am 09.04.2014 23:31, schrieb Daniel Kahn Gillmor:
>> On 04/09/2014 10:55 AM, Olaf Zaplinski wrote:
>>> I have a problem with SNI.
>>>
>>> I have 3 name based vhosts with GnuTLS.
>>
>> I think you're stalking about apache with mod_gnutls.
>
> Correct.
>
>> I'm sending this response to mod_gnutls-devel at lists.gnutls.org since
>> that's a better place for apache-related mod_gnutls questions.  please
>> follow up there.
>
> OK. But I will keep this list on CC, ok?
>
>> it does sound like there might be an SNI matching issue that we could
>> tighten up (presumably we'd want to take the most-specific match
>> possible, rather than the first-matching cert).
>
> I found a blog mentioning that GnuTLS has problems with subjectAltName:
>
> http://jan-krueger.net/development/mod_gnutls-and-startssl-level-1-certificates-the-problem-and-solution
>
>
> Sounds like my problem: GnuTLS chooses the "wrong" certificate.
Could you please check if you can install the latest mod_gnutls from
trunk? Some issues with VHosts were fixed with 0.6 but being
bleeding-edge might be worth a try.
>
> Olaf
>
Regards,
BenBE.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140410/d25265c1/attachment.sig>

From nmav at gnutls.org  Thu Apr 10 20:28:38 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 10 Apr 2014 20:28:38 +0200
Subject: [gnutls-help] gnutls 3.3.0
Message-ID: <1397154518.15268.7.camel@nomad.lan>

We are proud to announce the next stable GnuTLS release: Version 3.3.0.

GnuTLS is a modern C library that implements the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.  GnuTLS is developed for GNU/Linux, but works on many
Unix-like systems and Windows.

The GnuTLS library is distributed under the terms of the GNU Lesser
General Public License version 2 (or later).  The OpenSSL compatibility
library, the self tests and the command line tools are all distributed
under the GNU General Public License version 3.0 (or later).  The manual
is distributed under the GNU Free Documentation License version 1.3 (or
later).

Special thanks to Red Hat that sponsored several of the new features.

The project page of the library is available at:
  http://www.gnutls.org


What's New
==========
* Version 3.3.0 (released 2014-04-10)

** libgnutls: The initialization of the library was moved to a
constructor. That is, gnutls_global_init() is no longer required
unless linking with a static library or a system that does not
support library constructors.

** libgnutls: static libraries are not built by default.

** libgnutls: PKCS #11 initialization is delayed to first usage.
That avoids long delays in gnutls initialization due to broken PKCS #11
modules.

** libgnutls: The PKCS #11 subsystem is re-initialized "automatically"
on the first PKCS #11 API call after a fork. 

** libgnutls: certificate verification profiles were introduced
that can be specified as flags to verification functions. They
are enumerations in gnutls_certificate_verification_profiles_t
and can be converted to flags for use in a verification function
using GNUTLS_PROFILE_TO_VFLAGS().

** libgnutls: Added the ability to read system-specific initial
keywords, if they are prefixed with '@'. That allows a compile-time
specified configuration file to be used to read pre-configured priority
strings from. That can be used to impose system specific policies.

** libgnutls: Increased the default security level of priority
strings (NORMAL and PFS strings require at minimum a 1008 DH prime), 
and set a verification profile by default.  The LEGACY keyword is 
introduced to set the old defaults.

** libgnutls: Added support for the name constraints PKIX extension.
Currently only DNS names and e-mails are supported (no URIs, IPs
or DNs).

** libgnutls: Security parameter SEC_PARAM_NORMAL was renamed to 
SEC_PARAM_MEDIUM to avoid confusion with the priority string NORMAL.

** libgnutls: Added new API in x509-ext.h to handle X.509 extensions.
This API handles the X.509 extensions in isolation, allowing to parse
similarly formatted extensions stored in other structures.

** libgnutls: When generating DSA keys the macro GNUTLS_SUBGROUP_TO_BITS
can be used to specify a particular subgroup as the number of bits in
gnutls_privkey_generate; e.g., GNUTLS_SUBGROUP_TO_BITS(2048, 256).

** libgnutls: DH parameter generation is now delegated to nettle.
That unfortunately has the side-effect that DH parameters longer than
3072 bits, cannot be generated (not without a nettle update).

** libgnutls: Separated nonce RNG from the main RNG. The nonce
random number generator is based on salsa20/12.

** libgnutls: The buffer alignment provided to crypto backend is
enforced to be 16-byte aligned, when compiled with cryptodev
support. That allows certain cryptodev drivers to operate more
efficiently.

** libgnutls: Return error when a public/private key pair that doesn't
match is set into a credentials structure.

** libgnutls: Depend on p11-kit 0.20.0 or later.

** libgnutls: The new padding (%NEW_PADDING) experimental TLS extension
has been removed. It was not approved by IETF.

** libgnutls: The experimental xssl library is removed from the gnutls
distribution.

** libgnutls: Reduced the number of gnulib modules used in the main
library.

** libgnutls: Added priority string %DISABLE_WILDCARDS.

** libgnutls: Added the more extensible verification function
gnutls_certificate_verify_peers(), that allows checking, in addition
to a peer's DNS hostname, for the key purpose of the end certificate
(via PKIX extended key usage).

** certtool: Timestamps for serial numbers were increased to 8 bytes,
and in batch mode to 12 (appended with 4 random bytes).

** certtool: When no CRL number is provided (or value set to -1), then
a time-based number will be used, similarly to the serial generation
number in certificates.

** certtool: Print the SHA256 fingerprint of a certificate in addition
to SHA1.

** libgnutls: Added --enable-fips140-mode configuration option
(unsupported). That option enables (when running on FIPS140-enabled
system):
 o RSA, DSA and DH key generation as in FIPS-186-4 (using provable
primes)
 o The DRBG-CTR-AES256 deterministic random generator from SP800-90A.
 o Self-tests on initialization on ciphers/MACs, public key algorithms 
   and the random generator.
 o HMAC-SHA256 verification of the library on load.
 o MD5 is included for TLS purposes but cannot be used by the high level
   hashing functions.
 o All ciphers except AES are disabled.
 o All MACs and hashes except GCM and SHA are disabled (e.g., HMAC-MD5).
 o All keys (temporal and long term) are zeroized after use.
 o Security levels are adjusted to the FIPS140-2 recommendations (rather
   than ECRYPT).

** API and ABI modifications:
GNUTLS_VERIFY_DO_NOT_ALLOW_WILDCARDS: Added
gnutls_certificate_verify_peers: Added
gnutls_privkey_generate: Added
gnutls_pkcs11_crt_is_known: Added
gnutls_fips140_mode_enabled: Added
gnutls_sec_param_to_symmetric_bits: Added
gnutls_pubkey_export_ecc_x962: Added (replaces
gnutls_pubkey_get_pk_ecc_x962)
gnutls_pubkey_export_ecc_raw: Added (replaces
gnutls_pubkey_get_pk_ecc_raw)
gnutls_pubkey_export_dsa_raw: Added (replaces
gnutls_pubkey_get_pk_dsa_raw)
gnutls_pubkey_export_rsa_raw: Added (replaces
gnutls_pubkey_get_pk_rsa_raw)
gnutls_pubkey_verify_params: Added
gnutls_privkey_export_ecc_raw: Added
gnutls_privkey_export_dsa_raw: Added
gnutls_privkey_export_rsa_raw: Added
gnutls_privkey_import_ecc_raw: Added
gnutls_privkey_import_dsa_raw: Added
gnutls_privkey_import_rsa_raw: Added
gnutls_privkey_verify_params: Added
gnutls_x509_crt_check_hostname2: Added
gnutls_openpgp_crt_check_hostname2: Added
gnutls_x509_name_constraints_init: Added
gnutls_x509_name_constraints_deinit: Added
gnutls_x509_crt_get_name_constraints: Added
gnutls_x509_name_constraints_add_permitted: Added
gnutls_x509_name_constraints_add_excluded: Added
gnutls_x509_crt_set_name_constraints: Added
gnutls_x509_name_constraints_get_permitted: Added
gnutls_x509_name_constraints_get_excluded: Added
gnutls_x509_name_constraints_check: Added
gnutls_x509_name_constraints_check_crt: Added
gnutls_x509_crl_get_extension_data2: Added
gnutls_x509_crt_get_extension_data2: Added
gnutls_x509_crq_get_extension_data2: Added
gnutls_subject_alt_names_init: Added
gnutls_subject_alt_names_deinit: Added
gnutls_subject_alt_names_get: Added
gnutls_subject_alt_names_set: Added
gnutls_x509_ext_import_subject_alt_names: Added
gnutls_x509_ext_export_subject_alt_names: Added
gnutls_x509_crl_dist_points_init: Added
gnutls_x509_crl_dist_points_deinit: Added
gnutls_x509_crl_dist_points_get: Added
gnutls_x509_crl_dist_points_set: Added
gnutls_x509_ext_import_crl_dist_points: Added
gnutls_x509_ext_export_crl_dist_points: Added
gnutls_x509_ext_import_name_constraints: Added
gnutls_x509_ext_export_name_constraints: Added
gnutls_x509_aia_init: Added
gnutls_x509_aia_deinit: Added
gnutls_x509_aia_get: Added
gnutls_x509_aia_set: Added
gnutls_x509_ext_import_aia: Added
gnutls_x509_ext_export_aia: Added
gnutls_x509_ext_import_subject_key_id: Added
gnutls_x509_ext_export_subject_key_id: Added
gnutls_x509_ext_export_authority_key_id: Added
gnutls_x509_ext_import_authority_key_id: Added
gnutls_x509_aki_init: Added
gnutls_x509_aki_get_id: Added
gnutls_x509_aki_get_cert_issuer: Added
gnutls_x509_aki_set_id: Added
gnutls_x509_aki_set_cert_issuer: Added
gnutls_x509_aki_deinit: Added
gnutls_x509_ext_import_private_key_usage_period: Added
gnutls_x509_ext_export_private_key_usage_period: Added
gnutls_x509_ext_import_basic_constraints: Added
gnutls_x509_ext_export_basic_constraints: Added
gnutls_x509_ext_import_key_usage: Added
gnutls_x509_ext_export_key_usage: Added
gnutls_x509_ext_import_proxy: Added
gnutls_x509_ext_export_proxy: Added
gnutls_x509_policies_init: Added
gnutls_x509_policies_deinit: Added
gnutls_x509_policies_get: Added
gnutls_x509_policies_set: Added
gnutls_x509_ext_import_policies: Added
gnutls_x509_ext_export_policies: Added
gnutls_x509_key_purpose_init: Added
gnutls_x509_key_purpose_deinit: Added
gnutls_x509_key_purpose_set: Added
gnutls_x509_key_purpose_get: Added
gnutls_x509_ext_import_key_purposes: Added
gnutls_x509_ext_export_key_purposes: Added
gnutls_digest_self_test: Added (conditionally)
gnutls_mac_self_test: Added (conditionally)
gnutls_pk_self_test: Added (conditionally)
gnutls_cipher_self_test: Added (conditionally)
gnutls_global_set_mem_functions: Deprecated


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

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

Here are the XZ and LZIP compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.0.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.0.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.0.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.0.tar.lz.sig

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

regards,
Nikos




From mvoteiza at udel.edu  Fri Apr 11 04:39:25 2014
From: mvoteiza at udel.edu (Mark Oteiza)
Date: Thu, 10 Apr 2014 22:39:25 -0400
Subject: [gnutls-help] new EC cert: Received alert [51]: Decrypt error
References: <87txa22hjr.fsf@holos.localdomain>
 <CAJU7za+bSq8Yu7ODz69JxLWiDf5fzJ9SNzrNij9=ynKpfSy4Ow@mail.gmail.com>
Message-ID: <87ha60lhcy.fsf@holos.localdomain>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> On Thu, Apr 10, 2014 at 1:45 AM, Mark Oteiza <mvoteiza at udel.edu> wrote:
>>
>> Hi,
>> I generated a new EC client certificate to use with IRC.  I can use it with
>> s_client, but gnutls-cli fails
>
> I don't believe it works with s_client. Possible s_client doesn't send
> your key. See below.

I believe my key is sent with s_client, but not so with
gnutls-cli. s_client output:

$ openssl s_client -connect chat.freenode.net:7000 -state -debug
  -no_ssl2 -ign_eof -CAfile /etc/ssl/certs/ca-certificates.crt
  -cert foo.pem
...
SSL_connect:SSLv3 read server certificate request A
SSL_connect:SSLv3 read server done A
write to 0x10b6410 [0x11c1900] (654 bytes => 654 (0x28E))
0000 - 16 03 01 02 89 0b 00 02-85 00 02 82 00 02 7f 30   ...............0
<SNIP>
0280 - e8 60 f0 36 a3 e3 2f 66-36 4b 64 bb f2 91         .`.6../f6Kd...
SSL_connect:SSLv3 write client certificate A
write to 0x10b6410 [0x11c1900] (139 bytes => 139 (0x8B))
0000 - 16 03 01 00 86 10 00 00-82 00 80 99 db 85 34 14   ..............4.
<SNIP>
0090 - be ef f1 7c 54 91                                 ...|T.
SSL_connect:SSLv3 write certificate verify A
write to 0x10b6410 [0x11c1900] (6 bytes => 6 (0x6))
0000 - 14 03 01 00 01 01                                 ......
SSL_connect:SSLv3 write change cipher spec A
write to 0x10b6410 [0x11c1900] (53 bytes => 53 (0x35))
0000 - 16 03 01 00 30 59 90 0c-39 eb 85 12 66 c2 d7 ff   ....0Y..9...f...
<SNIP>
0030 - 96 1d 1b 25 6b                                    ...%k
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
read from 0x10b6410 [0x11b7b33] (5 bytes => 5 (0x5))
0000 - 16 03 01 03 3a                                    ....:
read from 0x10b6410 [0x11b7b38] (826 bytes => 826 (0x33A))
0000 - 04 00 03 36 00 00 00 00-03 30 cd da 47 9b 4d 44   ...6.....0..G.MD
<SNIP>
0330 - af 38 7b e6 5d 7b 74 cd-44 46                     .8{.]{t.DF
SSL_connect:SSLv3 read server session ticket A
read from 0x10b6410 [0x11b7b33] (5 bytes => 5 (0x5))
0000 - 14 03 01 00 01                                    .....
read from 0x10b6410 [0x11b7b38] (1 bytes => 1 (0x1))
0000 - 01                                                .
read from 0x10b6410 [0x11b7b33] (5 bytes => 5 (0x5))
0000 - 16 03 01 00 30                                    ....0
read from 0x10b6410 [0x11b7b38] (48 bytes => 48 (0x30))
0000 - c9 f8 8c 9e 31 e6 5a 7b-04 e2 17 8b ff 05 a6 35   ....1.Z{.......5
0010 - 7d 30 8e a3 80 69 8d d6-c0 41 1e 19 68 ad b6 cb   }0...i...A..h...
0020 - c0 35 9e 7c e6 a3 6c 1f-9d f2 3c 07 8f 75 68 bf   .5.|..l...<..uh.
SSL_connect:SSLv3 read finished A
---
Certificate chain
 0 s:/OU=Domain Control Validated/OU=Gandi Standard Wildcard
 SSL/CN=*.freenode.net
    i:/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA
     1 s:/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA
        i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
 Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
 ---
 Server certificate
 -----BEGIN CERTIFICATE-----
<SNIP>
 -----END CERTIFICATE-----
 subject=/OU=Domain Control Validated/OU=Gandi Standard Wildcard
 SSL/CN=*.freenode.net
 issuer=/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA
 ---
 No client certificate CA names sent
 ---
 SSL handshake has read 3965 bytes and written 1519 bytes
 ---
...

>> $ openssl req -nodes -newkey ec:key -x509 -days 730 -out cert
>
> Here you generate another key,

privkey.pem

> and a certificate for that key in cert.

Right, these two files which I combine into foo.pem and feed to s_client.

> I wouldn't expect any program to work with that combination. GnuTLS
> should have warned about the key mismatch though.
>
> regards,
> Nikos

I see now that the combinations I used are different for s_client than
gnutls-cli; totally wrong for the latter.  Thanks for pointing that out.
I am still unsure of what to do with gnutls-cli.  What if I do instead

$ gnutls-cli --debug 9999 --x509cafile /etc/ssl/certs/ca-certificates.crt
  --x509certfile foo.pem -p 7000 chat.freenode.net
|<2>| Intel SSSE3 was detected
|<2>| Intel AES accelerator was detected
|<2>| Intel GCM accelerator was detected
|<2>| p11: loaded provider 'p11-kit-trust'
|<2>| ASSERT: pkcs11.c:431
Processed 167 CA certificate(s).
Resolving 'chat.freenode.net'...
Connecting to '82.96.64.4:7000'...
|<4>| REC[0x13f1330]: Allocating epoch #0
<SNIP>
- Successfully sent 0 certificate(s) to server.
...

or perhaps:

$ gnutls-cli --debug 9999 --x509cafile /etc/ssl/certs/ca-certificates.crt
  --x509certfile cert --x509keyfile privkey.pem -p 7000 chat.freenode.net
|<2>| Intel SSSE3 was detected
|<2>| Intel AES accelerator was detected
|<2>| Intel GCM accelerator was detected
|<2>| p11: loaded provider 'p11-kit-trust'
|<2>| ASSERT: pkcs11.c:431
Processed 167 CA certificate(s).
|<2>| ASSERT: x509_b64.c:299
|<2>| Could not find '-----BEGIN RSA PRIVATE KEY'
|<2>| ASSERT: x509_b64.c:299
|<2>| Could not find '-----BEGIN DSA PRIVATE KEY'
|<2>| ASSERT: x509_b64.c:299
|<2>| Could not find '-----BEGIN EC PRIVATE KEY'
|<2>| ASSERT: privkey.c:481
|<2>| Falling back to PKCS #8 key decoding
|<2>| ASSERT: privkey.c:282
|<2>| ASSERT: privkey_pkcs8.c:1049
|<2>| ASSERT: privkey_pkcs8.c:1192
|<2>| ASSERT: privkey_pkcs8.c:987
|<2>| ASSERT: privkey_pkcs8.c:1292
|<2>| ASSERT: privkey.c:628
|<2>| ASSERT: privkey.c:282
|<2>| ASSERT: privkey_pkcs8.c:1049
|<2>| ASSERT: privkey_pkcs8.c:1192
|<2>| ASSERT: privkey_pkcs8.c:987
|<2>| ASSERT: privkey_pkcs8.c:1292
|<2>| ASSERT: x509_b64.c:299
|<2>| Could not find '-----BEGIN PKCS12'
|<2>| ASSERT: pkcs12.c:207
|<2>| ASSERT: privkey.c:569
|<2>| ASSERT: privkey_openssl.c:150
|<2>| ASSERT: privkey.c:652
|<2>| ASSERT: gnutls_privkey.c:958
*** Error loading url: Error in parsing.


From nmav at gnutls.org  Fri Apr 11 14:18:23 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 11 Apr 2014 14:18:23 +0200
Subject: [gnutls-help] new EC cert: Received alert [51]: Decrypt error
In-Reply-To: <87ha60lhcy.fsf@holos.localdomain>
References: <87txa22hjr.fsf@holos.localdomain>
 <CAJU7za+bSq8Yu7ODz69JxLWiDf5fzJ9SNzrNij9=ynKpfSy4Ow@mail.gmail.com>
 <87ha60lhcy.fsf@holos.localdomain>
Message-ID: <CAJU7zaJ1GdjajeqNErWSDSZX-bx0cm2j=WMNNpu5nQ13m5XJ8Q@mail.gmail.com>

On Fri, Apr 11, 2014 at 4:39 AM, Mark Oteiza <mvoteiza at udel.edu> wrote:

>>> $ openssl req -nodes -newkey ec:key -x509 -days 730 -out cert
>> Here you generate another key,
> privkey.pem
>> and a certificate for that key in cert.
> Right, these two files which I combine into foo.pem and feed to s_client.
>> I wouldn't expect any program to work with that combination. GnuTLS
>> should have warned about the key mismatch though.
> I see now that the combinations I used are different for s_client than
> gnutls-cli; totally wrong for the latter.  Thanks for pointing that out.
> I am still unsure of what to do with gnutls-cli.

I see. The format of the private key generated by
openssl ecparam -name secp521r1 -genkey -out key
is different than the format generated by:
openssl req -nodes -newkey ec:key -x509 -days 730 -out cert

The latter is an EC private key encoded using PKCS #8 (BEGIN PRIVATE
KEY header), but does not contain the curve that corresponds to the
key.

openssl asn1parse -inform der -in /tmp/der
    0:d=0  hl=3 l= 211 cons: SEQUENCE
    3:d=1  hl=2 l=   1 prim: INTEGER           :01
    6:d=1  hl=2 l=  66 prim: OCTET STRING      [HEX
DUMP]:01572E926009A1992AD2D04FF4C613625001053B3F5DB44BF43D3CCFE87E5A18104118E162EB7D38B9B1D90BDE72596FF25CF3C6F4FF350CB64545E3DD24F34CDD3F
   74:d=1  hl=3 l= 137 cons: cont [ 1 ]
   77:d=2  hl=3 l= 134 prim: BIT STRING

It does however, place the curve name on the privateKeyAlgorithm
parameters. I guess we would have to parse this format as well.

The former (BEGIN EC PRIVATE KEY header) on the other hand does
contain it (sec521r1).
$ openssl asn1parse -in key
    0:d=0  hl=3 l= 220 cons: SEQUENCE
    3:d=1  hl=2 l=   1 prim: INTEGER           :01
    6:d=1  hl=2 l=  66 prim: OCTET STRING      [HEX
DUMP]:01D10E089A647F43368B4DCA0BBB3AB4BD5036F2146540A18B5AAF60EB22601BB7424968821C51222535A3A2CB7977F15E1F7D92B0852FFF76F6DEC7FA24E6C16DD9
   74:d=1  hl=2 l=   7 cons: cont [ 0 ]
   76:d=2  hl=2 l=   5 prim: OBJECT            :secp521r1
   83:d=1  hl=3 l= 137 cons: cont [ 1 ]
   86:d=2  hl=3 l= 134 prim: BIT STRING

That's the reason gnutls fails to parse the PKCS #8 key. What I can
suggest though, is to either use certtool to generate the private key
and certificate, or try to generate a non-PKCS #8 EC key file with
openssl that corresponds to your certificate.

regards,
Nikos


From mk at cognitivedissonance.ca  Sat Apr 12 16:24:45 2014
From: mk at cognitivedissonance.ca (MK)
Date: Sat, 12 Apr 2014 10:24:45 -0400
Subject: [gnutls-help] 2.x 3.x API compatibility
In-Reply-To: <CAJU7zaK6McSw+TnJ_WpMWJQi4ydnjq7Csf3favpnw-Mg=9K0Rg@mail.gmail.com>
References: <20140331120027.8552377df4cbf8d9cda424ca@cognitivedissonance.ca>
 <CAJU7zaLqtitPWaFBA33-WCM6fGTYYa5kjGXG4eoGZYjtAXcBbA@mail.gmail.com>
 <20140407182527.21c017a0c6fd40fa120e9d6a@cognitivedissonance.ca>
 <CAJU7zaK6McSw+TnJ_WpMWJQi4ydnjq7Csf3favpnw-Mg=9K0Rg@mail.gmail.com>
Message-ID: <20140412102445.312f3ba4999c856622261b25@cognitivedissonance.ca>

Hi Niko,

I accidentally replied off list last time, but I've put this back on
because it may contain something of use to raspbian users in posterity.

On Wed, 9 Apr 2014 11:29:41 +0200
Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:

> On Tue, Apr 8, 2014 at 12:25 AM, MK <mk at cognitivedissonance.ca> wrote:
> 
> > make[3]: Entering directory `/usr/local/src/gnutls-3.2.12/src'
> >   CCLD     psktool
> > ../lib/.libs/libgnutls.so: undefined reference to
> > `nettle_umac96_update' ../lib/.libs/libgnutls.so: undefined
> > reference to `nettle_umac96_set_key' ../lib/.libs/libgnutls.so:
> > undefined reference to
> > `nettle_umac128_update' ../lib/.libs/libgnutls.so: undefined
> 
> This is the same issue. You should use ldd to libgnutls.so in order to
> see to which library it is actually linked to.

You're right.  There is of course an older distro version of
nettle installed, but I did not think this would take precedence as,
e.g., `pkg-config --libs nettle` returns `-L/usr/local/lib -lnettle`
and the only version there is 2.7.1, which is why ./configure passed
for gnuTLS 3.2.12 in the first place. But this is obviously unrelated
to the runtime linker path.

I thought that was strange, though (shouldn't /usr/local always take
precedence?) so I checked /etc/ld.so.conf.d and found:

arm-linux-gnueabihf.conf
libc.conf

The former, presumably unique to the raspbian variant of wheezy, would
be processed first in lexicographical order and adds 
/usr/lib/arm-linux-gnueabihf, where the distro nettle is. The latter
contains /usr/local/lib. I renamed these:

10-libc.conf  
20-arm-linux-gnueabihf.conf

Ran ldconfig and presto, 3.2.12 passes make check and make install and
I get a /usr/local/bin/certtool.

MK

-- 
"Enthusiasm is not the enemy of the intellect." (said of Irving Howe)


From polinaa at image-vault.com  Wed Apr 16 20:20:40 2014
From: polinaa at image-vault.com (Polina Abramov)
Date: Wed, 16 Apr 2014 18:20:40 +0000
Subject: [gnutls-help] Hanshake fails with "Error in the pull function"
Message-ID: <ca344bbef9944d7d8eede3b95c3a53fc@DM2PR08MB527.namprd08.prod.outlook.com>

Hi All,

I am fairly new to TLS/SSL in general and to GnuTLS in particular so this might be a very basic question, but  I don't seem to be able to figure it out by myself.

I am trying to implement a basic TLS/SSL client with anonymous authentication. I am using the code samples from GnuTLS Documentations and trying to connect to gnutls-serv utility with my client.
I run the utility with -a flag to disable  requesting client certificate.

The problem is that the handshake fails. The client prints out "GnuTLS error: Insufficient credentials for that request."
The server's outputs "Error in handshake Error: Error in the pull function.".

Below I am pasting the complete output from server. Can anybody help me out here?


* Accepted connection from IPv4 127.0.0.1 port 64072 on Wed Apr 16 13:33:12 2014

|<2>| ASSERT: gnutls_constate.c:583
|<4>| REC[027CCBE0]: Allocating epoch #1
|<2>| ASSERT: gnutls_buffers.c:1073
|<7>| READ: -1 returned from 00000005, errno=108 gerrno=0
|<2>| ASSERT: gnutls_buffers.c:333
|<2>| ASSERT: gnutls_buffers.c:518
|<2>| ASSERT: gnutls_record.c:1045
|<2>| ASSERT: gnutls_record.c:1165
|<2>| ASSERT: gnutls_buffers.c:1324
|<2>| ASSERT: gnutls_handshake.c:1412
|<2>| ASSERT: gnutls_handshake.c:3044
Error in handshake
Error: Error in the pull function.
|<4>| REC: Sending Alert[2|80] - Internal error
|<4>| REC[027CCBE0]: Preparing Packet Alert(21) with length: 2 and min pad: 0
|<9>| ENC[027CCBE0]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<7>| WRITE: enqueued 7 bytes for 00000005. Total 7 bytes.
|<7>| WRITE FLUSH: 7 bytes in buffer.
|<2>| ASSERT: gnutls_buffers.c:408
|<2>| errno: 0
|<2>| ASSERT: gnutls_buffers.c:192
|<7>| WRITE error: code -53, 7 bytes left.
|<2>| ASSERT: gnutls_buffers.c:650
|<2>| ASSERT: gnutls_record.c:570
|<2>| ASSERT: gnutls_record.c:342
|<4>| REC[027CCBE0]: Start of epoch cleanup
|<4>| REC[027CCBE0]: End of epoch cleanup
|<4>| REC[027CCBE0]: Epoch #0 freed
|<4>| REC[027CCBE0]: Epoch #1 freed

Thanks,
P.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140416/439ed83b/attachment.html>

From jens.lechtenboerger at fsfe.org  Thu Apr 17 19:33:39 2014
From: jens.lechtenboerger at fsfe.org (Jens Lechtenboerger)
Date: Thu, 17 Apr 2014 19:33:39 +0200
Subject: [gnutls-help] GnuTLS with TOFU verifies public keys,
	not certificates
Message-ID: <8638hb5098.fsf@informationelle-selbstbestimmung-im-internet.de>

Hi there,

as it took me a while to figure this out, I?d like to share this.

One of my e-mail providers changed an IMAP certificate, and
mail-notification warned me about the new certificate with an
unknown fingerprint.  Both certificates are issued by different CAs.

Surprisingly, though, gnutls-cli with option --tofu did not complain
at all (same for --strict-tofu).

It turns out that both certificates contain the same public key.
(Why would somebody do this?)

As gnutls-cli stores only the public key in ~/.gnutls/known_hosts,
but nothing about the certificate, it cannot detect any difference.
I don?t see any security issue here, but I suggest to extend the
documentation, in particular, the man page of gnutls-cli:

For --tofu, currently ?in addition to certificate authentication?:
This should probably read ?instead of certificate authentication.?
Afterwards emphasize: ?Note that public keys are recorded, not
certificates.?

For --strict-tofu: ?certificate? needs to be replaced with ?public
key? twice.

Alternatively, should ~/.gnutls/known_hosts also store the
certificate?s fingerprint to detect such changes?

Best wishes
Jens



From dkg at fifthhorseman.net  Thu Apr 17 20:44:57 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 17 Apr 2014 14:44:57 -0400
Subject: [gnutls-help] GnuTLS with TOFU verifies public keys,
	not certificates
In-Reply-To: <8638hb5098.fsf@informationelle-selbstbestimmung-im-internet.de>
References: <8638hb5098.fsf@informationelle-selbstbestimmung-im-internet.de>
Message-ID: <53502129.3000707@fifthhorseman.net>

On 04/17/2014 01:33 PM, Jens Lechtenboerger wrote:

> One of my e-mail providers changed an IMAP certificate, and
> mail-notification warned me about the new certificate with an
> unknown fingerprint.  Both certificates are issued by different CAs.
> 
> Surprisingly, though, gnutls-cli with option --tofu did not complain
> at all (same for --strict-tofu).
> 
> It turns out that both certificates contain the same public key.
> (Why would somebody do this?)

presumably they did this because they have a key that they do not think
has been compromised, but their certificate expired.

> As gnutls-cli stores only the public key in ~/.gnutls/known_hosts,
> but nothing about the certificate, it cannot detect any difference.
> I don?t see any security issue here,

I agree that there is no security issue.  Using TOFU *should* use the
public key, not the certificate; otherwise, it's guaranteed to fail when
the certificate expires, which seems kind of pointless for a
key-continuity-based approach like TOFU.

> but I suggest to extend the
> documentation, in particular, the man page of gnutls-cli:
> 
> For --tofu, currently ?in addition to certificate authentication?:
> This should probably read ?instead of certificate authentication.?

I agree that this change in documentation would match the current
behavior.  I'm wondering, though, whether we want to change the behavior
to match the documentation.   Both --tofu and --dane say "in addition to
certificate authentication", but only --dane seems to accept standard
X.509 certificate authentication as well.

even using "gnutls-cli --ca-verification --tofu www.example.org" doesn't
use certificate verification.

> Afterwards emphasize: ?Note that public keys are recorded, not
> certificates.?
> 
> For --strict-tofu: ?certificate? needs to be replaced with ?public
> key? twice.


The above changes seem reasonable to me.

> Alternatively, should ~/.gnutls/known_hosts also store the
> certificate?s fingerprint to detect such changes?

i don't think this is a good idea.  what would the benefit be?

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140417/fefc9b44/attachment-0001.sig>

From nmav at gnutls.org  Thu Apr 17 21:23:32 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 17 Apr 2014 21:23:32 +0200
Subject: [gnutls-help] GnuTLS with TOFU verifies public keys,
 not certificates
In-Reply-To: <53502129.3000707@fifthhorseman.net>
References: <8638hb5098.fsf@informationelle-selbstbestimmung-im-internet.de>
 <53502129.3000707@fifthhorseman.net>
Message-ID: <1397762612.16950.8.camel@nomad.lan>

On Thu, 2014-04-17 at 14:44 -0400, Daniel Kahn Gillmor wrote:

> > but I suggest to extend the
> > documentation, in particular, the man page of gnutls-cli:
> > 
> > For --tofu, currently ?in addition to certificate authentication?:
> > This should probably read ?instead of certificate authentication.?
> 
> I agree that this change in documentation would match the current
> behavior.  I'm wondering, though, whether we want to change the behavior
> to match the documentation.   Both --tofu and --dane say "in addition to
> certificate authentication", but only --dane seems to accept standard
> X.509 certificate authentication as well.
> even using "gnutls-cli --ca-verification --tofu www.example.org" doesn't
> use certificate verification.

Actually it does, although it only prints the verification failure. It
seems though that the certificate information is printed twice and thus
the failure isn't easily seen.

The idea was to allow the user to trust a self-signed certificate even
if PKI failed. That means of course that tofu takes precedence over PKI
and maybe that should be better documented.

> > Alternatively, should ~/.gnutls/known_hosts also store the
> > certificate?s fingerprint to detect such changes?
> i don't think this is a good idea.  what would the benefit be?

I agree. A certificate contains a lot of information that may change
over time such as e-mail, alternative dns names, legal name etc. (in
addition to expiration dates).

regards,
Nikos




From nmav at gnutls.org  Thu Apr 17 21:30:40 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 17 Apr 2014 21:30:40 +0200
Subject: [gnutls-help] GnuTLS with TOFU verifies public keys,
 not certificates
In-Reply-To: <8638hb5098.fsf@informationelle-selbstbestimmung-im-internet.de>
References: <8638hb5098.fsf@informationelle-selbstbestimmung-im-internet.de>
Message-ID: <1397763040.16950.12.camel@nomad.lan>

On Thu, 2014-04-17 at 19:33 +0200, Jens Lechtenboerger wrote:
> Hi there,
> 
> as it took me a while to figure this out, I?d like to share this.
> 
> One of my e-mail providers changed an IMAP certificate, and
> mail-notification warned me about the new certificate with an
> unknown fingerprint.  Both certificates are issued by different CAs.
> 
> Surprisingly, though, gnutls-cli with option --tofu did not complain
> at all (same for --strict-tofu).

Hello Jens,
 In addition to what Daniel mentioned, I'd like to note that in TOFU you
cannot trust the certificate nor any information within it. If for
example the certificate provides alternative names, it would be a
mistake to consider them, and it is only associated for the host you
connected to (remember in tofu there are no signatures considered, so
the certificate is just blurb the server sent). That's why it is not
needed to store it nor complain if it changes.

regards,
Nikos




From dkg at fifthhorseman.net  Thu Apr 17 21:52:21 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 17 Apr 2014 15:52:21 -0400
Subject: [gnutls-help] Combining certificate verification mechanisms [was:
 Re: GnuTLS with TOFU verifies public keys, not certificates]
In-Reply-To: <1397762612.16950.8.camel@nomad.lan>
References: <8638hb5098.fsf@informationelle-selbstbestimmung-im-internet.de>	
 <53502129.3000707@fifthhorseman.net> <1397762612.16950.8.camel@nomad.lan>
Message-ID: <535030F5.2060702@fifthhorseman.net>

On 04/17/2014 03:23 PM, Nikos Mavrogiannopoulos wrote:
> On Thu, 2014-04-17 at 14:44 -0400, Daniel Kahn Gillmor wrote:

>> I agree that this change in documentation would match the current
>> behavior.  I'm wondering, though, whether we want to change the behavior
>> to match the documentation.   Both --tofu and --dane say "in addition to
>> certificate authentication", but only --dane seems to accept standard
>> X.509 certificate authentication as well.
>> even using "gnutls-cli --ca-verification --tofu www.example.org" doesn't
>> use certificate verification.
> 
> Actually it does, although it only prints the verification failure. It
> seems though that the certificate information is printed twice and thus
> the failure isn't easily seen.

hm, really?  let me be more concrete than example.org.  the following
connects cleanly for me, with no complaints about certificate validation:

 gnutls-cli www.google.com

but if i connect using:

 gnutls-cli --tofu www.google.com

then i do see the certificate validation remark ("Status: The
certificate is trusted.") but i am *also* prompted with the TOFU prompt.
 If i say "no" on the TOFU prompt, the connection fails:

Host www.google.com (https) has never been contacted before.
Its certificate is valid for www.google.com.
Are you sure you want to trust it? (y/N): n
*** Fatal error: Error in the certificate.
*** Handshake has failed
GnuTLS error: Error in the certificate.
1 dkg at alice:~$

This seems like an odd combination, and *doesn't* match the behavior
when i use --dane.

it's also interesting to note the behavior when i use
--no-ca-verification without either --tofu or --dane: no cert check is
done at all, but the connection still goes through without a complaint.
 this seems like "failing open", and it isn't what i'd have expected.

it seems to me like we've got three different possible ways to verify a
certificate:

 * DANE
 * X.509 CA verification (and OpenPGP CA Verification for RFC 6091)
 * TOFU

each of these mechanisms can return "valid" or "not valid", right?  (or
should we consider that TOFU could return "valid", "unknown", and "does
not match known key"?)

how should these mechanisms be combined in a principled and predictable way?


	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140417/d455ca5f/attachment.sig>

From jens.lechtenboerger at fsfe.org  Thu Apr 17 22:11:07 2014
From: jens.lechtenboerger at fsfe.org (Jens Lechtenboerger)
Date: Thu, 17 Apr 2014 22:11:07 +0200
Subject: [gnutls-help] GnuTLS with TOFU verifies public keys,
	not certificates
References: <8638hb5098.fsf@informationelle-selbstbestimmung-im-internet.de>
 <53502129.3000707@fifthhorseman.net>
Message-ID: <86oazzsomc.fsf@informationelle-selbstbestimmung-im-internet.de>

On Thu, 17 Apr 2014 14:44:57 -0400, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> said:

> On 04/17/2014 01:33 PM, Jens Lechtenboerger wrote:
>> It turns out that both certificates contain the same public key.
>> (Why would somebody do this?)

> presumably they did this because they have a key that they do not
> think has been compromised, but their certificate expired.

Both certificates were created this January, the previous one valid
for one year, the one to which they switched valid for three years.

Thanks for your input
Jens



From jens.lechtenboerger at fsfe.org  Thu Apr 17 22:28:56 2014
From: jens.lechtenboerger at fsfe.org (Jens Lechtenboerger)
Date: Thu, 17 Apr 2014 22:28:56 +0200
Subject: [gnutls-help] Combining certificate verification mechanisms
	[was: Re: GnuTLS with TOFU verifies public keys, not certificates]
References: <8638hb5098.fsf@informationelle-selbstbestimmung-im-internet.de>
 <53502129.3000707@fifthhorseman.net>
 <1397762612.16950.8.camel@nomad.lan>
 <535030F5.2060702@fifthhorseman.net>
Message-ID: <86eh0vsnsn.fsf@informationelle-selbstbestimmung-im-internet.de>

On Thu, 17 Apr 2014 14:44:57 -0400, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> said:

> but if i connect using:
>
>  gnutls-cli --tofu www.google.com
>
> then i do see the certificate validation remark ("Status: The
> certificate is trusted.") but i am *also* prompted with the TOFU prompt.
>  If i say "no" on the TOFU prompt, the connection fails:
>
> Host www.google.com (https) has never been contacted before.
> Its certificate is valid for www.google.com.
> Are you sure you want to trust it? (y/N): n
> *** Fatal error: Error in the certificate.
> *** Handshake has failed
> GnuTLS error: Error in the certificate.
> 1 dkg at alice:~$

The above is precisely what I want.

Nikos wrote that the idea of TOFU was to trust even if PKI fails.

I use TOFU as I consider PKI to be broken.  Why should I trust PKI
with its assertion ?Its certificate is valid for www.google.com??

Best wishes
Jens



From nmav at gnutls.org  Thu Apr 17 22:41:40 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 17 Apr 2014 22:41:40 +0200
Subject: [gnutls-help] Combining certificate verification mechanisms
 [was: Re: GnuTLS with TOFU verifies public keys, not certificates]
In-Reply-To: <535030F5.2060702@fifthhorseman.net>
References: <8638hb5098.fsf@informationelle-selbstbestimmung-im-internet.de>
 <53502129.3000707@fifthhorseman.net> <1397762612.16950.8.camel@nomad.lan>
 <535030F5.2060702@fifthhorseman.net>
Message-ID: <1397767300.23550.5.camel@nomad.lan>

On Thu, 2014-04-17 at 15:52 -0400, Daniel Kahn Gillmor wrote:

> > Actually it does, although it only prints the verification failure. It
> > seems though that the certificate information is printed twice and thus
> > the failure isn't easily seen.
> hm, really?  let me be more concrete than example.org.  the following
> connects cleanly for me, with no complaints about certificate validation:
> 
>  gnutls-cli www.google.com
> 
> but if i connect using:
> 
>  gnutls-cli --tofu www.google.com
> 
> then i do see the certificate validation remark ("Status: The
> certificate is trusted.") but i am *also* prompted with the TOFU prompt.
>  If i say "no" on the TOFU prompt, the connection fails:
> Host www.google.com (https) has never been contacted before.
> Its certificate is valid for www.google.com.
> Are you sure you want to trust it? (y/N): n
> *** Fatal error: Error in the certificate.
> *** Handshake has failed
> GnuTLS error: Error in the certificate.
> 1 dkg at alice:~$

> This seems like an odd combination,

Why? In tofu the certificate authentication is pretty much advisory that
allows you to decide whether to accept or not.

>  and *doesn't* match the behavior
> when i use --dane.

That's true. In dane there is no user input so the PKI certification
can't be advisory. Nevertheless, if you have some better suggestion feel
free to propose it. That behavior isn't written in stone, and we can
still change the behavior of gnutls-cli in 3.3.0.


> it's also interesting to note the behavior when i use
> --no-ca-verification without either --tofu or --dane: no cert check is
> done at all, but the connection still goes through without a complaint.
>  this seems like "failing open", and it isn't what i'd have expected.

What would you have expected?

> it seems to me like we've got three different possible ways to verify a
> certificate:
>  * DANE
>  * X.509 CA verification (and OpenPGP CA Verification for RFC 6091)
>  * TOFU
> each of these mechanisms can return "valid" or "not valid", right?  (or
> should we consider that TOFU could return "valid", "unknown", and "does
> not match known key"?)

DANE and PKI are binary and automatic. TOFU has three states and is
interactive.

regards,
Nikos




From nmav at gnutls.org  Sat Apr 19 13:15:59 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 19 Apr 2014 13:15:59 +0200
Subject: [gnutls-help] gnutls 3.3.1
Message-ID: <1397906159.15205.1.camel@nomad.lan>

Hello,
 I've just released gnutls 3.3.1. This is a bugfix release on the next stable branch.


* Version 3.3.1 (released 2014-04-19)

** libgnutls: Enforce more strict checks to heartbeat messages
concerning padding and payload. Suggested by Peter Dettman.

** libgnutls: Allow decoding PKCS #8 files with ECC parameters
from openssl.

** libgnutls: Several small bug fixes found by coverity.

** libgnutls: The conditionally available self-test functions
were moved to self-test.h.

** libgnutls: Fixed issue with the check of incoming data when two
different recv and send pointers have been specified. Reported and
investigated by JMRecio.

** libgnutls: Fixed issue in the RSA-PSK key exchange, which would 
result to illegal memory access if a server hint was provided. Reported
by Andr? Klitzing.

** libgnutls: Fixed client memory leak in the PSK key exchange, if a
server hint was provided.

** libgnutls: Corrected the *get_*_othername_oid() functions.

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


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

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

Here are the XZ and LZIP compressed sources:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.1.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.1.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.1.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.1.tar.lz.sig

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

regards,
Nikos




From mkletzan at redhat.com  Tue Apr 22 16:01:20 2014
From: mkletzan at redhat.com (Martin Kletzander)
Date: Tue, 22 Apr 2014 16:01:20 +0200
Subject: [gnutls-help] Issues with both gnutls 3.3.0 and 3.3.1
Message-ID: <20140422140120.GC21999@wheatley>

Hello,

I recently upgraded to gnutls-3.3.0 (from 3.2.13) and found out that
there are 2 FDs leaked (read-only, pointing to /dev/urandom) into some
processes.  Looking at the code it looks like there should be
FD_CLOEXEC set, but it leaks through anyway.  The backtrace when
opening those files is:

#0  open64 () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007ffff60f20a7 in open (__oflag=0, __path=0x7ffff61031b9 "/dev/urandom")
    at /usr/include/bits/fcntl2.h:53
#2  _rnd_system_entropy_init () at rnd-common.c:192
#3  0x00007ffff60f29b0 in wrap_nettle_rnd_init (ctx=<optimized out>) at rnd.c:231
#4  0x00007ffff6055cce in _gnutls_rnd_init () at random.c:49
#5  0x00007ffff6047714 in gnutls_global_init () at gnutls_global.c:251
#6  0x00007ffff6025fdb in lib_init () at gnutls_global.c:385
#7  0x00007ffff7dea94b in call_init (l=<optimized out>, argc=argc at entry=1,
    argv=argv at entry=0x7fffffffe368, env=env at entry=0x7fffffffe378) at dl-init.c:78
#8  0x00007ffff7deaa5c in call_init (env=0x7fffffffe378, argv=0x7fffffffe368, argc=1,
    l=<optimized out>) at dl-init.c:36
#9  _dl_init (main_map=0x7ffff7ffe148, argc=1, argv=0x7fffffffe368, env=0x7fffffffe378)
    at dl-init.c:126
#10 0x00007ffff7ddc2da in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#11 0x0000000000000001 in ?? ()
#12 0x00007fffffffe67a in ?? ()
#13 0x0000000000000000 in ?? ()

No matter if I change it to use O_CLOEXEC when opening the file, it
still behaves the same.  When stepping through the code and looking at
the flags of the file using `lsof +fg -p <pid>`, the ouput of lsof
should read "LG,CX", but instead of the CX flag, lsof shows 0x80000
(FD_CLOEXEC should be 1 according to all my header files), however,
fcntl(device_fd, F_GETFD) returns 1 and works perfectly in other
programs.  I don't know if that matters, but I'm running kernel-3.14.1
and glibc-2.19 and it works properly in other programs.

Thanks for any pointers how to solve this (e.g. if there's an upstream
patch already),
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: </pipermail/attachments/20140422/a3e1f635/attachment.sig>

From Venkata.Chaitanya at GainSpan.com  Thu Apr 24 12:44:30 2014
From: Venkata.Chaitanya at GainSpan.com (Venkata Chaitanya)
Date: Thu, 24 Apr 2014 03:44:30 -0700
Subject: [gnutls-help] Configure gnutls with apache in windows
Message-ID: <3582894D7E3C1141A7D0D3132B8EC38B36E5B4C044@GS-EX01.GainSpan.LAN>

Hi,

I am new to gnutls and so far I was using openssl module for my apache on windows platform can you help me in moving to gnutls for apache on windows.



Thanks,
Chaitanya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140424/e5c0830a/attachment.html>

From Venkata.Chaitanya at GainSpan.com  Thu Apr 24 13:25:43 2014
From: Venkata.Chaitanya at GainSpan.com (Venkata Chaitanya)
Date: Thu, 24 Apr 2014 04:25:43 -0700
Subject: [gnutls-help] Configure gnutls with apache windows
Message-ID: <3582894D7E3C1141A7D0D3132B8EC38B36E5B4C04E@GS-EX01.GainSpan.LAN>

Hi,

I am new to gnutls and so far I was using openssl module for my apache on windows platform can you help me in moving to gnutls for apache on windows.



Thanks,
Chaitanya

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140424/e311108a/attachment.html>

From dkg at fifthhorseman.net  Thu Apr 24 15:20:48 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 24 Apr 2014 09:20:48 -0400
Subject: [gnutls-help] Configure gnutls with apache in windows
In-Reply-To: <3582894D7E3C1141A7D0D3132B8EC38B36E5B4C044@GS-EX01.GainSpan.LAN>
References: <3582894D7E3C1141A7D0D3132B8EC38B36E5B4C044@GS-EX01.GainSpan.LAN>
Message-ID: <53590FB0.2020501@fifthhorseman.net>

On 04/24/2014 06:44 AM, Venkata Chaitanya wrote:

> I am new to gnutls and so far I was using openssl module for my apache on windows platform can you help me in moving to gnutls for apache on windows.

I think you're interested in mod_gnutls, which is the module that
connects apache to gnutls.  The mailing list for that project is:

   mod_gnutls-devel at lists.gnutls.org

(i'm cc'ing there and setting followup there too; i'm one of the
developers on the project)

I don't think anyone has built the latest version of mod_gnutls on
Windows, and i don't have a Windows development machine to try it
myself.  If you'd like to try building it for Windows and reporting what
you did, and what problems you run into, i'd be happy to try to help you
figure it out.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140424/76db36a9/attachment.sig>

From mkletzan at redhat.com  Sat Apr 26 10:42:18 2014
From: mkletzan at redhat.com (Martin Kletzander)
Date: Sat, 26 Apr 2014 10:42:18 +0200
Subject: [gnutls-help] Issues with both gnutls 3.3.0 and 3.3.1
In-Reply-To: <20140422140120.GC21999@wheatley>
References: <20140422140120.GC21999@wheatley>
Message-ID: <20140426084217.GA13398@wheatley>

On Tue, Apr 22, 2014 at 04:01:20PM +0200, Martin Kletzander wrote:
>Hello,
>
>I recently upgraded to gnutls-3.3.0 (from 3.2.13) and found out that
>there are 2 FDs leaked (read-only, pointing to /dev/urandom) into some
>processes.  Looking at the code it looks like there should be
>FD_CLOEXEC set, but it leaks through anyway.  The backtrace when
>opening those files is:
>
>#0  open64 () at ../sysdeps/unix/syscall-template.S:81
>#1  0x00007ffff60f20a7 in open (__oflag=0, __path=0x7ffff61031b9 "/dev/urandom")
>    at /usr/include/bits/fcntl2.h:53
>#2  _rnd_system_entropy_init () at rnd-common.c:192
>#3  0x00007ffff60f29b0 in wrap_nettle_rnd_init (ctx=<optimized out>) at rnd.c:231
>#4  0x00007ffff6055cce in _gnutls_rnd_init () at random.c:49
>#5  0x00007ffff6047714 in gnutls_global_init () at gnutls_global.c:251
>#6  0x00007ffff6025fdb in lib_init () at gnutls_global.c:385
>#7  0x00007ffff7dea94b in call_init (l=<optimized out>, argc=argc at entry=1,
>    argv=argv at entry=0x7fffffffe368, env=env at entry=0x7fffffffe378) at dl-init.c:78
>#8  0x00007ffff7deaa5c in call_init (env=0x7fffffffe378, argv=0x7fffffffe368, argc=1,
>    l=<optimized out>) at dl-init.c:36
>#9  _dl_init (main_map=0x7ffff7ffe148, argc=1, argv=0x7fffffffe368, env=0x7fffffffe378)
>    at dl-init.c:126
>#10 0x00007ffff7ddc2da in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
>#11 0x0000000000000001 in ?? ()
>#12 0x00007fffffffe67a in ?? ()
>#13 0x0000000000000000 in ?? ()
>
>No matter if I change it to use O_CLOEXEC when opening the file, it
>still behaves the same.  When stepping through the code and looking at
>the flags of the file using `lsof +fg -p <pid>`, the ouput of lsof
>should read "LG,CX", but instead of the CX flag, lsof shows 0x80000
>(FD_CLOEXEC should be 1 according to all my header files), however,
>fcntl(device_fd, F_GETFD) returns 1 and works perfectly in other
>programs.  I don't know if that matters, but I'm running kernel-3.14.1
>and glibc-2.19 and it works properly in other programs.
>

I've gone through bisecting the repo and found out the first bad
commit is this one:

commit d5d302e278c3a813994f3fe3026f3990fd6a23d9
Author: Nikos Mavrogiannopoulos <nmav at gnutls.org>
Date:   Sat Nov 30 19:08:38 2013 +0100

    constructor and destructors were moved outside the FIPS140 mode.

Hoever, since I'm not familiar with the codebase, I'm rather reluctant
to go on.  Partyl because I don't know where to continue and partly
because I might be re-inventing the wheel.

Any thoughts about that?

Martin

>Thanks for any pointers how to solve this (e.g. if there's an upstream
>patch already),
>Martin



>_______________________________________________
>Gnutls-help mailing list
>Gnutls-help at lists.gnutls.org
>http://lists.gnupg.org/mailman/listinfo/gnutls-help
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: </pipermail/attachments/20140426/6cb083be/attachment.sig>

From m at matthewlai.ca  Sun Apr 27 10:49:42 2014
From: m at matthewlai.ca (Matthew Lai)
Date: Sun, 27 Apr 2014 01:49:42 -0700
Subject: [gnutls-help] SRP without certificates
Message-ID: <535CC4A6.8020504@matthewlai.ca>

Hello!

I have a question if you don't mind -

I am trying to use pure SRP for authentication, but for some reason, I 
am getting "Insufficient credentials for that request" on the client 
when I try to start the handshake.

On the server side, I am using gnutls_srp_set_server_credentials_file() 
and gnutls_credentials_set(session, GNUTLS_CRD_SRP, m_serverCred). Both 
returned GNUTLS_E_SUCCESS.

On the server side, I am using gnutls_srp_set_client_credentials() and 
gnutls_credentials_set(m_clientSessionTcp, GNUTLS_CRD_SRP, 
m_clientCred). Both returned GNUTLS_E_SUCCESS.

Can you tell what I am doing wrong?

I noticed that in the example a CA file is set on the client, and a CA 
file and a key file are set on the server. Are they required? I am not 
intending to use certificates.

Many thanks!
Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140427/f6c6ae65/attachment-0001.html>

From nmav at gnutls.org  Sun Apr 27 18:57:16 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 27 Apr 2014 18:57:16 +0200
Subject: [gnutls-help] Issues with both gnutls 3.3.0 and 3.3.1
In-Reply-To: <20140426084217.GA13398@wheatley>
References: <20140422140120.GC21999@wheatley> <20140426084217.GA13398@wheatley>
Message-ID: <1398617836.25589.26.camel@nomad.lan>

On Sat, 2014-04-26 at 10:42 +0200, Martin Kletzander wrote:
> On Tue, Apr 22, 2014 at 04:01:20PM +0200, Martin Kletzander wrote:
> >Hello,
> >
> >I recently upgraded to gnutls-3.3.0 (from 3.2.13) and found out that
> >there are 2 FDs leaked (read-only, pointing to /dev/urandom) into some
> >processes.  Looking at the code it looks like there should be
> >FD_CLOEXEC set, but it leaks through anyway.  The backtrace when
> >opening those files is:
> I've gone through bisecting the repo and found out the first bad
> commit is this one:
> 
> commit d5d302e278c3a813994f3fe3026f3990fd6a23d9
> Author: Nikos Mavrogiannopoulos <nmav at gnutls.org>
> Date:   Sat Nov 30 19:08:38 2013 +0100
> 
>     constructor and destructors were moved outside the FIPS140 mode.

This effectively moved gnutls_global_init() and _deinit() to library
constructor and destructor respectively. That means that any descriptors
will be left open until the library is unloaded.

The fact though that there are 2 descriptors open seems like a bug. I'll
check it.

regards,
Nikos




From nmav at gnutls.org  Sun Apr 27 19:25:10 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 27 Apr 2014 19:25:10 +0200
Subject: [gnutls-help] SRP without certificates
In-Reply-To: <535CC4A6.8020504@matthewlai.ca>
References: <535CC4A6.8020504@matthewlai.ca>
Message-ID: <1398619510.25589.31.camel@nomad.lan>

On Sun, 2014-04-27 at 01:49 -0700, Matthew Lai wrote:
> Hello!
> 
> I have a question if you don't mind -
> 
> I am trying to use pure SRP for authentication, but for some reason, I
> am getting "Insufficient credentials for that request" on the client
> when I try to start the handshake.
> On the server side, I am using
> gnutls_srp_set_server_credentials_file() and
> gnutls_credentials_set(session, GNUTLS_CRD_SRP, m_serverCred). Both
> returned GNUTLS_E_SUCCESS.
> On the server side, I am using gnutls_srp_set_client_credentials() and
> gnutls_credentials_set(m_clientSessionTcp, GNUTLS_CRD_SRP,
> m_clientCred). Both returned GNUTLS_E_SUCCESS.

> Can you tell what I am doing wrong?

There could be many things wrong. The best is to try first with
gnutls-cli and gnutls-serv instead of trying to make both client and
server at the same time. Note that you need to explicitly enable the SRP
key exchange method with a priority string.

regards,
Nikos






From m at matthewlai.ca  Sun Apr 27 21:25:33 2014
From: m at matthewlai.ca (Matthew Lai)
Date: Sun, 27 Apr 2014 12:25:33 -0700
Subject: [gnutls-help] SRP without certificates
In-Reply-To: <1398619510.25589.31.camel@nomad.lan>
References: <535CC4A6.8020504@matthewlai.ca>
 <1398619510.25589.31.camel@nomad.lan>
Message-ID: <535D59AD.2040801@matthewlai.ca>

Hi Nikos,

Thanks so much for your help!

The priority string is it. I was just using "NORMAL". Using 
"NORMAL:+SRP" now and handshake succeeds!

Thanks
Matthew

On 4/27/2014 10:25 AM, Nikos Mavrogiannopoulos wrote:
> On Sun, 2014-04-27 at 01:49 -0700, Matthew Lai wrote:
>> Hello!
>>
>> I have a question if you don't mind -
>>
>> I am trying to use pure SRP for authentication, but for some reason, I
>> am getting "Insufficient credentials for that request" on the client
>> when I try to start the handshake.
>> On the server side, I am using
>> gnutls_srp_set_server_credentials_file() and
>> gnutls_credentials_set(session, GNUTLS_CRD_SRP, m_serverCred). Both
>> returned GNUTLS_E_SUCCESS.
>> On the server side, I am using gnutls_srp_set_client_credentials() and
>> gnutls_credentials_set(m_clientSessionTcp, GNUTLS_CRD_SRP,
>> m_clientCred). Both returned GNUTLS_E_SUCCESS.
>> Can you tell what I am doing wrong?
> There could be many things wrong. The best is to try first with
> gnutls-cli and gnutls-serv instead of trying to make both client and
> server at the same time. Note that you need to explicitly enable the SRP
> key exchange method with a priority string.
>
> regards,
> Nikos
>
>
>
>



From nmav at gnutls.org  Mon Apr 28 15:53:41 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 28 Apr 2014 15:53:41 +0200
Subject: [gnutls-help] Issues with both gnutls 3.3.0 and 3.3.1
In-Reply-To: <20140422140120.GC21999@wheatley>
References: <20140422140120.GC21999@wheatley>
Message-ID: <CAJU7zaLZr_yNbxNjgEMhvR6KcRWT8NGX4cWSdDQM487gLYj6JQ@mail.gmail.com>

On Tue, Apr 22, 2014 at 4:01 PM, Martin Kletzander <mkletzan at redhat.com> wrote:
> Hello,
> I recently upgraded to gnutls-3.3.0 (from 3.2.13) and found out that
> there are 2 FDs leaked (read-only, pointing to /dev/urandom) into some
> processes.  Looking at the code it looks like there should be
> FD_CLOEXEC set, but it leaks through anyway.  The backtrace when
> opening those files is:

On a second read, I don't quite understand what is the issue you're having
there. Is it that you do a fork-then-exec, and you see the urandom descriptor
open? If you simply do a fork that is expected as the child inherits all the
open descriptors.

regards,
Nikos


From mkletzan at redhat.com  Mon Apr 28 16:49:01 2014
From: mkletzan at redhat.com (Martin Kletzander)
Date: Mon, 28 Apr 2014 16:49:01 +0200
Subject: [gnutls-help] Issues with both gnutls 3.3.0 and 3.3.1
In-Reply-To: <CAJU7zaLZr_yNbxNjgEMhvR6KcRWT8NGX4cWSdDQM487gLYj6JQ@mail.gmail.com>
References: <20140422140120.GC21999@wheatley>
 <CAJU7zaLZr_yNbxNjgEMhvR6KcRWT8NGX4cWSdDQM487gLYj6JQ@mail.gmail.com>
Message-ID: <20140428144901.GH13398@wheatley>

On Mon, Apr 28, 2014 at 03:53:41PM +0200, Nikos Mavrogiannopoulos wrote:
>On Tue, Apr 22, 2014 at 4:01 PM, Martin Kletzander <mkletzan at redhat.com> wrote:
>> Hello,
>> I recently upgraded to gnutls-3.3.0 (from 3.2.13) and found out that
>> there are 2 FDs leaked (read-only, pointing to /dev/urandom) into some
>> processes.  Looking at the code it looks like there should be
>> FD_CLOEXEC set, but it leaks through anyway.  The backtrace when
>> opening those files is:
>
>On a second read, I don't quite understand what is the issue you're having
>there. Is it that you do a fork-then-exec, and you see the urandom descriptor
>open? If you simply do a fork that is expected as the child inherits all the
>open descriptors.
>

It happens with usual fork-then-exec on some binaries.  I'm saying
some because I was not able to identify which ones as it doesn't
happen for every one.

I saw this error when running libvirt test suite (make check) where we
have one test checking that we leak no file descriptors into our
executed code (apart from other things).  However, even if I run that
command we are using [1] from shell, it still has these two FDs open.
The program just creates a log file with all its file descriptors,
environment data, etc.

If there's anything I can do to help find the bug, let me know.

Martin

[1] http://libvirt.org/git/?p=libvirt.git;a=blob;f=tests/commandhelper.c;hb=HEAD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: </pipermail/attachments/20140428/11973258/attachment.sig>

From nmav at gnutls.org  Mon Apr 28 17:25:13 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 28 Apr 2014 17:25:13 +0200
Subject: [gnutls-help] Issues with both gnutls 3.3.0 and 3.3.1
In-Reply-To: <20140428144901.GH13398@wheatley>
References: <20140422140120.GC21999@wheatley>
 <CAJU7zaLZr_yNbxNjgEMhvR6KcRWT8NGX4cWSdDQM487gLYj6JQ@mail.gmail.com>
 <20140428144901.GH13398@wheatley>
Message-ID: <CAJU7zaJX9e89C6_zm83huwCbGZnQMEQdo2mXvP6NfbJx4=6jbA@mail.gmail.com>

On Mon, Apr 28, 2014 at 4:49 PM, Martin Kletzander <mkletzan at redhat.com> wrote:
>> On a second read, I don't quite understand what is the issue you're having
>> there. Is it that you do a fork-then-exec, and you see the urandom
>> descriptor
>> open? If you simply do a fork that is expected as the child inherits all
>> the
>> open descriptors.
> It happens with usual fork-then-exec on some binaries.  I'm saying
> some because I was not able to identify which ones as it doesn't
> happen for every one.
> I saw this error when running libvirt test suite (make check) where we
> have one test checking that we leak no file descriptors into our
> executed code (apart from other things).  However, even if I run that
> command we are using [1] from shell, it still has these two FDs open.
> The program just creates a log file with all its file descriptors,
> environment data, etc.
> If there's anything I can do to help find the bug, let me know.

I could not reproduce it with a program that calls gnutls_global_init() and
then forks and execs. Is there a way to reproduce it with libvirt tools?

regards,
Nikos


From mkletzan at redhat.com  Mon Apr 28 17:36:27 2014
From: mkletzan at redhat.com (Martin Kletzander)
Date: Mon, 28 Apr 2014 17:36:27 +0200
Subject: [gnutls-help] Issues with both gnutls 3.3.0 and 3.3.1
In-Reply-To: <CAJU7zaJX9e89C6_zm83huwCbGZnQMEQdo2mXvP6NfbJx4=6jbA@mail.gmail.com>
References: <20140422140120.GC21999@wheatley>
 <CAJU7zaLZr_yNbxNjgEMhvR6KcRWT8NGX4cWSdDQM487gLYj6JQ@mail.gmail.com>
 <20140428144901.GH13398@wheatley>
 <CAJU7zaJX9e89C6_zm83huwCbGZnQMEQdo2mXvP6NfbJx4=6jbA@mail.gmail.com>
Message-ID: <20140428153627.GJ13398@wheatley>

On Mon, Apr 28, 2014 at 05:25:13PM +0200, Nikos Mavrogiannopoulos wrote:
>On Mon, Apr 28, 2014 at 4:49 PM, Martin Kletzander <mkletzan at redhat.com> wrote:
>>> On a second read, I don't quite understand what is the issue you're having
>>> there. Is it that you do a fork-then-exec, and you see the urandom
>>> descriptor
>>> open? If you simply do a fork that is expected as the child inherits all
>>> the
>>> open descriptors.
>> It happens with usual fork-then-exec on some binaries.  I'm saying
>> some because I was not able to identify which ones as it doesn't
>> happen for every one.
>> I saw this error when running libvirt test suite (make check) where we
>> have one test checking that we leak no file descriptors into our
>> executed code (apart from other things).  However, even if I run that
>> command we are using [1] from shell, it still has these two FDs open.
>> The program just creates a log file with all its file descriptors,
>> environment data, etc.
>> If there's anything I can do to help find the bug, let me know.
>
>I could not reproduce it with a program that calls gnutls_global_init() and
>then forks and execs. Is there a way to reproduce it with libvirt tools?
>

The program I was using does not do anything with
gnutls_global_init().  What I used when bisecting was:

tests/commandhelper </dev/null &>/dev/null
grep '^FD:' tests/commandhelper.log

When everything is ok, you'll see only:

FD:0
FD:1
FD:2

However with gnutls with that mentioned commit, I see:

FD:0
FD:1
FD:2
FD:3
FD:4

*However*, for this you need to configure libvirt with tests, build
them (or at least the commandhelper), etc.  I'll try to come up with a
simplified source code asap.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: </pipermail/attachments/20140428/84f873d8/attachment-0001.sig>

From mkletzan at redhat.com  Mon Apr 28 17:51:07 2014
From: mkletzan at redhat.com (Martin Kletzander)
Date: Mon, 28 Apr 2014 17:51:07 +0200
Subject: [gnutls-help] Issues with both gnutls 3.3.0 and 3.3.1
In-Reply-To: <20140428153627.GJ13398@wheatley>
References: <20140422140120.GC21999@wheatley>
 <CAJU7zaLZr_yNbxNjgEMhvR6KcRWT8NGX4cWSdDQM487gLYj6JQ@mail.gmail.com>
 <20140428144901.GH13398@wheatley>
 <CAJU7zaJX9e89C6_zm83huwCbGZnQMEQdo2mXvP6NfbJx4=6jbA@mail.gmail.com>
 <20140428153627.GJ13398@wheatley>
Message-ID: <20140428155107.GK13398@wheatley>

On Mon, Apr 28, 2014 at 05:36:27PM +0200, Martin Kletzander wrote:
>On Mon, Apr 28, 2014 at 05:25:13PM +0200, Nikos Mavrogiannopoulos wrote:
>>On Mon, Apr 28, 2014 at 4:49 PM, Martin Kletzander <mkletzan at redhat.com> wrote:
>>>> On a second read, I don't quite understand what is the issue you're having
>>>> there. Is it that you do a fork-then-exec, and you see the urandom
>>>> descriptor
>>>> open? If you simply do a fork that is expected as the child inherits all
>>>> the
>>>> open descriptors.
>>> It happens with usual fork-then-exec on some binaries.  I'm saying
>>> some because I was not able to identify which ones as it doesn't
>>> happen for every one.
>>> I saw this error when running libvirt test suite (make check) where we
>>> have one test checking that we leak no file descriptors into our
>>> executed code (apart from other things).  However, even if I run that
>>> command we are using [1] from shell, it still has these two FDs open.
>>> The program just creates a log file with all its file descriptors,
>>> environment data, etc.
>>> If there's anything I can do to help find the bug, let me know.
>>
>>I could not reproduce it with a program that calls gnutls_global_init() and
>>then forks and execs. Is there a way to reproduce it with libvirt tools?
>>
>
>The program I was using does not do anything with
>gnutls_global_init().  What I used when bisecting was:
>
>tests/commandhelper </dev/null &>/dev/null
>grep '^FD:' tests/commandhelper.log
>
>When everything is ok, you'll see only:
>
>FD:0
>FD:1
>FD:2
>
>However with gnutls with that mentioned commit, I see:
>
>FD:0
>FD:1
>FD:2
>FD:3
>FD:4
>
>*However*, for this you need to configure libvirt with tests, build
>them (or at least the commandhelper), etc.  I'll try to come up with a
>simplified source code asap.
>

I simplified it into a simple checker [1], that you just run without
parameters and see the list of open file descriptors.

But what I haven't realized earlier is that it only behaves weird when
compiled with '-lgnutls', not if compiled without that library.  I
guess in that case it is unloaded and the FDs are closed properly.

Martin

[1] http://ideone.com/0Nrv0d
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: </pipermail/attachments/20140428/925b3e6c/attachment.sig>

From nmav at gnutls.org  Mon Apr 28 19:12:28 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 28 Apr 2014 19:12:28 +0200
Subject: [gnutls-help] Issues with both gnutls 3.3.0 and 3.3.1
In-Reply-To: <20140428155107.GK13398@wheatley>
References: <20140422140120.GC21999@wheatley>
 <CAJU7zaLZr_yNbxNjgEMhvR6KcRWT8NGX4cWSdDQM487gLYj6JQ@mail.gmail.com>
 <20140428144901.GH13398@wheatley>
 <CAJU7zaJX9e89C6_zm83huwCbGZnQMEQdo2mXvP6NfbJx4=6jbA@mail.gmail.com>
 <20140428153627.GJ13398@wheatley> <20140428155107.GK13398@wheatley>
Message-ID: <1398705148.4303.5.camel@nomad.lan>

On Mon, 2014-04-28 at 17:51 +0200, Martin Kletzander wrote:

> I simplified it into a simple checker [1], that you just run without
> parameters and see the list of open file descriptors.
> But what I haven't realized earlier is that it only behaves weird when
> compiled with '-lgnutls', not if compiled without that library.  I
> guess in that case it is unloaded and the FDs are closed properly.

Then that's the expected behavior. Indeed if you compile with -lgnutls
you'll have /dev/urandom kept open. If I switch this behavior and
open /dev/urandom only when needed there will be problems in the cases
where a program chroots to a directory without it (and the current
behavior of gnutls didn't require /dev/urandom except on
initialization).

regards,
Nikos




From mkletzan at redhat.com  Tue Apr 29 18:00:11 2014
From: mkletzan at redhat.com (Martin Kletzander)
Date: Tue, 29 Apr 2014 18:00:11 +0200
Subject: [gnutls-help] Issues with both gnutls 3.3.0 and 3.3.1
In-Reply-To: <1398705148.4303.5.camel@nomad.lan>
References: <20140422140120.GC21999@wheatley>
 <CAJU7zaLZr_yNbxNjgEMhvR6KcRWT8NGX4cWSdDQM487gLYj6JQ@mail.gmail.com>
 <20140428144901.GH13398@wheatley>
 <CAJU7zaJX9e89C6_zm83huwCbGZnQMEQdo2mXvP6NfbJx4=6jbA@mail.gmail.com>
 <20140428153627.GJ13398@wheatley> <20140428155107.GK13398@wheatley>
 <1398705148.4303.5.camel@nomad.lan>
Message-ID: <20140429160011.GS13398@wheatley>

On Mon, Apr 28, 2014 at 07:12:28PM +0200, Nikos Mavrogiannopoulos wrote:
>On Mon, 2014-04-28 at 17:51 +0200, Martin Kletzander wrote:
>
>> I simplified it into a simple checker [1], that you just run without
>> parameters and see the list of open file descriptors.
>> But what I haven't realized earlier is that it only behaves weird when
>> compiled with '-lgnutls', not if compiled without that library.  I
>> guess in that case it is unloaded and the FDs are closed properly.
>
>Then that's the expected behavior. Indeed if you compile with -lgnutls
>you'll have /dev/urandom kept open. If I switch this behavior and
>open /dev/urandom only when needed there will be problems in the cases
>where a program chroots to a directory without it (and the current
>behavior of gnutls didn't require /dev/urandom except on
>initialization).
>

I would say that if any gnutls functionality is needed after the
program has started or after any gnutls init function was called, be
my guest, open file descriptors, and so on.  But this opinion is
subjective, so I'll see what others think about our code relying on
this.  Maybe the reply will be "just fix our code", I don't know.

Thanks for your responses, I won't cross-post in order not to flood
this ML.

Have a nice day,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: </pipermail/attachments/20140429/b4763c79/attachment.sig>

From dev at cor0.com  Tue Apr 29 21:01:31 2014
From: dev at cor0.com (dev)
Date: Tue, 29 Apr 2014 15:01:31 -0400 (EDT)
Subject: [gnutls-help] what exactly is gnutls 3.2.13 and 3.3.1 looking for
	in libgmp ??
Message-ID: <527955416.40066.1398798092325.JavaMail.vpopmail@webmail2.networksolutionsemail.com>


configure in 3.2.13 and 3.3.1 both seem broken regarding libgmp.

During configure of both 3.2.13 and 3.3.1 I get the same error
regarding libgmp :

.
.
.
checking for inline... inline
checking for ANSI C header files... (cached) yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for NETTLE... yes
checking for HOGWEED... yes
checking for __gmpz_cmp in -lgmp... no
configure: error:
***
*** gmp was not found.


However libgmp is just recently built, tested and fully up to date :

$ ls -lap /usr/local/lib/libgmp*
-rw-r--r--   1 dclarke  adbs     3599472 Apr 29 17:36
/usr/local/lib/libgmp.a
-rwxr-xr-x   1 dclarke  adbs         914 Apr 29 17:36
/usr/local/lib/libgmp.la
lrwxrwxrwx   1 dclarke  adbs          16 Apr 29 17:36
/usr/local/lib/libgmp.so -> libgmp.so.10.2.0*
lrwxrwxrwx   1 dclarke  adbs          16 Apr 29 17:36
/usr/local/lib/libgmp.so.10 -> libgmp.so.10.2.0*
-rwxr-xr-x   1 dclarke  other    1445024 Nov 12  2012
/usr/local/lib/libgmp.so.10.0.5
-rwxr-xr-x   1 dclarke  other    1790096 Mar 23  2013
/usr/local/lib/libgmp.so.10.1.1
-rwxr-xr-x   1 dclarke  adbs     1827824 Oct 17  2013
/usr/local/lib/libgmp.so.10.1.3
-rwxr-xr-x   1 dclarke  adbs     1842776 Apr 29 17:36
/usr/local/lib/libgmp.so.10.2.0
-rw-r--r--   1 dclarke  adbs      444456 Apr 29 17:36
/usr/local/lib/libgmpxx.a
-rwxr-xr-x   1 dclarke  adbs         990 Apr 29 17:36
/usr/local/lib/libgmpxx.la
lrwxrwxrwx   1 dclarke  adbs          17 Apr 29 17:36
/usr/local/lib/libgmpxx.so -> libgmpxx.so.4.4.0*
lrwxrwxrwx   1 dclarke  adbs          17 Apr 29 17:36
/usr/local/lib/libgmpxx.so.4 -> libgmpxx.so.4.4.0*
-rwxr-xr-x   1 dclarke  other     203088 Nov 12  2012
/usr/local/lib/libgmpxx.so.4.2.5
-rwxr-xr-x   1 dclarke  other     298280 Mar 23  2013
/usr/local/lib/libgmpxx.so.4.3.1
-rwxr-xr-x   1 dclarke  adbs      347088 Oct 17  2013
/usr/local/lib/libgmpxx.so.4.3.3
-rwxr-xr-x   1 dclarke  adbs      347272 Apr 29 17:36
/usr/local/lib/libgmpxx.so.4.4.0


So what exactly is this double underscore test for __gmpz_cmp about ?

Here is what config.log has to say :

configure:8421: checking for __gmpz_cmp in -lgmp
configure:8446: /opt/solarisstudio12.3/bin/cc -o conftest -errfmt=error
-erroff=%none -errshort=full -xstrconst -xildoff -m64 -xmemalign=8s
-xnolibmil -Xa -xcode=pic32 -xregs=no%appl -xlibmieee -mc -g -xs
-ftrap=%none -Qy -xbuiltin=%none -xdebugformat=dwarf -xunroll=1
-xtarget=ultraT2 -xcache=8/16/4:4096/64/16 -I/usr/local/include
-D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE  conftest.c
-lgmp   >&5
"conftest.c", line 44: warning: statement not reached
ld: fatal: library -lgmp: not found
ld: fatal: file processing errors. No output written to conftest
configure:8446: $? = 2
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GnuTLS"
| #define PACKAGE_TARNAME "gnutls"
| #define PACKAGE_VERSION "3.3.1"
| #define PACKAGE_STRING "GnuTLS 3.3.1"
| #define PACKAGE_BUGREPORT "bugs at gnutls.org"
| #define PACKAGE_URL ""
| #define PACKAGE "gnutls"
| #define VERSION "3.3.1"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define __EXTENSIONS__ 1
| #define _ALL_SOURCE 1
| #define _DARWIN_C_SOURCE 1
| #define _GNU_SOURCE 1
| #define _POSIX_PTHREAD_SEMANTICS 1
| #define _TANDEM_SOURCE 1
| #define HAVE_FSEEKO 1
| #define _DARWIN_USE_64_BIT_INODE 1
| #define STDC_HEADERS 1
| #define HAVE_LIBNETTLE 1
| /* end confdefs.h.  */
|
| /* Override any GCC internal prototype to avoid an error.
|    Use char because int might match the return type of a GCC
|    builtin and then its argument prototype would still apply.  */
| #ifdef __cplusplus
| extern "C"
| #endif
| char __gmpz_cmp ();
| int
| main ()
| {
| return __gmpz_cmp ();
|   ;
|   return 0;
| }
configure:8455: result: no
configure:8460: error:
***
*** gmp was not found.


I don't see the problem.

Here is foo.c :

$ cat foo.c
char __gmpz_cmp ();
int main () {
 return __gmpz_cmp ();
 return 0;
}


compiles and links fine :

$
$ cc $CFLAGS -H -c -o foo.o foo.c
"foo.c", line 4: warning: statement not reached
$ cc -R/usr/local/lib -L/usr/local/lib $CFLAGS -H -o foo foo.o -lgmp

$ file foo
foo: ELF 64-bit MSB executable, SPARC V9, total store ordering, version
1, dynamically linked (uses shared libs), not stripped

$ ldd foo
        libgmp.so.10 =>  /usr/local/lib/libgmp.so.10
        libc.so.1 =>     /lib/64/libc.so.1
        libgcc_s.so.1 =>
        /usr/local/gcc4/lib/sparcv9/libgcc_s.so.1
        libm.so.2 =>     /lib/64/libm.so.2
        /platform/SUNW,T5240/lib/sparcv9/libc_psr.so.1

$ elfdump -devl foo

ELF Header
  ei_magic:   { 0x7f, E, L, F }
  ei_class:   ELFCLASS64          ei_data:       ELFDATA2MSB
  ei_osabi:   ELFOSABI_SOLARIS    ei_abiversion: EAV_SUNW_CURRENT
  e_machine:  EM_SPARCV9          e_version:     EV_CURRENT
  e_type:     ET_EXEC
  e_flags:    [ EF_SPARCV9_TSO EF_SPARC_SUN_US1 EF_SPARC_SUN_US3 ]
  e_entry:           0x100000840  e_ehsize:     64  e_shstrndx:  25
  e_shoff:                0x19f0  e_shentsize:  64  e_shnum:     26
  e_phoff:                  0x40  e_phentsize:  56  e_phnum:     5

Version Needed Section:  .SUNW_version
     index  file                        version
       [2]  libc.so.1                   SUNW_0.7

Dynamic Section:  .dynamic
     index  tag                value
       [0]  NEEDED            0xde                libgmp.so.10
       [1]  NEEDED            0xcb                libc.so.1
       [2]  INIT              0x1000009d8
       [3]  FINI              0x1000009e8
       [4]  RUNPATH           0xeb
               /usr/local/lib/$ISALIST:/usr/local/lib:/usr/local/lib
       [5]  RPATH             0xeb
               /usr/local/lib/$ISALIST:/usr/local/lib:/usr/local/lib
       [6]  HASH              0x100000178
       [7]  STRTAB            0x100000460
       [8]  STRSZ             0x321
       [9]  SYMTAB            0x100000238
      [10]  SYMENT            0x18
      [11]  CHECKSUM          0xf08c
      [12]  VERNEED           0x100000788
      [13]  VERNEEDNUM        0x1
      [14]  PLTRELSZ          0x60
      [15]  PLTREL            0x7
      [16]  JMPREL            0x1000007d8
      [17]  RELA              0x1000007d8
      [18]  RELASZ            0x60
      [19]  RELAENT           0x18
      [20]  DEBUG             0
      [21]  FLAGS             0                   0
      [22]  FLAGS_1           0                   0
      [23]  SUNW_STRPAD       0x200
      [24]  SUNW_LDMACH       0x2b                EM_SPARCV9
      [25]  PLTGOT            0x100100b00
   [26-36]  NULL              0
$


So what exactly is the configure test looking for here ?

Really it looks like LD_OPTIONS and LD_RUN_PATH are being ignored :

$ echo $LD_OPTIONS
-64 -R/usr/local/lib/$ISALIST:/usr/local/lib
-L/usr/local/lib/$ISALIST:/usr/local/lib

$ echo $LD_RUN_PATH
/usr/local/lib


Unless configure depends on the ill used LD_LIBRARY_PATH value ?


Dennis


From dev at cor0.com  Tue Apr 29 22:20:56 2014
From: dev at cor0.com (dev)
Date: Tue, 29 Apr 2014 16:20:56 -0400 (EDT)
Subject: [gnutls-help] gnutls 3.31 fails to compile with  "gnutls_global.c",
 line 356: error: void function cannot return value
Message-ID: <1495170789.44914.1398802856765.JavaMail.vpopmail@webmail2.networksolutionsemail.com>


System is a Solaris 10 server with Oracle Studio 12.3 compiler tools.

"gnutls_global.c", line 356: error: void function cannot return value
cc: acomp failed for gnutls_global.c


Could be a valid bug if a void func is to return a value.

dc


From dev at cor0.com  Wed Apr 30 00:24:29 2014
From: dev at cor0.com (dev)
Date: Tue, 29 Apr 2014 18:24:29 -0400 (EDT)
Subject: [gnutls-help] gnutls-3.2.13 : another code bug "base64.c",
 line 99: error: void function cannot return value
Message-ID: <1005583104.59634.1398810269726.JavaMail.vpopmail@webmail2.networksolutionsemail.com>

I just checked and sure enough the code is trying to
return a value from a static void function :


First we have the static voide func :


/* Base64 encode IN array of size INLEN into OUT array. OUT needs
   to be of length >= BASE64_LENGTH(INLEN), and INLEN needs to be
   a multiple of 3.  */
static void
base64_encode_fast (const char *restrict in, size_t inlen, char
*restrict out)
{
  while (inlen)
    {
      *out++ = b64c[to_uchar (in[0]) >> 2];
      *out++ = b64c[((to_uchar (in[0]) << 4) + (to_uchar (in[1]) >> 4))
& 0x3f];
      *out++ = b64c[((to_uchar (in[1]) << 2) + (to_uchar (in[2]) >> 6))
& 0x3f];
      *out++ = b64c[to_uchar (in[2]) & 0x3f];

      inlen -= 3;
      in += 3;
    }
}



Then down here a little we have this mess :

void
base64_encode (const char *restrict in, size_t inlen,
               char *restrict out, size_t outlen)
{
  /* Note this outlen constraint can be enforced at compile time.
     I.E. that the output buffer is exactly large enough to hold
     the encoded inlen bytes.  The inlen constraints (of corresponding
     to outlen, and being a multiple of 3) can change at runtime
     at the end of input.  However the common case when reading
     large inputs is to have both constraints satisfied, so we depend
     on both in base_encode_fast().  */
  if (outlen % 4 == 0 && inlen == outlen / 4 * 3)
    return base64_encode_fast (in, inlen, out);


That right there is just plain wrong.


How can you return a value from a void function ?

Does this stuff compile with GCC and it seems to work ?

How is that even possible ?


Dennis


From nmav at gnutls.org  Wed Apr 30 09:38:02 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 30 Apr 2014 09:38:02 +0200
Subject: [gnutls-help] what exactly is gnutls 3.2.13 and 3.3.1 looking
 for in libgmp ??
In-Reply-To: <527955416.40066.1398798092325.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
References: <527955416.40066.1398798092325.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
Message-ID: <CAJU7zaKgczz_S110fPR1KLoYt-WT84xYzGjGHAjLHZKT7B-TpA@mail.gmail.com>

On Tue, Apr 29, 2014 at 9:01 PM, dev <dev at cor0.com> wrote:
>
> configure in 3.2.13 and 3.3.1 both seem broken regarding libgmp.
>
> During configure of both 3.2.13 and 3.3.1 I get the same error
> regarding libgmp :
[...]
> However libgmp is just recently built, tested and fully up to date :
> So what exactly is this double underscore test for __gmpz_cmp about ?

gmp prefixes all its functions using double underscore. If you check
the header file you'll see something like:
#define mpz_cmp __gmpz_cmp
__GMP_DECLSPEC int mpz_cmp (mpz_srcptr, mpz_srcptr) __GMP_NOTHROW
__GMP_ATTRIBUTE_PURE;

On which platform do you compile?

> I don't see the problem.
>
> Here is foo.c :
>
> $ cat foo.c
> char __gmpz_cmp ();
> int main () {
>  return __gmpz_cmp ();
>  return 0;
> }
>
> compiles and links fine :

Did you pass the correct LDFLAGS to configure? i.e.,
LDFLAGS=-L/usr/local/lib ./configure? As gmp doesn't use pkg-config
the configure script cannot easily derive them.

regards,
Nikos


From nmav at gnutls.org  Wed Apr 30 09:41:27 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 30 Apr 2014 09:41:27 +0200
Subject: [gnutls-help] gnutls 3.31 fails to compile with
 "gnutls_global.c", line 356: error: void function cannot return value
In-Reply-To: <1495170789.44914.1398802856765.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
References: <1495170789.44914.1398802856765.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
Message-ID: <CAJU7zaKpuprrqsTR3UZtENxha8PdsFJhPrebz5NHGvtYqM+ucw@mail.gmail.com>

On Tue, Apr 29, 2014 at 10:20 PM, dev <dev at cor0.com> wrote:
>
> System is a Solaris 10 server with Oracle Studio 12.3 compiler tools.
>
> "gnutls_global.c", line 356: error: void function cannot return value
> cc: acomp failed for gnutls_global.c
> Could be a valid bug if a void func is to return a value.

There is a return there but no value to be returned. I've removed the
return anyway. Thanks.

Nikos


From nmav at gnutls.org  Wed Apr 30 10:06:00 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 30 Apr 2014 10:06:00 +0200
Subject: [gnutls-help] gnutls-3.2.13 : another code bug "base64.c",
 line 99: error: void function cannot return value
In-Reply-To: <1005583104.59634.1398810269726.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
References: <1005583104.59634.1398810269726.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
Message-ID: <CAJU7zaKf4emnVL0BYgUwpLhYiBuP9OKrAwbwTyEDL8_7ia2+EA@mail.gmail.com>

On Wed, Apr 30, 2014 at 12:24 AM, dev <dev at cor0.com> wrote:
> I just checked and sure enough the code is trying to
> return a value from a static void function :
[...]
> That right there is just plain wrong.
> How can you return a value from a void function ?

I believe that comes from c++, no idea if it is in the c99 standard,
but work with gcc and clang.

> Does this stuff compile with GCC and it seems to work ?

Apparently yes. I'll modify the code to keep your compiler happy as well.

regards,
Nikos


From dev at cor0.com  Wed Apr 30 18:50:36 2014
From: dev at cor0.com (dev)
Date: Wed, 30 Apr 2014 12:50:36 -0400 (EDT)
Subject: [gnutls-help] gnutls-3.2.13 : another code bug "base64.c",
 line 99: error: void function cannot return value
In-Reply-To: <CAJU7zaKf4emnVL0BYgUwpLhYiBuP9OKrAwbwTyEDL8_7ia2+EA@mail.gmail.com>
References: <1005583104.59634.1398810269726.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
 <CAJU7zaKf4emnVL0BYgUwpLhYiBuP9OKrAwbwTyEDL8_7ia2+EA@mail.gmail.com>
Message-ID: <1790793603.27236.1398876636624.JavaMail.vpopmail@webmail2.networksolutionsemail.com>



On April 30, 2014 at 4:06 AM Nikos Mavrogiannopoulos <nmav at gnutls.org>
wrote:
> On Wed, Apr 30, 2014 at 12:24 AM, dev <dev at cor0.com> wrote:
> > I just checked and sure enough the code is trying to
> > return a value from a static void function :
> [...]
> > That right there is just plain wrong.
> > How can you return a value from a void function ?
>
> I believe that comes from c++, no idea if it is in the c99 standard,
> but work with gcc and clang.
>
> > Does this stuff compile with GCC and it seems to work ?
>
> Apparently yes. I'll modify the code to keep your compiler happy as
> well.

patch?   What is your change ?   Are you actually doing a "return" or
just an exit here or what was the intention?  A return(0) perhaps?

The problem is not "my compiler" but "the code" wherein there are
returns
for void functions.  That is just wrong on all compilers.  The fact that
this somehow slides past GCC makes me question GCC even more.

Perhaps now is a good time to try some pedantic flags on GCC and find
possibly hidden bugs that may be all over the place and you just
are not seeing them.  Better yet, some test platforms are needed on some
OS's like Solaris, AIX, HPUX, OpenBSD perhaps.

Regardless, getting this gnuTLS code to compile on a commercial UNIX
like
Solaris is a major incredible pain.

Dennis


From dev at cor0.com  Wed Apr 30 19:26:15 2014
From: dev at cor0.com (dev)
Date: Wed, 30 Apr 2014 13:26:15 -0400 (EDT)
Subject: [gnutls-help] what exactly is gnutls 3.2.13 and 3.3.1 looking
 for in libgmp ??
In-Reply-To: <CAJU7zaKgczz_S110fPR1KLoYt-WT84xYzGjGHAjLHZKT7B-TpA@mail.gmail.com>
References: <527955416.40066.1398798092325.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
 <CAJU7zaKgczz_S110fPR1KLoYt-WT84xYzGjGHAjLHZKT7B-TpA@mail.gmail.com>
Message-ID: <1545227721.29335.1398878775544.JavaMail.vpopmail@webmail2.networksolutionsemail.com>



On April 30, 2014 at 3:38 AM Nikos Mavrogiannopoulos <nmav at gnutls.org>
wrote:
> On Tue, Apr 29, 2014 at 9:01 PM, dev <dev at cor0.com> wrote:
> >
> > configure in 3.2.13 and 3.3.1 both seem broken regarding libgmp.
> >
> > During configure of both 3.2.13 and 3.3.1 I get the same error
> > regarding libgmp :
> [...]
> > However libgmp is just recently built, tested and fully up to date :
> > So what exactly is this double underscore test for __gmpz_cmp about
> > ?
>
> gmp prefixes all its functions using double underscore. If you check
> the header file you'll see something like:
> #define mpz_cmp __gmpz_cmp
> __GMP_DECLSPEC int mpz_cmp (mpz_srcptr, mpz_srcptr) __GMP_NOTHROW
> __GMP_ATTRIBUTE_PURE;
>
> On which platform do you compile?
>
> > I don't see the problem.
> >
> > Here is foo.c :
> >
> > $ cat foo.c
> > char __gmpz_cmp ();
> > int main () {
> >  return __gmpz_cmp ();
> >  return 0;
> > }
> >
> > compiles and links fine :
>
> Did you pass the correct LDFLAGS to configure? i.e.,
> LDFLAGS=-L/usr/local/lib ./configure? As gmp doesn't use pkg-config
> the configure script cannot easily derive them.

nope .. just tried with LD_FLAGS set and see this :

checking for inline... inline
checking for ANSI C header files... (cached) yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for NETTLE... yes
checking for HOGWEED... yes
checking for __gmpz_cmp in -lgmp... no
configure: error:
***
*** gmp was not found.

node002$ echo $LD_FLAGS
-L/usr/local/lib
node002$
node002$ echo $LD_LIBRARY_PATH

Looks like something isn't quite right in configure.

I'll use LD_LIBRARY_PATH for the configure stage and then remove it and
try to do the compile with more stringent compiler flags and see what
else shakes loose. With a bit of work the code base could be squeaky
clean and compile everywhere.

Dennis


From nmav at gnutls.org  Wed Apr 30 19:40:38 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 30 Apr 2014 19:40:38 +0200
Subject: [gnutls-help] gnutls-3.2.13 : another code bug "base64.c",
 line 99: error: void function cannot return value
In-Reply-To: <1790793603.27236.1398876636624.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
References: <1005583104.59634.1398810269726.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
 <CAJU7zaKf4emnVL0BYgUwpLhYiBuP9OKrAwbwTyEDL8_7ia2+EA@mail.gmail.com>
 <1790793603.27236.1398876636624.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
Message-ID: <1398879638.4169.9.camel@nomad.lan>

On Wed, 2014-04-30 at 12:50 -0400, dev wrote:
> 
> On April 30, 2014 at 4:06 AM Nikos Mavrogiannopoulos <nmav at gnutls.org>
> wrote:
> > On Wed, Apr 30, 2014 at 12:24 AM, dev <dev at cor0.com> wrote:
> > > I just checked and sure enough the code is trying to
> > > return a value from a static void function :
> > [...]
> > > That right there is just plain wrong.
> > > How can you return a value from a void function ?
> >
> > I believe that comes from c++, no idea if it is in the c99 standard,
> > but work with gcc and clang.
> >
> > > Does this stuff compile with GCC and it seems to work ?
> >
> > Apparently yes. I'll modify the code to keep your compiler happy as
> > well.
> 
> patch? 

It is on the repository.

> The problem is not "my compiler" but "the code" wherein there are
> returns
> for void functions.  That is just wrong on all compilers.  The fact
> that
> this somehow slides past GCC makes me question GCC even more.

and is that syntax forbidden by C99? Most major compilers support that
syntax due to C++, so it may simply be a limitation of the solaris
compiler.

> Perhaps now is a good time to try some pedantic flags on GCC and find
> possibly hidden bugs that may be all over the place and you just
> are not seeing them.  Better yet, some test platforms are needed on some
> OS's like Solaris, AIX, HPUX, OpenBSD perhaps.

Feel free to test it and provide patches for the various platforms you
tested it on.

> Regardless, getting this gnuTLS code to compile on a commercial UNIX
> like Solaris is a major incredible pain.

That's because it is not developed on these platforms. You are welcome
to provide patches to ease compilation to your favorite platform. gnutls
is developed on Linux systems with gcc and that's not going to change;
any other platforms are supported due to people contributing patches.

regards,
Nikos




From dev at cor0.com  Wed Apr 30 19:52:23 2014
From: dev at cor0.com (dev)
Date: Wed, 30 Apr 2014 13:52:23 -0400 (EDT)
Subject: [gnutls-help] gnutls-3.2.13 : another code bug "base64.c",
 line 99: error: void function cannot return value
In-Reply-To: <1398879638.4169.9.camel@nomad.lan>
References: <1005583104.59634.1398810269726.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
 <CAJU7zaKf4emnVL0BYgUwpLhYiBuP9OKrAwbwTyEDL8_7ia2+EA@mail.gmail.com>
 <1790793603.27236.1398876636624.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
 <1398879638.4169.9.camel@nomad.lan>
Message-ID: <1384098590.30683.1398880344150.JavaMail.vpopmail@webmail2.networksolutionsemail.com>


>
> That's because it is not developed on these platforms. You are welcome
> to provide patches to ease compilation to your favorite platform.
> gnutls
> is developed on Linux systems with gcc and that's not going to change;
> any other platforms are supported due to people contributing patches.

OKay, a linux only club.  Got it.


From dev at cor0.com  Wed Apr 30 20:03:19 2014
From: dev at cor0.com (dev)
Date: Wed, 30 Apr 2014 14:03:19 -0400 (EDT)
Subject: [gnutls-help] gnutls-3.2.13 : another code bug "base64.c",
 line 99: error: void function cannot return value
In-Reply-To: <1398879638.4169.9.camel@nomad.lan>
References: <1005583104.59634.1398810269726.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
 <CAJU7zaKf4emnVL0BYgUwpLhYiBuP9OKrAwbwTyEDL8_7ia2+EA@mail.gmail.com>
 <1790793603.27236.1398876636624.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
 <1398879638.4169.9.camel@nomad.lan>
Message-ID: <1865136203.43431.1398880999705.JavaMail.vpopmail@webmail2.networksolutionsemail.com>



<snippage>
> any other platforms are supported due to people contributing patches.

I'll look into these and just email in what I fix.


"x509.c", line 2894: warning: argument #3 is incompatible with
prototype:
        prototype: pointer to unsigned int :
"./../includes/gnutls/x509-ext.h", line 64
        argument : pointer to enum gnutls_x509_subject_alt_name_t
{GNUTLS_SAN_OTHERNAME_XMPP(1000), GNUTLS_SAN_DN(6),
GNUTLS_SAN_OTHERNAME(5), GNUTLS_SAN_IPADDRESS(4), GNUTLS_SAN_URI(3),
GNUTLS_SAN_RFC822NAME(2), GNUTLS_SAN_DNSNAME(1)}

"stream.c", line 668: warning: return value type mismatch
"stream.c", line 670: warning: return value type mismatch
"stream.c", line 672: warning: return value type mismatch
"stream.c", line 1119: warning: argument #2 is incompatible with
prototype:
        prototype: pointer to function(pointer to void, int, pointer to
struct __FILE {array[16] of long __pad}, pointer to struct __FILE
{array[16] of long __pad}) returning enum  {CDK_Network_Error(28),
CDK_No_Passphrase(27), CDK_No_Data(26), CDK_Unusable_Key(25),
CDK_Too_Short(24), CDK_Inv_Packet_Ver(23), CDK_Wrong_Format(22),
CDK_Error_No_Keyring(21), CDK_Inv_Mode(20), CDK_Bad_MDC(19),
CDK_Wrong_Seckey(18), CDK_Out_Of_Core(17), CDK_Weak_Key(16),
CDK_Zlib_Error(15), CDK_Time_Conflict(14), CDK_Chksum_Error(13),
CDK_Error_No_Key(12), CDK_Inv_Value(11), CDK_MPI_Error(10),
CDK_Armor_CRC_Error(9), CDK_Armor_Error(8), CDK_Not_Implemented(6),
CDK_Inv_Algo(5), CDK_Inv_Packet(4), CDK_Bad_Sig(3), CDK_File_Error(2),
CDK_General_Error(1), CDK_Success(0), CDK_EOF(-1)} : "stream.c", line
632
        argument : pointer to function(pointer to void, int, pointer to
struct __FILE {array[16] of long __pad}, pointer to struct __FILE
{array[16] of long __pad}) returning int
"stream.c", line 1158: warning: argument #2 is incompatible with
prototype:
        prototype: pointer to function(pointer to void, int, pointer to
struct __FILE {array[16] of long __pad}, pointer to struct __FILE
{array[16] of long __pad}) returning enum  {CDK_Network_Error(28),
CDK_No_Passphrase(27), CDK_No_Data(26), CDK_Unusable_Key(25),
CDK_Too_Short(24), CDK_Inv_Packet_Ver(23), CDK_Wrong_Format(22),
CDK_Error_No_Keyring(21), CDK_Inv_Mode(20), CDK_Bad_MDC(19),
CDK_Wrong_Seckey(18), CDK_Out_Of_Core(17), CDK_Weak_Key(16),
CDK_Zlib_Error(15), CDK_Time_Conflict(14), CDK_Chksum_Error(13),
CDK_Error_No_Key(12), CDK_Inv_Value(11), CDK_MPI_Error(10),
CDK_Armor_CRC_Error(9), CDK_Armor_Error(8), CDK_Not_Implemented(6),
CDK_Inv_Algo(5), CDK_Inv_Packet(4), CDK_Bad_Sig(3), CDK_File_Error(2),
CDK_General_Error(1), CDK_Success(0), CDK_EOF(-1)} : "stream.c", line
632
        argument : pointer to function(pointer to void, int, pointer to
struct __FILE {array[16] of long __pad}, pointer to struct __FILE
{array[16] of long __pad}) returning int
"stream.c", line 1211: warning: argument #2 is incompatible with
prototype:
        prototype: pointer to function(pointer to void, int, pointer to
struct __FILE {array[16] of long __pad}, pointer to struct __FILE
{array[16] of long __pad}) returning enum  {CDK_Network_Error(28),
CDK_No_Passphrase(27), CDK_No_Data(26), CDK_Unusable_Key(25),
CDK_Too_Short(24), CDK_Inv_Packet_Ver(23), CDK_Wrong_Format(22),
CDK_Error_No_Keyring(21), CDK_Inv_Mode(20), CDK_Bad_MDC(19),
CDK_Wrong_Seckey(18), CDK_Out_Of_Core(17), CDK_Weak_Key(16),
CDK_Zlib_Error(15), CDK_Time_Conflict(14), CDK_Chksum_Error(13),
CDK_Error_No_Key(12), CDK_Inv_Value(11), CDK_MPI_Error(10),
CDK_Armor_CRC_Error(9), CDK_Armor_Error(8), CDK_Not_Implemented(6),
CDK_Inv_Algo(5), CDK_Inv_Packet(4), CDK_Bad_Sig(3), CDK_File_Error(2),
CDK_General_Error(1), CDK_Success(0), CDK_EOF(-1)} : "stream.c", line
632
        argument : pointer to function(pointer to void, int, pointer to
struct __FILE {array[16] of long __pad}, pointer to struct __FILE
{array[16] of long __pad}) returning int



"system.c", line 623: warning: argument #2 is incompatible with
prototype:
        prototype: pointer to pointer to const char :
"/usr/local/include/iconv.h", line 83
        argument : pointer to pointer to char

"./includes/gnutls/gnutls.h", line 173: Warning, identexpected:
Identifier expected instead of "}".
"./includes/gnutls/gnutls.h", line 187: Warning, identexpected:
Identifier expected instead of "}".
"./includes/gnutls/gnutls.h", line 245: Warning, identexpected:
Identifier expected instead of "}".
"./includes/gnutls/gnutls.h", line 296: Warning, identexpected:
Identifier expected instead of "}".
"./includes/gnutls/gnutls.h", line 395: Warning, identexpected:
Identifier expected instead of "}".
"./includes/gnutls/gnutls.h", line 435: Warning, identexpected:
Identifier expected instead of "}".
"./includes/gnutls/gnutls.h", line 486: Warning, identexpected:
Identifier expected instead of "}".
"./includes/gnutls/gnutls.h", line 600: Warning, identexpected:
Identifier expected instead of "}".
"./includes/gnutls/gnutls.h", line 619: Warning, identexpected:
Identifier expected instead of "}".
"./includes/gnutls/gnutls.h", line 669: Warning, identexpected:
Identifier expected instead of "}".
"./includes/gnutls/gnutls.h", line 689: Warning, identexpected:
Identifier expected instead of "}".
"./includes/gnutls/gnutls.h", line 723: Warning, identexpected:
Identifier expected instead of "}".
"./includes/gnutls/gnutls.h", line 1587: Warning, identexpected:
Identifier expected instead of "}".
"./includes/gnutls/gnutls.h", line 1926: Warning, identexpected:
Identifier expected instead of "}".
"./includes/gnutls/gnutls.h", line 2074: Warning, identexpected:
Identifier expected instead of "}".
"gnutlsxx.cpp", line 364: Warning (Anachronism), badargtype2w: Formal
argument store_func of type extern "C"
int(*)(void*,gnutls_datum_t,gnutls_datum_t) in call to
gnutls_db_set_store_function(gnutls_session_int*, extern "C"
int(*)(void*,gnutls_datum_t,gnutls_datum_t)) is being passed
int(*)(void*,gnutls_datum_t,gnutls_datum_t).
"gnutlsxx.cpp", line 365: Warning (Anachronism), badargtype2w: Formal
argument retr_func of type extern "C"
gnutls_datum_t(*)(void*,gnutls_datum_t) in call to
gnutls_db_set_retrieve_function(gnutls_session_int*, extern "C"
gnutls_datum_t(*)(void*,gnutls_datum_t)) is being passed
gnutls_datum_t(*)(void*,gnutls_datum_t).
"gnutlsxx.cpp", line 366: Warning (Anachronism), badargtype2w: Formal
argument rem_func of type extern "C" int(*)(void*,gnutls_datum_t) in
call to gnutls_db_set_remove_function(gnutls_session_int*, extern "C"
int(*)(void*,gnutls_datum_t)) is being passed
int(*)(void*,gnutls_datum_t).
"gnutlsxx.cpp", line 642: Warning, wvarhidemem: type hides
gnutls::credentials::type.
"gnutlsxx.cpp", line 648: Warning, wvarhidemem: type hides
gnutls::credentials::type.
"gnutlsxx.cpp", line 655: Warning, wvarhidemem: type hides
gnutls::credentials::type.
"gnutlsxx.cpp", line 661: Warning, wvarhidemem: type hides
gnutls::credentials::type.
"gnutlsxx.cpp", line 668: Warning, wvarhidemem: type hides
gnutls::credentials::type.
"gnutlsxx.cpp", line 676: Warning, wvarhidemem: type hides
gnutls::credentials::type.
"gnutlsxx.cpp", line 683: Warning, wvarhidemem: type hides
gnutls::credentials::type.
25 Warning(s) detected.


From m at matthewlai.ca  Wed Apr 30 20:18:30 2014
From: m at matthewlai.ca (Matthew Lai)
Date: Wed, 30 Apr 2014 11:18:30 -0700
Subject: [gnutls-help] gnutls-3.2.13 : another code bug "base64.c",
 line 99: error: void function cannot return value
In-Reply-To: <1398879638.4169.9.camel@nomad.lan>
References: <1005583104.59634.1398810269726.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
 <CAJU7zaKf4emnVL0BYgUwpLhYiBuP9OKrAwbwTyEDL8_7ia2+EA@mail.gmail.com>
 <1790793603.27236.1398876636624.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
 <1398879638.4169.9.camel@nomad.lan>
Message-ID: <53613E76.3020104@matthewlai.ca>

On 30/04/2014 10:40 AM, Nikos Mavrogiannopoulos wrote:
>> The problem is not "my compiler" but "the code" wherein there are
>> returns
>> for void functions.  That is just wrong on all compilers.  The fact
>> that
>> this somehow slides past GCC makes me question GCC even more.
> and is that syntax forbidden by C99? Most major compilers support that
> syntax due to C++, so it may simply be a limitation of the solaris
> compiler.
Looks like it is valid C++, but not valid C99.

http://stackoverflow.com/questions/3383090/is-returning-void-valid-code

Matthew


From dev at cor0.com  Wed Apr 30 20:37:15 2014
From: dev at cor0.com (dev)
Date: Wed, 30 Apr 2014 14:37:15 -0400 (EDT)
Subject: [gnutls-help] "x509.c",
 line 2894: warning: argument #3 is incompatible with prototype:
Message-ID: <1655514655.45280.1398883035932.JavaMail.vpopmail@webmail2.networksolutionsemail.com>

cause :

"x509.c", line 2894: warning: argument #3 is incompatible with
prototype:
        prototype: pointer to unsigned int :
"./../includes/gnutls/x509-ext.h", line 64
        argument : pointer to enum gnutls_x509_subject_alt_name_t
{GNUTLS_SAN_OTHERNAME_XMPP(1000), GNUTLS_SAN_DN(6),
GNUTLS_SAN_OTHERNAME(5), GNUTLS_SAN_IPADDRESS(4), GNUTLS_SAN_URI(3),
GNUTLS_SAN_RFC822NAME(2), GNUTLS_SAN_DNSNAME(1)}


$ diff ./tests/x509-extensions.c_backup ./tests/x509-extensions.c
440c440
<       unsigned type;
---
>       gnutls_x509_subject_alt_name_t type;


$ diff ./lib/includes/gnutls/x509-ext.h_backup
./lib/includes/gnutls/x509-ext.h
65c65
<                                 unsigned int *type,
---
>                                 gnutls_x509_subject_alt_name_t *type,

$ diff ./lib/x509/x509_ext.c_backup ./lib/x509/x509_ext.c
2183c2183
<                                   unsigned int seq, unsigned int
*type,
---
>                                   unsigned int seq,
> gnutls_x509_subject_alt_name_t *type,


From dkg at fifthhorseman.net  Wed Apr 30 20:45:00 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 30 Apr 2014 14:45:00 -0400
Subject: [gnutls-help] "x509.c",
 line 2894: warning: argument #3 is incompatible with prototype:
In-Reply-To: <1655514655.45280.1398883035932.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
References: <1655514655.45280.1398883035932.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
Message-ID: <536144AC.5000205@fifthhorseman.net>

On 04/30/2014 02:37 PM, dev wrote:
> cause :
> 
> "x509.c", line 2894: warning: argument #3 is incompatible with
> prototype:
>         prototype: pointer to unsigned int :
> "./../includes/gnutls/x509-ext.h", line 64
>         argument : pointer to enum gnutls_x509_subject_alt_name_t
> {GNUTLS_SAN_OTHERNAME_XMPP(1000), GNUTLS_SAN_DN(6),
> GNUTLS_SAN_OTHERNAME(5), GNUTLS_SAN_IPADDRESS(4), GNUTLS_SAN_URI(3),
> GNUTLS_SAN_RFC822NAME(2), GNUTLS_SAN_DNSNAME(1)}

thanks for your code cleanup efforts, dev!

can you please send future patches in unified diff format (diff -u)
instead of the old-style diff format?  unified diffs are more stable and
give a bit more context to the reader.

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140430/db409814/attachment.sig>

From dev at cor0.com  Wed Apr 30 21:11:41 2014
From: dev at cor0.com (dev)
Date: Wed, 30 Apr 2014 15:11:41 -0400 (EDT)
Subject: [gnutls-help] "x509.c",
 line 2894: warning: argument #3 is incompatible with prototype:
In-Reply-To: <536144AC.5000205@fifthhorseman.net>
References: <1655514655.45280.1398883035932.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
 <536144AC.5000205@fifthhorseman.net>
Message-ID: <1596608598.47451.1398885101835.JavaMail.vpopmail@webmail2.networksolutionsemail.com>



On April 30, 2014 at 2:45 PM Daniel Kahn Gillmor <dkg at fifthhorseman.net>
wrote:
> On 04/30/2014 02:37 PM, dev wrote:
> > cause :
> >
> > "x509.c", line 2894: warning: argument #3 is incompatible with
> > prototype:
> >         prototype: pointer to unsigned int :
> > "./../includes/gnutls/x509-ext.h", line 64
> >         argument : pointer to enum gnutls_x509_subject_alt_name_t
> > {GNUTLS_SAN_OTHERNAME_XMPP(1000), GNUTLS_SAN_DN(6),
> > GNUTLS_SAN_OTHERNAME(5), GNUTLS_SAN_IPADDRESS(4), GNUTLS_SAN_URI(3),
> > GNUTLS_SAN_RFC822NAME(2), GNUTLS_SAN_DNSNAME(1)}
>
> thanks for your code cleanup efforts, dev!
>
> can you please send future patches in unified diff format (diff -u)
> instead of the old-style diff format?  unified diffs are more stable
> and
> give a bit more context to the reader.

Sorry.  What is the standard in the code for indents? I see tabs and
spaces
and if I make a change I will try to keep the line to 72 char or less in
length and generally indent with spaces but I see a mixture of both.


Also when I run into little things like this :

  CCLD     libgnutls-openssl.la
Undefined                       first referenced
 symbol                             in file
nanosleep                           .libs/gnutls_openssl.o
  (symbol belongs to implicit dependency /lib/64/librt.so.1)
ld: fatal: symbol referencing errors.
No output written to .libs/libgnutls-openssl.so.27.0.2
gmake[3]: *** [libgnutls-openssl.la] Error 2


I know that the fix won't be in the code because nanosleep on Solaris
needs -lrt in the link stage and I have to hack Makefile like so :


$ diff -u extra/Makefile.backup extra/Makefile
--- extra/Makefile.backup       Wed Apr 30 18:32:45 2014
+++ extra/Makefile      Wed Apr 30 18:56:41 2014
@@ -976,7 +976,7 @@
 LIBPTHREAD_PREFIX =
 LIBRT = -lrt
 LIBRT_PREFIX =
-LIBS = -lintl -lgen
+LIBS = -lintl -lgen -lrt
 LIBSOCKET = -lsocket
 LIBTASN1_CFLAGS =
 LIBTASN1_LIBS =


So that isn't a code change and so not sure how to help with that.

However things like this I can fix :

gmake[4]: Entering directory
`/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_001/src/libopts'
  CC       libopts_la-libopts.lo
"./compat/compat.h", line 188: error: invalid type combination
"./compat/compat.h", line 188: warning: typedef declares no type name
cc: acomp failed for libopts.c
gmake[4]: *** [libopts_la-libopts.lo] Error 1
gmake[4]: Leaving directory
`/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_001/src/libopts'


I'll use diff -u and just mail them in.


dev


From dev at cor0.com  Wed Apr 30 23:45:43 2014
From: dev at cor0.com (dev)
Date: Wed, 30 Apr 2014 17:45:43 -0400 (EDT)
Subject: [gnutls-help] "x509.c",
 line 2894: warning: argument #3 is incompatible with prototype:
In-Reply-To: <536144AC.5000205@fifthhorseman.net>
References: <1655514655.45280.1398883035932.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
 <536144AC.5000205@fifthhorseman.net>
Message-ID: <1563781636.57798.1398894343505.JavaMail.vpopmail@webmail2.networksolutionsemail.com>


I have hit a head scratch moment where I am trying to figure out
what the intent was in  src/libopts/compat/compat.h :

gmake[4]: Entering directory
`/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_001/src/libopts'
  CC       libopts_la-libopts.lo
"./compat/compat.h", line 188: error: invalid type combination


Well that's not good. So I look and see what looks like and
enumerated data type being defined as type _Bool complete
with a capital "B" :

   185  #ifdef HAVE_STDBOOL_H
   186  #  include <stdbool.h>
   187  #else
   188     typedef enum { false = 0, true = 1 } _Bool;
   189  #  define bool _Bool
   190
   191     /* The other macros must be usable in preprocessor
directives.  */
   192  #  define false 0
   193  #  define true 1
   194  #endif
   195

Well that's odd because I am not forcing C99 compliance.  I checked
stdbool.h
where I see :

/*
 * Included for alignment with the ISO/IEC 9899:1999 standard. The
 * contents of this header are only visible when using a c99
 * compiler, otherwise inclusion of this header will result in a
 * forced compilation failure.
 *
 * Note that the ability to undefine and redefine the macros bool,
 * true, and false  is an obsolescent feature which may be withdrawn
 * in a future version of the standards specifications.
 */


Also here :

http://pubs.opengroup.org/onlinepubs/009604499/basedefs/stdbool.h.html

So what is the intent here ?

Should I try to compile with c99 and not cc here ?

Dennis

ps: I have a 99% clean compile now .. just need to mail in a few
patches.


From nmav at gnutls.org  Wed Apr 30 23:51:17 2014
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 30 Apr 2014 23:51:17 +0200
Subject: [gnutls-help] what exactly is gnutls 3.2.13 and 3.3.1 looking
 for in libgmp ??
In-Reply-To: <1545227721.29335.1398878775544.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
References: <527955416.40066.1398798092325.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
 <CAJU7zaKgczz_S110fPR1KLoYt-WT84xYzGjGHAjLHZKT7B-TpA@mail.gmail.com>
 <1545227721.29335.1398878775544.JavaMail.vpopmail@webmail2.networksolutionsemail.com>
Message-ID: <1398894677.30886.2.camel@nomad.lan>

On Wed, 2014-04-30 at 13:26 -0400, dev wrote:

> > Did you pass the correct LDFLAGS to configure? i.e.,
> > LDFLAGS=-L/usr/local/lib ./configure? As gmp doesn't use pkg-config
> > the configure script cannot easily derive them.
> nope .. just tried with LD_FLAGS set and see this :

Why did you add an underscore? configure uses LDFLAGS.

> I'll use LD_LIBRARY_PATH for the configure stage and then remove it and
> try to do the compile with more stringent compiler flags and see what
> else shakes loose. With a bit of work the code base could be squeaky
> clean and compile everywhere.

I don't think that would help in that case. Check ./configure --help for
the flags you could specify to ease discovery. 

regards,
Nikos