From nmav at gnutls.org  Wed Jul  6 09:21:36 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 06 Jul 2016 09:21:36 +0200
Subject: [gnutls-devel] gnutls 3.4.14
Message-ID: <1467789696.7018.7.camel@gnutls.org>

Hello,?
?I've just released gnutls 3.4.14. This is a bug fix release of the
current stable branch, which addresses a vulnerability on systems
which utilize gnutls with the p11-kit trust module -see
http://www.gnutls.org/security.html#GNUTLS-SA-2016-2

* Version 3.4.14 (released 2016-06-06)

** libgnutls: Address issue when utilizing the p11-kit trust store
???for certificate verification (GNUTLS-SA-2016-2).

** libgnutls: Fixed DTLS handshake packet reconstruction. Reported by
???Guillaume Roguez.

** libgnutls: Fixed issues with PKCS#11 reading of sensitive objects
???from SafeNet Network HSM. Reported by Anthony Alba.

** libgnutls: Corrected the writing of PKCS#11 CKA_SERIAL_NUMBER.
? ?Report and fix by Stanislav ?idek.

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

? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.14.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.14.tar.xz.sig

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

regards,
Nikos



From nmav at gnutls.org  Wed Jul  6 09:21:43 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 06 Jul 2016 09:21:43 +0200
Subject: [gnutls-devel] gnutls 3.5.2
Message-ID: <1467789703.7018.8.camel@gnutls.org>

Hello,?
?I've just released gnutls 3.5.2. This is a bugfix release for
the 3.5.x branch, which also addresses a vulnerability on systems
which utilize gnutls with the p11-kit trust module.

* Version 3.5.2 (released 2016-06-06)

** libgnutls: Address issue when utilizing the p11-kit trust store
???for certificate verification (GNUTLS-SA-2016-2).

** libgnutls: Fixed DTLS handshake packet reconstruction. Reported by
???Guillaume Roguez.

** libgnutls: Fixed issues with PKCS#11 reading of sensitive objects
???from SafeNet Network HSM. Reported by Anthony Alba in #108.

** libgnutls: Corrected the writing of PKCS#11 CKA_SERIAL_NUMBER.
? ?Report and fix by Stanislav ?idek.

** libgnutls: Added AES-GCM optimizations using the AVX and MOVBE
???instructions. Uses Andy Polyakov's assembly code.

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

? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.2.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.2.tar.xz.sig

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

regards,
Nikos



From nmav at gnutls.org  Wed Jul  6 09:21:19 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 06 Jul 2016 09:21:19 +0200
Subject: [gnutls-devel] gnutls 3.3.24
Message-ID: <1467789679.7018.6.camel@gnutls.org>

Hello,?
?I've just released gnutls 3.3.24. This is a bug-fix release on
the previous stable branch which also addresses a vulnerability on
systems which utilize gnutls with the p11-kit trust module -see
http://www.gnutls.org/security.html#GNUTLS-SA-2016-2

* Version 3.3.24 (released 2016-06-06)

** libgnutls: Address issue when utilizing the p11-kit trust store
???for certificate verification (GNUTLS-SA-2016-2).

** libgnutls: when generating private keys mark the public key as not
???private.

** libgnutls: use secure_getenv() where available to obtain environment
???variables.

** libgnutls: Fixed DTLS handshake packet reconstruction. Reported by
???Guillaume Roguez.

** libgnutls: Fixed issues with PKCS#11 reading of sensitive objects
???from SafeNet Network HSM. Reported by Anthony Alba.

** libgnutls: Corrected reading and writing of PKCS#11
? ?CKA_SERIAL_NUMBER. Report and fix by Stanislav ?idek.

** libgnutls: Enhanced the priority functions to understand -VERS-ALL
? ?keyword to allow compatibility of priority strings between 3.4.x
? ?and 3.3.x.

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

? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.24.tar.xz

Here are OpenPGP detached signatures signed using key 0x96865171:

? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.24.tar.xz.sig

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

regards,
Nikos


From dam at opencsw.org  Fri Jul  8 22:10:09 2016
From: dam at opencsw.org (Dagobert Michelsen)
Date: Fri, 8 Jul 2016 22:10:09 +0200
Subject: [gnutls-devel] memmem missing when trying to compile gnutls 3.5.2
	on Solaris
Message-ID: <839E1FEC-D76A-4BDD-B7D4-E70D66984826@opencsw.org>

Hi,

I noticed ?memmem? is missing when trying to compile the testsuite for gnutls 3.5.2 on Solaris:

gmake[3]: 'setcredcrash' is up to date.
  CCLD     resume-x509
ld: warning: file /home/dam/mgar/pkg/gnutls3/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gnutls-3.5.2/lib/.libs/libgnutls.so: linked to ../lib/.libs/libgnutls.so: attempted multiple inclusion of file
Undefined                       first referenced
 symbol                             in file
memmem                              resume_x509-resume.o
ld: fatal: symbol referencing errors. No output written to resume-x509
collect2: error: ld returned 1 exit status

I suggest to import memmem from gnulib if necessary.


Best regards

  ? Dago


--
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20160708/49ccbce1/attachment.sig>

From n.mavrogiannopoulos at gmail.com  Sat Jul  9 00:44:36 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sat, 09 Jul 2016 00:44:36 +0200
Subject: [gnutls-devel] memmem missing when trying to compile gnutls
 3.5.2 on Solaris
In-Reply-To: <839E1FEC-D76A-4BDD-B7D4-E70D66984826@opencsw.org>
References: <839E1FEC-D76A-4BDD-B7D4-E70D66984826@opencsw.org>
Message-ID: <1468017876.9752.2.camel@gmail.com>

On Fri, 2016-07-08 at 22:10 +0200, Dagobert Michelsen wrote:
> Hi,
> 
> I noticed ?memmem? is missing when trying to compile the testsuite
> for gnutls 3.5.2 on Solaris:
> 
> gmake[3]: 'setcredcrash' is up to date.
> ? CCLD?????resume-x509
> ld: warning: file /home/dam/mgar/pkg/gnutls3/trunk/work/solaris10-
> sparc/build-isa-sparcv8plus/gnutls-3.5.2/lib/.libs/libgnutls.so:
> linked to ../lib/.libs/libgnutls.so: attempted multiple inclusion of
> file
> Undefined???????????????????????first referenced
> ?symbol?????????????????????????????in file
> memmem??????????????????????????????resume_x509-resume.o
> ld: fatal: symbol referencing errors. No output written to resume-
> x509
> collect2: error: ld returned 1 exit status
> I suggest to import memmem from gnulib if necessary.

Memmem() is included in gnutls via gnulib (in gl/ directory) and should
be used in systems that don't have it. Could you check in your logs why
it is not used?

regards,
Nikos



From tim.kosse at filezilla-project.org  Sat Jul  9 13:05:23 2016
From: tim.kosse at filezilla-project.org (Tim Kosse)
Date: Sat, 9 Jul 2016 13:05:23 +0200
Subject: [gnutls-devel] Bugfixes for certificate lists
Message-ID: <a6c756f1-5db8-017b-4858-eecb3edd15cc@filezilla-project.org>

Hi,

for small certificate lists, gnutls_x509_crt_list_import2 is ignoring
the GNUTLS_X509_CRT_LIST_SORT and GNUTLS_X509_CRT_LIST_FAIL_IF_UNSORTED
flags.

As result, gnutls-cli-debug incorrectly reports a server's certificate
chain order as sorted even if it isn't.


I've also fixed the documentation of gnutls_certificate_get_peers, the
list it returns isn't actually sorted.


I wonder, should we add a function that makes it easier to obtain a
sorted peer certificate list (or an error if it cannot be sorted)?


Regards,
Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-gnutls_certificate_get_peers-does-not-return-a-sorte.patch
Type: text/x-patch
Size: 1112 bytes
Desc: not available
URL: </pipermail/attachments/20160709/50cf4462/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-gnutls_x509_crl_list_import2-was-ignoring-the-passed.patch
Type: text/x-patch
Size: 860 bytes
Desc: not available
URL: </pipermail/attachments/20160709/50cf4462/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-gnutls_x509_crt_list_import2-was-ignoring-the-passed.patch
Type: text/x-patch
Size: 878 bytes
Desc: not available
URL: </pipermail/attachments/20160709/50cf4462/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Add-test-for-gnutls_x509_crt_list_import2-with-flag-.patch
Type: text/x-patch
Size: 1103 bytes
Desc: not available
URL: </pipermail/attachments/20160709/50cf4462/attachment-0003.bin>

From dam at opencsw.org  Mon Jul 11 14:28:39 2016
From: dam at opencsw.org (Dagobert Michelsen)
Date: Mon, 11 Jul 2016 14:28:39 +0200
Subject: [gnutls-devel] memmem missing when trying to compile gnutls
	3.5.2 on Solaris
In-Reply-To: <1468017876.9752.2.camel@gmail.com>
References: <839E1FEC-D76A-4BDD-B7D4-E70D66984826@opencsw.org>
 <1468017876.9752.2.camel@gmail.com>
Message-ID: <D4F46B6D-FBB9-46DC-B5F5-1E83155572DA@opencsw.org>

Hi Nikos,

Am 09.07.2016 um 00:44 schrieb Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com>:
> On Fri, 2016-07-08 at 22:10 +0200, Dagobert Michelsen wrote:
>> I noticed ?memmem? is missing when trying to compile the testsuite
>> for gnutls 3.5.2 on Solaris:
>> 
>> gmake[3]: 'setcredcrash' is up to date.
>>   CCLD     resume-x509
>> ld: warning: file /home/dam/mgar/pkg/gnutls3/trunk/work/solaris10-
>> sparc/build-isa-sparcv8plus/gnutls-3.5.2/lib/.libs/libgnutls.so:
>> linked to ../lib/.libs/libgnutls.so: attempted multiple inclusion of
>> file
>> Undefined                       first referenced
>>  symbol                             in file
>> memmem                              resume_x509-resume.o
>> ld: fatal: symbol referencing errors. No output written to resume-
>> x509
>> collect2: error: ld returned 1 exit status
>> I suggest to import memmem from gnulib if necessary.
> 
> Memmem() is included in gnutls via gnulib (in gl/ directory) and should
> be used in systems that don't have it. Could you check in your logs why
> it is not used?

I think this is missing:

> dam at unstable10s [unstable10s]:/home/dam/mgar/pkg/gnutls3/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gnutls-3.5.2/tests > git diff --no-color Makefile.am
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index e1f365f..0be380f 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -53,6 +53,7 @@ AM_CPPFLAGS = \
>  AM_LDFLAGS = -no-install
>  LDADD = ../lib/libgnutls.la \
>         libutils.la \
> +       ../gl/libgnu.la \
>         $(LIBSOCKET) $(INET_NTOP_LIB) $(INET_PTON_LIB) $(LIBSECCOMP)
> 
>  dane_LDADD = $(LDADD) ../libdane/libgnutls-dane.la

Unfortunately I can?t test right now as I don?t have recent enough gettext
at hand - another thing on my todo list for quite some time:
  https://buildfarm.opencsw.org/buildbot/waterfall?category=ggettext


Best regards

  ? Dago


--
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </pipermail/attachments/20160711/29068ed4/attachment-0001.sig>

From n.mavrogiannopoulos at gmail.com  Mon Jul 11 17:29:51 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Mon, 11 Jul 2016 17:29:51 +0200
Subject: [gnutls-devel] memmem missing when trying to compile gnutls
 3.5.2 on Solaris
In-Reply-To: <D4F46B6D-FBB9-46DC-B5F5-1E83155572DA@opencsw.org>
References: <839E1FEC-D76A-4BDD-B7D4-E70D66984826@opencsw.org>
 <1468017876.9752.2.camel@gmail.com>
 <D4F46B6D-FBB9-46DC-B5F5-1E83155572DA@opencsw.org>
Message-ID: <1468250991.2337.2.camel@gmail.com>

On Mon, 2016-07-11 at 14:28 +0200, Dagobert Michelsen wrote:
> ld: fatal: symbol referencing errors. No output written to
> > > resume-
> > > x509
> > > collect2: error: ld returned 1 exit status
> > > I suggest to import memmem from gnulib if necessary.
> > Memmem() is included in gnutls via gnulib (in gl/ directory) and
> > should
> > be used in systems that don't have it. Could you check in your logs
> > why
> > it is not used?
> I think this is missing:
> dam at unstable10s
> > [unstable10s]:/home/dam/mgar/pkg/gnutls3/trunk/work/solaris10-
> > sparc/build-isa-sparcv8plus/gnutls-3.5.2/tests > git diff --no-
> > color Makefile.am
> > diff --git a/tests/Makefile.am b/tests/Makefile.am
> > index e1f365f..0be380f 100644
> > --- a/tests/Makefile.am
> > +++ b/tests/Makefile.am
> > @@ -53,6 +53,7 @@ AM_CPPFLAGS = \
> > ?AM_LDFLAGS = -no-install
> > ?LDADD = ../lib/libgnutls.la \
> > ????????libutils.la \
> > +???????../gl/libgnu.la \
> > ????????$(LIBSOCKET) $(INET_NTOP_LIB) $(INET_PTON_LIB) 

I wanted to avoid introducing the gnulib dependency to all tests as it
often caused problems. I've solved it slightly different:

https://gitlab.com/gnutls/gnutls/commit/ec639d66325db855b91d41c969b753629fea9430

regards,
Nikos



From tim.ruehsen at gmx.de  Tue Jul 12 17:33:59 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Tue, 12 Jul 2016 17:33:59 +0200
Subject: [gnutls-devel] TCP Fast Open
Message-ID: <2702347.Ez2esJkPZ0@blitz-lx>

Hi,

I just wanted to mention that I recently added TFO in Wget2 using GnuTLS 
(tested on Linux, speedup ~ 1xRTT).

Is there any interest in a gnutls_ helper function ?

What I do now is setting my own vec_push function + transport pointer.
In the vec_push function I use sendmsg() with MSG_FASTOPEN and fallback to 
connect/writev on errno=EOPNOTSUPP (ups, just see that I didn't test the 
fallback yet). At this point we need the sockaddr + sockaddrlen of the socket 
descriptor.

From here on I set the vec_push function and the transport pointer 'back to 
normal', which is writev and a socket descriptor.

If there is interest, what would be the best place to add a function for this 
? 
It should be something like
gnutls_transport_set_int_tfo(tcp->ssl_session, tcp->sockfd, sockaddr *addr, 
socklen_t *addrlen);

Or is there any way retrieve addr/addrlen from the socket descriptor ?

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160712/8175eb89/attachment.sig>

From nmav at gnutls.org  Wed Jul 13 09:28:28 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 13 Jul 2016 09:28:28 +0200
Subject: [gnutls-devel] TCP Fast Open
In-Reply-To: <2702347.Ez2esJkPZ0@blitz-lx>
References: <2702347.Ez2esJkPZ0@blitz-lx>
Message-ID: <CAJU7zaK7vji5s7YdrmvVLJEqOCPXoHHo7MXtB_3RbZGtmmBJeA@mail.gmail.com>

On Tue, Jul 12, 2016 at 5:33 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> Hi,
> I just wanted to mention that I recently added TFO in Wget2 using GnuTLS
> (tested on Linux, speedup ~ 1xRTT).

Hi Tim,
 That sounds great. Did you combine that with other optimizations such
as session resumption and false start?

> Is there any interest in a gnutls_ helper function ?

Certainly. I have not a good overview of the changes required, but as
I understand from your description we would have to handle the
connect()/sendmsg() steps within gnutls and its callbacks. As you have
a better overview, I'd suggest that you make a proposal on what you
think is the simplest.

> What I do now is setting my own vec_push function + transport pointer.
> In the vec_push function I use sendmsg() with MSG_FASTOPEN and fallback to
> connect/writev on errno=EOPNOTSUPP (ups, just see that I didn't test the
> fallback yet). At this point we need the sockaddr + sockaddrlen of the socket
> descriptor.
>
> From here on I set the vec_push function and the transport pointer 'back to
> normal', which is writev and a socket descriptor.
>
> If there is interest, what would be the best place to add a function for this
> ?
> It should be something like
> gnutls_transport_set_int_tfo(tcp->ssl_session, tcp->sockfd, sockaddr *addr,
> socklen_t *addrlen);

That sounds reasonable.

> Or is there any way retrieve addr/addrlen from the socket descriptor ?

As far as I know you can get these from already connected sockets.

regards,
Nikos


From tim.ruehsen at gmx.de  Wed Jul 13 13:09:59 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Wed, 13 Jul 2016 13:09:59 +0200
Subject: [gnutls-devel] TCP Fast Open
In-Reply-To: <CAJU7zaK7vji5s7YdrmvVLJEqOCPXoHHo7MXtB_3RbZGtmmBJeA@mail.gmail.com>
References: <2702347.Ez2esJkPZ0@blitz-lx>
 <CAJU7zaK7vji5s7YdrmvVLJEqOCPXoHHo7MXtB_3RbZGtmmBJeA@mail.gmail.com>
Message-ID: <1483702.N32CStMd6Q@blitz-lx>

On Wednesday, July 13, 2016 9:28:28 AM CEST Nikos Mavrogiannopoulos wrote:
> On Tue, Jul 12, 2016 at 5:33 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> > Hi,
> > I just wanted to mention that I recently added TFO in Wget2 using GnuTLS
> > (tested on Linux, speedup ~ 1xRTT).
> 
> Hi Tim,
>  That sounds great. Did you combine that with other optimizations such
> as session resumption and false start?

My solution would work for both, but I didn't implement these optimizations - 
I simply wasn't aware of them. Thanks for pointing out, I'll investigate...

> > Is there any interest in a gnutls_ helper function ?
> 
> Certainly. I have not a good overview of the changes required, but as
> I understand from your description we would have to handle the
> connect()/sendmsg() steps within gnutls and its callbacks. As you have
> a better overview, I'd suggest that you make a proposal on what you
> think is the simplest.

We need addr/addrlen as addition to the socket descriptor before the first 
write. Both would be stored best within the 'session' structure. We also would 
need a helper flag to indicate if a write is the first one or not.

> > What I do now is setting my own vec_push function + transport pointer.
> > In the vec_push function I use sendmsg() with MSG_FASTOPEN and fallback to
> > connect/writev on errno=EOPNOTSUPP (ups, just see that I didn't test the
> > fallback yet). At this point we need the sockaddr + sockaddrlen of the
> > socket descriptor.
> > 
> > From here on I set the vec_push function and the transport pointer 'back
> > to
> > normal', which is writev and a socket descriptor.
> > 
> > If there is interest, what would be the best place to add a function for
> > this ?
> > It should be something like
> > gnutls_transport_set_int_tfo(tcp->ssl_session, tcp->sockfd, sockaddr
> > *addr,
> > socklen_t *addrlen);
> 
> That sounds reasonable.

I'll see if I find some time this afternoon to implement a show case to test 
with (function + usage in gnutls-cli).

> 
> > Or is there any way retrieve addr/addrlen from the socket descriptor ?

> As far as I know you can get these from already connected sockets.

If the socket is already connected, the time for TFO is already over :-)
I couldn't find/remember a way to set the destination address without a 
connect() or sendto()/sendmsg(). If we had such a possibility, we would just 
need a function to switch TFO on/off for a session.

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160713/0837f3da/attachment.sig>

From tim.ruehsen at gmx.de  Wed Jul 13 16:50:38 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Wed, 13 Jul 2016 16:50:38 +0200
Subject: [gnutls-devel] TCP Fast Open
In-Reply-To: <CAJU7zaK7vji5s7YdrmvVLJEqOCPXoHHo7MXtB_3RbZGtmmBJeA@mail.gmail.com>
References: <2702347.Ez2esJkPZ0@blitz-lx>
 <CAJU7zaK7vji5s7YdrmvVLJEqOCPXoHHo7MXtB_3RbZGtmmBJeA@mail.gmail.com>
Message-ID: <61189169.31ZdqjBfC4@blitz-lx>

Hi Nikos,

a question regarding the implementation...

The new function
void
gnutls_transport_set_fastopen(gnutls_session_t session,
			  struct sockaddr *connect_addr, socklen_t connect_addrlen)

needs sys/socket.h included in gnutls.h(.in). Is that ok for you, or how would 
you like me to proceed ? Doing so might break the build on some platforms...

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160713/ff916222/attachment.sig>

From nmav at gnutls.org  Wed Jul 13 17:42:50 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 13 Jul 2016 17:42:50 +0200
Subject: [gnutls-devel] TCP Fast Open
In-Reply-To: <61189169.31ZdqjBfC4@blitz-lx>
References: <2702347.Ez2esJkPZ0@blitz-lx>
 <CAJU7zaK7vji5s7YdrmvVLJEqOCPXoHHo7MXtB_3RbZGtmmBJeA@mail.gmail.com>
 <61189169.31ZdqjBfC4@blitz-lx>
Message-ID: <1468424570.1070.5.camel@gnutls.org>

On Wed, 2016-07-13 at 16:50 +0200, Tim Ruehsen wrote:
> Hi Nikos,
> 
> a question regarding the implementation...
> 
> The new function
> void
> gnutls_transport_set_fastopen(gnutls_session_t session,
> 			??struct sockaddr *connect_addr, socklen_t
> connect_addrlen)
> 
> needs sys/socket.h included in gnutls.h(.in). Is that ok for you, or
> how would?
> you like me to proceed ? Doing so might break the build on some
> platforms...

We can introduce a new header such as gnutls/socket.h. Even if now, it
is for a single function it may pay off in the future by having other
features specific for sockets and the default callbacks.?

regards,
Nikos



From n.mavrogiannopoulos at gmail.com  Thu Jul 14 11:44:00 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 14 Jul 2016 11:44:00 +0200
Subject: [gnutls-devel] TCP Fast Open
In-Reply-To: <1468424570.1070.5.camel@gnutls.org>
References: <2702347.Ez2esJkPZ0@blitz-lx>
 <CAJU7zaK7vji5s7YdrmvVLJEqOCPXoHHo7MXtB_3RbZGtmmBJeA@mail.gmail.com>
 <61189169.31ZdqjBfC4@blitz-lx> <1468424570.1070.5.camel@gnutls.org>
Message-ID: <1468489440.24484.1.camel@gmail.com>

On Wed, 2016-07-13 at 17:42 +0200, Nikos Mavrogiannopoulos wrote:
> On Wed, 2016-07-13 at 16:50 +0200, Tim Ruehsen wrote:
> > 
> > Hi Nikos,
> > 
> > a question regarding the implementation...
> > 
> > The new function
> > void
> > gnutls_transport_set_fastopen(gnutls_session_t session,
> > 			??struct sockaddr *connect_addr, socklen_t
> > connect_addrlen)
> > 
> > needs sys/socket.h included in gnutls.h(.in). Is that ok for you,
> > or
> > how would?
> > you like me to proceed ? Doing so might break the build on some
> > platforms...
> We can introduce a new header such as gnutls/socket.h. Even if now,
> it is for a single function it may pay off in the future by having
> other features specific for sockets and the default callbacks.?

On second thought, this is not necessary. struct sockaddr * is simply
a pointer, so we can use it without including any header, similarly
to what we do for gnutls_session_t. We can define struct sockaddr;
somewhere in the header before the fastopen function.

regards,
Nikos



From tim.ruehsen at gmx.de  Thu Jul 14 11:56:59 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Thu, 14 Jul 2016 11:56:59 +0200
Subject: [gnutls-devel] TCP Fast Open
In-Reply-To: <1468489440.24484.1.camel@gmail.com>
References: <2702347.Ez2esJkPZ0@blitz-lx> <1468424570.1070.5.camel@gnutls.org>
 <1468489440.24484.1.camel@gmail.com>
Message-ID: <1841089.hxWZhsy4nT@blitz-lx>

On Thursday, July 14, 2016 11:44:00 AM CEST Nikos Mavrogiannopoulos wrote:
> On Wed, 2016-07-13 at 17:42 +0200, Nikos Mavrogiannopoulos wrote:
> > On Wed, 2016-07-13 at 16:50 +0200, Tim Ruehsen wrote:
> > > Hi Nikos,
> > > 
> > > a question regarding the implementation...
> > > 
> > > The new function
> > > void
> > > gnutls_transport_set_fastopen(gnutls_session_t session,
> > > 
> > > 			  struct sockaddr *connect_addr, socklen_t
> > > 
> > > connect_addrlen)
> > > 
> > > needs sys/socket.h included in gnutls.h(.in). Is that ok for you,
> > > or
> > > how would 
> > > you like me to proceed ? Doing so might break the build on some
> > > platforms...
> > 
> > We can introduce a new header such as gnutls/socket.h. Even if now,
> > it is for a single function it may pay off in the future by having
> > other features specific for sockets and the default callbacks. 
> 
> On second thought, this is not necessary. struct sockaddr * is simply
> a pointer, so we can use it without including any header, similarly
> to what we do for gnutls_session_t. We can define struct sockaddr;
> somewhere in the header before the fastopen function.

I have the gnutls/socket.h already done (I start testing gnutls-cli --fastopen 
in a minute...).

Also, how do we avoids conflicts if someone includes gnutls.h and sys/socket.h 
- redefining sockaddr would result in a compilation error...

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160714/4971bbfc/attachment.sig>

From tim.ruehsen at gmx.de  Thu Jul 14 12:45:06 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Thu, 14 Jul 2016 12:45:06 +0200
Subject: [gnutls-devel] [PATCH] Re:  TCP Fast Open
In-Reply-To: <1468424570.1070.5.camel@gnutls.org>
References: <2702347.Ez2esJkPZ0@blitz-lx> <61189169.31ZdqjBfC4@blitz-lx>
 <1468424570.1070.5.camel@gnutls.org>
Message-ID: <5455741.liSV5HiIE3@blitz-lx>

Here is my patch, first version.

Please review and comment.

- I have no platform without TFO to test with... so compilation might break on 
such platforms, could anyone give it a try ?

- Please check the docs... I am unsure about completeness

- To check the timings / test TFO, I added 'return 0;' in line 1245 of src/
cli.c and run it with and without --fastopen against www.google.com 443.
I have ~35ms ping here and had a reproducable gain of ~32ms when using --
fastopen (152ms vs. 120ms).

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Support-TCP-Fast-Open.patch
Type: text/x-patch
Size: 17701 bytes
Desc: not available
URL: </pipermail/attachments/20160714/c46c26ed/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160714/c46c26ed/attachment-0001.sig>

From jan.vcelak at nic.cz  Thu Jul 14 17:28:28 2016
From: jan.vcelak at nic.cz (=?UTF-8?B?SmFuIFbEjWVsw6Fr?=)
Date: Thu, 14 Jul 2016 17:28:28 +0200
Subject: [gnutls-devel] gnutls_pkcs11_add_provider() duplicate modules
	detection
Message-ID: <26a75640-4d30-6a41-f47f-ee514a690926@nic.cz>

Hey,

I just found out that gnutls_pkcs11_add_provider() doesn't detect
duplicate modules to be loaded however the code indicates that some
duplicate detection happens. As a result, when a module is loaded
multiple times, the gnutls_pkcs11_obj_list_import_url4() function
retrieves objects as many times as many times the module is loaded.

Internally, the module address returned by p11_kit_module_load() is
checked against a list of already present modules. It doesn't work. (It
seems to work with P11_KIT_MODULE_UNMANAGED though).

I'm not sure how to fix this correctly. Any ideas?

Cheers,

Jan


From nmav at gnutls.org  Fri Jul 15 09:21:03 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 15 Jul 2016 09:21:03 +0200
Subject: [gnutls-devel] [PATCH] Re:  TCP Fast Open
In-Reply-To: <5455741.liSV5HiIE3@blitz-lx>
References: <2702347.Ez2esJkPZ0@blitz-lx> <61189169.31ZdqjBfC4@blitz-lx>
 <1468424570.1070.5.camel@gnutls.org> <5455741.liSV5HiIE3@blitz-lx>
Message-ID: <CAJU7zaKpFqiWmx39S1sLOs6f+sSZg1y8PSWxFvp=AywKsPEa5A@mail.gmail.com>

On Thu, Jul 14, 2016 at 12:45 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> Here is my patch, first version.
>
> Please review and comment.
>
> - I have no platform without TFO to test with... so compilation might break on
> such platforms, could anyone give it a try ?

I've committed it on a special branch and run through the CI. The
windows and freebsd builds fail:
https://gitlab.com/gnutls/gnutls/builds/2370926
https://gitlab.com/gnutls/gnutls/builds/2370929

> - Please check the docs... I am unsure about completeness

It would be best to mention that optimization in the manual, while
also discussing other optimizations such as false start and session
resumption. I could take care of that.

> - To check the timings / test TFO, I added 'return 0;' in line 1245 of src/
> cli.c and run it with and without --fastopen against www.google.com 443.
> I have ~35ms ping here and had a reproducable gain of ~32ms when using --
> fastopen (152ms vs. 120ms).

That's quite nice. Have you noticed firewalls or middle boxes blocking
that approach? Is there anything we can fix for them or fallback?

> @@ -496,8 +496,17 @@ _gnutls_writev(gnutls_session_t session, const giovec_t * giovec,
>         }
>
>         if (no_writev == 0) {
> -            i = session->internals.vec_push_func(fd, giovec,
> -                                 giovec_cnt);
> +            if (session->internals.connect_addr) {
> +                if (session->internals.vec_push_func == system_writev)
> +                    i = system_writev_tfo(session, giovec, giovec_cnt);
> +#ifdef MSG_NOSIGNAL
> +                else if (session->internals.vec_push_func == system_writev_nosignal)
> +                    i = system_writev_nosignal_tfo(session, giovec, giovec_cnt);
> +#endif
> +                else
> +                    i = session->internals.vec_push_func(fd, giovec, giovec_cnt);
> +            } else
> +                i = session->internals.vec_push_func(fd, giovec, giovec_cnt);

This path is a bit worrying. Why not have
gnutls_transport_set_fastopen() replace all the pull/push functions
with its own version?
A test program utilizing this code path should also be added to avoid
breaking that functionality in the future.

regards,
Nikos


From nmav at gnutls.org  Fri Jul 15 09:27:13 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 15 Jul 2016 09:27:13 +0200
Subject: [gnutls-devel] gnutls_pkcs11_add_provider() duplicate modules
	detection
In-Reply-To: <26a75640-4d30-6a41-f47f-ee514a690926@nic.cz>
References: <26a75640-4d30-6a41-f47f-ee514a690926@nic.cz>
Message-ID: <CAJU7za+r8Miv1qVWYs0CSrWwxKxR22tQ8qTC6tu0r-CnMjgYhA@mail.gmail.com>

On Thu, Jul 14, 2016 at 5:28 PM, Jan V?el?k <jan.vcelak at nic.cz> wrote:
> Hey,
> I just found out that gnutls_pkcs11_add_provider() doesn't detect
> duplicate modules to be loaded however the code indicates that some
> duplicate detection happens. As a result, when a module is loaded
> multiple times, the gnutls_pkcs11_obj_list_import_url4() function
> retrieves objects as many times as many times the module is loaded.
>
> Internally, the module address returned by p11_kit_module_load() is
> checked against a list of already present modules. It doesn't work. (It
> seems to work with P11_KIT_MODULE_UNMANAGED though).
> I'm not sure how to fix this correctly. Any ideas?

I'm not sure if there is a solution to that either. You could compare
whether the ck_info matches, but I've seen few cases of modules having
these fields identical (e.g., one could be remoted and the other
local). However, getting duplicate items can also happen with
different libraries. E.g., if you register both opensc and
opensc-onepin, as well as coolkey, you'll get objects in piv card
listed three times.

Why not address that in the configuration?

regards,
Nikos


From jan.vcelak at nic.cz  Fri Jul 15 11:06:44 2016
From: jan.vcelak at nic.cz (=?UTF-8?B?SmFuIFbEjWVsw6Fr?=)
Date: Fri, 15 Jul 2016 11:06:44 +0200
Subject: [gnutls-devel] gnutls_pkcs11_add_provider() duplicate modules
 detection
In-Reply-To: <CAJU7za+r8Miv1qVWYs0CSrWwxKxR22tQ8qTC6tu0r-CnMjgYhA@mail.gmail.com>
References: <26a75640-4d30-6a41-f47f-ee514a690926@nic.cz>
 <CAJU7za+r8Miv1qVWYs0CSrWwxKxR22tQ8qTC6tu0r-CnMjgYhA@mail.gmail.com>
Message-ID: <057ce848-6870-6eae-7ae5-7427f15b06ef@nic.cz>

Hi.

On 15.7.2016 09:27, Nikos Mavrogiannopoulos wrote:
> I'm not sure if there is a solution to that either. You could compare
> whether the ck_info matches, but I've seen few cases of modules having
> these fields identical (e.g., one could be remoted and the other
> local). However, getting duplicate items can also happen with
> different libraries. E.g., if you register both opensc and
> opensc-onepin, as well as coolkey, you'll get objects in piv card
> listed three times.

Hm, right. I was just wondering how reliable this is expected to be.

> Why not address that in the configuration?

That is what I will have to do, probably. At the moment, our software
(Knot DNS) can be configured to use multiple private key stores. And you
can manually specify the provider for each key store. So we just call
gnutls_pkcs11_add_provider() explicitly when we need to access the keys.

Regards,

Jan


From tim.ruehsen at gmx.de  Fri Jul 15 12:35:59 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Fri, 15 Jul 2016 12:35:59 +0200
Subject: [gnutls-devel] [PATCH] Re:  TCP Fast Open
In-Reply-To: <CAJU7zaKpFqiWmx39S1sLOs6f+sSZg1y8PSWxFvp=AywKsPEa5A@mail.gmail.com>
References: <2702347.Ez2esJkPZ0@blitz-lx> <5455741.liSV5HiIE3@blitz-lx>
 <CAJU7zaKpFqiWmx39S1sLOs6f+sSZg1y8PSWxFvp=AywKsPEa5A@mail.gmail.com>
Message-ID: <33393672.O1orn0MIiH@blitz-lx>

On Friday, July 15, 2016 9:21:03 AM CEST Nikos Mavrogiannopoulos wrote:
> On Thu, Jul 14, 2016 at 12:45 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> > Here is my patch, first version.
> > 
> > Please review and comment.
> > 
> > - I have no platform without TFO to test with... so compilation might
> > break on such platforms, could anyone give it a try ?
> 
> I've committed it on a special branch and run through the CI. The
> windows and freebsd builds fail:
> https://gitlab.com/gnutls/gnutls/builds/2370926
> https://gitlab.com/gnutls/gnutls/builds/2370929

I haven't taken care of HAVE_WRITEV in _gnutls_writev(). The amended patch 
should do that. Please test again.

> > - Please check the docs... I am unsure about completeness
> 
> It would be best to mention that optimization in the manual, while
> also discussing other optimizations such as false start and session
> resumption. I could take care of that.

That would be great !

> > - To check the timings / test TFO, I added 'return 0;' in line 1245 of
> > src/
> > cli.c and run it with and without --fastopen against www.google.com 443.
> > I have ~35ms ping here and had a reproducable gain of ~32ms when using --
> > fastopen (152ms vs. 120ms).
> 
> That's quite nice. Have you noticed firewalls or middle boxes blocking
> that approach? Is there anything we can fix for them or fallback?

Not that I know of. A fallback should IMO applied at the application layer.

But there is one thing that should be mentioned. The client applications 
(currently only gnutls-cli) need a different retry strategy with TFO.

Without TFO, socket.c/socket_open() loops over the addrinfo list returned by 
getaddrinfo() until connect() returns success. 

With TFO, we return with the first successful call to socket(). The implicit 
connect happens later - and from there we currently can't easily 'continue 
looping'. Of course we could (we still have 'res' and 'ptr' in the socket_st), 
but that needs some refactoring of socket.c - not part of this patch.

> > @@ -496,8 +496,17 @@ _gnutls_writev(gnutls_session_t session, const
> > giovec_t * giovec,> 
> >         }
> >         
> >         if (no_writev == 0) {
> > 
> > -            i = session->internals.vec_push_func(fd, giovec,
> > -                                 giovec_cnt);
> > +            if (session->internals.connect_addr) {
> > +                if (session->internals.vec_push_func == system_writev)
> > +                    i = system_writev_tfo(session, giovec, giovec_cnt);
> > +#ifdef MSG_NOSIGNAL
> > +                else if (session->internals.vec_push_func ==
> > system_writev_nosignal) +                    i =
> > system_writev_nosignal_tfo(session, giovec, giovec_cnt); +#endif
> > +                else
> > +                    i = session->internals.vec_push_func(fd, giovec,
> > giovec_cnt); +            } else
> > +                i = session->internals.vec_push_func(fd, giovec,
> > giovec_cnt);
> This path is a bit worrying. Why not have
> gnutls_transport_set_fastopen() replace all the pull/push functions
> with its own version?

True, but the new writev_tfo functions need a session pointer instead of a 
transport pointer. And I didn't want to take care for user supplied transport 
pointers + user defined write functions (set before or after 
gnutls_transport_set_fastopen()).
But I see room for a internal refactoring, that uses session for all system 
write/writev funtions... and call user supplied functions from there. IMO, 
that should be another patch.

> A test program utilizing this code path should also be added to avoid
> breaking that functionality in the future.

It needs client+server connected via TCP to test that code path. Can you 
propose any test that is best to start with ?

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Support-TCP-Fast-Open.patch
Type: text/x-patch
Size: 16527 bytes
Desc: not available
URL: </pipermail/attachments/20160715/668d3338/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160715/668d3338/attachment-0001.sig>

From nmav at gnutls.org  Fri Jul 15 14:04:41 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 15 Jul 2016 14:04:41 +0200
Subject: [gnutls-devel] [PATCH] Re:  TCP Fast Open
In-Reply-To: <33393672.O1orn0MIiH@blitz-lx>
References: <2702347.Ez2esJkPZ0@blitz-lx> <5455741.liSV5HiIE3@blitz-lx>
 <CAJU7zaKpFqiWmx39S1sLOs6f+sSZg1y8PSWxFvp=AywKsPEa5A@mail.gmail.com>
 <33393672.O1orn0MIiH@blitz-lx>
Message-ID: <CAJU7za+qXYnnLtS04Rbv7xPPFb+4HA19ekA2ynminb5UmiE6XQ@mail.gmail.com>

On Fri, Jul 15, 2016 at 12:35 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> On Friday, July 15, 2016 9:21:03 AM CEST Nikos Mavrogiannopoulos wrote:
>> On Thu, Jul 14, 2016 at 12:45 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
>> > Here is my patch, first version.
>> >
>> > Please review and comment.
>> >
>> > - I have no platform without TFO to test with... so compilation might
>> > break on such platforms, could anyone give it a try ?
>>
>> I've committed it on a special branch and run through the CI. The
>> windows and freebsd builds fail:
>> https://gitlab.com/gnutls/gnutls/builds/2370926
>> https://gitlab.com/gnutls/gnutls/builds/2370929
> I haven't taken care of HAVE_WRITEV in _gnutls_writev(). The amended patch
> should do that. Please test again.
Results will be at:
https://gitlab.com/gnutls/gnutls/pipelines/3717100

>> > - To check the timings / test TFO, I added 'return 0;' in line 1245 of
>> > src/
>> > cli.c and run it with and without --fastopen against www.google.com 443.
>> > I have ~35ms ping here and had a reproducable gain of ~32ms when using --
>> > fastopen (152ms vs. 120ms).
>> That's quite nice. Have you noticed firewalls or middle boxes blocking
>> that approach? Is there anything we can fix for them or fallback?
> Not that I know of. A fallback should IMO applied at the application layer.

Makes sense.

> But there is one thing that should be mentioned. The client applications
> (currently only gnutls-cli) need a different retry strategy with TFO.
> Without TFO, socket.c/socket_open() loops over the addrinfo list returned by
> getaddrinfo() until connect() returns success.
> With TFO, we return with the first successful call to socket(). The implicit
> connect happens later - and from there we currently can't easily 'continue
> looping'. Of course we could (we still have 'res' and 'ptr' in the socket_st),
> but that needs some refactoring of socket.c - not part of this patch.

That is going to create some trouble when testing this option with gnutls-cli.

>> This path is a bit worrying. Why not have
>> gnutls_transport_set_fastopen() replace all the pull/push functions
>> with its own version?
> True, but the new writev_tfo functions need a session pointer instead of a
> transport pointer. And I didn't want to take care for user supplied transport
> pointers + user defined write functions (set before or after
> gnutls_transport_set_fastopen()).
> But I see room for a internal refactoring, that uses session for all system
> write/writev funtions... and call user supplied functions from there. IMO,
> that should be another patch.

Would you be interested in making that patch? That would really
simplify any such additions in the future.

>> A test program utilizing this code path should also be added to avoid
>> breaking that functionality in the future.
> It needs client+server connected via TCP to test that code path. Can you
> propose any test that is best to start with ?

The simplest to modify for that, I think is tls-client-with-seccomp.c.
It uses a sockpair with AF_UNIX, which will have to be replaced with a
real socket connection, or a socketpair emulation such as:
https://github.com/ncm/selectable-socketpair/blob/master/socketpair.c

regards,
Nikos


From tim.ruehsen at gmx.de  Fri Jul 15 16:52:58 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Fri, 15 Jul 2016 16:52:58 +0200
Subject: [gnutls-devel] [PATCH] Re:  TCP Fast Open
In-Reply-To: <CAJU7za+qXYnnLtS04Rbv7xPPFb+4HA19ekA2ynminb5UmiE6XQ@mail.gmail.com>
References: <2702347.Ez2esJkPZ0@blitz-lx> <33393672.O1orn0MIiH@blitz-lx>
 <CAJU7za+qXYnnLtS04Rbv7xPPFb+4HA19ekA2ynminb5UmiE6XQ@mail.gmail.com>
Message-ID: <1969796.83Ks0MSh9s@blitz-lx>

On Friday, July 15, 2016 2:04:41 PM CEST Nikos Mavrogiannopoulos wrote:
> On Fri, Jul 15, 2016 at 12:35 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> > On Friday, July 15, 2016 9:21:03 AM CEST Nikos Mavrogiannopoulos wrote:
> >> On Thu, Jul 14, 2016 at 12:45 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> >> > Here is my patch, first version.
> >> > 
> >> > Please review and comment.
> >> > 
> >> > - I have no platform without TFO to test with... so compilation might
> >> > break on such platforms, could anyone give it a try ?
> >> 
> >> I've committed it on a special branch and run through the CI. The
> >> windows and freebsd builds fail:
> >> https://gitlab.com/gnutls/gnutls/builds/2370926
> >> https://gitlab.com/gnutls/gnutls/builds/2370929
> > 
> > I haven't taken care of HAVE_WRITEV in _gnutls_writev(). The amended patch
> > should do that. Please test again.
> 
> Results will be at:
> https://gitlab.com/gnutls/gnutls/pipelines/3717100

Wow, somehow I managed to remove gnutls/socket.h from the patch... here is the 
patch including it.

> > But there is one thing that should be mentioned. The client applications
> > (currently only gnutls-cli) need a different retry strategy with TFO.
> > Without TFO, socket.c/socket_open() loops over the addrinfo list returned
> > by getaddrinfo() until connect() returns success.
> > With TFO, we return with the first successful call to socket(). The
> > implicit connect happens later - and from there we currently can't easily
> > 'continue looping'. Of course we could (we still have 'res' and 'ptr' in
> > the socket_st), but that needs some refactoring of socket.c - not part of
> > this patch.
> That is going to create some trouble when testing this option with
> gnutls-cli.
> >> This path is a bit worrying. Why not have
> >> gnutls_transport_set_fastopen() replace all the pull/push functions
> >> with its own version?
> > 
> > True, but the new writev_tfo functions need a session pointer instead of a
> > transport pointer. And I didn't want to take care for user supplied
> > transport pointers + user defined write functions (set before or after
> > gnutls_transport_set_fastopen()).
> > But I see room for a internal refactoring, that uses session for all
> > system
> > write/writev funtions... and call user supplied functions from there. IMO,
> > that should be another patch.
> 
> Would you be interested in making that patch? That would really
> simplify any such additions in the future.

I can't test the non-POSIX code, so it might go into many time-wasting 
iterations. Time is something I don't have very much of...

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160715/973f202b/attachment.sig>

From nmav at gnutls.org  Fri Jul 15 20:54:45 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 15 Jul 2016 20:54:45 +0200
Subject: [gnutls-devel] [PATCH] Re:  TCP Fast Open
In-Reply-To: <1969796.83Ks0MSh9s@blitz-lx>
References: <2702347.Ez2esJkPZ0@blitz-lx> <33393672.O1orn0MIiH@blitz-lx>
 <CAJU7za+qXYnnLtS04Rbv7xPPFb+4HA19ekA2ynminb5UmiE6XQ@mail.gmail.com>
 <1969796.83Ks0MSh9s@blitz-lx>
Message-ID: <CAJU7zaLAy3Pcm9OzBNmwyebdMoOxKSbvfSAf0yfaJtHsh0iZtA@mail.gmail.com>

On Fri, Jul 15, 2016 at 4:52 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
>> > True, but the new writev_tfo functions need a session pointer instead of a
>> > transport pointer. And I didn't want to take care for user supplied
>> > transport pointers + user defined write functions (set before or after
>> > gnutls_transport_set_fastopen()).
>> > But I see room for a internal refactoring, that uses session for all
>> > system
>> > write/writev funtions... and call user supplied functions from there. IMO,
>> > that should be another patch.
>>
>> Would you be interested in making that patch? That would really
>> simplify any such additions in the future.
> I can't test the non-POSIX code, so it might go into many time-wasting
> iterations. Time is something I don't have very much of...

If that's the only issue you can make a fork at gitlab and I'll give
you access to the CI. This will ease things considerably.

btw. you didn't attach the new patch

regards,
Nikos


From tim.ruehsen at gmx.de  Sat Jul 16 21:04:09 2016
From: tim.ruehsen at gmx.de (Tim =?ISO-8859-1?Q?R=FChsen?=)
Date: Sat, 16 Jul 2016 21:04:09 +0200
Subject: [gnutls-devel] [PATCH] Re:  TCP Fast Open
In-Reply-To: <CAJU7zaLAy3Pcm9OzBNmwyebdMoOxKSbvfSAf0yfaJtHsh0iZtA@mail.gmail.com>
References: <2702347.Ez2esJkPZ0@blitz-lx> <1969796.83Ks0MSh9s@blitz-lx>
 <CAJU7zaLAy3Pcm9OzBNmwyebdMoOxKSbvfSAf0yfaJtHsh0iZtA@mail.gmail.com>
Message-ID: <1606873.ATDexdeZdp@debian>

On Friday 15 July 2016 20:54:45 Nikos Mavrogiannopoulos wrote:
> On Fri, Jul 15, 2016 at 4:52 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> >> > True, but the new writev_tfo functions need a session pointer instead
> >> > of a
> >> > transport pointer. And I didn't want to take care for user supplied
> >> > transport pointers + user defined write functions (set before or after
> >> > gnutls_transport_set_fastopen()).
> >> > But I see room for a internal refactoring, that uses session for all
> >> > system
> >> > write/writev funtions... and call user supplied functions from there.
> >> > IMO,
> >> > that should be another patch.
> >> 
> >> Would you be interested in making that patch? That would really
> >> simplify any such additions in the future.
> > 
> > I can't test the non-POSIX code, so it might go into many time-wasting
> > iterations. Time is something I don't have very much of...
> 
> If that's the only issue you can make a fork at gitlab and I'll give
> you access to the CI. This will ease things considerably.

I forked gnutls to https://gitlab.com/rockdaboot/gnutls. What do I have to do 
that the CI works on the fork ?

No promise to make it - I already had a look at it. I don't see a way to 
simplify code paths. It looks like _gnutls_writev_emu() is needed anyways, and 
there is the need for checking the type of callback (fd or session). Moving 
the code around (e.g. checks into system_writev() doesn't really help either).

So maybe my first impression was simply wrong. Without (all) the push 
callbacks taking session instead of fd, we can't simplify it. Even if that 
looks like a (weak) design flaw in the past, we can't change it easily without 
breaking existing application code. I guess we have to live with that ugly 
code in the patch. Maybe you see more and/or have a good idea about it.

But anyway - the CI would help in testing and correcting the patch for non 
POSIX system.s

> btw. you didn't attach the new patch

Sorry - it lacks gnutls/socket.h from the previos patch. Got lost when 
rebasing my branch onto upstream master. But anyway - with CI access I'll test 
it myself and prepare a new patch (earliest on Monday).

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160716/d7c8865a/attachment.sig>

From nmav at gnutls.org  Sun Jul 17 09:42:08 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 17 Jul 2016 09:42:08 +0200
Subject: [gnutls-devel] [PATCH] Re:  TCP Fast Open
In-Reply-To: <1606873.ATDexdeZdp@debian>
References: <2702347.Ez2esJkPZ0@blitz-lx> <1969796.83Ks0MSh9s@blitz-lx>
 <CAJU7zaLAy3Pcm9OzBNmwyebdMoOxKSbvfSAf0yfaJtHsh0iZtA@mail.gmail.com>
 <1606873.ATDexdeZdp@debian>
Message-ID: <1468741328.11011.1.camel@gnutls.org>

On Sat, 2016-07-16 at 21:04 +0200, Tim R?hsen wrote:

> I forked gnutls to https://gitlab.com/rockdaboot/gnutls. What do I
> have to do that the CI works on the fork ?

If you give me admin rights on the repository (user nmav) I'll enable
them for you.

> No promise to make it - I already had a look at it. I don't see a way
> to?
> simplify code paths. It looks like _gnutls_writev_emu() is needed
> anyways, and?
> there is the need for checking the type of callback (fd or session).
> Moving?
> the code around (e.g. checks into system_writev() doesn't really help
> either).
> So maybe my first impression was simply wrong. Without (all) the
> push?
> callbacks taking session instead of fd, we can't simplify it. Even if
> that?
> looks like a (weak) design flaw in the past, we can't change it
> easily without?
> breaking existing application code. I guess we have to live with that
> ugly?
> code in the patch. Maybe you see more and/or have a good idea about
> it.

Ok, if that's the case, let's land it as a merge request, and we see
how it can be handled.

regards,
Nikos



From tim.ruehsen at gmx.de  Sun Jul 17 11:07:45 2016
From: tim.ruehsen at gmx.de (Tim =?ISO-8859-1?Q?R=FChsen?=)
Date: Sun, 17 Jul 2016 11:07:45 +0200
Subject: [gnutls-devel] [PATCH] Re:  TCP Fast Open
In-Reply-To: <1468741328.11011.1.camel@gnutls.org>
References: <2702347.Ez2esJkPZ0@blitz-lx> <1606873.ATDexdeZdp@debian>
 <1468741328.11011.1.camel@gnutls.org>
Message-ID: <1506800.NdL40xbCkE@debian>

On Sunday 17 July 2016 09:42:08 Nikos Mavrogiannopoulos wrote:
> On Sat, 2016-07-16 at 21:04 +0200, Tim R?hsen wrote:
> > I forked gnutls to https://gitlab.com/rockdaboot/gnutls. What do I
> > have to do that the CI works on the fork ?
> 
> If you give me admin rights on the repository (user nmav) I'll enable
> them for you.

You are 'master' now (I guess that is like an admin).

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160717/131bce88/attachment.sig>

From tim.ruehsen at gmx.de  Tue Jul 19 11:13:28 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Tue, 19 Jul 2016 11:13:28 +0200
Subject: [gnutls-devel] [PATCH] Little fix for OpenSSL 1.1.0
Message-ID: <4427818.ubZyKotqyg@blitz-lx>

EVP_CIPHER_CTX is opaque now.

Using EVP_CIPHER_CTX_new() and EVP_CIPHER_CTX_free() *should* work on older 
versions of OpenSSL as well, but I am not sure how old they may be.

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-tests-slow-cipher-openssl-compat.c-for-OpenSSL-1.patch
Type: text/x-patch
Size: 2300 bytes
Desc: not available
URL: </pipermail/attachments/20160719/4a25d5e3/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160719/4a25d5e3/attachment.sig>

From tim.ruehsen at gmx.de  Tue Jul 19 12:11:08 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Tue, 19 Jul 2016 12:11:08 +0200
Subject: [gnutls-devel] [PATCH] Remove redundant if expression from
	tests/mini-loss-time.c
Message-ID: <10434543.93G0nHlvTT@blitz-lx>

Looks like you were not finished with something...

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Remove-redundant-if-expression-from-tests-mini-loss-.patch
Type: text/x-patch
Size: 808 bytes
Desc: not available
URL: </pipermail/attachments/20160719/518aba78/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160719/518aba78/attachment.sig>

From nmav at gnutls.org  Tue Jul 19 12:55:25 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 19 Jul 2016 12:55:25 +0200
Subject: [gnutls-devel] [PATCH] Remove redundant if expression from
	tests/mini-loss-time.c
In-Reply-To: <10434543.93G0nHlvTT@blitz-lx>
References: <10434543.93G0nHlvTT@blitz-lx>
Message-ID: <CAJU7za+3rm9bfjhp3CbDMu4PZPARFE0Dp6_kBpsWAGpkMwzSsQ@mail.gmail.com>

Both applied, thank you.

On Tue, Jul 19, 2016 at 12:11 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> Looks like you were not finished with something...
>
> Regards, Tim
>
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-devel


From tim.ruehsen at gmx.de  Wed Jul 20 12:30:29 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Wed, 20 Jul 2016 12:30:29 +0200
Subject: [gnutls-devel] Moving defines (3.4) to enum (3.5.) in header files
	needs discussion...
Message-ID: <2247751.yNvhTzIyrN@blitz-lx>

Hi Nikos,

I just realized that you turned several defines into enums with GnuTLS 3.5.x.

This simply breaks existing code (e.g. wget2) and took me a while to find out.

Example:
#ifdef GNUTLS_NONBLOCK
		gnutls_init(&session, GNUTLS_CLIENT | GNUTLS_NONBLOCK);
#else
	// very old gnutls version, likely to not work.
	gnutls_init(&session, GNUTLS_CLIENT);
#endif

Of course you might say, I should test this in ./configure ... but basically 
lot's of code uses this kind of checks (e.g. the new TCP fastopen code has 
things like #ifdef MSG_FASTOPEN etc.). I just pray that glibc maintainers 
don't do the same one day...

Personally, I don't see the point in using enums for flags in C. AFAIK, gcc 
doesn't check types for enums at all. Using any value for an enum variable or 
function parameter is allowed (no warning). Do I miss something here ?

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160720/b47cd89c/attachment.sig>

From tim.ruehsen at gmx.de  Wed Jul 20 13:06:34 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Wed, 20 Jul 2016 13:06:34 +0200
Subject: [gnutls-devel] TCP Fast Open
In-Reply-To: <CAJU7zaK7vji5s7YdrmvVLJEqOCPXoHHo7MXtB_3RbZGtmmBJeA@mail.gmail.com>
References: <2702347.Ez2esJkPZ0@blitz-lx>
 <CAJU7zaK7vji5s7YdrmvVLJEqOCPXoHHo7MXtB_3RbZGtmmBJeA@mail.gmail.com>
Message-ID: <1805247.TXJImJsc64@blitz-lx>

On Wednesday, July 13, 2016 9:28:28 AM CEST Nikos Mavrogiannopoulos wrote:
> On Tue, Jul 12, 2016 at 5:33 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> > Hi,
> > I just wanted to mention that I recently added TFO in Wget2 using GnuTLS
> > (tested on Linux, speedup ~ 1xRTT).
> 
> Hi Tim,
>  That sounds great. Did you combine that with other optimizations such
> as session resumption and false start?

I just did combine TFO with False Start in wget2 - and yes, it is another 
1xRTT speedup !

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160720/21c4cac2/attachment-0001.sig>

From nmav at gnutls.org  Wed Jul 20 13:28:42 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 20 Jul 2016 13:28:42 +0200
Subject: [gnutls-devel] Moving defines (3.4) to enum (3.5.) in header
 files needs discussion...
In-Reply-To: <2247751.yNvhTzIyrN@blitz-lx>
References: <2247751.yNvhTzIyrN@blitz-lx>
Message-ID: <CAJU7zaK+uf9BF2Cv3uL4NwGKuvmtPSBe5zfEdWy=TwgySnxd=w@mail.gmail.com>

On Wed, Jul 20, 2016 at 12:30 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> Hi Nikos,
> I just realized that you turned several defines into enums with GnuTLS 3.5.x.
> This simply breaks existing code (e.g. wget2) and took me a while to find out.

> Example:
> #ifdef GNUTLS_NONBLOCK
>                 gnutls_init(&session, GNUTLS_CLIENT | GNUTLS_NONBLOCK);
> #else
>         // very old gnutls version, likely to not work.
>         gnutls_init(&session, GNUTLS_CLIENT);
> #endif

You're right, that's an unintended side effect. A solution for gnutls'
code is to redefine these as in:
https://gitlab.com/gnutls/gnutls/merge_requests/25

For your code, you may want to use instead:
#if GNUTLS_VERSION_NUMBER > 0x030000
which is part of the documented API.

> Personally, I don't see the point in using enums for flags in C. AFAIK, gcc
> doesn't check types for enums at all. Using any value for an enum variable or
> function parameter is allowed (no warning). Do I miss something here ?

The reason of this change was that the current documentation
generation works well with enumerations but not definitions and I
wanted to include the gnutls_init flags to the generated
documentation.

regards,
Nikos


From tim.ruehsen at gmx.de  Wed Jul 20 13:41:51 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Wed, 20 Jul 2016 13:41:51 +0200
Subject: [gnutls-devel] Moving defines (3.4) to enum (3.5.) in header
	files needs discussion...
In-Reply-To: <CAJU7zaK+uf9BF2Cv3uL4NwGKuvmtPSBe5zfEdWy=TwgySnxd=w@mail.gmail.com>
References: <2247751.yNvhTzIyrN@blitz-lx>
 <CAJU7zaK+uf9BF2Cv3uL4NwGKuvmtPSBe5zfEdWy=TwgySnxd=w@mail.gmail.com>
Message-ID: <1676221.dbBe2AbsF9@blitz-lx>

On Wednesday, July 20, 2016 1:28:42 PM CEST Nikos Mavrogiannopoulos wrote:
> On Wed, Jul 20, 2016 at 12:30 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> > Hi Nikos,
> > I just realized that you turned several defines into enums with GnuTLS
> > 3.5.x. This simply breaks existing code (e.g. wget2) and took me a while
> > to find out.
> > 
> > Example:
> > #ifdef GNUTLS_NONBLOCK
> > 
> >                 gnutls_init(&session, GNUTLS_CLIENT | GNUTLS_NONBLOCK);
> > 
> > #else
> > 
> >         // very old gnutls version, likely to not work.
> >         gnutls_init(&session, GNUTLS_CLIENT);
> > 
> > #endif
> 
> You're right, that's an unintended side effect. A solution for gnutls'
> code is to redefine these as in:
> https://gitlab.com/gnutls/gnutls/merge_requests/25

Yes thanks, that should do it :-) And if it still works for the docs, it seems 
to be perfect.

> For your code, you may want to use instead:
> #if GNUTLS_VERSION_NUMBER > 0x030000
> which is part of the documented API.

Right. I just don't know when GNUTLS_NONBLOCK has been invented, so I do
#if GNUTLS_VERSION_NUMBER >= 0x030500
// 3.5+ code
#elif defined(GNUTLS_NONBLOCK)
// pre 3.5 code
#else
// legacy code
#endif

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160720/1a6a4634/attachment.sig>

From nmav at gnutls.org  Thu Jul 21 15:34:11 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 21 Jul 2016 15:34:11 +0200
Subject: [gnutls-devel] TCP Fast Open
In-Reply-To: <1805247.TXJImJsc64@blitz-lx>
References: <2702347.Ez2esJkPZ0@blitz-lx>
 <CAJU7zaK7vji5s7YdrmvVLJEqOCPXoHHo7MXtB_3RbZGtmmBJeA@mail.gmail.com>
 <1805247.TXJImJsc64@blitz-lx>
Message-ID: <CAJU7zaJFJzpzuvCU++EuL_cvTCRx3QOtRfS6nr+KKHjVzy2W7A@mail.gmail.com>

On Wed, Jul 20, 2016 at 1:06 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
>> > I just wanted to mention that I recently added TFO in Wget2 using GnuTLS
>> > (tested on Linux, speedup ~ 1xRTT).
>> Hi Tim,
>>  That sounds great. Did you combine that with other optimizations such
>> as session resumption and false start?
> I just did combine TFO with False Start in wget2 - and yes, it is another
> 1xRTT speedup !

One question with that. Do you plan to enable it unconditionally or
conditionally if some state is known about the server? I know that
google has done quite some experiments with false start and chrome and
they only enable it on specific servers. The reason I believe is that
certain middle-boxes choke when a finished message is followed by
application data.

regards,
Nikos


From tim.ruehsen at gmx.de  Thu Jul 21 16:06:17 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Thu, 21 Jul 2016 16:06:17 +0200
Subject: [gnutls-devel] TCP Fast Open
In-Reply-To: <CAJU7zaJFJzpzuvCU++EuL_cvTCRx3QOtRfS6nr+KKHjVzy2W7A@mail.gmail.com>
References: <2702347.Ez2esJkPZ0@blitz-lx> <1805247.TXJImJsc64@blitz-lx>
 <CAJU7zaJFJzpzuvCU++EuL_cvTCRx3QOtRfS6nr+KKHjVzy2W7A@mail.gmail.com>
Message-ID: <2071245.slB29yWU2K@blitz-lx>

On Thursday, July 21, 2016 3:34:11 PM CEST Nikos Mavrogiannopoulos wrote:
> On Wed, Jul 20, 2016 at 1:06 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> >> > I just wanted to mention that I recently added TFO in Wget2 using
> >> > GnuTLS
> >> > (tested on Linux, speedup ~ 1xRTT).
> >> 
> >> Hi Tim,
> >> 
> >>  That sounds great. Did you combine that with other optimizations such
> >> 
> >> as session resumption and false start?
> > 
> > I just did combine TFO with False Start in wget2 - and yes, it is another
> > 1xRTT speedup !
> 
> One question with that. Do you plan to enable it unconditionally or
> conditionally if some state is known about the server? I know that
> google has done quite some experiments with false start and chrome and
> they only enable it on specific servers. The reason I believe is that
> certain middle-boxes choke when a finished message is followed by
> application data.

Thanks for the hint !

I would like to enable it by default...
Everybody wants 0RTT for TLS a.s.a.p., middle boxes just have to work :-) .

But of course we have to be careful for the near future.

I will need to make lot's of tests before I can decide. But for now (during 
development / pre-release), I have these feature enabled by default.

BTW, just testing False Start together with session resumption (with GnuTLS 
3.5 / master)... as it turns out, after handshake returns there is no session 
data yet. I guess it is available after the first read !? Or what is the best 
time to retrieve it ?

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160721/53272788/attachment.sig>

From nmav at gnutls.org  Thu Jul 21 16:13:05 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 21 Jul 2016 16:13:05 +0200
Subject: [gnutls-devel] TCP Fast Open
In-Reply-To: <2071245.slB29yWU2K@blitz-lx>
References: <2702347.Ez2esJkPZ0@blitz-lx> <1805247.TXJImJsc64@blitz-lx>
 <CAJU7zaJFJzpzuvCU++EuL_cvTCRx3QOtRfS6nr+KKHjVzy2W7A@mail.gmail.com>
 <2071245.slB29yWU2K@blitz-lx>
Message-ID: <CAJU7zaJXU8U5XM4_h9NAUamJJ0e+v4BS5Awk36AZFC97KHoGCg@mail.gmail.com>

On Thu, Jul 21, 2016 at 4:06 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
>> One question with that. Do you plan to enable it unconditionally or
>> conditionally if some state is known about the server? I know that
>> google has done quite some experiments with false start and chrome and
>> they only enable it on specific servers. The reason I believe is that
>> certain middle-boxes choke when a finished message is followed by
>> application data.
> I would like to enable it by default...
> Everybody wants 0RTT for TLS a.s.a.p., middle boxes just have to work :-) .
> But of course we have to be careful for the near future.
> I will need to make lot's of tests before I can decide. But for now (during
> development / pre-release), I have these feature enabled by default.
> BTW, just testing False Start together with session resumption (with GnuTLS
> 3.5 / master)... as it turns out, after handshake returns there is no session
> data yet. I guess it is available after the first read !? Or what is the best
> time to retrieve it ?

False start doesn't do anything on resumed sessions because on these
sessions the client is the one sending the finished packet last. There
could be a server-side false start in that case (briefly discussed in
draft-ietf-tls-falsestart-02) but it is not defined by that draft -and
not implemented by gnutls. Thus, you shouldn't see a difference when
enabling it on client side and resuming.

regards,
Nikos


From tim.ruehsen at gmx.de  Thu Jul 21 16:27:55 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Thu, 21 Jul 2016 16:27:55 +0200
Subject: [gnutls-devel] TCP Fast Open
In-Reply-To: <CAJU7zaJXU8U5XM4_h9NAUamJJ0e+v4BS5Awk36AZFC97KHoGCg@mail.gmail.com>
References: <2702347.Ez2esJkPZ0@blitz-lx> <2071245.slB29yWU2K@blitz-lx>
 <CAJU7zaJXU8U5XM4_h9NAUamJJ0e+v4BS5Awk36AZFC97KHoGCg@mail.gmail.com>
Message-ID: <1862270.gEf2Ds9VPM@blitz-lx>

On Thursday, July 21, 2016 4:13:05 PM CEST Nikos Mavrogiannopoulos wrote:
> On Thu, Jul 21, 2016 at 4:06 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> >> One question with that. Do you plan to enable it unconditionally or
> >> conditionally if some state is known about the server? I know that
> >> google has done quite some experiments with false start and chrome and
> >> they only enable it on specific servers. The reason I believe is that
> >> certain middle-boxes choke when a finished message is followed by
> >> application data.
> > 
> > I would like to enable it by default...
> > Everybody wants 0RTT for TLS a.s.a.p., middle boxes just have to work :-)
> > .
> > But of course we have to be careful for the near future.
> > I will need to make lot's of tests before I can decide. But for now
> > (during
> > development / pre-release), I have these feature enabled by default.
> > BTW, just testing False Start together with session resumption (with
> > GnuTLS
> > 3.5 / master)... as it turns out, after handshake returns there is no
> > session data yet. I guess it is available after the first read !? Or what
> > is the best time to retrieve it ?
> 
> False start doesn't do anything on resumed sessions because on these
> sessions the client is the one sending the finished packet last. There
> could be a server-side false start in that case (briefly discussed in
> draft-ietf-tls-falsestart-02) but it is not defined by that draft -and
> not implemented by gnutls. Thus, you shouldn't see a difference when
> enabling it on client side and resuming.

From my understanding, False Start enabled makes handshake() come back before 
the handshake packet has been sent. How else can I piggy-back application data 
to the handshake ? So when the session is not resumed, I can't get session 
data right after handshake() comes back... the handshake isn't completed yet - 
resp. we didn't get any packet from the server so far.
I guess (will test it in a few minutes), that I have to wait for the first  
application data packet coming back.

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160721/453d0ece/attachment-0001.sig>

From tim.ruehsen at gmx.de  Thu Jul 21 16:50:04 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Thu, 21 Jul 2016 16:50:04 +0200
Subject: [gnutls-devel] TCP Fast Open
In-Reply-To: <1862270.gEf2Ds9VPM@blitz-lx>
References: <2702347.Ez2esJkPZ0@blitz-lx>
 <CAJU7zaJXU8U5XM4_h9NAUamJJ0e+v4BS5Awk36AZFC97KHoGCg@mail.gmail.com>
 <1862270.gEf2Ds9VPM@blitz-lx>
Message-ID: <13735011.V4oaDUmzaU@blitz-lx>

On Thursday, July 21, 2016 4:27:55 PM CEST Tim Ruehsen wrote:
> On Thursday, July 21, 2016 4:13:05 PM CEST Nikos Mavrogiannopoulos wrote:
> > On Thu, Jul 21, 2016 at 4:06 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> > >> One question with that. Do you plan to enable it unconditionally or
> > >> conditionally if some state is known about the server? I know that
> > >> google has done quite some experiments with false start and chrome and
> > >> they only enable it on specific servers. The reason I believe is that
> > >> certain middle-boxes choke when a finished message is followed by
> > >> application data.
> > > 
> > > I would like to enable it by default...
> > > Everybody wants 0RTT for TLS a.s.a.p., middle boxes just have to work
> > > :-)
> > > .
> > > But of course we have to be careful for the near future.
> > > I will need to make lot's of tests before I can decide. But for now
> > > (during
> > > development / pre-release), I have these feature enabled by default.
> > > BTW, just testing False Start together with session resumption (with
> > > GnuTLS
> > > 3.5 / master)... as it turns out, after handshake returns there is no
> > > session data yet. I guess it is available after the first read !? Or
> > > what
> > > is the best time to retrieve it ?
> > 
> > False start doesn't do anything on resumed sessions because on these
> > sessions the client is the one sending the finished packet last. There
> > could be a server-side false start in that case (briefly discussed in
> > draft-ietf-tls-falsestart-02) but it is not defined by that draft -and
> > not implemented by gnutls. Thus, you shouldn't see a difference when
> > enabling it on client side and resuming.

OK, now I see what you mean :-(
So how can we come down to 0RTT TLS overhead and send all in one packet ?

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160721/4cd473cc/attachment.sig>

From tim.ruehsen at gmx.de  Thu Jul 21 17:06:50 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Thu, 21 Jul 2016 17:06:50 +0200
Subject: [gnutls-devel] TCP Fast Open
In-Reply-To: <13735011.V4oaDUmzaU@blitz-lx>
References: <2702347.Ez2esJkPZ0@blitz-lx> <1862270.gEf2Ds9VPM@blitz-lx>
 <13735011.V4oaDUmzaU@blitz-lx>
Message-ID: <3065640.HWVo3kc5Oo@blitz-lx>

On Thursday, July 21, 2016 4:50:04 PM CEST Tim Ruehsen wrote:
> On Thursday, July 21, 2016 4:27:55 PM CEST Tim Ruehsen wrote:
> > On Thursday, July 21, 2016 4:13:05 PM CEST Nikos Mavrogiannopoulos wrote:
> > > On Thu, Jul 21, 2016 at 4:06 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> > > >> One question with that. Do you plan to enable it unconditionally or
> > > >> conditionally if some state is known about the server? I know that
> > > >> google has done quite some experiments with false start and chrome
> > > >> and
> > > >> they only enable it on specific servers. The reason I believe is that
> > > >> certain middle-boxes choke when a finished message is followed by
> > > >> application data.
> > > > 
> > > > I would like to enable it by default...
> > > > Everybody wants 0RTT for TLS a.s.a.p., middle boxes just have to work
> > > > 
> > > > :-)
> > > > 
> > > > .
> > > > But of course we have to be careful for the near future.
> > > > I will need to make lot's of tests before I can decide. But for now
> > > > (during
> > > > development / pre-release), I have these feature enabled by default.
> > > > BTW, just testing False Start together with session resumption (with
> > > > GnuTLS
> > > > 3.5 / master)... as it turns out, after handshake returns there is no
> > > > session data yet. I guess it is available after the first read !? Or
> > > > what
> > > > is the best time to retrieve it ?
> > > 
> > > False start doesn't do anything on resumed sessions because on these
> > > sessions the client is the one sending the finished packet last. There
> > > could be a server-side false start in that case (briefly discussed in
> > > draft-ietf-tls-falsestart-02) but it is not defined by that draft -and
> > > not implemented by gnutls. Thus, you shouldn't see a difference when
> > > enabling it on client side and resuming.
> 
> OK, now I see what you mean :-(
> So how can we come down to 0RTT TLS overhead and send all in one packet ?

To answer my own question: it needs TLS 1.3 (for a good explanation see [1]).
I read there is currently much discussion going on about it... Nikos, are you 
waiting for the finalization of [2] before you start an implementation or what 
is your plan ?

[1] https://timtaubert.de/blog/2015/11/more-privacy-less-latency-improved-handshakes-in-tls-13/).
[2] https://tlswg.github.io/tls13-spec/

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160721/41d9c6ac/attachment.sig>

From nmav at gnutls.org  Thu Jul 21 18:14:57 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 21 Jul 2016 18:14:57 +0200
Subject: [gnutls-devel] TCP Fast Open
In-Reply-To: <3065640.HWVo3kc5Oo@blitz-lx>
References: <2702347.Ez2esJkPZ0@blitz-lx> <1862270.gEf2Ds9VPM@blitz-lx>
 <13735011.V4oaDUmzaU@blitz-lx> <3065640.HWVo3kc5Oo@blitz-lx>
Message-ID: <CAJU7zaKTVuQ9FLuurRNEG+uV-PMBVFLkqDmgONrycyJGUB9M3g@mail.gmail.com>

On Thu, Jul 21, 2016 at 5:06 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
>> > > False start doesn't do anything on resumed sessions because on these
>> > > sessions the client is the one sending the finished packet last. There
>> > > could be a server-side false start in that case (briefly discussed in
>> > > draft-ietf-tls-falsestart-02) but it is not defined by that draft -and
>> > > not implemented by gnutls. Thus, you shouldn't see a difference when
>> > > enabling it on client side and resuming.
>> OK, now I see what you mean :-(
>> So how can we come down to 0RTT TLS overhead and send all in one packet ?
> To answer my own question: it needs TLS 1.3 (for a good explanation see [1]).
> I read there is currently much discussion going on about it... Nikos, are you
> waiting for the finalization of [2] before you start an implementation or what
> is your plan ?
> [1] https://timtaubert.de/blog/2015/11/more-privacy-less-latency-improved-handshakes-in-tls-13/).
> [2] https://tlswg.github.io/tls13-spec/

Yes, you cannot achieve 0-rtt with TLS 1.2 as it is now. For that TLS
1.3 will be required. However, since TLS 1.3 is a completely new
protocol (even though its name suggests a minor improvement, it will
share very little code with a TLS 1.2 implementation) and is still
under revision, I'll wait a little more for the protocol draft to
settle down before going into any implementation planning.

regards,
Nikos


From dkg at fifthhorseman.net  Fri Jul 22 21:56:48 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 22 Jul 2016 21:56:48 +0200
Subject: [gnutls-devel] TCP Fast Open
In-Reply-To: <CAJU7zaKTVuQ9FLuurRNEG+uV-PMBVFLkqDmgONrycyJGUB9M3g@mail.gmail.com>
References: <2702347.Ez2esJkPZ0@blitz-lx> <1862270.gEf2Ds9VPM@blitz-lx>
 <13735011.V4oaDUmzaU@blitz-lx> <3065640.HWVo3kc5Oo@blitz-lx>
 <CAJU7zaKTVuQ9FLuurRNEG+uV-PMBVFLkqDmgONrycyJGUB9M3g@mail.gmail.com>
Message-ID: <87vazxmoov.fsf@alice.fifthhorseman.net>

On Thu 2016-07-21 18:14:57 +0200, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> Yes, you cannot achieve 0-rtt with TLS 1.2 as it is now. For that TLS
> 1.3 will be required.

0-rtt for TLS 1.3 will only work in a situation where the client has
already completed a prior TLS handshake with the server (it needs
"priming").

Please be aware that pretty much all data sent in a 0-rtt flow on TLS
1.3 will have a range of security properties that differ from
(specifically: are worse than) what's normally expected from traffic in
a TLS flow.  For example, replay protection and forward secrecy
of data in a 0-rtt flow are worse than data in a normal TLS session.

> However, since TLS 1.3 is a completely new protocol (even though its
> name suggests a minor improvement, it will share very little code with
> a TLS 1.2 implementation) and is still under revision, I'll wait a
> little more for the protocol draft to settle down before going into
> any implementation planning.

fwiw, i think the draft has settled down a lot.  at the IETF hackathon
last week, there were 6 implementations all built against draft-14, and
they had most of the full 6?6 interop grid checked off successfully.

     --dkg


From nmav at gnutls.org  Sat Jul 23 17:01:10 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sat, 23 Jul 2016 17:01:10 +0200
Subject: [gnutls-devel] TCP Fast Open
In-Reply-To: <87vazxmoov.fsf@alice.fifthhorseman.net>
References: <2702347.Ez2esJkPZ0@blitz-lx> <1862270.gEf2Ds9VPM@blitz-lx>
 <13735011.V4oaDUmzaU@blitz-lx> <3065640.HWVo3kc5Oo@blitz-lx>
 <CAJU7zaKTVuQ9FLuurRNEG+uV-PMBVFLkqDmgONrycyJGUB9M3g@mail.gmail.com>
 <87vazxmoov.fsf@alice.fifthhorseman.net>
Message-ID: <1469286070.3282.3.camel@gnutls.org>

On Fri, 2016-07-22 at 21:56 +0200, Daniel Kahn Gillmor wrote:

> > However, since TLS 1.3 is a completely new protocol (even though
> > its
> > name suggests a minor improvement, it will share very little code
> > with
> > a TLS 1.2 implementation) and is still under revision, I'll wait a
> > little more for the protocol draft to settle down before going into
> > any implementation planning.
> fwiw, i think the draft has settled down a lot. ?at the IETF
> hackathon
> last week, there were 6 implementations all built against draft-14,
> and
> they had most of the full 6?6 interop grid checked off successfully.

Did that result to any code we can re-use in gnutls or nettle?

regards,
Nikos



From nmav at gnutls.org  Mon Jul 25 15:25:02 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 25 Jul 2016 15:25:02 +0200
Subject: [gnutls-devel] TCP Fast Open
In-Reply-To: <1805247.TXJImJsc64@blitz-lx>
References: <2702347.Ez2esJkPZ0@blitz-lx>
 <CAJU7zaK7vji5s7YdrmvVLJEqOCPXoHHo7MXtB_3RbZGtmmBJeA@mail.gmail.com>
 <1805247.TXJImJsc64@blitz-lx>
Message-ID: <CAJU7zaLzzN_9zeeZtELm67GDjjv1_RVmAtcsTC5O3BOTKh7D4w@mail.gmail.com>

On Wed, Jul 20, 2016 at 1:06 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> On Wednesday, July 13, 2016 9:28:28 AM CEST Nikos Mavrogiannopoulos wrote:
>> On Tue, Jul 12, 2016 at 5:33 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
>> > Hi,
>> > I just wanted to mention that I recently added TFO in Wget2 using GnuTLS
>> > (tested on Linux, speedup ~ 1xRTT).
>>
>> Hi Tim,
>>  That sounds great. Did you combine that with other optimizations such
>> as session resumption and false start?
> I just did combine TFO with False Start in wget2 - and yes, it is another
> 1xRTT speedup !

What do you think about this separation of the fast open code?
https://gitlab.com/gnutls/gnutls/commit/448af51f6a745fc1b9a2f68bce09adc3d28d3edc

When the fastopen() function is used, all the push and pull callbacks
are overridden with the ones that can cope with the TCP fast open.
This separates the two code bases.

What I found hard with TCP fast open, is error recovery. That has to
be implemented by checking errors of the gnutls_handshake() function.

regards,
Nikos


From tim.ruehsen at gmx.de  Mon Jul 25 16:38:28 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Mon, 25 Jul 2016 16:38:28 +0200
Subject: [gnutls-devel] TCP Fast Open
In-Reply-To: <CAJU7zaLzzN_9zeeZtELm67GDjjv1_RVmAtcsTC5O3BOTKh7D4w@mail.gmail.com>
References: <2702347.Ez2esJkPZ0@blitz-lx> <1805247.TXJImJsc64@blitz-lx>
 <CAJU7zaLzzN_9zeeZtELm67GDjjv1_RVmAtcsTC5O3BOTKh7D4w@mail.gmail.com>
Message-ID: <21940443.xaOkMomvc4@blitz-lx>

On Monday, July 25, 2016 3:25:02 PM CEST Nikos Mavrogiannopoulos wrote:
> On Wed, Jul 20, 2016 at 1:06 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> > On Wednesday, July 13, 2016 9:28:28 AM CEST Nikos Mavrogiannopoulos wrote:
> >> On Tue, Jul 12, 2016 at 5:33 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> >> > Hi,
> >> > I just wanted to mention that I recently added TFO in Wget2 using
> >> > GnuTLS
> >> > (tested on Linux, speedup ~ 1xRTT).
> >> 
> >> Hi Tim,
> >> 
> >>  That sounds great. Did you combine that with other optimizations such
> >> 
> >> as session resumption and false start?
> > 
> > I just did combine TFO with False Start in wget2 - and yes, it is another
> > 1xRTT speedup !

> 
> What do you think about this separation of the fast open code?
> https://gitlab.com/gnutls/gnutls/commit/448af51f6a745fc1b9a2f68bce09adc3d28d
> 3edc
> 
> When the fastopen() function is used, all the push and pull callbacks
> are overridden with the ones that can cope with the TCP fast open.
> This separates the two code bases.

This is a good thing, cleaner design.

A few little things:

# Comma missing after 'undesirable':
  * If this is undesirable TCP Fast Open must be implemented on the user

# Unneeded 'return' statement in gnutls_transport_set_fastopen()

# In _system_writev_tfo(), what about

if (likely(!p->connect_addrlen))
	return sendmsg(fd, &hdr, flags);

That would reduce one level of indentation for most of the code.

> What I found hard with TCP fast open, is error recovery. That has to
> be implemented by checking errors of the gnutls_handshake() function.

Could you give an example what exactly you mean ?
Maybe I have a brain slug... EAGAIN/EINPROGRESS/ENOTCONN/EOPNOTSUPP are 
handled. Most other errors are fatal and are returned by gnutls_handshake() as 
error. What am I missing ?

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160725/e878d63a/attachment.sig>

From nmav at gnutls.org  Mon Jul 25 17:23:13 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Mon, 25 Jul 2016 17:23:13 +0200
Subject: [gnutls-devel] TCP Fast Open
In-Reply-To: <21940443.xaOkMomvc4@blitz-lx>
References: <2702347.Ez2esJkPZ0@blitz-lx> <1805247.TXJImJsc64@blitz-lx>
 <CAJU7zaLzzN_9zeeZtELm67GDjjv1_RVmAtcsTC5O3BOTKh7D4w@mail.gmail.com>
 <21940443.xaOkMomvc4@blitz-lx>
Message-ID: <CAJU7zaKX1SdGf6-nyCPquYiznZeAYDQ1igzHCvp+JkdBqUrNhA@mail.gmail.com>

On Mon, Jul 25, 2016 at 4:38 PM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
>> What do you think about this separation of the fast open code?
>> https://gitlab.com/gnutls/gnutls/commit/448af51f6a745fc1b9a2f68bce09adc3d28d
>> 3edc
>> When the fastopen() function is used, all the push and pull callbacks
>> are overridden with the ones that can cope with the TCP fast open.
>> This separates the two code bases.
> This is a good thing, cleaner design.
> A few little things:
> # Comma missing after 'undesirable':
>   * If this is undesirable TCP Fast Open must be implemented on the user
> # Unneeded 'return' statement in gnutls_transport_set_fastopen()
> # In _system_writev_tfo(), what about
>
> if (likely(!p->connect_addrlen))
>         return sendmsg(fd, &hdr, flags);
>
> That would reduce one level of indentation for most of the code.

Thanks, I'll merge your comments, and resubmit a complete patch. I've
found that I need to handle win32 separately as well (no sendmsg
there).

>> What I found hard with TCP fast open, is error recovery. That has to
>> be implemented by checking errors of the gnutls_handshake() function.
> Could you give an example what exactly you mean ?
> Maybe I have a brain slug... EAGAIN/EINPROGRESS/ENOTCONN/EOPNOTSUPP are
> handled. Most other errors are fatal and are returned by gnutls_handshake() as
> error. What am I missing ?

I meant in abstractions like sockets.c as used in gnutls-cli which
retry connect() for failed attempts. It may not be as hard as I think
though, as we may simply include the handshake in the socket_connect()
process.

regards,
Nikos


From n.mavrogiannopoulos at gmail.com  Wed Jul 27 17:04:18 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 27 Jul 2016 17:04:18 +0200
Subject: [gnutls-devel] guile and SSL 3.0
Message-ID: <CAJU7zaLaS8aTABTnnj4BZ1mt6x27pVU-Zh0i1rWTZvT1o+q6XA@mail.gmail.com>

Hi Ludo,
 On a fedora 24 system (with guile-2.0.11-9.fc24.x86_64), the guile
tests crash when SSL 3.0 is disabled in gnutls. I am not sure if
that's related to SSL3.0 removal, but only these builds occasionally
fail.

Examples on the CI (which uses fedora):
https://gitlab.com/gnutls/gnutls/builds/2643058
https://gitlab.com/gnutls/gnutls/builds/2642725

On this one I enabled artifacts for guile:
https://gitlab.com/gnutls/gnutls/builds/2648886

You can see the results at:
https://gitlab.com/gnutls/gnutls/builds/2648886/artifacts/browse/build/guile/tests/
though I not sure how helpful they are.

Could there be some hardcoded dependency on SSL3.0?

regards,
Nikos


From ludo at gnu.org  Wed Jul 27 22:32:06 2016
From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Date: Wed, 27 Jul 2016 22:32:06 +0200
Subject: [gnutls-devel] Deconstructor deadlock
Message-ID: <878twmyg8p.fsf@gnu.org>

Hello,

Loading libgnutls.so can fail, as in this case (output of ld.so with
LD_DEBUG=files):

--8<---------------cut here---------------start------------->8---
      4478:	calling init: /gnu/store/vy5yzixfp3lz587rp52qdynisrnqgmiy-profile/lib/libnettle.so.6
      4478:	
      4478:	
      4478:	calling init: /gnu/store/vy5yzixfp3lz587rp52qdynisrnqgmiy-profile/lib/libhogweed.so.4
      4478:	
      4478:	
      4478:	calling init: /gnu/store/r9swffa651bgq4cvjgh81h6aqqzgwkjf-libtasn1-4.7/lib/libtasn1.so.6
      4478:	
      4478:	
      4478:	calling init: /gnu/store/pnax3d98xn5j7phj577v6sk9p9kfcs6m-libidn-1.32/lib/libidn.so.11
      4478:	
      4478:	
      4478:	calling init: /gnu/store/vy5yzixfp3lz587rp52qdynisrnqgmiy-profile/lib/libz.so.1
      4478:	
      4478:	
      4478:	calling init: /home/ludo/src/gnutls/+build/lib/.libs/libgnutls.so.30
      4478:	
      4478:	/home/ludo/src/gnutls/+build/lib/.libs/libgnutls.so.30: error: symbol lookup error: undefined symbol: getrandom (fatal)
      4478:	
      4478:	calling fini: /home/ludo/src/gnutls/+build/lib/.libs/libgnutls.so.30 [0]
--8<---------------cut here---------------end--------------->8---

However, at this stage, the program that loads libgnutls never returns
because the library?s destructor is stuck trying to acquire
?global_init_mutex?:

--8<---------------cut here---------------start------------->8---
(gdb) bt
#0  0x00007f4b339edd1c in __lll_lock_wait () from target:/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libpthread.so.0
#1  0x00007f4b339e7b15 in pthread_mutex_lock () from target:/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libpthread.so.0
#2  0x00007f4b302938dd in _gnutls_global_deinit (destructor=<optimized out>) at ../../lib/global.c:388
#3  0x00007f4b3420e167 in _dl_close_worker () from target:/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/ld-linux-x86-64.so.2
#4  0x00007f4b3420ce40 in _dl_open () from target:/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/ld-linux-x86-64.so.2
#5  0x00007f4b32dc7fb9 in dlopen_doit () from target:/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libdl.so.2
#6  0x00007f4b34208f34 in _dl_catch_error () from target:/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/ld-linux-x86-64.so.2
#7  0x00007f4b32dc8589 in _dlerror_run () from target:/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libdl.so.2
#8  0x00007f4b32dc8051 in dlopen@@GLIBC_2.2.5 () from target:/gnu/store/8m00x5x8ykmar27s9248cmhnkdb2n54a-glibc-2.22/lib/libdl.so.2
--8<---------------cut here---------------end--------------->8---

This happens due to lazy loading in ld.so under which the symbol lookup
error can happen in the middle of ?gnutls_global_init?, and thus trigger
the call to ?_gnutls_global_deinit? while ?global_init_mutex? is still
held.

Using LD_BIND_NOW=yes works around the problem: we get the error right
away, instead of having a program that never returns.

Ludo?.


From ludo at gnu.org  Wed Jul 27 21:56:49 2016
From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Date: Wed, 27 Jul 2016 21:56:49 +0200
Subject: [gnutls-devel] C99?
Message-ID: <87invqyhvi.fsf@gnu.org>

Hello,

With current master I get this:

--8<---------------cut here---------------start------------->8---
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../../lib/x509 -I../.. -I../../../lib/x509/../../gl -I./../../gl -I../../../lib/x509/../includes -I./../includes -I../../../lib/x509/.. -Wframe-larger-than=4096 -Wtype-limits -W -Wabi -Waddress -Waggressive-loop-optimizations -Wall -Wattributes -Wbad-function-cast -Wbuiltin-macro-redefined -Wcast-align -Wchar-subscripts -Wclobbered -Wcomment -Wcomments -Wcoverage-mismatch -Wcpp -Wdate-time -Wdeprecated -Wdeprecated-declarations -Wdisabled-optimization -Wdiv-by-zero -Wdouble-promotion -Wempty-body -Wendif-labels -Wenum-compare -Wextra -Wformat-contains-nul -Wformat-extra-args -Wformat-security -Wformat-zero-length -Wfree-nonheap-object -Wignored-qualifiers -Wimplicit -Wimplicit-function-declaration -Wimplicit-int -Winit-self -Wint-to-pointer-cast -Winvalid-memory-model -Winvalid-pch -Wjump-misses-init -Wlogical-op -Wmain -Wmaybe-uninitialized -Wmissing-braces -Wmissing-declarations -Wmissing-field-initializers -Wmissing-include-dirs -Wmissing-parameter-type -Wmissing-prototypes -Wmultichar -Wnarrowing -Wnested-externs -Wnonnull -Wold-style-declaration -Wold-style-definition -Wopenmp-simd -Woverflow -Woverride-init -Wpacked -Wpacked-bitfield-compat -Wparentheses -Wpointer-arith -Wpointer-sign -Wpointer-to-int-cast -Wpragmas -Wreturn-local-addr -Wreturn-type -Wsequence-point -Wshadow -Wsizeof-pointer-memaccess -Wstrict-aliasing -Wstrict-prototypes -Wsuggest-attribute=format -Wswitch -Wsync-nand -Wtrampolines -Wtrigraphs -Wtype-limits -Wuninitialized -Wunknown-pragmas -Wunused -Wunused-but-set-parameter -Wunused-but-set-variable -Wunused-function -Wunused-label -Wunused-local-typedefs -Wunused-macros -Wunused-parameter -Wunused-result -Wunused-value -Wunused-variable -Wvarargs -Wvariadic-macros -Wvector-operation-performance -Wvolatile-register-var -Wwrite-strings -Wnormalized=nfc -Wno-missing-field-initializers -Wno-unused-parameter -fdiagnostics-show-option -I/gnu/store/9b413hb811li9wim9advgcwllclhbgjg-nettle-3.2/include -I/gnu/store/r9swffa651bgq4cvjgh81h6aqqzgwkjf-libtasn1-4.7/include -I/gnu/store/pnax3d98xn5j7phj577v6sk9p9kfcs6m-libidn-1.32/include -g -O2 -MT name_constraints.lo -MD -MP -MF .deps/name_constraints.Tpo -c ../../../lib/x509/name_constraints.c  -fPIC -DPIC -o .libs/name_constraints.o
../../../lib/x509/name_constraints.c: In function '_gnutls_name_constraints_intersect':
../../../lib/x509/name_constraints.c:241:2: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
  for (int type = 1; type <= GNUTLS_SAN_MAX; type++) {
  ^
../../../lib/x509/name_constraints.c:241:2: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
Makefile:1438: recipe for target 'name_constraints.lo' failed
make[4]: *** [name_constraints.lo] Error 1
make[4]: Leaving directory '/home/ludo/src/gnutls/+build/lib/x509'
Makefile:1902: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/home/ludo/src/gnutls/+build/lib'
Makefile:1591: recipe for target 'all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory '/home/ludo/src/gnutls/+build/lib'
Makefile:1430: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/ludo/src/gnutls/+build'
Makefile:1358: recipe for target 'all' failed
make: *** [all] Error 2
ludo at pluto ~/src/gnutls/+build [env]# gcc --version
gcc (GCC) 4.9.3
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--8<---------------cut here---------------end--------------->8---

I don?t know if the intent is to use C99 or not.

Thanks,
Ludo?.


From ludo at gnu.org  Wed Jul 27 22:49:13 2016
From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Date: Wed, 27 Jul 2016 22:49:13 +0200
Subject: [gnutls-devel] guile and SSL 3.0
In-Reply-To: <CAJU7zaLaS8aTABTnnj4BZ1mt6x27pVU-Zh0i1rWTZvT1o+q6XA@mail.gmail.com>
 (Nikos Mavrogiannopoulos's message of "Wed, 27 Jul 2016 17:04:18
 +0200")
References: <CAJU7zaLaS8aTABTnnj4BZ1mt6x27pVU-Zh0i1rWTZvT1o+q6XA@mail.gmail.com>
Message-ID: <871t2eyfg6.fsf@gnu.org>

Hi,

Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> skribis:

>  On a fedora 24 system (with guile-2.0.11-9.fc24.x86_64), the guile
> tests crash when SSL 3.0 is disabled in gnutls. I am not sure if
> that's related to SSL3.0 removal, but only these builds occasionally
> fail.
>
> Examples on the CI (which uses fedora):
> https://gitlab.com/gnutls/gnutls/builds/2643058
> https://gitlab.com/gnutls/gnutls/builds/2642725

The above log has this:

--8<---------------cut here---------------start------------->8---
make[4]: Entering directory '/home/gitlab-runner/builds/0d36f420/1/gnutls/gnutls/build/guile'
PASS: tests/pkcs-import-export.scm
PASS: tests/errors.scm
PASS: tests/anonymous-auth.scm
PASS: tests/session-record-port.scm
PASS: tests/x509-certificates.scm
PASS: tests/openpgp-keys.scm
PASS: tests/priorities.scm
PASS: tests/x509-auth.scm
PASS: tests/openpgp-keyring.scm
PASS: tests/srp-base64.scm
../../build-aux/test-driver: line 107: 23410 Segmentation fault      (core dumped) "$@" > $log_file 2>&1
FAIL: tests/openpgp-auth.scm
--8<---------------cut here---------------end--------------->8---

I cannot reproduce it with 8098024c35f48a69ef88929ea370c0512bf235b0 when
running:

  while GUILE_WARN_DEPRECATED=no ./pre-inst-guile -L ../../guile/tests/ ../../guile/tests/openpgp-auth.scm ; do : ; done

Is there anything else I should know about the build environment or
configuration options?

> Could there be some hardcoded dependency on SSL3.0?

The generated file ?enum-map.i.c? refers to the
GNUTLS_A_SSL3_NO_CERTIFICATE and GNUTLS_SSL3 enum values, because they
are exported are part of the API.  If these enum values were no longer
defined, it would fail to build, but that?s all that could happen
AFAICS.

The ?tests/priorities.scm? file uses ?-VERS-SSL3.0? in priority strings,
but I guess this shouldn?t cause any problems either.

Ludo?.


From n.mavrogiannopoulos at gmail.com  Wed Jul 27 23:46:13 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 27 Jul 2016 23:46:13 +0200
Subject: [gnutls-devel] guile and SSL 3.0
In-Reply-To: <871t2eyfg6.fsf@gnu.org>
References: <CAJU7zaLaS8aTABTnnj4BZ1mt6x27pVU-Zh0i1rWTZvT1o+q6XA@mail.gmail.com>
 <871t2eyfg6.fsf@gnu.org>
Message-ID: <1469655973.4298.12.camel@gmail.com>

On Wed, 2016-07-27 at 22:49 +0200, Ludovic Court?s wrote:

> --8<---------------cut here---------------start------------->8---
> make[4]: Entering directory '/home/gitlab-
> runner/builds/0d36f420/1/gnutls/gnutls/build/guile'
> PASS: tests/pkcs-import-export.scm
> PASS: tests/errors.scm
> PASS: tests/anonymous-auth.scm
> PASS: tests/session-record-port.scm
> PASS: tests/x509-certificates.scm
> PASS: tests/openpgp-keys.scm
> PASS: tests/priorities.scm
> PASS: tests/x509-auth.scm
> PASS: tests/openpgp-keyring.scm
> PASS: tests/srp-base64.scm
> ../../build-aux/test-driver: line 107: 23410 Segmentation
> fault??????(core dumped) "$@" > $log_file 2>&1
> FAIL: tests/openpgp-auth.scm
> --8<---------------cut here---------------end--------------->8---
> 
> I cannot reproduce it with 8098024c35f48a69ef88929ea370c0512bf235b0
> when
> running:
> 
> ? while GUILE_WARN_DEPRECATED=no ./pre-inst-guile -L
> ../../guile/tests/ ../../guile/tests/openpgp-auth.scm ; do : ; done
> 
> Is there anything else I should know about the build environment or
> configuration options?

It may be the compiler (either compilation of guile or gnutls'
bindings)... That system uses gcc 6.1.1. Not sure if you'd like to
debug it further, but if you do and you make a clone of the gnutls
repository in gitlab I could give you access to that CI system.

Otherwise I'll disable that system from being used for the guile CI.

> > Could there be some hardcoded dependency on SSL3.0?
> The generated file ?enum-map.i.c? refers to the
> GNUTLS_A_SSL3_NO_CERTIFICATE and GNUTLS_SSL3 enum values, because
> they
> are exported are part of the API.??If these enum values were no
> longer
> defined, it would fail to build, but that?s all that could happen
> AFAICS.
> 
> The ?tests/priorities.scm? file uses ?-VERS-SSL3.0? in priority
> strings,
> but I guess this shouldn?t cause any problems either.

These should not pose any problem.

regards,
Nikos



From n.mavrogiannopoulos at gmail.com  Wed Jul 27 23:29:43 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 27 Jul 2016 23:29:43 +0200
Subject: [gnutls-devel] Deconstructor deadlock
In-Reply-To: <878twmyg8p.fsf@gnu.org>
References: <878twmyg8p.fsf@gnu.org>
Message-ID: <1469654983.4298.3.camel@gmail.com>

On Wed, 2016-07-27 at 22:32 +0200, Ludovic Court?s wrote:
> Hello,


? ? ? 4478:	/home/ludo/src/gnutls/+build/lib/.libs/libgnutls.s
> o.30: error: symbol lookup error: undefined symbol: getrandom (fatal)
> ??????4478:	
> ??????4478:	calling fini:
> /home/ludo/src/gnutls/+build/lib/.libs/libgnutls.so.30 [0]
> --8<---------------cut here---------------end--------------->8---

Thanks for the report. That's quite strange though. I would have
expected configure to detect that getrandom was not available in that
system. Is it a binary configured in a different system than being run?
If not what is the output of config.log near the "checking for
getrandom" lines?

For the deadlock, it may be a good idea to remove all locking when
called at the constructor. There is no concurrency there.

regards,
Nikos



From n.mavrogiannopoulos at gmail.com  Wed Jul 27 23:39:51 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Wed, 27 Jul 2016 23:39:51 +0200
Subject: [gnutls-devel] C99?
In-Reply-To: <87invqyhvi.fsf@gnu.org>
References: <87invqyhvi.fsf@gnu.org>
Message-ID: <1469655591.4298.6.camel@gmail.com>

On Wed, 2016-07-27 at 21:56 +0200, Ludovic Court?s wrote:
> Hello,
> 
> With current master I get this:
> 

> '_gnutls_name_constraints_intersect':
> ../../../lib/x509/name_constraints.c:241:2: error: 'for' loop initial
> declarations are only allowed in C99 or C11 mode
> ? for (int type = 1; type <= GNUTLS_SAN_MAX; type++) {
> ? ^
> ../../../lib/x509/name_constraints.c:241:2: note: use option
> -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
> Makefile:1438: recipe for target 'name_constraints.lo' failed

Thanks, I didn't know that gcc4 choked on it. I would expect any
compiler to understand c99 today. Anyway I've committed a fix for it,
since we don't use this declaration form anywhere else. Otherwise, I'm
quite inclined towards moving to c99 completely.

regards,
Nikos



From tim.kosse at filezilla-project.org  Wed Jul 27 23:56:17 2016
From: tim.kosse at filezilla-project.org (Tim Kosse)
Date: Wed, 27 Jul 2016 23:56:17 +0200
Subject: [gnutls-devel] Bugfixes for certificate lists
In-Reply-To: <a6c756f1-5db8-017b-4858-eecb3edd15cc@filezilla-project.org>
References: <a6c756f1-5db8-017b-4858-eecb3edd15cc@filezilla-project.org>
Message-ID: <74dbe304-974d-e7bb-3105-7bf9a27a91e3@filezilla-project.org>

Hi,

could I please get some feedback on these patches?

Regards,
Tim

On 2016-07-09 13:05, Tim Kosse wrote:
> Hi,
> 
> for small certificate lists, gnutls_x509_crt_list_import2 is ignoring
> the GNUTLS_X509_CRT_LIST_SORT and GNUTLS_X509_CRT_LIST_FAIL_IF_UNSORTED
> flags.
> 
> As result, gnutls-cli-debug incorrectly reports a server's certificate
> chain order as sorted even if it isn't.
> 
> 
> I've also fixed the documentation of gnutls_certificate_get_peers, the
> list it returns isn't actually sorted.
> 
> 
> I wonder, should we add a function that makes it easier to obtain a
> sorted peer certificate list (or an error if it cannot be sorted)?
> 
> 
> Regards,
> Tim
> 


From tmatth at videolan.org  Thu Jul 28 02:22:21 2016
From: tmatth at videolan.org (Tristan Matthews)
Date: Wed, 27 Jul 2016 21:22:21 -0300
Subject: [gnutls-devel] [PATCH] .gitignore: add config.rpath-
Message-ID: <1469665341-14857-1-git-send-email-tmatth@videolan.org>

---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index c03a8b8..6aa0646 100644
--- a/.gitignore
+++ b/.gitignore
@@ -20,6 +20,7 @@ aclocal.m4
 autom4te.cache/
 build-aux/compile
 build-aux/config.guess
+build-aux/config.rpath-
 build-aux/config.sub
 build-aux/depcomp
 build-aux/install-sh
-- 
1.9.1



From eliz at gnu.org  Thu Jul 28 04:36:35 2016
From: eliz at gnu.org (Eli Zaretskii)
Date: Thu, 28 Jul 2016 05:36:35 +0300
Subject: [gnutls-devel] C99?
In-Reply-To: <1469655591.4298.6.camel@gmail.com> (message from Nikos
 Mavrogiannopoulos on Wed, 27 Jul 2016 23:39:51 +0200)
References: <87invqyhvi.fsf@gnu.org> <1469655591.4298.6.camel@gmail.com>
Message-ID: <834m7asd3g.fsf@gnu.org>

> From: Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com>
> Date: Wed, 27 Jul 2016 23:39:51 +0200
> 
> > '_gnutls_name_constraints_intersect':
> > ../../../lib/x509/name_constraints.c:241:2: error: 'for' loop initial
> > declarations are only allowed in C99 or C11 mode
> > ? for (int type = 1; type <= GNUTLS_SAN_MAX; type++) {
> > ? ^
> > ../../../lib/x509/name_constraints.c:241:2: note: use option
> > -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
> > Makefile:1438: recipe for target 'name_constraints.lo' failed
> 
> Thanks, I didn't know that gcc4 choked on it. I would expect any
> compiler to understand c99 today.

It does, but only if you say -std=gnu99 or -std=c99.  The default in
GCC 4 is still C90.


From nmav at gnutls.org  Thu Jul 28 08:50:36 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 28 Jul 2016 08:50:36 +0200
Subject: [gnutls-devel] [PATCH] .gitignore: add config.rpath-
In-Reply-To: <1469665341-14857-1-git-send-email-tmatth@videolan.org>
References: <1469665341-14857-1-git-send-email-tmatth@videolan.org>
Message-ID: <CAJU7zaJM5=RZHvW1__LpGRS5t4n3xWo8pCx44Hnsm2rOKUK7GA@mail.gmail.com>

On Thu, Jul 28, 2016 at 2:22 AM, Tristan Matthews <tmatth at videolan.org> wrote:
> ---
>  .gitignore | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/.gitignore b/.gitignore
> index c03a8b8..6aa0646 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -20,6 +20,7 @@ aclocal.m4
>  autom4te.cache/
>  build-aux/compile
>  build-aux/config.guess
> +build-aux/config.rpath-

Hi,
 Is that file still needed to be ignored? In the master repository it
should no longer be generated/used.

regards,
Nikos


From nmav at gnutls.org  Thu Jul 28 09:45:50 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 28 Jul 2016 09:45:50 +0200
Subject: [gnutls-devel] Bugfixes for certificate lists
In-Reply-To: <74dbe304-974d-e7bb-3105-7bf9a27a91e3@filezilla-project.org>
References: <a6c756f1-5db8-017b-4858-eecb3edd15cc@filezilla-project.org>
 <74dbe304-974d-e7bb-3105-7bf9a27a91e3@filezilla-project.org>
Message-ID: <CAJU7zaLGgGKx66GAi2QQPJLyJFp_mi93Z2_gec938cq+gWXBoA@mail.gmail.com>

On Wed, Jul 27, 2016 at 11:56 PM, Tim Kosse
<tim.kosse at filezilla-project.org> wrote:
> Hi,
> could I please get some feedback on these patches?

I cannot find them in my mailbox, and I only found this email of yours
in my spam folder. I'll try to figure them out from gmane.

regards,
Nikos


From tim.ruehsen at gmx.de  Thu Jul 28 10:06:59 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Thu, 28 Jul 2016 10:06:59 +0200
Subject: [gnutls-devel] C99?
In-Reply-To: <834m7asd3g.fsf@gnu.org>
References: <87invqyhvi.fsf@gnu.org> <1469655591.4298.6.camel@gmail.com>
 <834m7asd3g.fsf@gnu.org>
Message-ID: <2717202.YTqtL5r1vT@blitz-lx>

On Thursday, July 28, 2016 5:36:35 AM CEST Eli Zaretskii wrote:
> > From: Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com>
> > Date: Wed, 27 Jul 2016 23:39:51 +0200
> > 
> > > '_gnutls_name_constraints_intersect':
> > > ../../../lib/x509/name_constraints.c:241:2: error: 'for' loop initial
> > > declarations are only allowed in C99 or C11 mode
> > >   for (int type = 1; type <= GNUTLS_SAN_MAX; type++) {
> > >   ^
> > > ../../../lib/x509/name_constraints.c:241:2: note: use option
> > > -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
> > > Makefile:1438: recipe for target 'name_constraints.lo' failed
> > 
> > Thanks, I didn't know that gcc4 choked on it. I would expect any
> > compiler to understand c99 today.
> 
> It does, but only if you say -std=gnu99 or -std=c99.  The default in
> GCC 4 is still C90.

IMO, C99 is a good thing that the project should move forward to.

Here is a patch to require a C99 supporting compiler.
For e.g. GCC 4, -std=gnu99 is automatically added to the CFLAGS with this 
patch, so that simply works.

You could consider to change the AC_ERROR into a warning and try to continue.

But anyways, be prepared to get rants from people who try to keep ultra-aged 
systems with just GnuTLS enforced to the latest version ;-)

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Require-compiler-to-support-C99.patch
Type: text/x-patch
Size: 658 bytes
Desc: not available
URL: </pipermail/attachments/20160728/d992da55/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160728/d992da55/attachment.sig>

From tim.ruehsen at gmx.de  Thu Jul 28 10:12:55 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Thu, 28 Jul 2016 10:12:55 +0200
Subject: [gnutls-devel] [PATCH] .gitignore: add config.rpath-
In-Reply-To: <CAJU7zaJM5=RZHvW1__LpGRS5t4n3xWo8pCx44Hnsm2rOKUK7GA@mail.gmail.com>
References: <1469665341-14857-1-git-send-email-tmatth@videolan.org>
 <CAJU7zaJM5=RZHvW1__LpGRS5t4n3xWo8pCx44Hnsm2rOKUK7GA@mail.gmail.com>
Message-ID: <6625832.M1M7d57f5N@blitz-lx>

On Thursday, July 28, 2016 8:50:36 AM CEST Nikos Mavrogiannopoulos wrote:
> On Thu, Jul 28, 2016 at 2:22 AM, Tristan Matthews <tmatth at videolan.org> 
wrote:
> > ---
> > 
> >  .gitignore | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/.gitignore b/.gitignore
> > index c03a8b8..6aa0646 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -20,6 +20,7 @@ aclocal.m4
> > 
> >  autom4te.cache/
> >  build-aux/compile
> >  build-aux/config.guess
> > 
> > +build-aux/config.rpath-
> 
> Hi,
>  Is that file still needed to be ignored? In the master repository it
> should no longer be generated/used.

It will be auto-generated (at least here), but is catched by the '*~' rule in 
.gitignore.

But what about adding
        config.cache
        gl/tests/ctype.h
        gl/tests/test-ctype

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160728/a9ee181d/attachment.sig>

From nmav at gnutls.org  Thu Jul 28 10:58:56 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 28 Jul 2016 10:58:56 +0200
Subject: [gnutls-devel] Bugfixes for certificate lists
In-Reply-To: <74dbe304-974d-e7bb-3105-7bf9a27a91e3@filezilla-project.org>
References: <a6c756f1-5db8-017b-4858-eecb3edd15cc@filezilla-project.org>
 <74dbe304-974d-e7bb-3105-7bf9a27a91e3@filezilla-project.org>
Message-ID: <CAJU7za+4r2ua4ZpNYw=oYKZCmzkT0JvOL4151RO5Ycy3=CVm8Q@mail.gmail.com>

On Wed, Jul 27, 2016 at 11:56 PM, Tim Kosse
<tim.kosse at filezilla-project.org> wrote:
> Hi,
> could I please get some feedback on these patches?

They look good, thank you.

I didn't like that change though:
> - * a X.509 then a certificate list may be present.  The first
> - * certificate in the list is the peer's certificate, following the
> - * issuer's certificate, then the issuer's issuer etc.
> + * a X.509 then a certificate list may be present.  This list is not
> + * sorted.

I think it is more accurate to say that the list is provided as sent
by the server, and servers are expected to provide a sorted list. I've
added some text on these lines at the following merge request. Let me
know if that's ok.
https://gitlab.com/gnutls/gnutls/merge_requests/31

I wonder whether we need to add a certificate_get_peers function which
is guaranteed to return a sorted list (or modify that one to do so).

regards,
Nikos


From n.mavrogiannopoulos at gmail.com  Thu Jul 28 11:21:08 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 28 Jul 2016 11:21:08 +0200
Subject: [gnutls-devel] C99?
In-Reply-To: <2717202.YTqtL5r1vT@blitz-lx>
References: <87invqyhvi.fsf@gnu.org> <1469655591.4298.6.camel@gmail.com>
 <834m7asd3g.fsf@gnu.org> <2717202.YTqtL5r1vT@blitz-lx>
Message-ID: <CAJU7za+MAoJyMmvRjWRyXa5wrgTgTFf9qTULS8FM-DHK37Ntmw@mail.gmail.com>

On Thu, Jul 28, 2016 at 10:06 AM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
>> > > '_gnutls_name_constraints_intersect':
>> > > ../../../lib/x509/name_constraints.c:241:2: error: 'for' loop initial
>> > > declarations are only allowed in C99 or C11 mode
>> > >   for (int type = 1; type <= GNUTLS_SAN_MAX; type++) {
>> > >   ^
>> > > ../../../lib/x509/name_constraints.c:241:2: note: use option
>> > > -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
>> > > Makefile:1438: recipe for target 'name_constraints.lo' failed
>> >
>> > Thanks, I didn't know that gcc4 choked on it. I would expect any
>> > compiler to understand c99 today.
>>
>> It does, but only if you say -std=gnu99 or -std=c99.  The default in
>> GCC 4 is still C90.
> IMO, C99 is a good thing that the project should move forward to.
> Here is a patch to require a C99 supporting compiler.
> For e.g. GCC 4, -std=gnu99 is automatically added to the CFLAGS with this
> patch, so that simply works.
> You could consider to change the AC_ERROR into a warning and try to continue.

Seems like a good idea. I've changed the error to warning and made a
merge request.

> But anyways, be prepared to get rants from people who try to keep ultra-aged
> systems with just GnuTLS enforced to the latest version ;-)

It's funny that C99 was always a considered a new thing as long as I
can remember. I think after 17 years is time to consider it something
old and support it by default :)

regards,
Nikos


From ludo at gnu.org  Thu Jul 28 11:25:32 2016
From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Date: Thu, 28 Jul 2016 11:25:32 +0200
Subject: [gnutls-devel] Deconstructor deadlock
In-Reply-To: <1469654983.4298.3.camel@gmail.com> (Nikos Mavrogiannopoulos's
 message of "Wed, 27 Jul 2016 23:29:43 +0200")
References: <878twmyg8p.fsf@gnu.org> <1469654983.4298.3.camel@gmail.com>
Message-ID: <87invqktbn.fsf@gnu.org>

Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> skribis:

> On Wed, 2016-07-27 at 22:32 +0200, Ludovic Court?s wrote:
>> Hello,
>
>
> ? ? ? 4478:	/home/ludo/src/gnutls/+build/lib/.libs/libgnutls.s
>> o.30: error: symbol lookup error: undefined symbol: getrandom (fatal)
>> ??????4478:	
>> ??????4478:	calling fini:
>> /home/ludo/src/gnutls/+build/lib/.libs/libgnutls.so.30 [0]
>> --8<---------------cut here---------------end--------------->8---
>
> Thanks for the report. That's quite strange though. I would have
> expected configure to detect that getrandom was not available in that
> system. Is it a binary configured in a different system than being run?
> If not what is the output of config.log near the "checking for
> getrandom" lines?

Here I fiddled with rnd-linux.c, but that would be the subject of
another report.  :-)

> For the deadlock, it may be a good idea to remove all locking when
> called at the constructor. There is no concurrency there.

Definitely.

Thanks,
Ludo?.


From nmav at gnutls.org  Thu Jul 28 11:25:28 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 28 Jul 2016 11:25:28 +0200
Subject: [gnutls-devel] [PATCH] .gitignore: add config.rpath-
In-Reply-To: <6625832.M1M7d57f5N@blitz-lx>
References: <1469665341-14857-1-git-send-email-tmatth@videolan.org>
 <CAJU7zaJM5=RZHvW1__LpGRS5t4n3xWo8pCx44Hnsm2rOKUK7GA@mail.gmail.com>
 <6625832.M1M7d57f5N@blitz-lx>
Message-ID: <CAJU7zaKyjhPKhvTS42MhOc-R_H7kqDfbPdJuDHfYXUcAGf=50Q@mail.gmail.com>

On Thu, Jul 28, 2016 at 10:12 AM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
>> > +build-aux/config.rpath-
>>
>> Hi,
>>  Is that file still needed to be ignored? In the master repository it
>> should no longer be generated/used.
>
> It will be auto-generated (at least here), but is catched by the '*~' rule in
> .gitignore.

Hi,
 Is that a typo? The file has '-' as suffix.

> But what about adding
>         config.cache
>         gl/tests/ctype.h
>         gl/tests/test-ctype

Makes sense. Included in the previous merge req.

Thanks.

regards,
Nikos


From tim.ruehsen at gmx.de  Thu Jul 28 11:31:11 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Thu, 28 Jul 2016 11:31:11 +0200
Subject: [gnutls-devel] [PATCH] .gitignore: add config.rpath-
In-Reply-To: <CAJU7zaKyjhPKhvTS42MhOc-R_H7kqDfbPdJuDHfYXUcAGf=50Q@mail.gmail.com>
References: <1469665341-14857-1-git-send-email-tmatth@videolan.org>
 <6625832.M1M7d57f5N@blitz-lx>
 <CAJU7zaKyjhPKhvTS42MhOc-R_H7kqDfbPdJuDHfYXUcAGf=50Q@mail.gmail.com>
Message-ID: <1907453.tgheKrBh0y@blitz-lx>

On Thursday, July 28, 2016 11:25:28 AM CEST Nikos Mavrogiannopoulos wrote:
> On Thu, Jul 28, 2016 at 10:12 AM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> >> > +build-aux/config.rpath-
> >> 
> >> Hi,
> >> 
> >>  Is that file still needed to be ignored? In the master repository it
> >> 
> >> should no longer be generated/used.
> > 
> > It will be auto-generated (at least here), but is catched by the '*~' rule
> > in .gitignore.
> 
> Hi,
>  Is that a typo? The file has '-' as suffix.

Ups, yes. Must be the font (not to say that I might need new glasses :).
Can't see a file here tailed with '-' (minus) .

Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160728/1cb0b61e/attachment.sig>

From tim.kosse at filezilla-project.org  Thu Jul 28 13:32:13 2016
From: tim.kosse at filezilla-project.org (Tim Kosse)
Date: Thu, 28 Jul 2016 13:32:13 +0200
Subject: [gnutls-devel] Bugfixes for certificate lists
In-Reply-To: <CAJU7za+4r2ua4ZpNYw=oYKZCmzkT0JvOL4151RO5Ycy3=CVm8Q@mail.gmail.com>
References: <a6c756f1-5db8-017b-4858-eecb3edd15cc@filezilla-project.org>
 <74dbe304-974d-e7bb-3105-7bf9a27a91e3@filezilla-project.org>
 <CAJU7za+4r2ua4ZpNYw=oYKZCmzkT0JvOL4151RO5Ycy3=CVm8Q@mail.gmail.com>
Message-ID: <e8b4c614-d451-20a2-5b36-494351d7f88b@filezilla-project.org>

On 2016-07-28 10:58, Nikos Mavrogiannopoulos wrote:
> I didn't like that change though:
>> - * a X.509 then a certificate list may be present.  The first
>> - * certificate in the list is the peer's certificate, following the
>> - * issuer's certificate, then the issuer's issuer etc.
>> + * a X.509 then a certificate list may be present.  This list is not
>> + * sorted.
> 
> I think it is more accurate to say that the list is provided as sent
> by the server, and servers are expected to provide a sorted list. I've
> added some text on these lines at the following merge request. Let me
> know if that's ok.
> https://gitlab.com/gnutls/gnutls/merge_requests/31

Sounds good.

> I wonder whether we need to add a certificate_get_peers function which
> is guaranteed to return a sorted list (or modify that one to do so).

Changing the existing function would break programs relying that it
returns the certificates as received by the server, e.g. gnutls-cli-debug.

So I suppose there needs to be a function to return the certificates as
received. How about adding certificate_get_peers2 with a flags argument
just like gnutls_x509_crt_list_import2?

Regards,
Tim


From n.mavrogiannopoulos at gmail.com  Thu Jul 28 13:44:55 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Thu, 28 Jul 2016 13:44:55 +0200
Subject: [gnutls-devel] Deconstructor deadlock
In-Reply-To: <87invqktbn.fsf@gnu.org>
References: <878twmyg8p.fsf@gnu.org> <1469654983.4298.3.camel@gmail.com>
 <87invqktbn.fsf@gnu.org>
Message-ID: <CAJU7zaJBu8uefyJLVyXhq29qiFaqPEW9E954cHaWMauPKRJSwg@mail.gmail.com>

On Thu, Jul 28, 2016 at 11:25 AM, Ludovic Court?s <ludo at gnu.org> wrote:
>> Thanks for the report. That's quite strange though. I would have
>> expected configure to detect that getrandom was not available in that
>> system. Is it a binary configured in a different system than being run?
>> If not what is the output of config.log near the "checking for
>> getrandom" lines?
> Here I fiddled with rnd-linux.c, but that would be the subject of
> another report.  :-)

Ok, thanks. I'm not changing the getrandom detection then.

>> For the deadlock, it may be a good idea to remove all locking when
>> called at the constructor. There is no concurrency there.
> Definitely.

Already done in master.

regards,
Nikos


From nmav at gnutls.org  Thu Jul 28 14:04:05 2016
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 28 Jul 2016 14:04:05 +0200
Subject: [gnutls-devel] Bugfixes for certificate lists
In-Reply-To: <e8b4c614-d451-20a2-5b36-494351d7f88b@filezilla-project.org>
References: <a6c756f1-5db8-017b-4858-eecb3edd15cc@filezilla-project.org>
 <74dbe304-974d-e7bb-3105-7bf9a27a91e3@filezilla-project.org>
 <CAJU7za+4r2ua4ZpNYw=oYKZCmzkT0JvOL4151RO5Ycy3=CVm8Q@mail.gmail.com>
 <e8b4c614-d451-20a2-5b36-494351d7f88b@filezilla-project.org>
Message-ID: <CAJU7zaK-32JHnh8K8At_+ZAwwNfaSBhXKbNMQAqKcswMRaCX+w@mail.gmail.com>

On Thu, Jul 28, 2016 at 1:32 PM, Tim Kosse
<tim.kosse at filezilla-project.org> wrote:
>> I wonder whether we need to add a certificate_get_peers function which
>> is guaranteed to return a sorted list (or modify that one to do so).
> Changing the existing function would break programs relying that it
> returns the certificates as received by the server, e.g. gnutls-cli-debug.
> So I suppose there needs to be a function to return the certificates as
> received. How about adding certificate_get_peers2 with a flags argument
> just like gnutls_x509_crt_list_import2?

Sounds reasonable. It's not priority for me, but I've created a ticket
for it, so it doesn't get lost.
https://gitlab.com/gnutls/gnutls/issues/116

regards,
Nikos


From tmatth at videolan.org  Thu Jul 28 15:32:16 2016
From: tmatth at videolan.org (Tristan Matthews)
Date: Thu, 28 Jul 2016 10:32:16 -0300
Subject: [gnutls-devel] [PATCH] .gitignore: add config.rpath-
In-Reply-To: <1907453.tgheKrBh0y@blitz-lx>
References: <1469665341-14857-1-git-send-email-tmatth@videolan.org>
 <6625832.M1M7d57f5N@blitz-lx>
 <CAJU7zaKyjhPKhvTS42MhOc-R_H7kqDfbPdJuDHfYXUcAGf=50Q@mail.gmail.com>
 <1907453.tgheKrBh0y@blitz-lx>
Message-ID: <CAN8HRDmwxYjnCOZCetVpDPJH7fvrTBTjUhH5mKYDv63kxryiAw@mail.gmail.com>

On Thu, Jul 28, 2016 at 6:31 AM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
> On Thursday, July 28, 2016 11:25:28 AM CEST Nikos Mavrogiannopoulos wrote:
>> On Thu, Jul 28, 2016 at 10:12 AM, Tim Ruehsen <tim.ruehsen at gmx.de> wrote:
>> >> > +build-aux/config.rpath-
>> >>
>> >> Hi,
>> >>
>> >>  Is that file still needed to be ignored? In the master repository it
>> >>
>> >> should no longer be generated/used.

Seems like it was only generated with older autotools (or on error?),
I've since upgraded and can no longer reproduce, so please ignore.

Best,
Tristan


From eliz at gnu.org  Thu Jul 28 16:51:22 2016
From: eliz at gnu.org (Eli Zaretskii)
Date: Thu, 28 Jul 2016 17:51:22 +0300
Subject: [gnutls-devel] C99?
In-Reply-To: <CAJU7za+MAoJyMmvRjWRyXa5wrgTgTFf9qTULS8FM-DHK37Ntmw@mail.gmail.com>
 (message from Nikos Mavrogiannopoulos on Thu, 28 Jul 2016 11:21:08
 +0200)
References: <87invqyhvi.fsf@gnu.org> <1469655591.4298.6.camel@gmail.com>
 <834m7asd3g.fsf@gnu.org> <2717202.YTqtL5r1vT@blitz-lx>
 <CAJU7za+MAoJyMmvRjWRyXa5wrgTgTFf9qTULS8FM-DHK37Ntmw@mail.gmail.com>
Message-ID: <83vazprf2t.fsf@gnu.org>

> From: Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com>
> Date: Thu, 28 Jul 2016 11:21:08 +0200
> Cc: GnuTLS development list <gnutls-devel at lists.gnutls.org>, Eli Zaretskii <eliz at gnu.org>, 
> 	Ludovic Court?s <ludo at gnu.org>
> 
> It's funny that C99 was always a considered a new thing as long as I
> can remember. I think after 17 years is time to consider it something
> old and support it by default :)

Latest versions of GCC do.


From tim.ruehsen at gmx.de  Thu Jul 28 17:01:44 2016
From: tim.ruehsen at gmx.de (Tim Ruehsen)
Date: Thu, 28 Jul 2016 17:01:44 +0200
Subject: [gnutls-devel] C99?
In-Reply-To: <83vazprf2t.fsf@gnu.org>
References: <87invqyhvi.fsf@gnu.org>
 <CAJU7za+MAoJyMmvRjWRyXa5wrgTgTFf9qTULS8FM-DHK37Ntmw@mail.gmail.com>
 <83vazprf2t.fsf@gnu.org>
Message-ID: <2149067.Hz4Pvpc4Cc@blitz-lx>

On Thursday, July 28, 2016 5:51:22 PM CEST Eli Zaretskii wrote:
> > From: Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com>
> > Date: Thu, 28 Jul 2016 11:21:08 +0200
> > Cc: GnuTLS development list <gnutls-devel at lists.gnutls.org>, Eli Zaretskii
> > <eliz at gnu.org>,> 
> > 	Ludovic Court?s <ludo at gnu.org>
> > 
> > It's funny that C99 was always a considered a new thing as long as I
> > can remember. I think after 17 years is time to consider it something
> > old and support it by default :)
> 
> Latest versions of GCC do.

Many of the 1990ies GCC extensions went into the C99 standard.
So maybe even very old (20+ years) versions of GCC are good enough - but 
really... anyone using GCC 3.x to compile 2016 C sources ?

I still use 2.95.3 for one customer (and I guess even 2.7 on an old SCO 
development system - but used rarely and thus currently down)... but hey, I 
would never even try to compile GnuTLS 5.3.x there :-))

Regards, Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160728/417c9f5e/attachment.sig>

From mukrop at redhat.com  Fri Jul 29 15:29:23 2016
From: mukrop at redhat.com (Martin Ukrop)
Date: Fri, 29 Jul 2016 15:29:23 +0200
Subject: [gnutls-devel] New developer DCO
Message-ID: <2b9fd70e-3988-dc60-0536-b353a5a36f8d@redhat.com>

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
     have the right to submit it under the open source license
     indicated in the file; or

(b) The contribution is based upon previous work that, to the best
     of my knowledge, is covered under an appropriate open source
     license and I have the right under that license to submit that
     work with modifications, whether created in whole or in part
     by me, under the same open source license (unless I am
     permitted to submit under a different license), as indicated
     in the file; or

(c) The contribution was provided directly to me by some other
     person who certified (a), (b) or (c) and I have not modified
     it.

(d) I understand and agree that this project and the contribution
     are public and that a record of the contribution (including all
     personal information I submit with it, including my sign-off) is
     maintained indefinitely and may be redistributed consistent with
     this project or the open source license(s) involved.

Martin Ukrop
(mukrop at redhat.com)



From ludo at gnu.org  Fri Jul 29 16:47:16 2016
From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Date: Fri, 29 Jul 2016 16:47:16 +0200
Subject: [gnutls-devel] guile and SSL 3.0
In-Reply-To: <1469655973.4298.12.camel@gmail.com> (Nikos Mavrogiannopoulos's
 message of "Wed, 27 Jul 2016 23:46:13 +0200")
References: <CAJU7zaLaS8aTABTnnj4BZ1mt6x27pVU-Zh0i1rWTZvT1o+q6XA@mail.gmail.com>
 <871t2eyfg6.fsf@gnu.org> <1469655973.4298.12.camel@gmail.com>
Message-ID: <87h9b8bix7.fsf@gnu.org>

Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> skribis:

> On Wed, 2016-07-27 at 22:49 +0200, Ludovic Court?s wrote:
>
>> --8<---------------cut here---------------start------------->8---
>> make[4]: Entering directory '/home/gitlab-
>> runner/builds/0d36f420/1/gnutls/gnutls/build/guile'
>> PASS: tests/pkcs-import-export.scm
>> PASS: tests/errors.scm
>> PASS: tests/anonymous-auth.scm
>> PASS: tests/session-record-port.scm
>> PASS: tests/x509-certificates.scm
>> PASS: tests/openpgp-keys.scm
>> PASS: tests/priorities.scm
>> PASS: tests/x509-auth.scm
>> PASS: tests/openpgp-keyring.scm
>> PASS: tests/srp-base64.scm
>> ../../build-aux/test-driver: line 107: 23410 Segmentation
>> fault??????(core dumped) "$@" > $log_file 2>&1
>> FAIL: tests/openpgp-auth.scm
>> --8<---------------cut here---------------end--------------->8---
>> 
>> I cannot reproduce it with 8098024c35f48a69ef88929ea370c0512bf235b0
>> when
>> running:
>> 
>> ? while GUILE_WARN_DEPRECATED=no ./pre-inst-guile -L
>> ../../guile/tests/ ../../guile/tests/openpgp-auth.scm ; do : ; done
>> 
>> Is there anything else I should know about the build environment or
>> configuration options?
>
> It may be the compiler (either compilation of guile or gnutls'
> bindings)... That system uses gcc 6.1.1. Not sure if you'd like to
> debug it further, but if you do and you make a clone of the gnutls
> repository in gitlab I could give you access to that CI system.

I?ve rebuilt GnuTLS master (but not Guile) with GCC 6.1.0 and can?t seem
to reproduce this segfault.

Could you post a backtrace of the core dump?  It might give clues.

Thanks,
Ludo?.


From n.mavrogiannopoulos at gmail.com  Fri Jul 29 18:15:43 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Fri, 29 Jul 2016 18:15:43 +0200
Subject: [gnutls-devel] guile and SSL 3.0
In-Reply-To: <87h9b8bix7.fsf@gnu.org>
References: <CAJU7zaLaS8aTABTnnj4BZ1mt6x27pVU-Zh0i1rWTZvT1o+q6XA@mail.gmail.com>
 <871t2eyfg6.fsf@gnu.org> <1469655973.4298.12.camel@gmail.com>
 <87h9b8bix7.fsf@gnu.org>
Message-ID: <CAJU7zaJAMjn0JomD4fYK0Rxvqn+24950SCJ9mC6fU=oGmdg78w@mail.gmail.com>

On Fri, Jul 29, 2016 at 4:47 PM, Ludovic Court?s <ludo at gnu.org> wrote:
>>> I cannot reproduce it with 8098024c35f48a69ef88929ea370c0512bf235b0
>>> when
>>> running:
>>>   while GUILE_WARN_DEPRECATED=no ./pre-inst-guile -L
>>> ../../guile/tests/ ../../guile/tests/openpgp-auth.scm ; do : ; done
>>> Is there anything else I should know about the build environment or
>>> configuration options?
>> It may be the compiler (either compilation of guile or gnutls'
>> bindings)... That system uses gcc 6.1.1. Not sure if you'd like to
>> debug it further, but if you do and you make a clone of the gnutls
>> repository in gitlab I could give you access to that CI system.
> I?ve rebuilt GnuTLS master (but not Guile) with GCC 6.1.0 and can?t seem
> to reproduce this segfault.
> Could you post a backtrace of the core dump?  It might give clues.

I couldn't reproduce it in my last attempts but accessing that system
isn't easy. Would it work if we run the guile tests under valgrind
similarly to how we do at tests, or could there be a problem with
guile? If that could work, we would have the trace on any failure on
the build artifacts (in the .log files).

regards,
Nikos


From ludo at gnu.org  Fri Jul 29 22:40:49 2016
From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Date: Fri, 29 Jul 2016 22:40:49 +0200
Subject: [gnutls-devel] guile and SSL 3.0
In-Reply-To: <CAJU7zaJAMjn0JomD4fYK0Rxvqn+24950SCJ9mC6fU=oGmdg78w@mail.gmail.com>
 (Nikos Mavrogiannopoulos's message of "Fri, 29 Jul 2016 18:15:43
 +0200")
References: <CAJU7zaLaS8aTABTnnj4BZ1mt6x27pVU-Zh0i1rWTZvT1o+q6XA@mail.gmail.com>
 <871t2eyfg6.fsf@gnu.org> <1469655973.4298.12.camel@gmail.com>
 <87h9b8bix7.fsf@gnu.org>
 <CAJU7zaJAMjn0JomD4fYK0Rxvqn+24950SCJ9mC6fU=oGmdg78w@mail.gmail.com>
Message-ID: <87fuqsxjn2.fsf@gnu.org>

Nikos Mavrogiannopoulos <n.mavrogiannopoulos at gmail.com> skribis:

> On Fri, Jul 29, 2016 at 4:47 PM, Ludovic Court?s <ludo at gnu.org> wrote:
>>>> I cannot reproduce it with 8098024c35f48a69ef88929ea370c0512bf235b0
>>>> when
>>>> running:
>>>>   while GUILE_WARN_DEPRECATED=no ./pre-inst-guile -L
>>>> ../../guile/tests/ ../../guile/tests/openpgp-auth.scm ; do : ; done
>>>> Is there anything else I should know about the build environment or
>>>> configuration options?
>>> It may be the compiler (either compilation of guile or gnutls'
>>> bindings)... That system uses gcc 6.1.1. Not sure if you'd like to
>>> debug it further, but if you do and you make a clone of the gnutls
>>> repository in gitlab I could give you access to that CI system.
>> I?ve rebuilt GnuTLS master (but not Guile) with GCC 6.1.0 and can?t seem
>> to reproduce this segfault.
>> Could you post a backtrace of the core dump?  It might give clues.
>
> I couldn't reproduce it in my last attempts but accessing that system
> isn't easy. Would it work if we run the guile tests under valgrind
> similarly to how we do at tests, or could there be a problem with
> guile?

Valgrind misinterprets the tricks that libgc (the Boehm-Demers-Weiser
garbage collector) plays.  There are libgc suppression files floating
around, but I?m not sure if there?s anything reliable.  :-/

Ludo?.


From n.mavrogiannopoulos at gmail.com  Sat Jul 30 20:28:01 2016
From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos)
Date: Sat, 30 Jul 2016 20:28:01 +0200
Subject: [gnutls-devel] guile and SSL 3.0
In-Reply-To: <87fuqsxjn2.fsf@gnu.org>
References: <CAJU7zaLaS8aTABTnnj4BZ1mt6x27pVU-Zh0i1rWTZvT1o+q6XA@mail.gmail.com>
 <871t2eyfg6.fsf@gnu.org> <1469655973.4298.12.camel@gmail.com>
 <87h9b8bix7.fsf@gnu.org>
 <CAJU7zaJAMjn0JomD4fYK0Rxvqn+24950SCJ9mC6fU=oGmdg78w@mail.gmail.com>
 <87fuqsxjn2.fsf@gnu.org>
Message-ID: <CAJU7zaK1r9VYt1SWhtfAsDMOo35KHt1PCAvmEyMCvQ-3Wr-+Tw@mail.gmail.com>

On Fri, Jul 29, 2016 at 10:40 PM, Ludovic Court?s <ludo at gnu.org> wrote:
>> On Fri, Jul 29, 2016 at 4:47 PM, Ludovic Court?s <ludo at gnu.org> wrote:
>>>>> I cannot reproduce it with 8098024c35f48a69ef88929ea370c0512bf235b0
>>>>> when
>>>>> running:
>>>>>   while GUILE_WARN_DEPRECATED=no ./pre-inst-guile -L
>>>>> ../../guile/tests/ ../../guile/tests/openpgp-auth.scm ; do : ; done
>>>>> Is there anything else I should know about the build environment or
>>>>> configuration options?
>>>> It may be the compiler (either compilation of guile or gnutls'
>>>> bindings)... That system uses gcc 6.1.1. Not sure if you'd like to
>>>> debug it further, but if you do and you make a clone of the gnutls
>>>> repository in gitlab I could give you access to that CI system.
>>> I?ve rebuilt GnuTLS master (but not Guile) with GCC 6.1.0 and can?t seem
>>> to reproduce this segfault.
>>> Could you post a backtrace of the core dump?  It might give clues.
>>
>> I couldn't reproduce it in my last attempts but accessing that system
>> isn't easy. Would it work if we run the guile tests under valgrind
>> similarly to how we do at tests, or could there be a problem with
>> guile?
> Valgrind misinterprets the tricks that libgc (the Boehm-Demers-Weiser
> garbage collector) plays.  There are libgc suppression files floating
> around, but I?m not sure if there?s anything reliable.  :-/

Let's ignore it for the moment then. If the crash happens again I'll
try to reproduce on the CI system and catch it if possible with gdb.

regards,
Nikos