From INVALID.NOREPLY at gnu.org Sun Nov 2 21:02:33 2014 From: INVALID.NOREPLY at gnu.org (Chris) Date: Sun, 02 Nov 2014 20:02:33 +0000 Subject: [gnutls-devel] [sr #108679] Updated Documentation Message-ID: <20141102-200231.sv97267.13663@savannah.gnu.org> URL: Summary: Updated Documentation Project: GnuTLS Submitted by: chrisbarry Submitted on: Sun 02 Nov 2014 08:02:31 PM GMT Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: Hi, I have cleaned up some documentation. Mainly, I have made the English flow better, and made sure that spacing around sentences was consistent. _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Sun 02 Nov 2014 08:02:31 PM GMT Name: gnutls-documenataion.patch Size: 65kB By: chrisbarry _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Nov 3 18:35:28 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 03 Nov 2014 17:35:28 +0000 Subject: [gnutls-devel] [sr #108679] Updated Documentation In-Reply-To: <20141102-200231.sv97267.13663@savannah.gnu.org> References: <20141102-200231.sv97267.13663@savannah.gnu.org> Message-ID: <20141103-193528.sv707.25743@savannah.gnu.org> Follow-up Comment #1, sr #108679 (project gnutls): Thank you. Could you separate however, the space insertions before the dots, and the rest of the changes? The patch is quite long and not easy to review. I notice there is an unterminated "@acronym{TLS session". btw. why did you add the spaces before the dots? As far as I understand latex would ignore double spaces anyway. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Nov 3 18:37:10 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 03 Nov 2014 17:37:10 +0000 Subject: [gnutls-devel] [sr #108665] secp256k1 support wish In-Reply-To: <20141013-075642.sv0.22056@savannah.gnu.org> References: <20141013-075642.sv0.22056@savannah.gnu.org> Message-ID: <20141103-193709.sv707.47242@savannah.gnu.org> Follow-up Comment #1, sr #108665 (project gnutls): Hello, Is there a reason (e.g. performance or otherwise) for this request? That would be best wished in the nettle crypto library though. Once it is supported there it would be trivial to add in gnutls. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Nov 3 18:37:36 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Mon, 03 Nov 2014 17:37:36 +0000 Subject: [gnutls-devel] [sr #108655] Issue tracker's git link outdated In-Reply-To: <20140921-022127.sv707.66691@savannah.gnu.org> References: <20140919-012454.sv64386.58648@savannah.gnu.org> <20140921-022127.sv707.66691@savannah.gnu.org> Message-ID: <20141103-193736.sv707.58293@savannah.gnu.org> Update of sr #108655 (project gnutls): Status: None => Invalid Open/Closed: Open => Closed _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From jaak.ristioja at cyber.ee Mon Nov 3 20:28:27 2014 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Mon, 3 Nov 2014 21:28:27 +0200 Subject: [gnutls-devel] [PATCH 1/2] doc: Fixed typo in inline comment of gnutls_transport_set_errno(). Message-ID: <1415042908-15896-1-git-send-email-jaak.ristioja@cyber.ee> --- lib/system_override.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/system_override.c b/lib/system_override.c index d673f2d..0e0f32e 100644 --- a/lib/system_override.c +++ b/lib/system_override.c @@ -45,7 +45,7 @@ * @err: error value to store in session-specific errno variable. * * Store @err in the session-specific errno variable. Useful values - * for @err is EAGAIN and EINTR, other values are treated will be + * for @err are EAGAIN and EINTR, other values are treated will be * treated as real errors in the push/pull function. * * This function is useful in replacement push and pull functions set by -- 2.1.3 From jaak.ristioja at cyber.ee Mon Nov 3 20:28:28 2014 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Mon, 3 Nov 2014 21:28:28 +0200 Subject: [gnutls-devel] [PATCH 2/2] doc: Added missing reference for EMSGSIZE to inline documentation of gnutls_transport_set_errno(). In-Reply-To: <1415042908-15896-1-git-send-email-jaak.ristioja@cyber.ee> References: <1415042908-15896-1-git-send-email-jaak.ristioja@cyber.ee> Message-ID: <1415042908-15896-2-git-send-email-jaak.ristioja@cyber.ee> --- lib/system_override.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/system_override.c b/lib/system_override.c index 0e0f32e..f8250ba 100644 --- a/lib/system_override.c +++ b/lib/system_override.c @@ -45,7 +45,7 @@ * @err: error value to store in session-specific errno variable. * * Store @err in the session-specific errno variable. Useful values - * for @err are EAGAIN and EINTR, other values are treated will be + * for @err are EINTR, EAGAIN and EMSGSIZE, other values are treated will be * treated as real errors in the push/pull function. * * This function is useful in replacement push and pull functions set by -- 2.1.3 From nmav at gnutls.org Mon Nov 3 21:37:50 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 03 Nov 2014 21:37:50 +0100 Subject: [gnutls-devel] [PATCH 2/2] doc: Added missing reference for EMSGSIZE to inline documentation of gnutls_transport_set_errno(). In-Reply-To: <1415042908-15896-2-git-send-email-jaak.ristioja@cyber.ee> References: <1415042908-15896-1-git-send-email-jaak.ristioja@cyber.ee> <1415042908-15896-2-git-send-email-jaak.ristioja@cyber.ee> Message-ID: <1415047070.4935.0.camel@nomad.lan> On Mon, 2014-11-03 at 21:28 +0200, Jaak Ristioja wrote: > --- > lib/system_override.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Both applied; thank you. From INVALID.NOREPLY at gnu.org Mon Nov 3 22:54:50 2014 From: INVALID.NOREPLY at gnu.org (Chris) Date: Mon, 03 Nov 2014 21:54:50 +0000 Subject: [gnutls-devel] [sr #108679] Updated Documentation In-Reply-To: <20141103-193528.sv707.25743@savannah.gnu.org> References: <20141102-200231.sv97267.13663@savannah.gnu.org> <20141103-193528.sv707.25743@savannah.gnu.org> Message-ID: <20141103-215450.sv97267.23785@savannah.gnu.org> Follow-up Comment #2, sr #108679 (project gnutls): > Thank you. Could you separate however, the space insertions before the dots, and the rest of the changes? Will do. > why did you add the spaces before the dots? Latex will ignore them, but emacs uses it as a sentence seperator, so some people will enjoy it more. And I feel it looks more consistent. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Nov 4 20:41:24 2014 From: INVALID.NOREPLY at gnu.org (Chris) Date: Tue, 04 Nov 2014 19:41:24 +0000 Subject: [gnutls-devel] [sr #108679] Updated Documentation In-Reply-To: <20141103-215450.sv97267.23785@savannah.gnu.org> References: <20141102-200231.sv97267.13663@savannah.gnu.org> <20141103-193528.sv707.25743@savannah.gnu.org> <20141103-215450.sv97267.23785@savannah.gnu.org> Message-ID: <20141104-194124.sv97267.94194@savannah.gnu.org> Additional Item Attachment, sr #108679 (project gnutls): File name: 0001-Cleaning-up-some-awkward-phrasings.patch Size:8 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Nov 4 21:55:54 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Tue, 04 Nov 2014 20:55:54 +0000 Subject: [gnutls-devel] [sr #108679] Updated Documentation In-Reply-To: <20141104-194124.sv97267.94194@savannah.gnu.org> References: <20141102-200231.sv97267.13663@savannah.gnu.org> <20141103-193528.sv707.25743@savannah.gnu.org> <20141103-215450.sv97267.23785@savannah.gnu.org> <20141104-194124.sv97267.94194@savannah.gnu.org> Message-ID: <20141104-225554.sv707.15671@savannah.gnu.org> Follow-up Comment #3, sr #108679 (project gnutls): Thank you, applied. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From aklitzing at gmail.com Wed Nov 5 11:04:13 2014 From: aklitzing at gmail.com (A. Klitzing) Date: Wed, 5 Nov 2014 11:04:13 +0100 Subject: [gnutls-devel] Patch for iOS (crt_externs.h) Message-ID: Hi there, we tried to build newest gnutls for iOS and run into a compiler error. It cannot find the file crt_externs.h which does not exist for iOS. We successfully modified gnutls with the attached patch. Maybe you can add it.... Best regards, Andr? Klitzing -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls_iOS.patch Type: text/x-diff Size: 1384 bytes Desc: not available URL: From nmav at gnutls.org Wed Nov 5 13:39:21 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 5 Nov 2014 13:39:21 +0100 Subject: [gnutls-devel] Patch for iOS (crt_externs.h) In-Reply-To: References: Message-ID: On Wed, Nov 5, 2014 at 11:04 AM, A. Klitzing wrote: > Hi there, > we tried to build newest gnutls for iOS and run into a compiler error. It > cannot find the file crt_externs.h which does not exist for iOS. > We successfully modified gnutls with the attached patch. Maybe you can add > it.... Thank you. I can apply it for now, but it will be undone the next time I update gnulib (this is gnulib source). Could you send that patch to gnulib as well? regards, Nikos From albert.choy at tridsys.com Wed Nov 5 19:07:16 2014 From: albert.choy at tridsys.com (Albert Choy) Date: Wed, 5 Nov 2014 13:07:16 -0500 Subject: [gnutls-devel] I found a small problem with your sample programs Message-ID: Here is the UDP echo server with DTLS http://www.gnutls.org/manual/gnutls.html#DTLS-echo-server-with-X_002e509-authentication The sample has the server listening on port 5556 This is the client helper function http://www.gnutls.org/manual/gnutls.html#Helper-functions-for-UDP-connections The source has the client connecting to port 5557! I assume you meant 5556. Best regards, -- Albert Choy | *Trident Systems Incorporated* Sr. Software Engineer, Software Systems Engineering Group One Copley Parkway | Suite 420 | Morrisville, NC 27560 d: 919.439.0467 | f: 919.388.1267 e: albert.choy at tridsys.com | www.tridsys.com *Notice: The information contained in this email message is considered confidential and proprietary to the sender and is intended solely for review and use by the named recipient. Any unauthorized review, use or distribution is strictly prohibited. If you have received this message in error, please advise the sender by reply email and delete the message. * -------------- next part -------------- An HTML attachment was scrubbed... URL: From nille0386 at googlemail.com Thu Nov 6 16:37:51 2014 From: nille0386 at googlemail.com (Nille) Date: Thu, 06 Nov 2014 16:37:51 +0100 Subject: [gnutls-devel] Msys mingw Message-ID: <545B95CF.2060001@googlemail.com> Since one of the last mingw Updates, gnutls can't be compiled. http://sourceforge.net/p/msys2/mailman/message/32957469/ make[3]: Entering directory '/build64/gnutls/lib/x509' CC common.lo In file included from ./../../gl/time.h:39:0, from ./../../gl/sys/stat.h:44, from ./../gnutls_int.h:52, from common.c:23: ./../../gl/time.h:461:1: error: expected identifier or '(' before '{' token _GL_FUNCDECL_SYS (localtime_r, struct tm *, (time_t const *restrict __timer, ^ ./../../gl/time.h:483:1: error: expected identifier or '(' before '{' token _GL_FUNCDECL_SYS (gmtime_r, struct tm *, (time_t const *restrict __timer, ^ Makefile:1384: recipe for target 'common.lo' failed make[3]: *** [common.lo] Error 1 make[3]: Leaving directory '/build64/gnutls/lib/x509' Makefile:1819: recipe for target 'install-recursive' failed make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory '/build64/gnutls/lib' Makefile:1976: recipe for target 'install' failed make[1]: *** [install] Error 2 make[1]: Leaving directory '/build64/gnutls/lib' Makefile:1384: die Regel f?r Ziel ?install-recursive? scheiterte make: *** [install-recursive] Fehler 1 From aklitzing at gmail.com Fri Nov 7 10:18:11 2014 From: aklitzing at gmail.com (A. Klitzing) Date: Fri, 7 Nov 2014 10:18:11 +0100 Subject: [gnutls-devel] Patch for iOS (crt_externs.h) In-Reply-To: References: Message-ID: Thanks for the hint! I sent the patch to gnulib and they added it now. :-) http://lists.gnu.org/archive/html/bug-gnulib/2014-11/msg00013.html http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=08c22d94af9eaac33f7eaa48fdfcffcf2831ec1a Best regards Andr? -------------- next part -------------- An HTML attachment was scrubbed... URL: From aklitzing at gmail.com Fri Nov 7 13:50:15 2014 From: aklitzing at gmail.com (A. Klitzing) Date: Fri, 7 Nov 2014 13:50:15 +0100 Subject: [gnutls-devel] undefined reference to htons and ntohs (Android) Message-ID: Hi, I compiled gnutls 3.3.9 for Android with Googles NDK (standalone toolchain) and get some linker errors. The library will be built but some cmdline tools don't.... I can successfully build gnutls 3.3.6. Any hints for me? It would be enough if I can disable the build of any cmdline tool. [...] Making all in src Making all in gl Making all in libopts CCLD gnutls-cli-debug CCLD certtool CCLD ocsptool CCLD danetool CCLD gnutls-serv socket.o:socket.c:function port_to_service: error: undefined reference to 'htons' socket.o:socket.c:function service_to_port: error: undefined reference to 'ntohs' collect2: error: ld returned 1 exit status Makefile:1754: recipe for target 'gnutls-serv' failed make[8]: *** [gnutls-serv] Error 1 make[8]: *** Waiting for unfinished jobs.... socket.o:socket.c:function port_to_service: error: undefined reference to 'htons' socket.o:socket.c:function service_to_port: error: undefined reference to 'ntohs' collect2: error: ld returned 1 exit status Makefile:1742: recipe for target 'danetool' failed make[8]: *** [danetool] Error 1 socket.o:socket.c:function port_to_service: error: undefined reference to 'htons' socket.o:socket.c:function service_to_port: error: undefined reference to 'ntohs' collect2: error: ld returned 1 exit status socket.o:socket.c:function port_to_service: error: undefined reference to 'htons' socket.o:socket.c:function service_to_port: error: undefined reference to 'ntohs' collect2: error: ld returned 1 exit status [...] Best regards Andr? Klitzing -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.ruehsen at gmx.de Fri Nov 7 14:15:40 2014 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Fri, 07 Nov 2014 14:15:40 +0100 Subject: [gnutls-devel] Looking for OCSP Stapling client example Message-ID: <3213306.Wb2fQ2uKpo@blitz-lx> Hi, could you point to GnuTLS client code that uses OCSP Stapling and/or some docs that explains how to implement this for a client ? I would like to put this feature into Wget. Best 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 Fri Nov 7 19:05:45 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 07 Nov 2014 19:05:45 +0100 Subject: [gnutls-devel] undefined reference to htons and ntohs (Android) In-Reply-To: References: Message-ID: <1415383545.2033.2.camel@gnutls.org> On Fri, 2014-11-07 at 13:50 +0100, A. Klitzing wrote: > Hi, > I compiled gnutls 3.3.9 for Android with Googles NDK (standalone > toolchain) and get some linker errors. The library will be built but > some cmdline tools don't.... > I can successfully build gnutls 3.3.6. > Any hints for me? It would be enough if I can disable the build of any > cmdline tool. > > > [...] > Making all in src > Making all in gl > Making all in libopts > CCLD gnutls-cli-debug > CCLD certtool > CCLD ocsptool > CCLD danetool > CCLD gnutls-serv > socket.o:socket.c:function port_to_service: error: undefined reference > to 'htons' > socket.o:socket.c:function service_to_port: error: undefined reference > to 'ntohs' Maybe these are macros. Would the issue go away if you add #include in socket.c? regards, Nikos From nmav at gnutls.org Fri Nov 7 19:17:16 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 07 Nov 2014 19:17:16 +0100 Subject: [gnutls-devel] Looking for OCSP Stapling client example In-Reply-To: <3213306.Wb2fQ2uKpo@blitz-lx> References: <3213306.Wb2fQ2uKpo@blitz-lx> Message-ID: <1415384236.2033.4.camel@gnutls.org> On Fri, 2014-11-07 at 14:15 +0100, Tim Ruehsen wrote: > Hi, > > could you point to GnuTLS client code that uses OCSP Stapling and/or some docs > that explains how to implement this for a client ? You mean verification of the servers certificate using OCSP? That is already discussed in the manual, maybe not in a clear way. There are two options for a client (and you can combined them): 1. Rely on the server's status request which attaches an OCSP response during handshake. This is check automatically by gnutls if available and you can query whether it was checked using gnutls_ocsp_status_request_is_checked(). Limitation: it only checks the server's end certificate (so if there are intermediate CAs which are revoked you may never know). http://www.gnutls.org/manual/html_node/OCSP-status-request.html#OCSP-status-request 2. Query the OCSP servers of the certificates that you received manually. This pretty much involves making HTTP queries, and is discussed at: http://www.gnutls.org/manual/html_node/OCSP-certificate-status-checking.html#OCSP-certificate-status-checking and an example using libcurl is at: http://www.gnutls.org/manual/html_node/OCSP-example.html#OCSP-example The above example sets a nonce in the message to ensure that the reply received from the OCSP server is fresh. That unfortunately as far as I remember is supported by almost no servers, so you may want to skip it (or test it and see how it is now). You can also check gnutls-cli how it checks against the ocsp servers. Suggestions or patches to improve the documentation are welcome. regards, Nikos From nmav at gnutls.org Fri Nov 7 19:18:56 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 07 Nov 2014 19:18:56 +0100 Subject: [gnutls-devel] I found a small problem with your sample programs In-Reply-To: References: Message-ID: <1415384336.2033.5.camel@gnutls.org> On Wed, 2014-11-05 at 13:07 -0500, Albert Choy wrote: > > > Here is the UDP echo server with DTLS > > > http://www.gnutls.org/manual/gnutls.html#DTLS-echo-server-with-X_002e509-authentication > The sample has the server listening on port 5556 > This is the client helper function > http://www.gnutls.org/manual/gnutls.html#Helper-functions-for-UDP-connections > The source has the client connecting to port 5557! I assume you meant > 5556. Thanks. A patch to address that was applied. regards, Nikos From nmav at gnutls.org Fri Nov 7 19:19:40 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 07 Nov 2014 19:19:40 +0100 Subject: [gnutls-devel] Msys mingw In-Reply-To: <545B95CF.2060001@googlemail.com> References: <545B95CF.2060001@googlemail.com> Message-ID: <1415384380.2033.6.camel@gnutls.org> On Thu, 2014-11-06 at 16:37 +0100, Nille wrote: > Since one of the last mingw Updates, gnutls can't be compiled. > > http://sourceforge.net/p/msys2/mailman/message/32957469/ > > make[3]: Entering directory '/build64/gnutls/lib/x509' > CC common.lo > In file included from ./../../gl/time.h:39:0, > from ./../../gl/sys/stat.h:44, > from ./../gnutls_int.h:52, > from common.c:23: > ./../../gl/time.h:461:1: error: expected identifier or '(' before '{' token > _GL_FUNCDECL_SYS (localtime_r, struct tm *, (time_t const *restrict > __timer, > ^ Hi, That's a gnulib issue. Would updating gnulib address that? regards, Nikos From aklitzing at gmail.com Fri Nov 7 21:27:38 2014 From: aklitzing at gmail.com (A. Klitzing) Date: Fri, 7 Nov 2014 21:27:38 +0100 Subject: [gnutls-devel] undefined reference to htons and ntohs (Android) In-Reply-To: <1415383545.2033.2.camel@gnutls.org> References: <1415383545.2033.2.camel@gnutls.org> Message-ID: > > Maybe these are macros. Would the issue go away if you add #include > in socket.c? > > regards, > Nikos > Yes, thank you! It compiles and links again now. regards Andr? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Nov 10 08:47:41 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 10 Nov 2014 08:47:41 +0100 Subject: [gnutls-devel] gnutls 3.1.28 Message-ID: <1415605661.2918.1.camel@gnutls.org> Hello, I've just released gnutls 3.1.28. This is a bug-fix release on the previous stable branch. * Version 3.1.28 (released 2014-11-10) ** libgnutls: Corrected issue in export of ECC parameters to X9.63 format. Reported by Sean Burford [GNUTLS-SA-2014-5]. ** 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 and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.28.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.28.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.28.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.28.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos 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 Mon Nov 10 08:49:56 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 10 Nov 2014 08:49:56 +0100 Subject: [gnutls-devel] gnutls 3.2.20 / GNUTLS-SA-2014-5 Message-ID: <1415605796.2918.3.camel@gnutls.org> Hello, I've just released gnutls 3.2.20 and posted the security advisory http://www.gnutls.org/security.html#GNUTLS-SA-2014-5 This release includes bug fixes for the previous stable branch. * Version 3.2.20 (released 2014-11-10) ** libgnutls: Removed superfluous random generator refresh on every call of gnutls_deinit(). That reduces load and usage of /dev/urandom. ** libgnutls: Corrected issue in export of ECC parameters to X9.63 format. Reported by Sean Burford [GNUTLS-SA-2014-5]. ** 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 and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.20.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.20.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.20.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.20.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos 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 Mon Nov 10 08:51:40 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 10 Nov 2014 08:51:40 +0100 Subject: [gnutls-devel] gnutls 3.3.10 / GNUTLS-SA-2014-5 Message-ID: <1415605900.2918.5.camel@gnutls.org> Hello, I've just released gnutls 3.3.10 and the security advisory http://www.gnutls.org/security.html#GNUTLS-SA-2014-5 This release contains bug-fixes release for the stable branch. * Version 3.3.10 (released 2014-11-10) ** libgnutls: Refuse to import v1 or v2 certificates that contain extensions. ** libgnutls: Fixes in usage of PKCS #11 token callback ** libgnutls: Fixed bug in gnutls_x509_trust_list_get_issuer() when used with a PKCS #11 trust module and without the GNUTLS_TL_GET_COPY flag. Reported by David Woodhouse. ** libgnutls: Removed superfluous random generator refresh on every call of gnutls_deinit(). That reduces load and usage of /dev/urandom. ** libgnutls: Corrected issue in export of ECC parameters to X9.63 format. Reported by Sean Burford [GNUTLS-SA-2014-5]. ** libgnutls: When gnutls_global_init() is called for a second time, it will check whether the /dev/urandom fd kept is still open and matches the original one. That behavior works around issues with servers that close all file descriptors. ** libgnutls: Corrected behavior with PKCS #11 objects that are marked as CKA_ALWAYS_AUTHENTICATE. ** certtool: The default cipher for PKCS #12 structures is 3des-pkcs12. That option is more compatible than AES or RC4. ** 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 and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.10.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.10.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.10.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.10.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos 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 tim.ruehsen at gmx.de Wed Nov 12 12:38:25 2014 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Wed, 12 Nov 2014 12:38:25 +0100 Subject: [gnutls-devel] Looking for OCSP Stapling client example In-Reply-To: <1415384236.2033.4.camel@gnutls.org> References: <3213306.Wb2fQ2uKpo@blitz-lx> <1415384236.2033.4.camel@gnutls.org> Message-ID: <3106022.PEbZ7CmWM5@blitz-lx> Hi Nikos, thanks for your answer. On Friday 07 November 2014 19:17:16 Nikos Mavrogiannopoulos wrote: > On Fri, 2014-11-07 at 14:15 +0100, Tim Ruehsen wrote: > > Hi, > > > > could you point to GnuTLS client code that uses OCSP Stapling and/or some > > docs that explains how to implement this for a client ? > > You mean verification of the servers certificate using OCSP? That is > already discussed in the manual, maybe not in a clear way. > > There are two options for a client (and you can combined them): > 1. Rely on the server's status request which attaches an OCSP response > during handshake. This is check automatically by gnutls if available > and you can query whether it was checked using > gnutls_ocsp_status_request_is_checked(). Limitation: it only checks the > server's end certificate (so if there are intermediate CAs which are > revoked you may never know). > http://www.gnutls.org/manual/html_node/OCSP-status-request.html#OCSP-status-> request > > 2. Query the OCSP servers of the certificates that you received > manually. This pretty much involves making HTTP queries, and is > discussed at: > http://www.gnutls.org/manual/html_node/OCSP-certificate-status-checking.html > #OCSP-certificate-status-checking and an example using libcurl is at: > http://www.gnutls.org/manual/html_node/OCSP-example.html#OCSP-example Right now I am interested in 1. (OCSP Stapling). It took a while for me to find a server that is appropriately configured. Testing with OpenSSL $ openssl s_client -connect movlib.org:443 -tls1 -tlsextdebug -status ... OCSP response: ====================================== OCSP Response Data: OCSP Response Status: successful (0x0) Response Type: Basic OCSP Response Version: 1 (0x0) Responder Id: C = IL, O = StartCom Ltd. (Start Commercial Limited), CN = StartCom Class 1 Server OCSP Signer Produced At: Nov 11 19:31:12 2014 GMT ... In my verify callback routine (after gnutls_certificate_verify_peers3()), gnutls_ocsp_status_request_is_checked() always returns 0. Even when explicitly calling gnutls_ocsp_status_request_enable_client() before handshake. Do you have any idea, what is going wrong or how to find out ? gnutls-cli --ocsp seems only to work 2. (Querying OCSP Server) !? $ gnutls-cli --version gnutls-cli 3.3.8 > The above example sets a nonce in the message to ensure that the reply > received from the OCSP server is fresh. That unfortunately as far as I > remember is supported by almost no servers, so you may want to skip it > (or test it and see how it is now). You can also check gnutls-cli how it > checks against the ocsp servers. Suggestions or patches to improve the > documentation are welcome. The docs of gnutls_ocsp_status_request_is_checked() say that this function only works after gnutls_certificate_verify_peers3(). What about gnutls_certificate_verify_peers2() ? What you wrote above (1. and 2.) should go (a bit polished) in here: > http://www.gnutls.org/manual/html_node/OCSP-status-request.html#OCSP-status-> request 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 thor at dbteam.de Wed Nov 12 16:06:44 2014 From: thor at dbteam.de (Thomas Thorberger) Date: Wed, 12 Nov 2014 16:06:44 +0100 Subject: [gnutls-devel] gnutls-3.3.10 SIGBUS on Solaris 10 in gettime() Message-ID: <7e4d588c6b727443d39e84adab04f542@admin.dbteam.de> Hello! I found a bug on Solaris which crashes all applications using libgnutls with a SIGBUS in the function gettime() called by _rnd_get_event() [lib/nettle/rnd-common.c]. Environment: Solaris 10 (Oracle Solaris 10 1/13 s10s_u11wos_24a SPARC) Compiler: gcc (GCC) 4.9.2 (using Sun AS/LD) The compiler was generating code for the 64-bit environment. GDB Output: Program terminated with signal SIGBUS, Bus error. (gdb) bt #0 0xffffffff7d3dcedc in __clock_gettime () from /lib/64/libc.so.1 #1 0xffffffff7f011e34 in _rnd_get_event () from /var/local/rpm/src/BUILD/gnutls-3.3.10/lib/.libs/libgnutls.so.28 #2 0xffffffff7f0125cc in wrap_nettle_rnd_init () from /var/local/rpm/src/BUILD/gnutls-3.3.10/lib/.libs/libgnutls.so.28 #3 0xffffffff7ef6d968 in _gnutls_rnd_init () from /var/local/rpm/src/BUILD/gnutls-3.3.10/lib/.libs/libgnutls.so.28 #4 0xffffffff7ef60120 in gnutls_global_init () from /var/local/rpm/src/BUILD/gnutls-3.3.10/lib/.libs/libgnutls.so.28 #5 0xffffffff7ef60548 in lib_init () from /var/local/rpm/src/BUILD/gnutls-3.3.10/lib/.libs/libgnutls.so.28 #6 0xffffffff7f012ebc in _init () from /var/local/rpm/src/BUILD/gnutls-3.3.10/lib/.libs/libgnutls.so.28 #7 0xffffffff7f61831c in call_init () from /lib/sparcv9/ld.so.1 #8 0xffffffff7f617608 in setup () from /lib/sparcv9/ld.so.1 #9 0xffffffff7f629f04 in _setup () from /lib/sparcv9/ld.so.1 #10 0xffffffff7f60850c in _alias_start () from /lib/sparcv9/ld.so.1 The bug is triggered by the "__attribute__((packed))" in the structure definition of "struct event_st" in lib/nettle/rnd-common.h. If the "packed" attribute is active all references to the substructure "struct timespec" generate a SIGBUS. I guess that the alignment for a 64bit long falls below the minimum required alignment when using "packed" with "struct timespec". I cannot tell you if this is specific to my environment or if it affects all Solaris Systems with the recent GCC generating a 64-bit version of libgnutls. I attached the patch I used to get gnutls working again. Regards, Thomas Thorberger --- gnutls-3.3.10/lib/nettle/rnd-common.h.orig 2014-11-12 13:37:43.916658427 +0100 +++ gnutls-3.3.10/lib/nettle/rnd-common.h 2014-11-12 13:40:56.636814380 +0100 @@ -42,7 +42,7 @@ unsigned count; /* a running counter */ unsigned err; /* the last errno */ } -#ifdef __GNUC__ +#if defined(__GNUC__) && !defined(__sun) __attribute__((packed)) #endif ; From ametzler at bebt.de Wed Nov 12 20:22:47 2014 From: ametzler at bebt.de (Andreas Metzler) Date: Wed, 12 Nov 2014 20:22:47 +0100 Subject: [gnutls-devel] gnutls-3.3.10 - crq test always succeeds Message-ID: <20141112192246.GA1288@downhill.g.la> Hello, tests/cert-tests/crq is broken, it tries to read crq-invalid.der while the file is named csr-invalid.der. This has the effect that the test always succeeds, because certtools exits with 1 on unreadable input. Renaming the file (or fixing the filename in the test) makes the test fail with gnutls 3.3.8 and succeed with gnutls 3.3.10. On a sidenote I do not understand why the whole thing is written the way it is: ----------- certtool ... rc=$? # We're done. if test "$rc" != "1"; then echo "Invalid crq decoding failed" exit $rc fi exit 0 ----------- The if clause is always hit. gnutls 3.3.10 exits with 0, gnutls 3.3.8 exits with 134. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From nmav at gnutls.org Thu Nov 13 09:29:49 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 13 Nov 2014 09:29:49 +0100 Subject: [gnutls-devel] gnutls-3.3.10 SIGBUS on Solaris 10 in gettime() In-Reply-To: <7e4d588c6b727443d39e84adab04f542@admin.dbteam.de> References: <7e4d588c6b727443d39e84adab04f542@admin.dbteam.de> Message-ID: On Wed, Nov 12, 2014 at 4:06 PM, Thomas Thorberger wrote: > Hello! > > I found a bug on Solaris which crashes all applications using libgnutls with > a SIGBUS in the function gettime() called by _rnd_get_event() > [lib/nettle/rnd-common.c]. [...] > The bug is triggered by the "__attribute__((packed))" in the structure > definition of "struct event_st" in lib/nettle/rnd-common.h. If the "packed" > attribute is active all references to the substructure "struct timespec" > generate a SIGBUS. I guess that the alignment for a 64bit long falls below > the minimum required alignment when using "packed" with "struct timespec". > I cannot tell you if this is specific to my environment or if it affects all > Solaris Systems with the recent GCC generating a 64-bit version of > libgnutls. Thank you. I applied the fix. regards, Nikos From nmav at gnutls.org Thu Nov 13 10:21:07 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 13 Nov 2014 10:21:07 +0100 Subject: [gnutls-devel] Looking for OCSP Stapling client example In-Reply-To: <3106022.PEbZ7CmWM5@blitz-lx> References: <3213306.Wb2fQ2uKpo@blitz-lx> <1415384236.2033.4.camel@gnutls.org> <3106022.PEbZ7CmWM5@blitz-lx> Message-ID: On Wed, Nov 12, 2014 at 12:38 PM, Tim Ruehsen wrote: >> 2. Query the OCSP servers of the certificates that you received >> manually. This pretty much involves making HTTP queries, and is >> discussed at: >> http://www.gnutls.org/manual/html_node/OCSP-certificate-status-checking.html >> #OCSP-certificate-status-checking and an example using libcurl is at: >> http://www.gnutls.org/manual/html_node/OCSP-example.html#OCSP-example > Right now I am interested in 1. (OCSP Stapling). > It took a while for me to find a server that is appropriately configured. > Testing with OpenSSL > $ openssl s_client -connect movlib.org:443 -tls1 -tlsextdebug -status [...] > In my verify callback routine (after gnutls_certificate_verify_peers3()), > gnutls_ocsp_status_request_is_checked() always returns 0. There is something strange with that server. I check the wireshark output of a connection to that server with openssl and the one with gnutls. They are different. With gnutls client the server doesn't advertise its support for ocsp and doesn't send the ocsp response. The contents of the extension sent by the client are the same in both cases. regards, Nikos From tim.ruehsen at gmx.de Thu Nov 13 11:23:08 2014 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Thu, 13 Nov 2014 11:23:08 +0100 Subject: [gnutls-devel] Looking for OCSP Stapling client example In-Reply-To: References: <3213306.Wb2fQ2uKpo@blitz-lx> <3106022.PEbZ7CmWM5@blitz-lx> Message-ID: <4696334.Oc5E7XgZ5S@blitz-lx> On Thursday 13 November 2014 10:21:07 Nikos Mavrogiannopoulos wrote: > On Wed, Nov 12, 2014 at 12:38 PM, Tim Ruehsen wrote: > >> 2. Query the OCSP servers of the certificates that you received > >> manually. This pretty much involves making HTTP queries, and is > >> discussed at: > >> http://www.gnutls.org/manual/html_node/OCSP-certificate-status-checking.h > >> tml #OCSP-certificate-status-checking and an example using libcurl is at: > >> http://www.gnutls.org/manual/html_node/OCSP-example.html#OCSP-example> > > Right now I am interested in 1. (OCSP Stapling). > > It took a while for me to find a server that is appropriately configured. > > Testing with OpenSSL > > $ openssl s_client -connect movlib.org:443 -tls1 -tlsextdebug -status > > [...] > > > In my verify callback routine (after gnutls_certificate_verify_peers3()), > > gnutls_ocsp_status_request_is_checked() always returns 0. > > There is something strange with that server. I check the wireshark > output of a connection to that server with openssl and the one with > gnutls. They are different. With gnutls client the server doesn't > advertise its support for ocsp and doesn't send the ocsp response. The > contents of the extension sent by the client are the same in both > cases. I can't find a working web server. They seem to behave like movlib.org, e.g. take blog.cloudflare.com:443. They seemingly made lot's of tests: http://blog.cloudflare.com/ocsp-stapling-how-cloudflare-just-made-ssl-30/ 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 Nov 13 11:47:50 2014 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Thu, 13 Nov 2014 11:47:50 +0100 Subject: [gnutls-devel] Looking for OCSP Stapling client example In-Reply-To: <4696334.Oc5E7XgZ5S@blitz-lx> References: <3213306.Wb2fQ2uKpo@blitz-lx> <4696334.Oc5E7XgZ5S@blitz-lx> Message-ID: <5391566.XdQz2caatd@blitz-lx> On Thursday 13 November 2014 11:23:08 Tim Ruehsen wrote: > On Thursday 13 November 2014 10:21:07 Nikos Mavrogiannopoulos wrote: > > On Wed, Nov 12, 2014 at 12:38 PM, Tim Ruehsen wrote: > > >> 2. Query the OCSP servers of the certificates that you received > > >> manually. This pretty much involves making HTTP queries, and is > > >> discussed at: > > >> http://www.gnutls.org/manual/html_node/OCSP-certificate-status-checking > > >> .h > > >> tml #OCSP-certificate-status-checking and an example using libcurl is > > >> at: > > >> http://www.gnutls.org/manual/html_node/OCSP-example.html#OCSP-example> > > > > > > Right now I am interested in 1. (OCSP Stapling). > > > It took a while for me to find a server that is appropriately > > > configured. > > > Testing with OpenSSL > > > $ openssl s_client -connect movlib.org:443 -tls1 -tlsextdebug -status > > > > [...] > > > > > In my verify callback routine (after > > > gnutls_certificate_verify_peers3()), > > > gnutls_ocsp_status_request_is_checked() always returns 0. > > > > There is something strange with that server. I check the wireshark > > output of a connection to that server with openssl and the one with > > gnutls. They are different. With gnutls client the server doesn't > > advertise its support for ocsp and doesn't send the ocsp response. The > > contents of the extension sent by the client are the same in both > > cases. > > I can't find a working web server. They seem to behave like movlib.org, > e.g. take blog.cloudflare.com:443. > > They seemingly made lot's of tests: > http://blog.cloudflare.com/ocsp-stapling-how-cloudflare-just-made-ssl-30/ More examples: yahoo.com and yandex.ru. Tim From nmav at gnutls.org Fri Nov 14 07:47:56 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 14 Nov 2014 07:47:56 +0100 Subject: [gnutls-devel] gnutls-3.3.10 - crq test always succeeds In-Reply-To: <20141112192246.GA1288@downhill.g.la> References: <20141112192246.GA1288@downhill.g.la> Message-ID: <1415947676.2025.1.camel@gnutls.org> On Wed, 2014-11-12 at 20:22 +0100, Andreas Metzler wrote: > Hello, > > tests/cert-tests/crq is broken, it tries to read crq-invalid.der while > the file is named csr-invalid.der. > This has the effect that the test always succeeds, because certtools > exits with 1 on unreadable input. > Renaming the file (or fixing the filename in the test) makes the test > fail with gnutls 3.3.8 and succeed with gnutls 3.3.10. Thanks. It was hastily written and didn't actually verify the fix. I've now update it to use the correct file and figure the error case from the output of certtool rather than the exit code. regards, Nikos From dave at veryflatcat.com Fri Nov 14 11:01:17 2014 From: dave at veryflatcat.com (David Weber) Date: Fri, 14 Nov 2014 12:01:17 +0200 Subject: [gnutls-devel] Bug in DTLS-SRTP processing in gnutls-serv (with fix) Message-ID: Hi When setting up an echo server for SRTP, gnutls-serv fails with a "Success" message because the handling of the return codes from gnutls_srtp_set_profile_direct() is broken. Attached is the result of `diff gnutls-3.3.10/src/serv.c gnutls-3.3.10.orig/src/serv.c` which fixes the problem. -- Dave W. http://veryflatcat.com -------------- next part -------------- 391c391 < else if (ret != 0) --- > else 394,397c394 < else fprintf(stderr,"DTLS profile set to %s\n", < OPT_ARG(SRTP_PROFILES)); < < if (ret != 0) exit(1); --- > exit(1); From nmav at gnutls.org Fri Nov 14 20:57:57 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 14 Nov 2014 20:57:57 +0100 Subject: [gnutls-devel] Looking for OCSP Stapling client example In-Reply-To: <5391566.XdQz2caatd@blitz-lx> References: <3213306.Wb2fQ2uKpo@blitz-lx> <4696334.Oc5E7XgZ5S@blitz-lx> <5391566.XdQz2caatd@blitz-lx> Message-ID: <1415995077.2035.1.camel@gnutls.org> On Thu, 2014-11-13 at 11:47 +0100, Tim Ruehsen wrote: > > > > In my verify callback routine (after > > > > gnutls_certificate_verify_peers3()), > > > > gnutls_ocsp_status_request_is_checked() always returns 0. > > > There is something strange with that server. I check the wireshark > > > output of a connection to that server with openssl and the one with > > > gnutls. They are different. With gnutls client the server doesn't > > > advertise its support for ocsp and doesn't send the ocsp response. The > > > contents of the extension sent by the client are the same in both > > > cases. > > I can't find a working web server. They seem to behave like movlib.org, > > e.g. take blog.cloudflare.com:443. > > They seemingly made lot's of tests: > > http://blog.cloudflare.com/ocsp-stapling-how-cloudflare-just-made-ssl-30/ > More examples: yahoo.com and yandex.ru. Thanks for insisting. It seems that there is an issue in libtasn1 which does not properly re-encode these OCSP responses, and as far as I see this is a persistent issue. OCSP responders must have switched from setting the issuer's DN to setting the SHA1 hash of the key, and that must have uncovered the issue. I don't think if I can manage to work on libtasn1, but I've worked around the issue in gnutls 3.3 branch, so unfortunately you cannot rely on the verification of OCSP stapled responses with the released versions of gnutls. regards, Nikos From nmav at gnutls.org Fri Nov 14 21:11:17 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 14 Nov 2014 21:11:17 +0100 Subject: [gnutls-devel] Bug in DTLS-SRTP processing in gnutls-serv (with fix) In-Reply-To: References: Message-ID: <1415995877.2035.3.camel@gnutls.org> On Fri, 2014-11-14 at 12:01 +0200, David Weber wrote: > Hi > When setting up an echo server for SRTP, gnutls-serv fails with a > "Success" message because the handling of the return codes from > gnutls_srtp_set_profile_direct() is broken. Attached is the result of > `diff gnutls-3.3.10/src/serv.c gnutls-3.3.10.orig/src/serv.c` which > fixes the problem. Hello, Thank you. I am unable, though, to use the attached patch. Please use "diff -u" or git diff which both produce content that can be applied with patch. regards, Nikos From uwe.heuert at hs-merseburg.de Sat Nov 15 23:14:47 2014 From: uwe.heuert at hs-merseburg.de (Uwe Heuert) Date: Sat, 15 Nov 2014 23:14:47 +0100 Subject: [gnutls-devel] DTLS problems under Windows Message-ID: <000001d00121$9f792690$de6b73b0$@hs-merseburg.de> Hello, I have problems to get DTLS running with gnutls-3.3.10 (and older versions too). I use the pre-compiled w32 binaries available on ftp://ftp.gnutls.org/gcrypt/gnutls/w32/. I start the server: I start the client: The server tries to establish the connection but repeats this very very often . it hangs here. The client gives up (timeout). I also compiled the sample code for server and client myself, but it fails in the same way. Do I make a mistake? The same command lines for server and client without "-u" (TLS instead of DTLS) work well. I work under Windows 7 x64, with and without firewall off. Thank you for your response! Best regards Uwe Prof. Dr. Uwe Heuert Email: uwe.heuert at hs-merseburg.de Web: www.inw.hs-merseburg.de/~uheuert/ IPW: www.ipw-merseburg.de/index.php?id=966 Tel: +49 3461 46 2189 Fax: +49 3461 46 2192 Rechnernetze und Virtuelle Instrumentierung Fachbereich Ingenieur- und Naturwissenschaften Hochschule Merseburg (FH) Eberhard-Leibnitz-Str. 2 06217 Merseburg -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 35808 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 28693 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 30680 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 31415 bytes Desc: not available URL: From tim.ruehsen at gmx.de Mon Nov 17 10:05:59 2014 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Mon, 17 Nov 2014 10:05:59 +0100 Subject: [gnutls-devel] Looking for OCSP Stapling client example In-Reply-To: <1415995077.2035.1.camel@gnutls.org> References: <3213306.Wb2fQ2uKpo@blitz-lx> <5391566.XdQz2caatd@blitz-lx> <1415995077.2035.1.camel@gnutls.org> Message-ID: <1966142.u2HXLautJM@blitz-lx> On Friday 14 November 2014 20:57:57 Nikos Mavrogiannopoulos wrote: > On Thu, 2014-11-13 at 11:47 +0100, Tim Ruehsen wrote: > > > > > In my verify callback routine (after > > > > > gnutls_certificate_verify_peers3()), > > > > > gnutls_ocsp_status_request_is_checked() always returns 0. > > > > > > > > There is something strange with that server. I check the wireshark > > > > output of a connection to that server with openssl and the one with > > > > gnutls. They are different. With gnutls client the server doesn't > > > > advertise its support for ocsp and doesn't send the ocsp response. The > > > > contents of the extension sent by the client are the same in both > > > > cases. > > > > > > I can't find a working web server. They seem to behave like movlib.org, > > > e.g. take blog.cloudflare.com:443. > > > They seemingly made lot's of tests: > > > http://blog.cloudflare.com/ocsp-stapling-how-cloudflare-just-made-ssl-30 > > > / > > > > More examples: yahoo.com and yandex.ru. > > Thanks for insisting. It seems that there is an issue in libtasn1 which > does not properly re-encode these OCSP responses, and as far as I see > this is a persistent issue. OCSP responders must have switched from > setting the issuer's DN to setting the SHA1 hash of the key, and that > must have uncovered the issue. I don't think if I can manage to work on > libtasn1, but I've worked around the issue in gnutls 3.3 branch, so > unfortunately you cannot rely on the verification of OCSP stapled > responses with the released versions of gnutls. Thanks for having a second look. There is no pressure and I am just looking forward to the next release of GnuTLS. 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 INVALID.NOREPLY at gnu.org Wed Nov 19 12:50:26 2014 From: INVALID.NOREPLY at gnu.org (Martin Lambers) Date: Wed, 19 Nov 2014 11:50:26 +0000 Subject: [gnutls-devel] [sr #108689] gnutls_x509_crt_check_hostname() and Internationalized Domain Names Message-ID: <20141119-125024.sv38407.9197@savannah.gnu.org> URL: Summary: gnutls_x509_crt_check_hostname() and Internationalized Domain Names Project: GnuTLS Submitted by: marlam Submitted on: Wed 19 Nov 2014 12:50:24 PM CET Category: Core library Priority: 5 - Normal Severity: 1 - Wish Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: According to RFC 6125 section 6.4.2, host name checking must be performed on the ASCII representation of Internationalized Domain Names (IDN). Therefore, a client program currently must call idna_to_ascii_lz() from libidn on the host name before passing it to gnutls_x509_crt_check_hostname(). It would be nice if gnutls_x509_crt_check_hostname() did this automatically instead of using dubious byte-for-byte comparison of non-ASCII characters. As an alternative, a new GNUTLS_VERIFY_IDN flag could be added and taken into account by gnutls_x509_crt_check_hostname2(). This would result in easy support for IDN, in a similar way that the getaddrinfo() function provides easy support for IDN nowadays via the AI_IDN flag. Client programs would not have to deal with libidn at all in order to support IDN. Best regards, Martin _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Nov 19 15:11:58 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Wed, 19 Nov 2014 14:11:58 +0000 Subject: [gnutls-devel] [sr #108689] gnutls_x509_crt_check_hostname() and Internationalized Domain Names In-Reply-To: <20141119-125024.sv38407.9197@savannah.gnu.org> References: <20141119-125024.sv38407.9197@savannah.gnu.org> Message-ID: <20141119-161158.sv707.81265@savannah.gnu.org> Follow-up Comment #1, sr #108689 (project gnutls): This is planned to be included in 3.4.0 and is in fact already present in the git repository. Unfortunately there is no timeline for 3.4.0 yet (what remains for a release is nettle 3.x supporting chacha20-poly and porting gnutls to it). _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From ametzler at bebt.de Wed Nov 19 19:45:32 2014 From: ametzler at bebt.de (Andreas Metzler) Date: Wed, 19 Nov 2014 19:45:32 +0100 Subject: [gnutls-devel] disabling SSL 3.0 by default in 3.4.0 In-Reply-To: References: Message-ID: <20141119184532.GA2159@downhill.g.la> On 2014-10-15 Nikos Mavrogiannopoulos wrote: > Given the new and old attacks known for SSL 3.0, would it make sense > to disable SSL 3.0 in the default priority strings? Hello, FWIW I have been asked to disable SSL 3.0 by default for GnuTLS in Debian. The main point being that it brings consistency across implementations, OpenSSL in Debian is built without SSLv3 since mid of October. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From INVALID.NOREPLY at gnu.org Wed Nov 19 20:22:36 2014 From: INVALID.NOREPLY at gnu.org (Martin Lambers) Date: Wed, 19 Nov 2014 19:22:36 +0000 Subject: [gnutls-devel] [sr #108689] gnutls_x509_crt_check_hostname() and Internationalized Domain Names In-Reply-To: <20141119-161158.sv707.81265@savannah.gnu.org> References: <20141119-125024.sv38407.9197@savannah.gnu.org> <20141119-161158.sv707.81265@savannah.gnu.org> Message-ID: <20141119-202236.sv38407.51161@savannah.gnu.org> Follow-up Comment #2, sr #108689 (project gnutls): Great! I will try the current git version as soon as I find the time. Thank you. Best regards, Martin _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Fri Nov 21 16:48:33 2014 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Fri, 21 Nov 2014 15:48:33 +0000 Subject: [gnutls-devel] [sr #108690] gnutls 3.1.27 breaks use of GNUTLS_E_GOT_APPLICATION_DATA Message-ID: <20141121-154832.sv0.32001@savannah.gnu.org> URL: Summary: gnutls 3.1.27 breaks use of GNUTLS_E_GOT_APPLICATION_DATA Project: GnuTLS Submitted by: None Submitted on: Fri 21 Nov 2014 03:48:32 PM UTC Category: Core library Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: danw at gnome.org Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: In 3.1.27, it appears to no longer be possible to process application data packets received when a rehandshake was expected. The attached programs splits itself into a client and server. The server requests a rehandshake immediately after the first handshake, but tries to handle application data packets received before the rehandshake begins. The client writes data immediately after the first handshake, and only processes the rehandshake request after that. With 3.1.26, I get: danw at laptop:Desktop> ./rehandshake-test GNUTLS_E_GOT_APPLICATION_DATA: hello server rehandshaked but with 3.1.27 or 3.1.28: danw at laptop:Desktop> ./rehandshake-test GNUTLS_E_GOT_APPLICATION_DATA: server read app data: GnuTLS error: The specified session has been invalidated for some reason. _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Fri 21 Nov 2014 03:48:32 PM UTC Name: rehandshake-test.c Size: 8kB By: None _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Fri Nov 21 20:45:24 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Fri, 21 Nov 2014 19:45:24 +0000 Subject: [gnutls-devel] [sr #108690] gnutls 3.1.27 breaks use of GNUTLS_E_GOT_APPLICATION_DATA In-Reply-To: <20141121-154832.sv0.32001@savannah.gnu.org> References: <20141121-154832.sv0.32001@savannah.gnu.org> Message-ID: <20141121-214523.sv707.93297@savannah.gnu.org> Follow-up Comment #1, sr #108690 (project gnutls): Thank you for noticing and for the reproducer. It is indeed a regression which treats that error as fatal. I'll commit a fix. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From mabrand at mabrand.nl Mon Nov 24 09:07:03 2014 From: mabrand at mabrand.nl (Mark Brand) Date: Mon, 24 Nov 2014 09:07:03 +0100 Subject: [gnutls-devel] [patch]: windows build fix: ws2tcpip.h supplies inet_ntop Message-ID: <5472E727.9000904@mabrand.nl> Small build fix for gnutls_3_3_x branch. commit 6e239fdb653f89f9324ec6e3f00052e8a5641557 Author: Mark Brand Date: Mon Nov 24 08:56:48 2014 +0100 windows build fix: ws2tcpip.h supplies inet_ntop Follow-up to 492c2b937ab66134d0b37499a6f3a747e19bc31a Signed-off-by: Mark Brand diff --git a/lib/x509/output.c b/lib/x509/output.c index bf01834..1ec18de 100644 --- a/lib/x509/output.c +++ b/lib/x509/output.c @@ -32,7 +32,11 @@ #include #ifdef HAVE_INET_NTOP -# include +# ifdef _WIN32 +# include +# else +# include +# endif #endif #define addf _gnutls_buffer_append_printf From georg at mariadb.com Mon Nov 24 13:15:43 2014 From: georg at mariadb.com (Georg Richter) Date: Mon, 24 Nov 2014 13:15:43 +0100 Subject: [gnutls-devel] Memory leak in read_key_mem (gnutls:x509.c) Message-ID: Hi, I just stumbled over a memory leak in read_key_mem function: The function allocates memory via gnutls_privkey_init but doesn't free it if gnutls_privkey_impport_x509_raw fails. Patch attached. /Georg -- Georg Richter, Senior Software Engineer MariaDB Corporation -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls_memleak.patch Type: text/x-patch Size: 322 bytes Desc: not available URL: From eliz at gnu.org Mon Nov 24 14:16:45 2014 From: eliz at gnu.org (Eli Zaretskii) Date: Mon, 24 Nov 2014 15:16:45 +0200 Subject: [gnutls-devel] [patch]: windows build fix: ws2tcpip.h supplies inet_ntop In-Reply-To: <5472E727.9000904@mabrand.nl> References: <5472E727.9000904@mabrand.nl> Message-ID: <83bnnwrb5u.fsf@gnu.org> > Date: Mon, 24 Nov 2014 09:07:03 +0100 > From: Mark Brand > > Small build fix for gnutls_3_3_x branch. > > commit 6e239fdb653f89f9324ec6e3f00052e8a5641557 > Author: Mark Brand > Date: Mon Nov 24 08:56:48 2014 +0100 > > windows build fix: ws2tcpip.h supplies inet_ntop In which version of what compiler/library? I don't have it in my w32api headers (MinGW32 version 3.17). From mabrand at mabrand.nl Mon Nov 24 15:01:55 2014 From: mabrand at mabrand.nl (Mark Brand) Date: Mon, 24 Nov 2014 15:01:55 +0100 Subject: [gnutls-devel] [patch]: windows build fix: ws2tcpip.h supplies inet_ntop In-Reply-To: <83bnnwrb5u.fsf@gnu.org> References: <5472E727.9000904@mabrand.nl> <83bnnwrb5u.fsf@gnu.org> Message-ID: <54733A53.2010005@mabrand.nl> On 11/24/2014 02:16 PM, Eli Zaretskii wrote: >> Date: Mon, 24 Nov 2014 09:07:03 +0100 >> From: Mark Brand >> >> Small build fix for gnutls_3_3_x branch. >> >> commit 6e239fdb653f89f9324ec6e3f00052e8a5641557 >> Author: Mark Brand >> Date: Mon Nov 24 08:56:48 2014 +0100 >> >> windows build fix: ws2tcpip.h supplies inet_ntop > In which version of what compiler/library? I don't have it in my > w32api headers (MinGW32 version 3.17). Mingw-w64 3.3.0 has ws2tcpip.h with inet_ntop. Apparently it's in the Win API since Vista: http://msdn.microsoft.com/en-us/library/windows/desktop/cc805843%28v=vs.85%29.aspx Mark From eliz at gnu.org Mon Nov 24 15:09:25 2014 From: eliz at gnu.org (Eli Zaretskii) Date: Mon, 24 Nov 2014 16:09:25 +0200 Subject: [gnutls-devel] [patch]: windows build fix: ws2tcpip.h supplies inet_ntop In-Reply-To: <54733A53.2010005@mabrand.nl> References: <5472E727.9000904@mabrand.nl> <83bnnwrb5u.fsf@gnu.org> <54733A53.2010005@mabrand.nl> Message-ID: <834mtor8q2.fsf@gnu.org> > Date: Mon, 24 Nov 2014 15:01:55 +0100 > From: Mark Brand > CC: gnutls-devel at lists.gnutls.org > > > On 11/24/2014 02:16 PM, Eli Zaretskii wrote: > >> Date: Mon, 24 Nov 2014 09:07:03 +0100 > >> From: Mark Brand > >> > >> Small build fix for gnutls_3_3_x branch. > >> > >> commit 6e239fdb653f89f9324ec6e3f00052e8a5641557 > >> Author: Mark Brand > >> Date: Mon Nov 24 08:56:48 2014 +0100 > >> > >> windows build fix: ws2tcpip.h supplies inet_ntop > > In which version of what compiler/library? I don't have it in my > > w32api headers (MinGW32 version 3.17). > > Mingw-w64 3.3.0 has ws2tcpip.h with inet_ntop. Apparently it's in the > Win API since Vista: > > http://msdn.microsoft.com/en-us/library/windows/desktop/cc805843%28v=vs.85%29.aspx Thanks. So I guess some version checking is in order here. From eliz at gnu.org Mon Nov 24 15:21:25 2014 From: eliz at gnu.org (Eli Zaretskii) Date: Mon, 24 Nov 2014 16:21:25 +0200 Subject: [gnutls-devel] [patch]: windows build fix: ws2tcpip.h supplies inet_ntop In-Reply-To: <54733CAD.2040108@mabrand.nl> References: <5472E727.9000904@mabrand.nl> <83bnnwrb5u.fsf@gnu.org> <54733A53.2010005@mabrand.nl> <834mtor8q2.fsf@gnu.org> <54733CAD.2040108@mabrand.nl> Message-ID: <833898r862.fsf@gnu.org> > Date: Mon, 24 Nov 2014 15:11:57 +0100 > From: Mark Brand > > > Thanks. So I guess some version checking is in order here. > > I'm not sure that's necessary. It seems safe to assume that if inet_ntop > is detected and the platform is windows, then we need ws2tcpip.h. Perhaps you are right. Does the configure test program include ws2tcpip.h, and does removing the inet_ntop prototype from that header fails the test? (I cannot easily test that where I'm typing this, sorry.) If the answer to both questions is YES, then you are right, and nothing else is needed. From nmav at gnutls.org Mon Nov 24 18:53:17 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 24 Nov 2014 18:53:17 +0100 Subject: [gnutls-devel] [patch]: windows build fix: ws2tcpip.h supplies inet_ntop In-Reply-To: <54733A53.2010005@mabrand.nl> References: <5472E727.9000904@mabrand.nl> <83bnnwrb5u.fsf@gnu.org> <54733A53.2010005@mabrand.nl> Message-ID: <1416851597.2057.1.camel@gnutls.org> On Mon, 2014-11-24 at 15:01 +0100, Mark Brand wrote: > On 11/24/2014 02:16 PM, Eli Zaretskii wrote: > >> Date: Mon, 24 Nov 2014 09:07:03 +0100 > >> From: Mark Brand > >> > >> Small build fix for gnutls_3_3_x branch. > >> > >> commit 6e239fdb653f89f9324ec6e3f00052e8a5641557 > >> Author: Mark Brand > >> Date: Mon Nov 24 08:56:48 2014 +0100 > >> > >> windows build fix: ws2tcpip.h supplies inet_ntop > > In which version of what compiler/library? I don't have it in my > > w32api headers (MinGW32 version 3.17). > > Mingw-w64 3.3.0 has ws2tcpip.h with inet_ntop. Apparently it's in the > Win API since Vista: > http://msdn.microsoft.com/en-us/library/windows/desktop/cc805843%28v=vs.85%29.aspx Thanks Mark. Wouldn't that make though the distributed gnutls binaries required windows vista+? I'd like to keep windows xp compatibility. A way would be by doing something similar to what system-keys-win.c does in master for the CNG API, or bundling a tiny inet_ntop, but I'm not sure it's worth the effort. In any case, if there is a patch that would allow compatibility with older windows systems I'll apply it. regards, Nikos From nmav at gnutls.org Mon Nov 24 18:57:20 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 24 Nov 2014 18:57:20 +0100 Subject: [gnutls-devel] Memory leak in read_key_mem (gnutls:x509.c) In-Reply-To: References: Message-ID: <1416851840.2057.2.camel@gnutls.org> On Mon, 2014-11-24 at 13:15 +0100, Georg Richter wrote: > Hi, > I just stumbled over a memory leak in read_key_mem function: > > The function allocates memory via gnutls_privkey_init but doesn't free > it if gnutls_privkey_impport_x509_raw fails. Patch applied. Thank you. From eliz at gnu.org Mon Nov 24 19:11:47 2014 From: eliz at gnu.org (Eli Zaretskii) Date: Mon, 24 Nov 2014 20:11:47 +0200 Subject: [gnutls-devel] [patch]: windows build fix: ws2tcpip.h supplies inet_ntop In-Reply-To: <1416851597.2057.1.camel@gnutls.org> References: <5472E727.9000904@mabrand.nl> <83bnnwrb5u.fsf@gnu.org> <54733A53.2010005@mabrand.nl> <1416851597.2057.1.camel@gnutls.org> Message-ID: <83tx1opixo.fsf@gnu.org> > From: Nikos Mavrogiannopoulos > Cc: Eli Zaretskii , gnutls-devel at lists.gnutls.org > Date: Mon, 24 Nov 2014 18:53:17 +0100 > > Thanks Mark. Wouldn't that make though the distributed gnutls binaries > required windows vista+? I'd like to keep windows xp compatibility. A > way would be by doing something similar to what system-keys-win.c does > in master for the CNG API, or bundling a tiny inet_ntop, but I'm not > sure it's worth the effort. In any case, if there is a patch that would > allow compatibility with older windows systems I'll apply it. There's inet_ntop module in gnulib, perhaps using it would be the best. From nmav at gnutls.org Mon Nov 24 19:15:08 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 24 Nov 2014 19:15:08 +0100 Subject: [gnutls-devel] [patch]: windows build fix: ws2tcpip.h supplies inet_ntop In-Reply-To: <83tx1opixo.fsf@gnu.org> References: <5472E727.9000904@mabrand.nl> <83bnnwrb5u.fsf@gnu.org> <54733A53.2010005@mabrand.nl> <1416851597.2057.1.camel@gnutls.org> <83tx1opixo.fsf@gnu.org> Message-ID: <1416852908.2057.6.camel@gnutls.org> On Mon, 2014-11-24 at 20:11 +0200, Eli Zaretskii wrote: > > From: Nikos Mavrogiannopoulos > > Cc: Eli Zaretskii , gnutls-devel at lists.gnutls.org > > Date: Mon, 24 Nov 2014 18:53:17 +0100 > > > > Thanks Mark. Wouldn't that make though the distributed gnutls binaries > > required windows vista+? I'd like to keep windows xp compatibility. A > > way would be by doing something similar to what system-keys-win.c does > > in master for the CNG API, or bundling a tiny inet_ntop, but I'm not > > sure it's worth the effort. In any case, if there is a patch that would > > allow compatibility with older windows systems I'll apply it. > There's inet_ntop module in gnulib, perhaps using it would be the > best. I spent quite some time removing gnulib's networking part for the main library. It makes interplay with applications using windows sockets almost impossible. regards, Nikos From eliz at gnu.org Mon Nov 24 19:24:03 2014 From: eliz at gnu.org (Eli Zaretskii) Date: Mon, 24 Nov 2014 20:24:03 +0200 Subject: [gnutls-devel] [patch]: windows build fix: ws2tcpip.h supplies inet_ntop In-Reply-To: <1416852908.2057.6.camel@gnutls.org> References: <5472E727.9000904@mabrand.nl> <83bnnwrb5u.fsf@gnu.org> <54733A53.2010005@mabrand.nl> <1416851597.2057.1.camel@gnutls.org> <83tx1opixo.fsf@gnu.org> <1416852908.2057.6.camel@gnutls.org> Message-ID: <83sih8pid8.fsf@gnu.org> > From: Nikos Mavrogiannopoulos > Cc: mabrand at mabrand.nl, gnutls-devel at lists.gnutls.org > Date: Mon, 24 Nov 2014 19:15:08 +0100 > > On Mon, 2014-11-24 at 20:11 +0200, Eli Zaretskii wrote: > > > From: Nikos Mavrogiannopoulos > > > Cc: Eli Zaretskii , gnutls-devel at lists.gnutls.org > > > Date: Mon, 24 Nov 2014 18:53:17 +0100 > > > > > > Thanks Mark. Wouldn't that make though the distributed gnutls binaries > > > required windows vista+? I'd like to keep windows xp compatibility. A > > > way would be by doing something similar to what system-keys-win.c does > > > in master for the CNG API, or bundling a tiny inet_ntop, but I'm not > > > sure it's worth the effort. In any case, if there is a patch that would > > > allow compatibility with older windows systems I'll apply it. > > There's inet_ntop module in gnulib, perhaps using it would be the > > best. > > I spent quite some time removing gnulib's networking part for the main > library. It makes interplay with applications using windows sockets > almost impossible. OK, but since inet_ntop doesn't actually call any network functions, you could just steal its code from gnulib, and provide that as fallback on pre-Vista Windows systems. IOW, the only "networking part" I see in gnulib's inet_ntop is the inclusion of arpa/inet.h and use of AF_* macros. That is easy to deal with while leaving the code parts intact. In any case, if you want XP compatibility, you will have to provide some replacement for that, right? There's no way around that. From tzz at lifelogs.com Wed Nov 26 18:25:26 2014 From: tzz at lifelogs.com (Ted Zlatanov) Date: Wed, 26 Nov 2014 12:25:26 -0500 Subject: [gnutls-devel] Emacs 24, 25, and future integration of GnuTLS 2.x vs. 3.x Message-ID: <87k32han7d.fsf@lifelogs.com> Hi, Emacs 24 supports GnuTLS 2.x. We plan to continue that support in Emacs 25 (master branch of the new Emacs Git repo) but will revisit 2.x support and possibly remove it with Emacs 26. Partly that's driven by the state of GnuTLS 2.x vs. 3.x support in Debian Stable and other distribution, and partly by the burden of supporting the older versions that lack many useful features. I wanted to ask here if there are any scenarios we should beware with supporting 2.x, especially as far as user risk and exposure to exploits. What about introduced features, should we support them by version or by a feature-specific ifdef? Thanks! Ted From dkg at fifthhorseman.net Wed Nov 26 21:42:01 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 26 Nov 2014 15:42:01 -0500 Subject: [gnutls-devel] Emacs 24, 25, and future integration of GnuTLS 2.x vs. 3.x In-Reply-To: <87k32han7d.fsf@lifelogs.com> References: <87k32han7d.fsf@lifelogs.com> Message-ID: <54763B19.6020706@fifthhorseman.net> On 11/26/2014 12:25 PM, Ted Zlatanov wrote: > Emacs 24 supports GnuTLS 2.x. We plan to continue that support in Emacs > 25 (master branch of the new Emacs Git repo) but will revisit 2.x > support and possibly remove it with Emacs 26. Partly that's driven by > the state of GnuTLS 2.x vs. 3.x support in Debian Stable and other > distribution, and partly by the burden of supporting the older versions > that lack many useful features. I strongly recommend switching to 3.x as soon as possible, and not committing long-term to anything in the 2.x series. If you care about debian stable, Jessie will not have 2.x at all, and 3.x is well-supported in wheezy-backports already. > I wanted to ask here if there are any scenarios we should beware with > supporting 2.x, especially as far as user risk and exposure to exploits. > What about introduced features, should we support them by version or by > a feature-specific ifdef? I don't think 2.x is receiving much upstream attention at all right now. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Thu Nov 27 10:59:07 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 27 Nov 2014 10:59:07 +0100 Subject: [gnutls-devel] Emacs 24, 25, and future integration of GnuTLS 2.x vs. 3.x In-Reply-To: <87k32han7d.fsf@lifelogs.com> References: <87k32han7d.fsf@lifelogs.com> Message-ID: On Wed, Nov 26, 2014 at 6:25 PM, Ted Zlatanov wrote: > Hi, > > Emacs 24 supports GnuTLS 2.x. We plan to continue that support in Emacs > 25 (master branch of the new Emacs Git repo) but will revisit 2.x > support and possibly remove it with Emacs 26. Partly that's driven by > the state of GnuTLS 2.x vs. 3.x support in Debian Stable and other > distribution, and partly by the burden of supporting the older versions > that lack many useful features. > I wanted to ask here if there are any scenarios we should beware with > supporting 2.x, especially as far as user risk and exposure to exploits. Hello Ted, The oldest supported release is stable-old (which is 3.2.x now). Anything else before that, is typically not supported (I may release fixes for some older releases for serious issues occasionally but there are no guarantees). The 2.x releases are totally unsupported, I see no reason for depending on them. regards, Nikos From tzz at lifelogs.com Fri Nov 28 02:09:39 2014 From: tzz at lifelogs.com (Ted Zlatanov) Date: Thu, 27 Nov 2014 20:09:39 -0500 Subject: [gnutls-devel] Emacs 24, 25, and future integration of GnuTLS 2.x vs. 3.x References: <87k32han7d.fsf@lifelogs.com> Message-ID: <87y4qw3zcc.fsf@lifelogs.com> On Thu, 27 Nov 2014 10:59:07 +0100 Nikos Mavrogiannopoulos wrote: NM> The oldest supported release is stable-old (which is 3.2.x now). NM> Anything else before that, is typically not supported (I may release NM> fixes for some older releases for serious issues occasionally but NM> there are no guarantees). The 2.x releases are totally unsupported, I NM> see no reason for depending on them. On Wed, 26 Nov 2014 15:42:01 -0500 Daniel Kahn Gillmor wrote: DKG> I strongly recommend switching to 3.x as soon as possible, and not DKG> committing long-term to anything in the 2.x series. DKG> If you care about debian stable, Jessie will not have 2.x at all, and DKG> 3.x is well-supported in wheezy-backports already. ... DKG> I don't think 2.x is receiving much upstream attention at all right now. Hello again, and thank you so much for the answers. One of the Emacs maintainers, Stefan Monnier, disagrees with my interpretation of Daniel's message (Nikos' followup came later): Stefan: "My reading of it doesn't say that we should only support GnuTLS-3.x, but that we should start supporting GnuTLS-3.x ASAP." Could you thus specifically recommend if the next major release, Emacs 25.1, should *require* GnuTLS 3.x and *drop* support for 2.x? I believe Nikos and Daniel are saying so, but want to be clear. Thanks! Ted From nmav at gnutls.org Fri Nov 28 09:01:19 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 28 Nov 2014 09:01:19 +0100 Subject: [gnutls-devel] Emacs 24, 25, and future integration of GnuTLS 2.x vs. 3.x In-Reply-To: <87y4qw3zcc.fsf@lifelogs.com> References: <87k32han7d.fsf@lifelogs.com> <87y4qw3zcc.fsf@lifelogs.com> Message-ID: On Fri, Nov 28, 2014 at 2:09 AM, Ted Zlatanov wrote: > DKG> I strongly recommend switching to 3.x as soon as possible, and not > DKG> committing long-term to anything in the 2.x series. > DKG> If you care about debian stable, Jessie will not have 2.x at all, and > DKG> 3.x is well-supported in wheezy-backports already. > ... > DKG> I don't think 2.x is receiving much upstream attention at all right now. > Hello again, and thank you so much for the answers. > > One of the Emacs maintainers, Stefan Monnier, disagrees with my > interpretation of Daniel's message (Nikos' followup came later): > > Stefan: "My reading of it doesn't say that we should only support > GnuTLS-3.x, but that we should start supporting GnuTLS-3.x ASAP." Whether you need to support gnutls 2.12.x is up to you. However, I note that this version is totally unsupported, if it is broken or has a critical bug you are on your own. regards, Nikos From n.mavrogiannopoulos at gmail.com Fri Nov 28 11:51:32 2014 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 28 Nov 2014 11:51:32 +0100 Subject: [gnutls-devel] system-keys API Message-ID: Hello, I've updated the plan for gnutls 3.4.0 [0] to include a new API for system-keys. That is keys and certificates that are available in the system storage (if it exists). Currently there is a proposed API [1] that works well for the system wide keys in windows (using the CNG API). Are you aware of other systems that provide such functionality that we could add support for? Do you think the API in [1] be sufficient for such systems? regards, Nikos [0]. https://gitorious.org/gnutls/pages/Plan3_4 [1]. https://gitorious.org/gnutls/gnutls/source/91472921689d799cb991db84af7e04fba6b049f1:lib/includes/gnutls/system-keys.h From n.mavrogiannopoulos at gmail.com Fri Nov 28 16:07:17 2014 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 28 Nov 2014 16:07:17 +0100 Subject: [gnutls-devel] system-keys API In-Reply-To: References: Message-ID: On Fri, Nov 28, 2014 at 3:50 PM, Martin Paljak wrote: > OSX Keychain ? Do you know if that can be used by a C library? > Does this retrieve the actual plaintext DER? What if smart cards are > behind the system API? The iterator function gnutls_system_key_iter_get_info(gnutls_system_key_iter_t *iter, char **cert_url, char **key_url, char **label, gnutls_datum_t *der, unsigned int flags); returns URLs of the certificate and the key, something like: "system:win:xxxxxxxxxx;type=cert" and "system:win:xxxxxxxxxx;type=privkey" The @der parameter is to get the certificate. The API assumes that private keys are not available. Reportedly, using this API openconnect-gui [0] works with smart cards on windows. regards, Nikos [0]. https://github.com/openconnect/openconnect-gui/wiki From martin at martinpaljak.net Fri Nov 28 15:50:25 2014 From: martin at martinpaljak.net (Martin Paljak) Date: Fri, 28 Nov 2014 16:50:25 +0200 Subject: [gnutls-devel] system-keys API In-Reply-To: References: Message-ID: OSX Keychain ? Does this retrieve the actual plaintext DER? What if smart cards are behind the system API? -- Martin +372 515 6495 On Fri, Nov 28, 2014 at 12:51 PM, Nikos Mavrogiannopoulos wrote: > Hello, > I've updated the plan for gnutls 3.4.0 [0] to include a new API for > system-keys. That is keys and certificates that are available in the > system storage (if it exists). Currently there is a proposed API [1] > that works well for the system wide keys in windows (using the CNG > API). Are you aware of other systems that provide such functionality > that we could add support for? Do you think the API in [1] be > sufficient for such systems? > > regards, > Nikos > > [0]. https://gitorious.org/gnutls/pages/Plan3_4 > > [1]. https://gitorious.org/gnutls/gnutls/source/91472921689d799cb991db84af7e04fba6b049f1:lib/includes/gnutls/system-keys.h > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-devel From tzz at lifelogs.com Fri Nov 28 21:53:58 2014 From: tzz at lifelogs.com (Ted Zlatanov) Date: Fri, 28 Nov 2014 15:53:58 -0500 Subject: [gnutls-devel] Emacs 24, 25, and future integration of GnuTLS 2.x vs. 3.x References: <87k32han7d.fsf@lifelogs.com> <87y4qw3zcc.fsf@lifelogs.com> Message-ID: <87ppc72gih.fsf@lifelogs.com> On Fri, 28 Nov 2014 09:01:19 +0100 Nikos Mavrogiannopoulos wrote: NM> Whether you need to support gnutls 2.12.x is up to you. However, I NM> note that this version is totally unsupported, if it is broken or NM> has a critical bug you are on your own. Thank you for explaining. It looks like Emacs will keep supporting 2.x in its next major release (25) because I wasn't able to convince the maintainers otherwise. I'll bring this up again when we get to 26. Ted