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 .??A list of GnuTLS mirrors can be found at . 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 gnutls.org> uid??????????????????Nikos Mavrogiannopoulos 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 .??A list of GnuTLS mirrors can be found at . 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 gnutls.org> uid??????????????????Nikos Mavrogiannopoulos 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 .??A list of GnuTLS mirrors can be found at . 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 gnutls.org> uid??????????????????Nikos Mavrogiannopoulos 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: 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: 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: -------------- 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: -------------- 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: -------------- 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: 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: Hi Nikos, Am 09.07.2016 um 00:44 schrieb Nikos Mavrogiannopoulos : > 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: 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: References: <839E1FEC-D76A-4BDD-B7D4-E70D66984826@opencsw.org> <1468017876.9752.2.camel@gmail.com> 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: 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: On Tue, Jul 12, 2016 at 5:33 PM, Tim Ruehsen 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: References: <2702347.Ez2esJkPZ0@blitz-lx> 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 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: 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: References: <2702347.Ez2esJkPZ0@blitz-lx> 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: 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> <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> <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: 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: -------------- 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: 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: On Thu, Jul 14, 2016 at 12:45 PM, Tim Ruehsen 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: On Thu, Jul 14, 2016 at 5:28 PM, Jan V?el?k 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: References: <26a75640-4d30-6a41-f47f-ee514a690926@nic.cz> 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: References: <2702347.Ez2esJkPZ0@blitz-lx> <5455741.liSV5HiIE3@blitz-lx> 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 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: -------------- 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: 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> <33393672.O1orn0MIiH@blitz-lx> Message-ID: On Fri, Jul 15, 2016 at 12:35 PM, Tim Ruehsen 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 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: References: <2702347.Ez2esJkPZ0@blitz-lx> <33393672.O1orn0MIiH@blitz-lx> 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 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 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: 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> <1969796.83Ks0MSh9s@blitz-lx> Message-ID: On Fri, Jul 15, 2016 at 4:52 PM, Tim Ruehsen 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: References: <2702347.Ez2esJkPZ0@blitz-lx> <1969796.83Ks0MSh9s@blitz-lx> 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 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: 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> <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: 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: -------------- 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: 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: -------------- 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: 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: Both applied, thank you. On Tue, Jul 19, 2016 at 12:11 PM, Tim Ruehsen 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: 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: References: <2702347.Ez2esJkPZ0@blitz-lx> 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 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: 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: On Wed, Jul 20, 2016 at 12:30 PM, Tim Ruehsen 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: References: <2247751.yNvhTzIyrN@blitz-lx> 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 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: 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> <1805247.TXJImJsc64@blitz-lx> Message-ID: On Wed, Jul 20, 2016 at 1:06 PM, Tim Ruehsen 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: References: <2702347.Ez2esJkPZ0@blitz-lx> <1805247.TXJImJsc64@blitz-lx> 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 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: 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> <2071245.slB29yWU2K@blitz-lx> Message-ID: On Thu, Jul 21, 2016 at 4:06 PM, Tim Ruehsen 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: References: <2702347.Ez2esJkPZ0@blitz-lx> <2071245.slB29yWU2K@blitz-lx> 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 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: 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> <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 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: 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 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: 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: On Thu, Jul 21, 2016 at 5:06 PM, Tim Ruehsen 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: References: <2702347.Ez2esJkPZ0@blitz-lx> <1862270.gEf2Ds9VPM@blitz-lx> <13735011.V4oaDUmzaU@blitz-lx> <3065640.HWVo3kc5Oo@blitz-lx> Message-ID: <87vazxmoov.fsf@alice.fifthhorseman.net> On Thu 2016-07-21 18:14:57 +0200, Nikos Mavrogiannopoulos 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> <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> <1805247.TXJImJsc64@blitz-lx> Message-ID: On Wed, Jul 20, 2016 at 1:06 PM, Tim Ruehsen 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 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: References: <2702347.Ez2esJkPZ0@blitz-lx> <1805247.TXJImJsc64@blitz-lx> 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 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 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: 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> <21940443.xaOkMomvc4@blitz-lx> Message-ID: On Mon, Jul 25, 2016 at 4:38 PM, Tim Ruehsen 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: 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=) 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: (Nikos Mavrogiannopoulos's message of "Wed, 27 Jul 2016 17:04:18 +0200") References: Message-ID: <871t2eyfg6.fsf@gnu.org> Hi, Nikos Mavrogiannopoulos 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: <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: References: 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 > 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: On Thu, Jul 28, 2016 at 2:22 AM, Tristan Matthews 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: <74dbe304-974d-e7bb-3105-7bf9a27a91e3@filezilla-project.org> Message-ID: On Wed, Jul 27, 2016 at 11:56 PM, Tim Kosse 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 > > 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: -------------- 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: 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: References: <1469665341-14857-1-git-send-email-tmatth@videolan.org> 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 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: 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: <74dbe304-974d-e7bb-3105-7bf9a27a91e3@filezilla-project.org> Message-ID: On Wed, Jul 27, 2016 at 11:56 PM, Tim Kosse 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: On Thu, Jul 28, 2016 at 10:06 AM, Tim Ruehsen 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 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> <6625832.M1M7d57f5N@blitz-lx> Message-ID: On Thu, Jul 28, 2016 at 10:12 AM, Tim Ruehsen 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: References: <1469665341-14857-1-git-send-email-tmatth@videolan.org> <6625832.M1M7d57f5N@blitz-lx> 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 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: 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: References: <74dbe304-974d-e7bb-3105-7bf9a27a91e3@filezilla-project.org> Message-ID: 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: On Thu, Jul 28, 2016 at 11:25 AM, Ludovic Court?s 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: References: <74dbe304-974d-e7bb-3105-7bf9a27a91e3@filezilla-project.org> Message-ID: On Thu, Jul 28, 2016 at 1:32 PM, Tim Kosse 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> <1907453.tgheKrBh0y@blitz-lx> Message-ID: On Thu, Jul 28, 2016 at 6:31 AM, Tim Ruehsen 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 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: (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> Message-ID: <83vazprf2t.fsf@gnu.org> > From: Nikos Mavrogiannopoulos > Date: Thu, 28 Jul 2016 11:21:08 +0200 > Cc: GnuTLS development list , Eli Zaretskii , > Ludovic Court?s > > 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> <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 > > Date: Thu, 28 Jul 2016 11:21:08 +0200 > > Cc: GnuTLS development list , Eli Zaretskii > > ,> > > Ludovic Court?s > > > > 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: 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: <871t2eyfg6.fsf@gnu.org> <1469655973.4298.12.camel@gmail.com> Message-ID: <87h9b8bix7.fsf@gnu.org> Nikos Mavrogiannopoulos 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: <871t2eyfg6.fsf@gnu.org> <1469655973.4298.12.camel@gmail.com> <87h9b8bix7.fsf@gnu.org> Message-ID: On Fri, Jul 29, 2016 at 4:47 PM, Ludovic Court?s 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: (Nikos Mavrogiannopoulos's message of "Fri, 29 Jul 2016 18:15:43 +0200") References: <871t2eyfg6.fsf@gnu.org> <1469655973.4298.12.camel@gmail.com> <87h9b8bix7.fsf@gnu.org> Message-ID: <87fuqsxjn2.fsf@gnu.org> Nikos Mavrogiannopoulos skribis: > On Fri, Jul 29, 2016 at 4:47 PM, Ludovic Court?s 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: <871t2eyfg6.fsf@gnu.org> <1469655973.4298.12.camel@gmail.com> <87h9b8bix7.fsf@gnu.org> <87fuqsxjn2.fsf@gnu.org> Message-ID: On Fri, Jul 29, 2016 at 10:40 PM, Ludovic Court?s wrote: >> On Fri, Jul 29, 2016 at 4:47 PM, Ludovic Court?s 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