From sona.sarmadi at enea.com  Tue Sep  1 08:32:20 2015
From: sona.sarmadi at enea.com (Sona Sarmadi)
Date: Tue, 1 Sep 2015 06:32:20 +0000
Subject: [gnutls-devel] Use CVE-2015-6251 for GNUTLS-SA-2015-3.
Message-ID: <3230301C09DEF9499B442BBE162C5E4825A1FC08@SESTOEX04.enea.se>

Greetings,

The Security Advisories page below says: "GNUTLS-SA-2015-2 No CVE assigned"
http://www.gnutls.org/security.html#GNUTLS-SA-2015-1


Mitre has assigned CVE-2015-6251 for GNUTLS-SA-2015-3:
http://www.openwall.com/lists/oss-security/2015/08/17/6 

Just wanted to ping you to update the page, not sure though if this is the right mailing list.

One question,
Why "CVE-2015-3308 gnutls: use-after-free flaw in CRL distribution points parsing" is not listed in 
the Security Advisories page? 

(This is of some unknown reason for me still " ** RESERVED **" by Mitre:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3308)

Thanks
//Sona



From nmav at gnutls.org  Tue Sep  1 16:19:18 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 1 Sep 2015 16:19:18 +0200
Subject: [gnutls-devel] Use CVE-2015-6251 for GNUTLS-SA-2015-3.
In-Reply-To: <3230301C09DEF9499B442BBE162C5E4825A1FC08@SESTOEX04.enea.se>
References: <3230301C09DEF9499B442BBE162C5E4825A1FC08@SESTOEX04.enea.se>
Message-ID: <CAJU7za+k5x=MXiJppe+v9gzpV8nst7VNDdn4hn0qWAxwjc+h2Q@mail.gmail.com>

On Tue, Sep 1, 2015 at 8:32 AM, Sona Sarmadi <sona.sarmadi at enea.com> wrote:
> Greetings,
> The Security Advisories page below says: "GNUTLS-SA-2015-2 No CVE assigned"
> http://www.gnutls.org/security.html#GNUTLS-SA-2015-1
> Mitre has assigned CVE-2015-6251 for GNUTLS-SA-2015-3:
> http://www.openwall.com/lists/oss-security/2015/08/17/6
> Just wanted to ping you to update the page, not sure though if this is the right mailing list.

Hello Sona,
 This is the right mailing list. Not sure I understand the request.
GNUTLS-SA-2015-3 has CVE-2015-6251 assigned, and I think that this is
visible in the security page. GNUTLS-SA-2015-2 has indeed no CVE
assigned which is also reflected in that page.

> One question,
> Why "CVE-2015-3308 gnutls: use-after-free flaw in CRL distribution points parsing" is not listed in
> the Security Advisories page?

I tend to prioritise advisories for issues that affect the majority of
applications. E.g., if there is a bug which causes a crash in all
gnutls clients, it will get an advisory as soon, for issues that
affect only a small set of applications an advisory may be skipped.
For these issues we rely mostly on 3rd parties' advisories. That's not
ideal, but a compromise due to limited time at the moment.

> (This is of some unknown reason for me still " ** RESERVED **" by Mitre:
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3308)

Is that related with the no CVE assigned issue above?

regards,
Nikos


From snover1992 at gmail.com  Tue Sep  8 10:41:35 2015
From: snover1992 at gmail.com (Loc Vu)
Date: Tue, 8 Sep 2015 15:41:35 +0700
Subject: [gnutls-devel] Fwd: install gnutls fail in kali linux
In-Reply-To: <CAJ_V9QSWdvb9Jknc29csL=pjwRZ5yGW_zrHXZGR_GWiaTbRvOA@mail.gmail.com>
References: <CAJ_V9QSWdvb9Jknc29csL=pjwRZ5yGW_zrHXZGR_GWiaTbRvOA@mail.gmail.com>
Message-ID: <CAJ_V9QRJYbJ5SfjkMd9XM7xyuWaqo=UstcKNYzWXniAxdSaNfg@mail.gmail.com>

---------- Forwarded message ----------
From: Loc Vu <snover1992 at gmail.com>
Date: 2015-09-08 11:27 GMT+07:00
Subject: install gnutls fail in kali linux
To: gnutls-help at lists.gnutls.org


HI.I have a problem when try to install gnutls in kali linux.
in configure process :
root at lco:~/Downloads/gnutls-3.4.4# ./configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
***
*** Checking for compilation programs...

checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for Minix Amsterdam compiler... no
checking for ar... ar
checking for ranlib... ranlib
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether _XOPEN_SOURCE should be defined... no
checking for _LARGEFILE_SOURCE value needed for large files... no
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking dependency style of gcc... gcc3
checking the archiver (ar) interface... ar
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking for bison... no
checking for byacc... no
checking for a sed that does not truncate output... /bin/sed
checking for autogen... /bin/true
configure: WARNING:
***
*** autogen not found. Will not link against libopts.
***
checking for inline... inline
checking for ANSI C header files... (cached) yes
checking cpuid.h usability... yes
checking cpuid.h presence... yes
checking for cpuid.h... yes
checking for getrandom... no
checking for getentropy... no
checking for NETTLE... no
configure: error:
  ***
  *** Libnettle 3.1 was not found.


I have manually isntalll libnettle3.1 but it's still not found.My English
is not good so hope you can understand.
Thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150908/19f68ace/attachment.html>

From tzz at lifelogs.com  Tue Sep  8 16:21:49 2015
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Tue, 08 Sep 2015 10:21:49 -0400
Subject: [gnutls-devel] simplifying certificate verification
References: <CAJU7za+uq9179fFiP=W1MSorpYXwW2hAXv4y3h9g0Ua52qYn9w@mail.gmail.com>
Message-ID: <87io7lf0ua.fsf@lifelogs.com>

On Mon, 24 Aug 2015 13:58:08 +0200 Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> wrote: 

NM> One the pains in using gnutls is the fact that there is needed quite
NM> some copy-paste code to perform certificate verification. I decided to
NM> simplify that from 3.5.0, using a function called
NM> gnutls_session_auto_verify_cert(), and the result can be seen on the
NM> following example
...
NM> I'd appreciate any comments or suggestions for improving that interface [0].

NM> [0]. https://gitlab.com/gnutls/gnutls/blob/master/lib/includes/gnutls/gnutls.h.in#L1296

To me it looks nice and usable. Are there reasons not to use it (other
than backwards compatibility)?  Any logging gotchas for the users (since
the logging will change from their point of view if a GnuTLS upgrade
triggers the use of gnutls_session_auto_verify_cert())?

Thanks
Ted



From nmav at gnutls.org  Fri Sep 11 15:39:04 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 11 Sep 2015 15:39:04 +0200
Subject: [gnutls-devel] simplifying certificate verification
In-Reply-To: <87io7lf0ua.fsf@lifelogs.com>
References: <CAJU7za+uq9179fFiP=W1MSorpYXwW2hAXv4y3h9g0Ua52qYn9w@mail.gmail.com>
 <87io7lf0ua.fsf@lifelogs.com>
Message-ID: <CAJU7zaKBv3oJ-gOrTu0NvYQAcdBnkeVtci6Be+npURHmJy_R+w@mail.gmail.com>

On Tue, Sep 8, 2015 at 4:21 PM, Ted Zlatanov <tzz at lifelogs.com> wrote:
> NM> One the pains in using gnutls is the fact that there is needed quite
> NM> some copy-paste code to perform certificate verification. I decided to
> NM> simplify that from 3.5.0, using a function called
> NM> gnutls_session_auto_verify_cert(), and the result can be seen on the
> NM> following example
> ...
> NM> I'd appreciate any comments or suggestions for improving that interface [0].
> NM> [0]. https://gitlab.com/gnutls/gnutls/blob/master/lib/includes/gnutls/gnutls.h.in#L1296
>
> To me it looks nice and usable. Are there reasons not to use it (other
> than backwards compatibility)?

None that I can think of, if you use X.509 certificates.

>  Any logging gotchas for the users (since
> the logging will change from their point of view if a GnuTLS upgrade
> triggers the use of gnutls_session_auto_verify_cert())?

I introduced a new error code to be returned by gnutls_handshake() on failure.


From nmav at gnutls.org  Sat Sep 12 11:56:47 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 12 Sep 2015 11:56:47 +0200
Subject: [gnutls-devel] gnutls 3.3.18
Message-ID: <1442051807.11698.0.camel@gnutls.org>

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


* Version 3.3.18 (released 2015-09-12)

** libgnutls: When re-importing CRLs to a trust list ensure that there
   no duplicate entries.

** certtool: Removed any arbitrary limits imposed on input file sizes
   and maximum number of certificates imported.

** 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.18.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.18.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

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

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

regards,
Nikos



From nmav at gnutls.org  Sat Sep 12 11:57:37 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 12 Sep 2015 11:57:37 +0200
Subject: [gnutls-devel] gnutls 3.4.5
Message-ID: <1442051857.11698.1.camel@gnutls.org>

Hello, 
 I've just released gnutls 3.4.5. This version fixes bugs and adds
minor features to the next stable branch.


* Version 3.4.5 (released 2015-09-12)

** libgnutls: When re-importing CRLs to a trust list ensure that there
   no duplicate entries.

** certtool: Removed any arbitrary limits imposed on input file sizes
   and maximum number of certificates imported.

** certtool: Allow specifying fixed dates on CRL generation.

** gnutls-cli-debug: Added check for inappropriate fallback support
   (RFC7507).

** 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.4/gnutls-3.4.5.tar.xz
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.5.tar.lz

Here are OpenPGP detached signatures signed using key 0x96865171:

  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.5.tar.xz.sig
  ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.5.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 a.radke at arcor.de  Sat Sep 12 21:34:44 2015
From: a.radke at arcor.de (Andreas Radke)
Date: Sat, 12 Sep 2015 21:34:44 +0200
Subject: [gnutls-devel] gnutls 3.4.5
In-Reply-To: <1442051857.11698.1.camel@gnutls.org>
References: <1442051857.11698.1.camel@gnutls.org>
Message-ID: <20150912213444.66e0eec6@laptop64.home>

This one now fails again building without dane support:

===================================================
   GnuTLS 3.4.5: tests/cert-tests/test-suite.log
===================================================

# TOTAL: 13
# PASS:  10
# SKIP:  2
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

SKIP: certtool
==============

./certtool: line 83: datefudge: command not found

You need datefudge to run this test
SKIP certtool (exit status: 77)

FAIL: pkcs7
===========

import error: ASN1 parser: Error in DER parsing.
full.p7b: PKCS7 decoding failed
FAIL pkcs7 (exit status: 1)

SKIP: template-test
===================

./template-test: line 30: datefudge: command not found

You need datefudge to run this test
SKIP template-test (exit status: 77)


-Andy
Arch LInux


From nmav at gnutls.org  Sun Sep 13 14:11:51 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 13 Sep 2015 14:11:51 +0200
Subject: [gnutls-devel] provable primes in private keys
Message-ID: <1442146311.17766.18.camel@gnutls.org>

For gnutls 3.5.0 (current master branch) I wanted to expose the API to
generate and verify private keys consisting of provable primes as in
FIPS 186-4. That API was internally available and enabled by default
when gnutls was switch to FIPS-140 mode [0].

While the requirements of FIPS have been controversial, this particular
property of generated parameters, seems quite useful for certain
scenarios. That's the reason I decided to expose it in non-FIPS
compliant systems.

It allows to generate RSA or DSA private keys using primes which can be
proven to be prime if given the seed used for their generation. That
currently be done with the following commands:
$ certtool --generate-privkey --provable --outfile key.pem
$ certtool --verify-provable-privkey --load-privkey key.pem
optionally the seed can be given using --seed and it must comply to
FIPS 186-4 requirements (i.e., 2048 and 3072 bit keys and 24 or 32
bytes for RSA seeds).

Unfortunately, to store the generated seed and allow future validation
I had to extend to private key format for both RSA and DSA keys, in a
way that is not compatible with older versions.  For that I introduced
a new pem header (FIPS186-4 RSA PRIVATE KEY).

The API additions can be summarized to these 3 functions:
int
gnutls_x509_privkey_generate2(gnutls_x509_privkey_t key,
  gnutls_pk_algorithm_t algo, unsigned int bits,
  unsigned int flags, const gnutls_keygen_data_st *data,
  unsigned data_size);

int gnutls_x509_privkey_verify_seed(gnutls_x509_privkey_t key, 
  gnutls_digest_algorithm_t, const void *seed, size_t seed_size);
int gnutls_x509_privkey_get_seed(gnutls_x509_privkey_t key, 
  gnutls_digest_algorithm_t*, void *seed, size_t *seed_size);

Any comments or suggestions for improvement?

regards,
Nikos

[0]. https://gitlab.com/gnutls/gnutls/issues/34


From nmav at gnutls.org  Mon Sep 14 15:38:39 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 14 Sep 2015 15:38:39 +0200
Subject: [gnutls-devel] gnutls 3.4.5
In-Reply-To: <20150912213444.66e0eec6@laptop64.home>
References: <1442051857.11698.1.camel@gnutls.org>
 <20150912213444.66e0eec6@laptop64.home>
Message-ID: <CAJU7za+SMABp1TkJjqe8F+_pJMz08HMZKaTSrgj_q2SzBKH4Ng@mail.gmail.com>

On Sat, Sep 12, 2015 at 9:34 PM, Andreas Radke <a.radke at arcor.de> wrote:
> This one now fails again building without dane support:
> FAIL: pkcs7
> ===========
> import error: ASN1 parser: Error in DER parsing.
> full.p7b: PKCS7 decoding failed
> FAIL pkcs7 (exit status: 1)

Thanks. This is a regression of libtasn1 4.6. I've committed a fix in
libtasn1's repository.

regards,
Nikos


From tim.ruehsen at gmx.de  Wed Sep 16 16:57:14 2015
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Wed, 16 Sep 2015 16:57:14 +0200
Subject: [gnutls-devel] Question regarding gnutls_record_set_timeout()
Message-ID: <3828897.2AjAXPMrcH@blitz-lx>

Hi,

I would like to use gnutls_record_set_timeout() instead of using my own 
timeout code.

I see no way to specify an 'indefinite' timeout, e.g. by using a negative 
value. Should I set the fd to blocking or what is the best 'gnutls' way ?


BTW, looking at the code in system_recv_timeout(), with high timeout values, 
there might be unexpected CPU usage due to this loop:

	tv.tv_sec = 0;
	tv.tv_usec = ms * 1000;

	while (tv.tv_usec >= 1000000) {
		tv.tv_usec -= 1000000;
		tv.tv_sec++;
	}

IMHO, it could be replaced by
	tv.tv_sec = ms / 1000;
	tv.tv_usec = (ms % 1000) * 1000;


Regards, Tim



From tzz at lifelogs.com  Wed Sep 16 17:56:44 2015
From: tzz at lifelogs.com (Ted Zlatanov)
Date: Wed, 16 Sep 2015 11:56:44 -0400
Subject: [gnutls-devel] simplifying certificate verification
References: <CAJU7za+uq9179fFiP=W1MSorpYXwW2hAXv4y3h9g0Ua52qYn9w@mail.gmail.com>
 <87io7lf0ua.fsf@lifelogs.com>
 <CAJU7zaKBv3oJ-gOrTu0NvYQAcdBnkeVtci6Be+npURHmJy_R+w@mail.gmail.com>
Message-ID: <87d1xijr2b.fsf@lifelogs.com>

On Fri, 11 Sep 2015 15:39:04 +0200 Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: 

NM> On Tue, Sep 8, 2015 at 4:21 PM, Ted Zlatanov <tzz at lifelogs.com> wrote:

>> Any logging gotchas for the users (since
>> the logging will change from their point of view if a GnuTLS upgrade
>> triggers the use of gnutls_session_auto_verify_cert())?

NM> I introduced a new error code to be returned by gnutls_handshake() on failure.

I think that's fine, and the simplification is great.  Thanks for
working on this.

Ted



From dkg at fifthhorseman.net  Thu Sep 17 01:56:25 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 16 Sep 2015 19:56:25 -0400
Subject: [gnutls-devel] simplifying certificate verification
In-Reply-To: <CAJU7za+uq9179fFiP=W1MSorpYXwW2hAXv4y3h9g0Ua52qYn9w@mail.gmail.com>
References: <CAJU7za+uq9179fFiP=W1MSorpYXwW2hAXv4y3h9g0Ua52qYn9w@mail.gmail.com>
Message-ID: <87si6d6hqu.fsf@alice.fifthhorseman.net>

On Mon 2015-08-24 07:58:08 -0400, Nikos Mavrogiannopoulos wrote:
> One the pains in using gnutls is the fact that there is needed quite
> some copy-paste code to perform certificate verification. I decided to
> simplify that from 3.5.0, using a function called
> gnutls_session_auto_verify_cert(), and the result can be seen on the
> following example
>
> https://gitlab.com/gnutls/gnutls/blob/master/doc/examples/ex-client-x509.c
>
> That is about ~60 lines of code less per program using gnutls.
> https://gitlab.com/gnutls/gnutls/commit/25f2b0814401d1e9c98f3fdc833e09b3c877fc72
>
> I'd appreciate any comments or suggestions for improving that interface [0].

I really like the idea of simplifying this UI to something managable and
correct by default for the common use case.  In particular, i think the
common use case is for TLS clients to verify server certificates.
Handling that simply would make the life of many developers much
better. :)

Is this interface intended to work for servers to verify client
certificates as well?  I think we should avoid trying to make one
configuration that handles them both, and this improvement should focus
explicitly on the server certificate use case.

But the proposed interface is a bit unclear to me, and i'd be happy to
help clarify it.  I'm looking at master, at
368018efccee25f82149cba47e05f5af6af28ae9.

Looking at NEWS :

It says gnutls_session_auto_verify_cert() was added, but
gnutls_session_set_verify_cert and gnutls_session_set_verify_cert2()
functions are the only ones i see implemented and exposed in the
headers. what am i missing?

Looking at gnutls.h.in:

> /**
>  * gnutls_vdata_types_t:
>  * @GNUTLS_DT_UNKNOWN: Unknown data type.
>  * @GNUTLS_DT_DNS_HOSTNAME: The data contain a null-terminated DNS hostname.
>  * @GNUTLS_DT_RFC822NAME: The data contain a null-terminated email address.
>  * @GNUTLS_DT_KEY_PURPOSE_OID: The data contain a null-terminated key purpose OID.
>  *
>  * Enumeration of different key exchange algorithms.
>  */

These are not key exchange algorithms.  Maybe they're "X.509 certificate
data field elements" or something?

> typedef enum {
>         GNUTLS_DT_UNKNOWN = 0,
>         GNUTLS_DT_DNS_HOSTNAME = 1,
>         GNUTLS_DT_KEY_PURPOSE_OID = 2,
>         GNUTLS_DT_RFC822NAME = 3
> } gnutls_vdata_types_t;
> 
> typedef struct {
>         gnutls_vdata_types_t type;
>         unsigned char *data;
>         unsigned int size;
> } gnutls_typed_vdata_st;

This seems to be a set of fields that the user is asking GnuTLS to look
for in the cert, but it's unclear what it means -- for example, with
GNUTLS_DT_DNS_HOSTNAME:

Would an element of this type be checked only in SubjectAltNames, or
would it also checked in the leaf CommonName of the Subject's
DistinguishedName?  Is it verified case-insensitively?  normalized in
any way?  how is IDN/punycode handled?

If multiple GNUTLS_DT_DNS_HOSTNAMEs are listed in an array of
gnutls_typed_vdata_st, would any of them acceptable for verification?
or do they all have to be present?

For GNUTLS_DT_RFC822NAME, are these SubjectAltNames also, or will they
be looked for in other fields in the cert?

For GNUTLS_DT_KEY_PURPOSE_OID, is that keyUsage or extendedKeyUsage?  In
practice and in specifications, keyUsage and extendedKeyUsage have
unusual combining behavior -- see, for example, the discussion in
https://bugzilla.mozilla.org/show_bug.cgi?id=1049176 about the
relationship between kU and eKU.  In particular RFC 5280 says:

   If a certificate contains both a key usage extension and an extended
   key usage extension, then both extensions MUST be processed
   independently and the certificate MUST only be used for a purpose
   consistent with both extensions.  If there is no purpose consistent
   with both extensions, then the certificate MUST NOT be used for any
   purpose.

So what would that requirement look like?

What about adding something like a SRVNAME option here as well to handle
https://tools.ietf.org/html/rfc6125#section-6.5.1 ?

Looking at lib/auto-verify.c:

> /**
>  * gnutls_session_set_verify_cert:
>  * @session: is a gnutls session
>  * @hostname: is the expected name of the peer; may be %NULL
>  * @flags: flags for certificate verification -- #gnutls_certificate_verify_flags
>  *
>  * This function instructs GnuTLS to verify the peer's certificate
>  * using the provided hostname. If the verification fails the handshake
>  * will also fail with %GNUTLS_E_CERTIFICATE_VERIFICATION_ERROR. In that
>  * case the verification result can be obtained using gnutls_session_get_verify_cert_status().

The same questions about GNUTLS_DT_DNS_HOSTNAME above (canonicalization;
SAN vs. Subject leaf CN) apply here.

Also, it looks to me like this doesn't verify anything about the
server's certificate's eKU or kU flags -- but i think the simple default should at least:

 (a) if keyUsage extension exists, require the appropriate flags for the
     type of key exchange mechanism used in the TLS handshake
     (digitalSignature for (EC)DHE, keyEncipherment for RSA, or
     keyAgreement for static DH)

 (b) if extendedKeyUsage extension exists, require the "TLS Server"
      value set (id-kp-serverAuth)

Or are these requirements already present by default?

We might also want to review the policies articulated by the CA/B Forum
for subscriber certificates:

https://cabforum.org/baseline-requirements-certificate-contents/#Subscriber-Certificates

I'm no big fan of the CA/B forum, but some of their recommendations may
be things we want to expect.  At the moment, i'm torn about their
requirement for BasicConstraints: CA:False for end-entity certificates.
I think that's an excellent requirement for CAs issuing EE certs -- i'm
not sure whether we should enforce it as a TLS client as well.

I'm sure there are some homebrew CA setups that use CA:True certs for
servers.

>  * The @hostname pointer provided must remain valid for the lifetime
>  * of the session. More precisely it should be available during any subsequent
>  * handshakes.

This memory management sounds cumbersome to me for what will likely
become the default handler for most applications -- though it's similar
to gnutls_credentials_set.  The difference is that this is likely to be
called from code that itself received the hostname from elsewhere.  Can
we have the session object allocate a copy for the case where this
default function is called so that the default caller doesn't have to
think about bundling the hostname's memory management with the session
object?

>    If not hostname is provided, no hostname verification
>  * will be performed.

This should be "If no hostname is provided, ..."  Perhaps it should also
indicate what else happens -- for example, if no hostname verification
is performed, is any certificate valid?  or does GnuTLS only check that
the certificate chains back to a trusted root, which means it can be
replaced by any other certificate that chains to a trusted root?  We
should be clear that leaving hostname blank here represents a security
risk.

>     For a more advanced verification function check
>  * gnutls_session_set_verify_cert2().
>  *
>  * That function is intended to be used by clients.

which function?  It's unclear whether this last sentence applies to
g_s_set_verify_cert() or g_s_set_verify_cert2().

is "by clients" supposed to mean "only TLS clients"?  What happens if a
server calls it?


> /**
>  * gnutls_session_set_verify_cert2:
>  * @session: is a gnutls session
>  * @data: an array of typed data
>  * @elements: the number of data elements
>  * @flags: flags for certificate verification -- #gnutls_certificate_verify_flags
>  *
>  * This function instructs GnuTLS to verify the peer's certificate
>  * using the provided typed data information. If the verification fails the handshake
>  * will also fail with %GNUTLS_E_CERTIFICATE_VERIFICATION_ERROR. In that
>  * case the verification result can be obtained using gnutls_session_get_verify_cert_status().
>  *
>  * The acceptable typed data are the same as in gnutls_certificate_verify_peers(),
>  * and once set must remain valid for the lifetime of the session. More precisely
>  * they should be available during any subsequent handshakes.
>  *
>  * Since: 3.5.0
>  **/
> void gnutls_session_set_verify_cert2(gnutls_session_t session,
> 				     gnutls_typed_vdata_st * data,
> 				     unsigned elements,
> 				     unsigned flags)
> {

Would it help to comment here that this is equivalent to calling
gnutls_certificate_verify_peers with the same data object?

Regards,

      --dkg


From dkg at fifthhorseman.net  Thu Sep 17 01:59:12 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 16 Sep 2015 19:59:12 -0400
Subject: [gnutls-devel] [PATCH] improve docs for
	gnutls_certificate_verify_peers*()
Message-ID: <1442447952-6610-1-git-send-email-dkg@fifthhorseman.net>

The gnutls_certificate_verify_peers{,2,3}() functions all return
GNUTLS_E_SUCCESS (0) even in situations when the peer's certificate
was not verified.  This is explained in the first paragraphs
("i.e. failure to trust a certificate does not imply a negative return
value"), but the Returns: line isn't comparably clear.
---
 lib/cert.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/lib/cert.c b/lib/cert.c
index fb01d1b..2d79c96 100644
--- a/lib/cert.c
+++ b/lib/cert.c
@@ -597,7 +597,9 @@ _gnutls_openpgp_crt_verify_peers(gnutls_session_t session,
  * the verified certificate belongs to the actual peer, see gnutls_x509_crt_check_hostname(),
  * or use gnutls_certificate_verify_peers3().
  *
- * Returns: a negative error code on error and %GNUTLS_E_SUCCESS (0) on success.
+ * Returns: a negative error code on error and %GNUTLS_E_SUCCESS (0)
+ * when the peer's certificate was successfully parsed, whether or not
+ * it was verified.
  **/
 int
 gnutls_certificate_verify_peers2(gnutls_session_t session,
@@ -629,7 +631,9 @@ gnutls_certificate_verify_peers2(gnutls_session_t session,
  * In order to verify the purpose of the end-certificate (by checking the extended
  * key usage), use gnutls_certificate_verify_peers().
  *
- * Returns: a negative error code on error and %GNUTLS_E_SUCCESS (0) on success.
+ * Returns: a negative error code on error and %GNUTLS_E_SUCCESS (0) 
+ * when the peer's certificate was successfully parsed, whether or not
+ * it was verified.
  *
  * Since: 3.1.4
  **/
@@ -673,7 +677,9 @@ gnutls_typed_vdata_st data;
  * usage PKIX extension, it will be required to be have the provided key purpose 
  * or be marked for any purpose, otherwise verification will fail with %GNUTLS_CERT_SIGNER_CONSTRAINTS_FAILURE status.
  *
- * Returns: a negative error code on error and %GNUTLS_E_SUCCESS (0) on success.
+ * Returns: a negative error code on error and %GNUTLS_E_SUCCESS (0)
+ * when the peer's certificate was successfully parsed, whether or not
+ * it was verified.
  *
  * Since: 3.3.0
  **/
-- 
2.5.1



From tim.ruehsen at gmx.de  Thu Sep 17 16:52:32 2015
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Thu, 17 Sep 2015 16:52:32 +0200
Subject: [gnutls-devel] Question regarding gnutls_record_set_timeout()
In-Reply-To: <CAJU7zaKBbp2AAL4SdGphXr3hJTt9KZdwg1+VzCMLr+TPiYPOhg@mail.gmail.com>
References: <3828897.2AjAXPMrcH@blitz-lx>
 <CAJU7zaKBbp2AAL4SdGphXr3hJTt9KZdwg1+VzCMLr+TPiYPOhg@mail.gmail.com>
Message-ID: <2758704.d37AHcddQ4@blitz-lx>

On Thursday 17 September 2015 14:53:06 Nikos Mavrogiannopoulos wrote:
> On Wed, Sep 16, 2015 at 4:57 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> > Hi,
> > I would like to use gnutls_record_set_timeout() instead of using my own
> > timeout code.
> > I see no way to specify an 'indefinite' timeout, e.g. by using a negative
> > value. Should I set the fd to blocking or what is the best 'gnutls' way ?
> 
> The timeout for this function only makes sense with blocking fds. For
> non-blocking fds you always have the function return as soon as
> possible. By not setting a timeout with this function you get the
> indefinite timeout. Does this answer your question?

Just a slight correction.
I use gnutls_record_set_timeout() / gnutls_record_recv() together with non-
blocking sockets. And it works flawlessly since the timeout just adds a 
select() before the read().
If you take a blocking fd, you might experience a select() saying 'yo man, 
it's readable' and the subsequent read() being stuck. At least I experienced 
this a long time ago and since than I never used blocking fds any more :-)
(but this is beyond discussion here, I guess).

So, Yes. So far I can live with a max. timeout of 2^32 / 1000 seconds (that's 
almost 50 days). I guess no one ever complains...

Thanks for your answer and sorry for the noise.

Tim



From nmav at gnutls.org  Thu Sep 17 10:08:47 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 17 Sep 2015 10:08:47 +0200
Subject: [gnutls-devel] [PATCH] improve docs for
	gnutls_certificate_verify_peers*()
In-Reply-To: <1442447952-6610-1-git-send-email-dkg@fifthhorseman.net>
References: <1442447952-6610-1-git-send-email-dkg@fifthhorseman.net>
Message-ID: <CAJU7za+qDcw+NKx8MXNp10Trtc=H+bx1LSdvh7y-Bcq5fQa82Q@mail.gmail.com>

On Thu, Sep 17, 2015 at 1:59 AM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> The gnutls_certificate_verify_peers{,2,3}() functions all return
> GNUTLS_E_SUCCESS (0) even in situations when the peer's certificate
> was not verified.  This is explained in the first paragraphs
> ("i.e. failure to trust a certificate does not imply a negative return
> value"), but the Returns: line isn't comparably clear.

Applied, thanks.


From nmav at gnutls.org  Thu Sep 17 14:53:06 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 17 Sep 2015 14:53:06 +0200
Subject: [gnutls-devel] Question regarding gnutls_record_set_timeout()
In-Reply-To: <3828897.2AjAXPMrcH@blitz-lx>
References: <3828897.2AjAXPMrcH@blitz-lx>
Message-ID: <CAJU7zaKBbp2AAL4SdGphXr3hJTt9KZdwg1+VzCMLr+TPiYPOhg@mail.gmail.com>

On Wed, Sep 16, 2015 at 4:57 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> Hi,
> I would like to use gnutls_record_set_timeout() instead of using my own
> timeout code.
> I see no way to specify an 'indefinite' timeout, e.g. by using a negative
> value. Should I set the fd to blocking or what is the best 'gnutls' way ?

The timeout for this function only makes sense with blocking fds. For
non-blocking fds you always have the function return as soon as
possible. By not setting a timeout with this function you get the
indefinite timeout. Does this answer your question?

> BTW, looking at the code in system_recv_timeout(), with high timeout values,
> there might be unexpected CPU usage due to this loop:
>
>         tv.tv_sec = 0;
>         tv.tv_usec = ms * 1000;
>
>         while (tv.tv_usec >= 1000000) {
>                 tv.tv_usec -=  1000000;
>                 tv.tv_sec++;
>         }
> IMHO, it could be replaced by
>         tv.tv_sec = ms / 1000;
>         tv.tv_usec = (ms % 1000) * 1000;

Indeed, this code was written with small timeout values in mind. I'll update it.

regards,
Nikos


From n.mavrogiannopoulos at gmail.com  Thu Sep 17 10:50:50 2015
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 17 Sep 2015 10:50:50 +0200
Subject: [gnutls-devel] simplifying certificate verification
In-Reply-To: <87si6d6hqu.fsf@alice.fifthhorseman.net>
References: <CAJU7za+uq9179fFiP=W1MSorpYXwW2hAXv4y3h9g0Ua52qYn9w@mail.gmail.com>
 <87si6d6hqu.fsf@alice.fifthhorseman.net>
Message-ID: <CAJU7zaL+BQic5QR2ThwVxnvvND_BuDsX3xVKUzSf_aOrjoMkZQ@mail.gmail.com>

On Thu, Sep 17, 2015 at 1:56 AM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> On Mon 2015-08-24 07:58:08 -0400, Nikos Mavrogiannopoulos wrote:
>> One the pains in using gnutls is the fact that there is needed quite
>> some copy-paste code to perform certificate verification. I decided to
>> simplify that from 3.5.0, using a function called
>> gnutls_session_auto_verify_cert(), and the result can be seen on the
>> following example
>> https://gitlab.com/gnutls/gnutls/blob/master/doc/examples/ex-client-x509.c
>> That is about ~60 lines of code less per program using gnutls.
>> https://gitlab.com/gnutls/gnutls/commit/25f2b0814401d1e9c98f3fdc833e09b3c877fc72
>> I'd appreciate any comments or suggestions for improving that interface [0].
> I really like the idea of simplifying this UI to something managable and
> correct by default for the common use case.  In particular, i think the
> common use case is for TLS clients to verify server certificates.
> Handling that simply would make the life of many developers much
> better. :)
> Is this interface intended to work for servers to verify client
> certificates as well?  I think we should avoid trying to make one
> configuration that handles them both, and this improvement should focus
> explicitly on the server certificate use case.

I also considered that, but for the majority of use cases both can be
handled in quite manageable way (at the cost of using the
gnutls_session_set_verify_cert2()).

> But the proposed interface is a bit unclear to me, and i'd be happy to
> help clarify it.  I'm looking at master, at
> 368018efccee25f82149cba47e05f5af6af28ae9.
> Looking at NEWS :
> It says gnutls_session_auto_verify_cert() was added, but
> gnutls_session_set_verify_cert and gnutls_session_set_verify_cert2()
> functions are the only ones i see implemented and exposed in the
> headers. what am i missing?

I've removed the _auto_ from the name and replaced it with _set_. I've
updated the NEWS to reflect that.

> Looking at gnutls.h.in:
>> /**
>>  * gnutls_vdata_types_t:
>>  * @GNUTLS_DT_UNKNOWN: Unknown data type.
>>  * @GNUTLS_DT_DNS_HOSTNAME: The data contain a null-terminated DNS hostname.
>>  * @GNUTLS_DT_RFC822NAME: The data contain a null-terminated email address.
>>  * @GNUTLS_DT_KEY_PURPOSE_OID: The data contain a null-terminated key purpose OID.
>>  *
>>  * Enumeration of different key exchange algorithms.
>>  */

Corrected. Text updated.

> These are not key exchange algorithms.  Maybe they're "X.509 certificate
> data field elements" or something?
>
>> typedef enum {
>>         GNUTLS_DT_UNKNOWN = 0,
>>         GNUTLS_DT_DNS_HOSTNAME = 1,
>>         GNUTLS_DT_KEY_PURPOSE_OID = 2,
>>         GNUTLS_DT_RFC822NAME = 3
>> } gnutls_vdata_types_t;
>>
>> typedef struct {
>>         gnutls_vdata_types_t type;
>>         unsigned char *data;
>>         unsigned int size;
>> } gnutls_typed_vdata_st;
> This seems to be a set of fields that the user is asking GnuTLS to look
> for in the cert, but it's unclear what it means -- for example, with
> GNUTLS_DT_DNS_HOSTNAME:

The new text is:
 * Enumeration of different typed-data options. They are used as input
to certificate
 * verification functions to provide information about the name and
purpose of the
 * certificate.

> Would an element of this type be checked only in SubjectAltNames, or
> would it also checked in the leaf CommonName of the Subject's
> DistinguishedName?  Is it verified case-insensitively?  normalized in
> any way?  how is IDN/punycode handled?

I've added in the text that RFC6125 comparison is being used.

> If multiple GNUTLS_DT_DNS_HOSTNAMEs are listed in an array of
> gnutls_typed_vdata_st, would any of them acceptable for verification?
> or do they all have to be present?

Only a single one is accepted. I've made that clear.

> For GNUTLS_DT_RFC822NAME, are these SubjectAltNames also, or will they
> be looked for in other fields in the cert?

Since there is no specific RFC for that, I've added more text there.
"The data contain a null-terminated email address; the email will be
 matched against the RFC822Name field of the certificate, or the EMAIL
DN component if the
 former isn't available. Prior to matching the email address will be
converted to ACE
  (ASCII-compatible-encoding)"

> For GNUTLS_DT_KEY_PURPOSE_OID, is that keyUsage or extendedKeyUsage?  In
> practice and in specifications, keyUsage and extendedKeyUsage have
> unusual combining behavior -- see, for example, the discussion in

This is the Extended Key Usage.

> https://bugzilla.mozilla.org/show_bug.cgi?id=1049176 about the
> relationship between kU and eKU.  In particular RFC 5280 says:
>    If a certificate contains both a key usage extension and an extended
>    key usage extension, then both extensions MUST be processed
>    independently and the certificate MUST only be used for a purpose
>    consistent with both extensions.  If there is no purpose consistent
>    with both extensions, then the certificate MUST NOT be used for any
>    purpose.

That's an interesting case. I'm not sure I agree that when an extended
key usage is present the key usage extension should be nullified.
That's certainly something to be clarified in PKIX and RFC5280. As it
is now, I don't think that gnutls is strict about the extended key
usage, unless the verifier explicitly specifies a particular usage.

> So what would that requirement look like?
> What about adding something like a SRVNAME option here as well to handle
> https://tools.ietf.org/html/rfc6125#section-6.5.1 ?

That looks interesting. Please open an issue about it in the issue
tracker so I don't forget for 3.5.0.

> Looking at lib/auto-verify.c:
>
>> /**
>>  * gnutls_session_set_verify_cert:
>>  * @session: is a gnutls session
>>  * @hostname: is the expected name of the peer; may be %NULL
>>  * @flags: flags for certificate verification -- #gnutls_certificate_verify_flags
>>  *
>>  * This function instructs GnuTLS to verify the peer's certificate
>>  * using the provided hostname. If the verification fails the handshake
>>  * will also fail with %GNUTLS_E_CERTIFICATE_VERIFICATION_ERROR. In that
>>  * case the verification result can be obtained using gnutls_session_get_verify_cert_status().
>
> The same questions about GNUTLS_DT_DNS_HOSTNAME above (canonicalization;
> SAN vs. Subject leaf CN) apply here.
> Also, it looks to me like this doesn't verify anything about the
> server's certificate's eKU or kU flags -- but i think the simple default should at least:

The kU flags don't really need to be specified the verifier. The
verification routine has enough information to know when to use them.
The eKU cannot be specified indeed.

>  (a) if keyUsage extension exists, require the appropriate flags for the
>      type of key exchange mechanism used in the TLS handshake
>      (digitalSignature for (EC)DHE, keyEncipherment for RSA, or
>      keyAgreement for static DH)

That should be the case already.

>  (b) if extendedKeyUsage extension exists, require the "TLS Server"
>       value set (id-kp-serverAuth)

I have problem with that because RFC5280 specifies "TLS WWW server
authentication". So if for example this is used for IMAP this key
purpose is invalid. That's the reason it is not set by default.

> Or are these requirements already present by default?
> We might also want to review the policies articulated by the CA/B Forum
> for subscriber certificates:
> https://cabforum.org/baseline-requirements-certificate-contents/#Subscriber-Certificates
> I'm no big fan of the CA/B forum, but some of their recommendations may
> be things we want to expect.  At the moment, i'm torn about their
> requirement for BasicConstraints: CA:False for end-entity certificates.
> I think that's an excellent requirement for CAs issuing EE certs -- i'm
> not sure whether we should enforce it as a TLS client as well.

That's too strict to be useful. It is a good practice to be explicit,
but in reality there will be many cases with certificates that have
some fields implicit. We only need to have good defaults for these
cases.

>>  * The @hostname pointer provided must remain valid for the lifetime
>>  * of the session. More precisely it should be available during any subsequent
>>  * handshakes.
> This memory management sounds cumbersome to me for what will likely
> become the default handler for most applications -- though it's similar
> to gnutls_credentials_set.  The difference is that this is likely to be
> called from code that itself received the hostname from elsewhere.  Can
> we have the session object allocate a copy for the case where this
> default function is called so that the default caller doesn't have to
> think about bundling the hostname's memory management with the session
> object?

Talloc would have been very handy here. I agree, but will have to
think how to solve that. Please open a bug, or follow up if that is
not solved prior to 3.5.0.

>>    If not hostname is provided, no hostname verification
>>  * will be performed.
> This should be "If no hostname is provided, ..."  Perhaps it should also
> indicate what else happens -- for example, if no hostname verification
> is performed, is any certificate valid?  or does GnuTLS only check that
> the certificate chains back to a trusted root, which means it can be
> replaced by any other certificate that chains to a trusted root?  We
> should be clear that leaving hostname blank here represents a security
> risk.

Any text suggestion?

regards,
Nikos


From nmav at gnutls.org  Thu Sep 17 14:53:06 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 17 Sep 2015 14:53:06 +0200
Subject: [gnutls-devel] Question regarding gnutls_record_set_timeout()
In-Reply-To: <3828897.2AjAXPMrcH@blitz-lx>
References: <3828897.2AjAXPMrcH@blitz-lx>
Message-ID: <CAJU7zaKBbp2AAL4SdGphXr3hJTt9KZdwg1+VzCMLr+TPiYPOhg@mail.gmail.com>

On Wed, Sep 16, 2015 at 4:57 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> Hi,
> I would like to use gnutls_record_set_timeout() instead of using my own
> timeout code.
> I see no way to specify an 'indefinite' timeout, e.g. by using a negative
> value. Should I set the fd to blocking or what is the best 'gnutls' way ?

The timeout for this function only makes sense with blocking fds. For
non-blocking fds you always have the function return as soon as
possible. By not setting a timeout with this function you get the
indefinite timeout. Does this answer your question?

> BTW, looking at the code in system_recv_timeout(), with high timeout values,
> there might be unexpected CPU usage due to this loop:
>
>         tv.tv_sec = 0;
>         tv.tv_usec = ms * 1000;
>
>         while (tv.tv_usec >= 1000000) {
>                 tv.tv_usec -=  1000000;
>                 tv.tv_sec++;
>         }
> IMHO, it could be replaced by
>         tv.tv_sec = ms / 1000;
>         tv.tv_usec = (ms % 1000) * 1000;

Indeed, this code was written with small timeout values in mind. I'll update it.

regards,
Nikos


From nmav at gnutls.org  Fri Sep 18 13:06:49 2015
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 18 Sep 2015 13:06:49 +0200
Subject: [gnutls-devel] Question regarding gnutls_record_set_timeout()
In-Reply-To: <2758704.d37AHcddQ4@blitz-lx>
References: <3828897.2AjAXPMrcH@blitz-lx>
 <CAJU7zaKBbp2AAL4SdGphXr3hJTt9KZdwg1+VzCMLr+TPiYPOhg@mail.gmail.com>
 <2758704.d37AHcddQ4@blitz-lx>
Message-ID: <CAJU7zaLgin_U+K1mN_wipiGwYMZP3W+W0=4fTt9_jtQJRvDQug@mail.gmail.com>

On Thu, Sep 17, 2015 at 4:52 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> On Thursday 17 September 2015 14:53:06 Nikos Mavrogiannopoulos wrote:
>> On Wed, Sep 16, 2015 at 4:57 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
>> > Hi,
>> > I would like to use gnutls_record_set_timeout() instead of using my own
>> > timeout code.
>> > I see no way to specify an 'indefinite' timeout, e.g. by using a negative
>> > value. Should I set the fd to blocking or what is the best 'gnutls' way ?
>>
>> The timeout for this function only makes sense with blocking fds. For
>> non-blocking fds you always have the function return as soon as
>> possible. By not setting a timeout with this function you get the
>> indefinite timeout. Does this answer your question?
> Just a slight correction.
> I use gnutls_record_set_timeout() / gnutls_record_recv() together with non-
> blocking sockets. And it works flawlessly since the timeout just adds a
> select() before the read().  If you take a blocking fd, you might experience a select() saying 'yo man,
> it's readable' and the subsequent read() being stuck. At least I experienced
> this a long time ago and since than I never used blocking fds any more :-)
> (but this is beyond discussion here, I guess).

Ok that's a use case I was not aware of... It would be then useful to
have an indicator for indefinite time. Please add an issue on the
issue tracker so I don't forget before 3.5.0.

regards,
Nikos