From eliz at gnu.org Tue Oct 4 13:09:38 2016 From: eliz at gnu.org (Eli Zaretskii) Date: Tue, 04 Oct 2016 14:09:38 +0300 Subject: [gnutls-devel] Building a MinGW port of GnuTLS 3.4.15 Message-ID: <83vax8mkul.fsf@gnu.org> I've built and tested this version natively on MS-Windows using mingw.org's MinGW tools. I've bumped into some issues which I'd like to report here: 1. There are relatively many compilation warnings, triggered by the warning options passed to the compiler. I think most of the warnings are not Windows-specific. I wonder if all of these switches are appropriate for production builds. Some examples of the warnings include: . unused variables . comparison between signed and unsigned . stack frame size is larger than 2048 bytes (why such a low limit, when on modern platforms a program's stack size is something like 2MB?) . mismatch in signedness between prototype and actual arguments . "cannot optimize loop, the loop counter may overflow" . use of visibility attribute, which non-ELF binaries don't support, in x86-common.c 2. system-keys-win.c was written using features that are available with the MinGW64 toolchain, but not with mingw.org's one. I needed to add the missing stuff by hand; see the patch below. 3. libgnutls fails to link due to unresolved external rpl_fseek: CCLD libgnutls.la opencdk/.libs/libminiopencdk.a(armor.o): In function `armor_decode': d:\gnu\gnutls-3.4.15\lib\opencdk/armor.c:232: undefined reference to `rpl_fseek' opencdk/.libs/libminiopencdk.a(stream.o): In function `cdk_stream_seek': d:\gnu\gnutls-3.4.15\lib\opencdk/stream.c:1081: undefined reference to `rpl_fseek' I reported this for 3.3.11 back in Dec 2014. 4. certuniqueid.c in the test suite uses %zd, which is not supported by the Windows runtime. 5. Test programs fail to run because they don't find the libgnutls shared library (which was not installed yet). I fixed that by manually adding the directories with the DLLs to PATH, but I think the test suite should do that, because if a previous version of the same DLL is installed, the tests will silently use it instead of the one in the source tree, which might cause incorrect results and subtle failures. 6. "make install-strip" installs the *.def files in the ${prefix}/bin directory, whereas it should install them in ${prefix}/lib, I think. 7. The *.def file for the produced libgnutls-openssl-27.dll is libgnutls-openssl-30.def, for some reason. Which version number is correct for libgnutls-openssl, 27 or 30? 8. benchmark.c doesn't declare the MS-Windows variant of alarm_handler 'static', which causes a warning converted to error by the compiler switches, and stops the compilation. 9. certtool-cfg.c doesn't include the Gnulib-provided arpa/inet.h header, which triggers warnings about inet_pton missing a declaration. 10.The Gnulib stdio.h header declares all the functions of the *printf family using the __gnu_printf__ attribute, which then causes bogus warnings about %I64u format in certtool-cfg.c. I already saw this in another package and reported to Gnulib here: https://lists.gnu.org/archive/html/bug-gnulib/2016-06/msg00018.html Paul Eggert replied here: https://lists.gnu.org/archive/html/bug-gnulib/2016-06/msg00021.html saying that packages need to use the printf-posix module to resolve this issue. 11.tests/utils.c lacks the 'sleep' function, which is needed for MinGW, as the Windows runtime lacks it. HTH, and thanks for developing GnuTLS. Here's the patch to build system-keys-win.c with mingw.org's tools: --- ./lib/system-keys-win.c~0 2015-11-21 12:34:26.000000000 +0200 +++ ./lib/system-keys-win.c 2016-10-02 18:18:00.859375000 +0300 @@ -46,7 +46,32 @@ #define DYN_NCRYPT -#include +#ifdef __MINGW32__ +# include <_mingw.h> +# ifdef __MINGW64_VERSION_MAJOR +/* MinGW64 */ +# include +# else +/* mingw.org's MinGW */ +# include +# define BCRYPT_PAD_PKCS1 0x00000002 +# define BCRYPT_RSA_ALGORITHM L"RSA" +# define BCRYPT_DSA_ALGORITHM L"DSA" +# define BCRYPT_SHA1_ALGORITHM L"SHA1" +# define BCRYPT_SHA256_ALGORITHM L"SHA256" +# define BCRYPT_SHA384_ALGORITHM L"SHA384" +# define BCRYPT_SHA512_ALGORITHM L"SHA512" +# define BCRYPT_ECDSA_P256_ALGORITHM L"ECDSA_P256" +# define BCRYPT_ECDSA_P384_ALGORITHM L"ECDSA_P384" +# define BCRYPT_ECDSA_P521_ALGORITHM L"ECDSA_P521" + typedef ULONG_PTR NCRYPT_HANDLE; + typedef ULONG_PTR NCRYPT_PROV_HANDLE; + typedef ULONG_PTR NCRYPT_KEY_HANDLE; + typedef struct _BCRYPT_PKCS1_PADDING_INFO { + LPCWSTR pszAlgId; + } BCRYPT_PKCS1_PADDING_INFO; +# endif +#endif // MinGW headers may not have these defines #ifndef NCRYPT_SHA1_ALGORITHM From nmav at gnutls.org Wed Oct 5 08:50:19 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 5 Oct 2016 08:50:19 +0200 Subject: [gnutls-devel] Building a MinGW port of GnuTLS 3.4.15 In-Reply-To: <83vax8mkul.fsf@gnu.org> References: <83vax8mkul.fsf@gnu.org> Message-ID: On Tue, Oct 4, 2016 at 1:09 PM, Eli Zaretskii wrote: > I've built and tested this version natively on MS-Windows using > mingw.org's MinGW tools. I've bumped into some issues which I'd like > to report here: > > 1. There are relatively many compilation warnings, triggered by the > warning options passed to the compiler. I think most of the > warnings are not Windows-specific. I wonder if all of these > switches are appropriate for production builds. Some examples > of the warnings include: > . unused variables > . comparison between signed and unsigned > . stack frame size is larger than 2048 bytes (why such a low limit, > when on modern platforms a program's stack size is something like > 2MB?) That was added mainly to allow gnutls to run on platforms with limited memory. I also consider using too much stack in a library an issue, since memory errors due to stack exhaustion cannot be caught by the calling application and result to a crash. Currently the stack usage warnings are on legacy code which will be hopefully at some point removed. > . mismatch in signedness between prototype and actual arguments If that's on the main library code, I'd appreciate pointing them. > . "cannot optimize loop, the loop counter may overflow" These warnings I have not been able to eliminate. I could not see reasonable conditions of overflowing but I could be wrong. > 2. system-keys-win.c was written using features that are available > with the MinGW64 toolchain, but not with mingw.org's one. I needed > to add the missing stuff by hand; see the patch below. I've included this patch, though I'm not sure we should carry too much legacy code. Is there are reason you don't use mingw64? > 3. libgnutls fails to link due to unresolved external rpl_fseek: > > CCLD libgnutls.la > opencdk/.libs/libminiopencdk.a(armor.o): In function `armor_decode': > d:\gnu\gnutls-3.4.15\lib\opencdk/armor.c:232: undefined reference to `rpl_fseek' > opencdk/.libs/libminiopencdk.a(stream.o): In function `cdk_stream_seek': > d:\gnu\gnutls-3.4.15\lib\opencdk/stream.c:1081: undefined reference to `rpl_fseek' > I reported this for 3.3.11 back in Dec 2014. I do not know about this issue or what could trigger it. Note that builds for windows32/64 are included in our CI and they seem to work well under wine. For tagged releases you can see the build process and download the produced dlls in the builds pages like: https://gitlab.com/gnutls/gnutls/commit/64fd6aa9e7c38b645c710aac036d4c5bd08b0b0c/builds (I have not found a way to link to a particular tag dlls directly) > 4. certuniqueid.c in the test suite uses %zd, which is not supported > by the Windows runtime. Thanks. These were removed. > 5. Test programs fail to run because they don't find the libgnutls > shared library (which was not installed yet). I fixed that by > manually adding the directories with the DLLs to PATH, but I think > the test suite should do that, because if a previous version of the > same DLL is installed, the tests will silently use it instead of > the one in the source tree, which might cause incorrect results and > subtle failures. That does not seem to be the case in the mingw builds under fedora as shown above. Could that be something related to mingw vs mingw64? > 6. "make install-strip" installs the *.def files in the ${prefix}/bin > directory, whereas it should install them in ${prefix}/lib, I > think. No opinion about that. I have no idea what are the conventions for win libraries. If you think that libdir is a better location I'll update the Makefile.am. > 7. The *.def file for the produced libgnutls-openssl-27.dll is > libgnutls-openssl-30.def, for some reason. Which version number > is correct for libgnutls-openssl, 27 or 30? It is 27. There seems to be some assumption in the makefile that these are equal. Corrected. > 8. benchmark.c doesn't declare the MS-Windows variant of alarm_handler > 'static', which causes a warning converted to error by the compiler > switches, and stops the compilation. Fixed. > 9. certtool-cfg.c doesn't include the Gnulib-provided arpa/inet.h > header, which triggers warnings about inet_pton missing a > declaration. Fixed. > 11.tests/utils.c lacks the 'sleep' function, which is needed for > MinGW, as the Windows runtime lacks it. Could that be something that mingw64 added as macro or so? I was also wondering how that works under mingw. regards, Nikos From eliz at gnu.org Wed Oct 5 09:29:48 2016 From: eliz at gnu.org (Eli Zaretskii) Date: Wed, 05 Oct 2016 10:29:48 +0300 Subject: [gnutls-devel] Building a MinGW port of GnuTLS 3.4.15 In-Reply-To: (message from Nikos Mavrogiannopoulos on Wed, 5 Oct 2016 08:50:19 +0200) References: <83vax8mkul.fsf@gnu.org> Message-ID: <83y423l0cz.fsf@gnu.org> > From: Nikos Mavrogiannopoulos > Date: Wed, 5 Oct 2016 08:50:19 +0200 > Cc: GnuTLS development list > > > . stack frame size is larger than 2048 bytes (why such a low limit, > > when on modern platforms a program's stack size is something like > > 2MB?) > > That was added mainly to allow gnutls to run on platforms with limited > memory. I also consider using too much stack in a library an issue, > since memory errors due to stack exhaustion cannot be caught by the > calling application and result to a crash. Currently the stack usage > warnings are on legacy code which will be hopefully at some point > removed. I understand the concern for the stack usage, but 2KB sounds awfully low by modern standards. If this is for special-purpose platforms, perhaps the warning should be turned on only on those platforms? > > . mismatch in signedness between prototype and actual arguments > > If that's on the main library code, I'd appreciate pointing them. I will show the full list of these warnings for library code in a separate message. > > . "cannot optimize loop, the loop counter may overflow" > > These warnings I have not been able to eliminate. I could not see > reasonable conditions of overflowing but I could be wrong. I agree, but then maybe this warning option shouldn't be used, as it produces too many false positives? > > 2. system-keys-win.c was written using features that are available > > with the MinGW64 toolchain, but not with mingw.org's one. I needed > > to add the missing stuff by hand; see the patch below. > > I've included this patch, though I'm not sure we should carry too much > legacy code. mingw.org is still developing its MinGW, albeit not as actively as MinGW64. So it's hardly "legacy", at least not yet. > Is there are reason you don't use mingw64? Yes, I don't trust their QA. Besides, switching from a well-tuned and fully operational and proven development environment to a subtly incompatible environment should be for a very good reason, and I don't yet have such a reason. > > 3. libgnutls fails to link due to unresolved external rpl_fseek: > > > > CCLD libgnutls.la > > opencdk/.libs/libminiopencdk.a(armor.o): In function `armor_decode': > > d:\gnu\gnutls-3.4.15\lib\opencdk/armor.c:232: undefined reference to `rpl_fseek' > > opencdk/.libs/libminiopencdk.a(stream.o): In function `cdk_stream_seek': > > d:\gnu\gnutls-3.4.15\lib\opencdk/stream.c:1081: undefined reference to `rpl_fseek' > > I reported this for 3.3.11 back in Dec 2014. > > I do not know about this issue or what could trigger it. I'm sure I explained it back then: This is because gl/libgnu.a does not compile fseek replacement in src/gl/fseek.c and src/gl/fseeko.c (unlike src/gl/libgnu.a), but gl/stdio.h defines fseek to rpl_fseek, which is defined in src/gl/fseek.c. Let me know if something is still unclear about this. > Note that builds for windows32/64 are included in our CI and they > seem to work well under wine. This issue depends on the configure-time tests, so perhaps they are different in your cross-compiled environment. > > 5. Test programs fail to run because they don't find the libgnutls > > shared library (which was not installed yet). I fixed that by > > manually adding the directories with the DLLs to PATH, but I think > > the test suite should do that, because if a previous version of the > > same DLL is installed, the tests will silently use it instead of > > the one in the source tree, which might cause incorrect results and > > subtle failures. > > That does not seem to be the case in the mingw builds under fedora as > shown above. Could that be something related to mingw vs mingw64? No, it can't, AFAIK. It's a general Windows issue: a DLL is looked according to certain rules and order described here: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx (only the "Desktop applications" part is relevant for this discussion). In a nutshell, Windows first looks in the same directory where the .exe file lives, then in the current directory, then along the PATH (the other places are not relevant for this case). The just-built libgnutls DLL is in neither of these. I don't think MinGW64 could affect this because this search happens before the application code starts, it is part of the process of loading the application by the Windows loader. > > 6. "make install-strip" installs the *.def files in the ${prefix}/bin > > directory, whereas it should install them in ${prefix}/lib, I > > think. > > No opinion about that. I have no idea what are the conventions for win > libraries. If you think that libdir is a better location I'll update > the Makefile.am. bindir is definitely wrong. The other *.def files I have are in libdir, so yes, I think it's a better place. > > 11.tests/utils.c lacks the 'sleep' function, which is needed for > > MinGW, as the Windows runtime lacks it. > > Could that be something that mingw64 added as macro or so? It looks like MinGW64 has it as a function in their add-on runtime library, so only mingw.org needs that. The way to discern between these two MinGW flavors is a bit tricky, and is shown in the patch for system-keys-win.c: #ifdef __MINGW32__ # include <_mingw.h> # ifdef __MINGW64_VERSION_MAJOR /* MinGW64 stuff */ # else /* mingw.org stuff */ # endif #endif Btw, one other annoyance with warnings is this: CCLD libexamples.la libtool: link: warning: `-no-install' is ignored for i686-pc-mingw32 libtool: link: warning: assuming `-no-fast-install' instead AFAIR, it is issued for every example and test program. Thanks for the fixes, they will definitely make building GnuTLS easier next time. From eliz at gnu.org Wed Oct 5 09:34:07 2016 From: eliz at gnu.org (Eli Zaretskii) Date: Wed, 05 Oct 2016 10:34:07 +0300 Subject: [gnutls-devel] Building a MinGW port of GnuTLS 3.4.15 In-Reply-To: (message from Nikos Mavrogiannopoulos on Wed, 5 Oct 2016 08:50:19 +0200) References: <83vax8mkul.fsf@gnu.org> Message-ID: <83wphnl05s.fsf@gnu.org> > From: Nikos Mavrogiannopoulos > Date: Wed, 5 Oct 2016 08:50:19 +0200 > Cc: GnuTLS development list > > > . mismatch in signedness between prototype and actual arguments > > If that's on the main library code, I'd appreciate pointing them. Here's the full list of these warnings for files under lib/ misc.c:170:24: warning: pointer targets in passing argument 2 of 'GetTempPathA' differ in signedness [-Wpointer-sign] if (!GetTempPath(464, buf)) ^ In file included from d:\usr\include\windows.h:50:0, from d:\usr\include\winsock2.h:22, from d:\usr\include\ws2tcpip.h:19, from ./../gnutls_int.h:57, from ./opencdk.h:27, from misc.c:31: d:\usr\include\winbase.h:1748:25: note: expected 'LPSTR {aka char *}' but argument is of type 'unsigned char *' WINBASEAPI DWORD WINAPI GetTempPathA(DWORD,LPSTR); ^ misc.c:172:18: warning: pointer targets in passing argument 1 of '_gnutls_str_cat' differ in signedness [-Wpointer-sign] _gnutls_str_cat(buf, sizeof(buf), "_cdk_"); ^ In file included from ./../gnutls_int.h:242:0, from ./opencdk.h:27, from misc.c:31: ./../gnutls_str.h:42:6: note: expected 'char *' but argument is of type 'unsigned char *' void _gnutls_str_cat(char *dest, size_t dest_tot_size, const char *src); ^ misc.c:173:18: warning: pointer targets in passing argument 1 of '_gnutls_str_cat' differ in signedness [-Wpointer-sign] _gnutls_str_cat(buf, sizeof(buf), rnd); ^ In file included from ./../gnutls_int.h:242:0, from ./opencdk.h:27, from misc.c:31: ./../gnutls_str.h:42:6: note: expected 'char *' but argument is of type 'unsigned char *' void _gnutls_str_cat(char *dest, size_t dest_tot_size, const char *src); ^ misc.c:173:36: warning: pointer targets in passing argument 3 of '_gnutls_str_cat' differ in signedness [-Wpointer-sign] _gnutls_str_cat(buf, sizeof(buf), rnd); ^ ^ In file included from ./../gnutls_int.h:242:0, from ./opencdk.h:27, from misc.c:31: ./../gnutls_str.h:42:6: note: expected 'const char *' but argument is of type 'unsigned char *' void _gnutls_str_cat(char *dest, size_t dest_tot_size, const char *src); ^ misc.c:176:13: warning: pointer targets in passing argument 1 of '_open' differ in signedness [-Wpointer-sign] fd = _open(buf, _O_CREAT | _O_EXCL | _O_TEMPORARY | ^ In file included from ./../../gl/sys/stat.h:373:0, from misc.c:29: d:\usr\include\io.h:365:37: note: expected 'const char *' but argument is of type 'unsigned char *' _CRTIMP int __cdecl __MINGW_NOTHROW _open (const char*, int, ...); ^ I fixed the above by declaring buf[] and dst[] 'char', not 'unsigned char'. CC system.lo system.c:664:15: warning: pointer targets in assignment differ in signedness [-Wpointer-sign] output->data = dst; ^ I fixed this by a type cast. From ludo at gnu.org Wed Oct 5 14:30:33 2016 From: ludo at gnu.org (=?UTF-8?q?Ludovic=20Court=C3=A8s?=) Date: Wed, 5 Oct 2016 14:30:33 +0200 Subject: [gnutls-devel] [PATCH 3/3] guile: Implement session record ports using the Guile 2.2 API. In-Reply-To: <20161005123033.18891-1-ludo@gnu.org> References: <20161005123033.18891-1-ludo@gnu.org> Message-ID: <20161005123033.18891-4-ludo@gnu.org> This allows the Guile bindings to be built and used with Guile >= 2.1.4, which introduced a new port API. * guile/src/core.c (USING_GUILE_BEFORE_2_2): New macro. (session_record_port_type) [!USING_GUILE_BEFORE_2_2]: New definition. (read_from_session_record_port, write_to_session_record_port) (make_session_record_port) [!USING_GUILE_BEFORE_2_2]: New functions. Conditionalize the other same-named functions on USING_GUILE_BEFORE_2_2. (scm_init_gnutls_session_record_port_type): Use 'read_from_session_record_port' when !USING_GUILE_BEFORE_2_2. --- guile/src/core.c | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 82 insertions(+), 5 deletions(-) diff --git a/guile/src/core.c b/guile/src/core.c index a42ba76..605c91f 100644 --- a/guile/src/core.c +++ b/guile/src/core.c @@ -1,5 +1,5 @@ /* GnuTLS --- Guile bindings for GnuTLS. - Copyright (C) 2007-2014 Free Software Foundation, Inc. + Copyright (C) 2007-2014, 2016 Free Software Foundation, Inc. GnuTLS is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public @@ -15,7 +15,7 @@ License along with GnuTLS; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA */ -/* Written by Ludovic Court?s . */ +/* Written by Ludovic Court??s . */ #ifdef HAVE_CONFIG_H #include @@ -782,8 +782,18 @@ SCM_DEFINE (scm_gnutls_record_receive_x, "record-receive!", 2, 0, 0, #undef FUNC_NAME -/* The session record port type. */ +/* Whether we're using Guile < 2.2. */ +#define USING_GUILE_BEFORE_2_2 \ + (SCM_MAJOR_VERSION < 2 \ + || (SCM_MAJOR_VERSION == 2 && SCM_MINOR_VERSION == 0)) + +/* The session record port type. Guile 2.1.4 introduced a brand new port API, + so we have a separate implementation for these newer versions. */ +#if USING_GUILE_BEFORE_2_2 static scm_t_bits session_record_port_type; +#else +static scm_t_port_type *session_record_port_type; +#endif /* Return the session associated with PORT. */ #define SCM_GNUTLS_SESSION_RECORD_PORT_SESSION(_port) \ @@ -840,6 +850,8 @@ free_session_record_port (SCM port) #endif /* SCM_MAJOR_VERSION == 1 && SCM_MINOR_VERSION <= 8 */ +#if USING_GUILE_BEFORE_2_2 + /* Data passed to `do_fill_port ()'. */ typedef struct { @@ -937,7 +949,7 @@ write_to_session_record_port (SCM port, const void *data, size_t size) #undef FUNC_NAME /* Return a new session port for SESSION. */ -static inline SCM +static SCM make_session_record_port (SCM session) { SCM port; @@ -972,6 +984,67 @@ make_session_record_port (SCM session) return (port); } +#else /* !USING_GUILE_BEFORE_2_2 */ + +static size_t +read_from_session_record_port (SCM port, SCM dst, size_t start, size_t count) +#define FUNC_NAME "read_from_session_record_port" +{ + SCM session; + gnutls_session_t c_session; + char *read_buf; + ssize_t result; + + session = SCM_GNUTLS_SESSION_RECORD_PORT_SESSION (port); + c_session = scm_to_gnutls_session (session, 1, FUNC_NAME); + + read_buf = (char *) SCM_BYTEVECTOR_CONTENTS (dst) + start; + + /* XXX: Leave guile mode when SCM_GNUTLS_SESSION_TRANSPORT_IS_FD is + true? */ + result = gnutls_record_recv (c_session, read_buf, count); + if (EXPECT_FALSE (result < 0)) + /* FIXME: Silently swallowed! */ + scm_gnutls_error (result, FUNC_NAME); + + return result; +} +#undef FUNC_NAME + +static size_t +write_to_session_record_port (SCM port, SCM src, size_t start, size_t count) +#define FUNC_NAME "write_to_session_record_port" +{ + SCM session; + gnutls_session_t c_session; + char *data; + ssize_t result; + + session = SCM_GNUTLS_SESSION_RECORD_PORT_SESSION (port); + c_session = scm_to_gnutls_session (session, 1, FUNC_NAME); + data = (char *) SCM_BYTEVECTOR_CONTENTS (src) + start; + + result = gnutls_record_send (c_session, data, count); + + if (EXPECT_FALSE (result < 0)) + scm_gnutls_error (result, FUNC_NAME); + + return result; +} +#undef FUNC_NAME + +/* Return a new session port for SESSION. */ +static SCM +make_session_record_port (SCM session) +{ + return scm_c_make_port (session_record_port_type, + SCM_OPN | SCM_RDNG | SCM_WRTNG | SCM_BUF0, + SCM_UNPACK (session)); +} + +#endif /* !USING_GUILE_BEFORE_2_2 */ + + SCM_DEFINE (scm_gnutls_session_record_port, "session-record-port", 1, 0, 0, (SCM session), "Return a read-write port that may be used to communicate over " @@ -999,12 +1072,16 @@ SCM_DEFINE (scm_gnutls_session_record_port, "session-record-port", 1, 0, 0, #undef FUNC_NAME /* Create the session port type. */ -static inline void +static void scm_init_gnutls_session_record_port_type (void) { session_record_port_type = scm_make_port_type ("gnutls-session-port", +#if USING_GUILE_BEFORE_2_2 fill_session_record_port_input, +#else + read_from_session_record_port, +#endif write_to_session_record_port); /* Guile >= 1.9.3 doesn't need a custom mark procedure, and doesn't need a -- 2.10.0 From ludo at gnu.org Wed Oct 5 14:30:32 2016 From: ludo at gnu.org (=?UTF-8?q?Ludovic=20Court=C3=A8s?=) Date: Wed, 5 Oct 2016 14:30:32 +0200 Subject: [gnutls-devel] [PATCH 2/3] guile: Test 'set-session-transport-fd!'. In-Reply-To: <20161005123033.18891-1-ludo@gnu.org> References: <20161005123033.18891-1-ludo@gnu.org> Message-ID: <20161005123033.18891-3-ludo@gnu.org> * guile/tests/session-record-port.scm: Use 'set-session-transport-fd!' on the server side. --- guile/tests/session-record-port.scm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/guile/tests/session-record-port.scm b/guile/tests/session-record-port.scm index 0eafefa..8764d43 100644 --- a/guile/tests/session-record-port.scm +++ b/guile/tests/session-record-port.scm @@ -83,7 +83,7 @@ (let ((server (make-session connection-end/server))) (set-session-priorities! server priorities) - (set-session-transport-port! server (cdr socket-pair)) + (set-session-transport-fd! server (fileno (cdr socket-pair))) (let ((cred (make-anonymous-server-credentials)) (dh-params (import-dh-params "dh-parameters.pem"))) ;; Note: DH parameter generation can take some time. -- 2.10.0 From ludo at gnu.org Wed Oct 5 14:30:31 2016 From: ludo at gnu.org (=?UTF-8?q?Ludovic=20Court=C3=A8s?=) Date: Wed, 5 Oct 2016 14:30:31 +0200 Subject: [gnutls-devel] [PATCH 1/3] guile: Guile 2.x 'uniform-vector-read!' replacement returns 0 upon EOF. In-Reply-To: <20161005123033.18891-1-ludo@gnu.org> References: <20161005123033.18891-1-ludo@gnu.org> Message-ID: <20161005123033.18891-2-ludo@gnu.org> This problem was never hit in practice because our tests always got the non-EOF case. * guile/modules/gnutls/build/tests.scm (uniform-vector-read!) [guile-2]: Return 0 upon EOF. --- guile/modules/gnutls/build/tests.scm | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/guile/modules/gnutls/build/tests.scm b/guile/modules/gnutls/build/tests.scm index 2fe6be2..2c5c573 100644 --- a/guile/modules/gnutls/build/tests.scm +++ b/guile/modules/gnutls/build/tests.scm @@ -70,7 +70,8 @@ process exits upon failure." (else ;2.0 and 2.2 (use-modules (rnrs io ports) - (rnrs bytevectors)) + (rnrs bytevectors) + (ice-9 match)) (define-syntax-rule (define-replacement (name args ...) body ...) ;; Define a compatibility replacement for NAME, if needed. @@ -84,8 +85,10 @@ process exits upon failure." ;; and absent in 2.2. (define-replacement (uniform-vector-read! buf port) - (get-bytevector-n! port buf - 0 (bytevector-length buf))) + (match (get-bytevector-n! port buf + 0 (bytevector-length buf)) + ((? eof-object?) 0) + ((? integer? n) n))) (define-replacement (uniform-vector-write buf port) (put-bytevector port buf)))) -- 2.10.0 From ludo at gnu.org Wed Oct 5 14:30:30 2016 From: ludo at gnu.org (=?UTF-8?q?Ludovic=20Court=C3=A8s?=) Date: Wed, 5 Oct 2016 14:30:30 +0200 Subject: [gnutls-devel] [PATCH 0/3] Guile bindings port to forthcoming 2.2 series Message-ID: <20161005123033.18891-1-ludo@gnu.org> Hello, This patch series (actually the third patch of the series) ports the Guile bindings to the forthcoming Guile 2.2 series, currently known as 2.1, while retaining compatibility with 2.0 and 1.8. The API that the bindings expose is unchanged. Would it be possible to integrate in the next 3.4 release? I can write a 'NEWS' snippet. Thanks! Ludo'. Ludovic Court?s (3): guile: Guile 2.x 'uniform-vector-read!' replacement returns 0 upon EOF. guile: Test 'set-session-transport-fd!'. guile: Implement session record ports using the Guile 2.2 API. guile/modules/gnutls/build/tests.scm | 9 ++-- guile/src/core.c | 87 +++++++++++++++++++++++++++++++++--- guile/tests/session-record-port.scm | 2 +- 3 files changed, 89 insertions(+), 9 deletions(-) -- 2.10.0 From eliz at gnu.org Wed Oct 5 19:13:47 2016 From: eliz at gnu.org (Eli Zaretskii) Date: Wed, 05 Oct 2016 20:13:47 +0300 Subject: [gnutls-devel] Building a MinGW port of GnuTLS 3.4.15 In-Reply-To: <83y423l0cz.fsf@gnu.org> (message from Eli Zaretskii on Wed, 05 Oct 2016 10:29:48 +0300) References: <83vax8mkul.fsf@gnu.org> <83y423l0cz.fsf@gnu.org> Message-ID: <83bmyylnw4.fsf@gnu.org> > Date: Wed, 05 Oct 2016 10:29:48 +0300 > From: Eli Zaretskii > Cc: gnutls-devel at lists.gnutls.org > > > > 11.tests/utils.c lacks the 'sleep' function, which is needed for > > > MinGW, as the Windows runtime lacks it. > > > > Could that be something that mingw64 added as macro or so? > > It looks like MinGW64 has it as a function in their add-on runtime > library, so only mingw.org needs that. Actually, I see now that the very latest release of the mingw.org's runtime also has an inline definition of 'sleep', so maybe you should disregard this issue entirely. Thanks. From nmav at gnutls.org Wed Oct 5 20:32:29 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 05 Oct 2016 20:32:29 +0200 Subject: [gnutls-devel] [PATCH 0/3] Guile bindings port to forthcoming 2.2 series In-Reply-To: <20161005123033.18891-1-ludo@gnu.org> References: <20161005123033.18891-1-ludo@gnu.org> Message-ID: <1475692349.2060.1.camel@gnutls.org> On Wed, 2016-10-05 at 14:30 +0200, Ludovic Court?s wrote: > Hello, > > This patch series (actually the third patch of the series) ports the > Guile > bindings to the forthcoming Guile 2.2 series, currently known as 2.1, > while > retaining compatibility with 2.0 and 1.8.??The API that the bindings > expose > is unchanged. > Would it be possible to integrate in the next 3.4 release???I can > write a 'NEWS' snippet. Thank you Ludo! I've created a merge request to make it pass through all the CI tests, and I'll merge to 3.5.x and 3.4.x just after that. https://gitlab.com/gnutls/gnutls/merge_requests/103 (just send the news entry, and I'll include it) regards, Nikos From nmav at gnutls.org Wed Oct 5 20:45:42 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 05 Oct 2016 20:45:42 +0200 Subject: [gnutls-devel] Building a MinGW port of GnuTLS 3.4.15 In-Reply-To: <83y423l0cz.fsf@gnu.org> References: <83vax8mkul.fsf@gnu.org> <83y423l0cz.fsf@gnu.org> Message-ID: <1475693142.2060.10.camel@gnutls.org> On Wed, 2016-10-05 at 10:29 +0300, Eli Zaretskii wrote: > > > 3. libgnutls fails to link due to unresolved external rpl_fseek: > > > > > > ???????CCLD?????libgnutls.la > > > ?????opencdk/.libs/libminiopencdk.a(armor.o): In function > > > `armor_decode': > > > ?????d:\gnu\gnutls-3.4.15\lib\opencdk/armor.c:232: undefined > > > reference to `rpl_fseek' > > > ?????opencdk/.libs/libminiopencdk.a(stream.o): In function > > > `cdk_stream_seek': > > > ?????d:\gnu\gnutls-3.4.15\lib\opencdk/stream.c:1081: undefined > > > reference to `rpl_fseek' > > > ???I reported this for 3.3.11 back in Dec 2014. > > I do not know about this issue or what could trigger it. > I'm sure I explained it back then: This is because gl/libgnu.a does > not compile fseek replacement in src/gl/fseek.c and src/gl/fseeko.c > (unlike src/gl/libgnu.a), but gl/stdio.h defines fseek to rpl_fseek, > which is defined in src/gl/fseek.c. > Let me know if something is still unclear about this. Well, I understand what the issue is, what I have no idea how to address it on that particular case. Dealing with gnulib replacements is no fun, and the fact that it works with mingw64 does not add an incentive for me to figure that out. If you have a fix though I'll include it. > > 5. Test programs fail to run because they don't find the > > > libgnutls > > > ???shared library (which was not installed yet).??I fixed that by > > > ???manually adding the directories with the DLLs to PATH, but I > > > think > > > ???the test suite should do that, because if a previous version > > > of the > > > ???same DLL is installed, the tests will silently use it instead > > > of > > > ???the one in the source tree, which might cause incorrect > > > results and > > > ???subtle failures. > > That does not seem to be the case in the mingw builds under fedora > > as > > shown above. Could that be something related to mingw vs mingw64? > No, it can't, AFAIK.??It's a general Windows issue: a DLL is looked > according to certain rules and order described here: > ?https://msdn.microsoft.com/en- > us/library/windows/desktop/ms682586(v=vs.85).aspx > (only the "Desktop applications" part is relevant for this > discussion).??In a nutshell, Windows first looks in the same > directory > where the .exe file lives, then in the current directory, then along > the PATH (the other places are not relevant for this case).??The > just-built libgnutls DLL is in neither of these. > I don't think MinGW64 could affect this because this search happens > before the application code starts, it is part of the process of > loading the application by the Windows loader. My understanding of the latest builds with libtool and mingw64 was that there is a placeholder .exe generated in src/ which probably as you say do the lib resolution and the actual exe lives in src/.libs/. I don't have the system I cross compile to verify but the build I referred in the previous post was using that structure for executables. > > > ${prefix}/bin > > > ???directory, whereas it should install them in ${prefix}/lib, I > > > ???think. > > No opinion about that. I have no idea what are the conventions for > > win > > libraries. If you think that libdir is a better location I'll > > update > > the Makefile.am. > bindir is definitely wrong.??The other *.def files I have are in > libdir, so yes, I think it's a better place. Done, thanks. regards, Nikos From eliz at gnu.org Wed Oct 5 21:07:22 2016 From: eliz at gnu.org (Eli Zaretskii) Date: Wed, 05 Oct 2016 22:07:22 +0300 Subject: [gnutls-devel] Building a MinGW port of GnuTLS 3.4.15 In-Reply-To: <1475693142.2060.10.camel@gnutls.org> (message from Nikos Mavrogiannopoulos on Wed, 05 Oct 2016 20:45:42 +0200) References: <83vax8mkul.fsf@gnu.org> <83y423l0cz.fsf@gnu.org> <1475693142.2060.10.camel@gnutls.org> Message-ID: <8360p6limt.fsf@gnu.org> > From: Nikos Mavrogiannopoulos > Cc: gnutls-devel at lists.gnutls.org > Date: Wed, 05 Oct 2016 20:45:42 +0200 > > On Wed, 2016-10-05 at 10:29 +0300, Eli Zaretskii wrote: > > > > > 3. libgnutls fails to link due to unresolved external rpl_fseek: > > > > > > > > ???????CCLD?????libgnutls.la > > > > ?????opencdk/.libs/libminiopencdk.a(armor.o): In function > > > > `armor_decode': > > > > ?????d:\gnu\gnutls-3.4.15\lib\opencdk/armor.c:232: undefined > > > > reference to `rpl_fseek' > > > > ?????opencdk/.libs/libminiopencdk.a(stream.o): In function > > > > `cdk_stream_seek': > > > > ?????d:\gnu\gnutls-3.4.15\lib\opencdk/stream.c:1081: undefined > > > > reference to `rpl_fseek' > > > > ???I reported this for 3.3.11 back in Dec 2014. > > > I do not know about this issue or what could trigger it. > > I'm sure I explained it back then: This is because gl/libgnu.a does > > not compile fseek replacement in src/gl/fseek.c and src/gl/fseeko.c > > (unlike src/gl/libgnu.a), but gl/stdio.h defines fseek to rpl_fseek, > > which is defined in src/gl/fseek.c. > > Let me know if something is still unclear about this. > > Well, I understand what the issue is, what I have no idea how to > address it on that particular case. Dealing with gnulib replacements is > no fun, and the fact that it works with mingw64 does not add an > incentive for me to figure that out. If you have a fix though I'll > include it. The fix I used is a hack: I simply #include'd the necessary source files in ftell.c, which is compiled into libgnu.a. > > > That does not seem to be the case in the mingw builds under fedora > > > as > > > shown above. Could that be something related to mingw vs mingw64? > > No, it can't, AFAIK.??It's a general Windows issue: a DLL is looked > > according to certain rules and order described here: > > ?https://msdn.microsoft.com/en- > > us/library/windows/desktop/ms682586(v=vs.85).aspx > > (only the "Desktop applications" part is relevant for this > > discussion).??In a nutshell, Windows first looks in the same > > directory > > where the .exe file lives, then in the current directory, then along > > the PATH (the other places are not relevant for this case).??The > > just-built libgnutls DLL is in neither of these. > > I don't think MinGW64 could affect this because this search happens > > before the application code starts, it is part of the process of > > loading the application by the Windows loader. > > My understanding of the latest builds with libtool and mingw64 was that > there is a placeholder .exe generated in src/ which probably as you say > do the lib resolution and the actual exe lives in src/.libs/. I don't > have the system I cross compile to verify but the build I referred in > the previous post was using that structure for executables. Yes, this is what happens in my build as well. I don't know how to set that up, either. I do know that other projects that use libtol succeed in this, so maybe asking on the libtool list will help? Thanks. From ludo at gnu.org Wed Oct 5 21:56:56 2016 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Wed, 05 Oct 2016 21:56:56 +0200 Subject: [gnutls-devel] [PATCH 0/3] Guile bindings port to forthcoming 2.2 series In-Reply-To: <1475692349.2060.1.camel@gnutls.org> (Nikos Mavrogiannopoulos's message of "Wed, 05 Oct 2016 20:32:29 +0200") References: <20161005123033.18891-1-ludo@gnu.org> <1475692349.2060.1.camel@gnutls.org> Message-ID: <874m4q7enr.fsf@gnu.org> Hi Nikos, Nikos Mavrogiannopoulos skribis: > On Wed, 2016-10-05 at 14:30 +0200, Ludovic Court?s wrote: >> Hello, >> >> This patch series (actually the third patch of the series) ports the >> Guile >> bindings to the forthcoming Guile 2.2 series, currently known as 2.1, >> while >> retaining compatibility with 2.0 and 1.8.??The API that the bindings >> expose >> is unchanged. >> Would it be possible to integrate in the next 3.4 release???I can >> write a 'NEWS' snippet. > > Thank you Ludo! I've created a merge request to make it pass through > all the CI tests, and I'll merge to 3.5.x and 3.4.x just after that. > https://gitlab.com/gnutls/gnutls/merge_requests/103 Great. > (just send the news entry, and I'll include it) Here we go: --8<---------------cut here---------------start------------->8--- ** guile: Update code to the I/O port API of Guile >= 2.1.4 This makes sure the GnuTLS bindings will work with the forthcoming 2.2 stable series of Guile, of which 2.1 is a preview. --8<---------------cut here---------------end--------------->8--- Thank you! Ludo?. From nmav at gnutls.org Sun Oct 9 20:34:05 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 09 Oct 2016 20:34:05 +0200 Subject: [gnutls-devel] gnutls 3.5.5 Message-ID: <1476038045.32389.1.camel@gnutls.org> Hello,? ?I've just released gnutls 3.5.5. This is an enhancements and bugfix release for the 3.5.x branch. * Version 3.5.5 (released 2016-10-09) ** libgnutls: enhanced gnutls_certificate_set_ocsp_status_request_file() ???to allow importing multiple OCSP request files, one for each chain ???provided. ** libgnutls: The gnutls_certificate_set_key* functions return an ???index of the added chain. That index can be used either with ???gnutls_certificate_set_ocsp_status_request_file(), or with ???gnutls_certificate_get_crt_raw() and friends. ** libgnutls: Added SHA*, AES-GCM, AES-CCM and AES-CBC optimized implementations ???for the aarch64 architecture. Uses Andy Polyakov's assembly code. ** libgnutls: Ensure proper cleanups on gnutls_certificate_set_*key() ???failures due to key mismatch. This prevents leaks or double freeing ???on such failures. ** libgnutls: Increased the maximum size of the handshake message hash. ???This will allow the library to cope better with larger packets, as ???the ones offered by current TLS 1.3 drafts. ** libgnutls: Allow to use client certificates despite them containing ???disallowed algorithms for a session. That allows for example a client ???to use DSA-SHA1 due to his old DSA certificate, without requiring him ???to enable DSA-SHA1 (and thus make it acceptable for the server's certificate). ** libgnutls: Reverted AESNI code on x86 to earlier version as the ???latest version was creating position depending code. Added checks ???in the CI to detect position depending code early. ** guile: Update code to the I/O port API of Guile >= 2.1.4 ???This makes sure the GnuTLS bindings will work with the forthcoming 2.2 ???stable series of Guile, of which 2.1 is a preview. ** API and ABI modifications: gnutls_certificate_set_ocsp_status_request_function2: Added gnutls_session_ext_register: Added gnutls_session_supplemental_register: Added GNUTLS_E_PK_INVALID_PUBKEY: Added GNUTLS_E_PK_INVALID_PRIVKEY: Added 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.5.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.5/gnutls-3.5.5.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 Sun Oct 9 20:35:14 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 09 Oct 2016 20:35:14 +0200 Subject: [gnutls-devel] gnutls 3.4.16 Message-ID: <1476038114.32389.2.camel@gnutls.org> Hello,? ?I've just released gnutls 3.4.16. This is a bug fix release of the current stable branch. * Version 3.4.16 (released 2016-10-09) ** libgnutls: Ensure proper cleanups on gnutls_certificate_set_*key() ???failures due to key mismatch. This prevents leaks or double freeing ???on such failures. ** libgnutls: Increased the maximum size of the handshake message hash. ???This will allow the library to cope better with larger packets, as ???the ones offered by current TLS 1.3 drafts. ** libgnutls: Allow to use client certificates despite them containing ???disallowed algorithms for a session. That allows for example a client ???to use DSA-SHA1 due to his old DSA certificate, without requiring him ???to enable DSA-SHA1 (and thus make it acceptable for the server's certificate). ** guile: Backported all improvements from 3.5.x branch. ** guile: Update code to the I/O port API of Guile >= 2.1.4 ???This makes sure the GnuTLS bindings will work with the forthcoming 2.2 ???stable series of Guile, of which 2.1 is a preview. ** 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.16.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.16.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 Sun Oct 9 20:38:57 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 09 Oct 2016 20:38:57 +0200 Subject: [gnutls-devel] gnutls 3.3.25 Message-ID: <1476038337.32389.6.camel@gnutls.org> Hello,? ?I've just released gnutls 3.3.25. This is a bug-fix release on the previous stable branch which addresses GNUTLS-SA-2016-3, and backports some functionality used by recent samba versions. * Version 3.3.25 (released 2016-10-9) ** libgnutls: Ensure proper cleanups on gnutls_certificate_set_*key() ???failures due to key mismatch. This prevents leaks or double freeing ???on such failures. ** libgnutls: Corrected the comparison of the serial size in OCSP response. ???Previously the OCSP certificate check wouldn't verify the serial length ???and could succeed in cases it shouldn't (GNUTLS-SA-2016-3). ???Reported by Stefan Buehler. ** libgnutls: Fixes in gnutls_x509_crt_list_import2, which was ???ignoring flags if all certificates in the list fit within the ???initially allocated memory. ** libgnutls: Fix gnutls_pkcs12_simple_parse to always extract the complete chain, ???even when the extra_certs was non-null. Report and fix by Stefan S?rensen. ** libgnutls: Added support for decrypting PKCS#8 files which use the HMAC-SHA256 ???as PRF. ** libgnutls: Addressed issue with PKCS#11 signature generation on ECDSA ???keys. The signature is now written as unsigned integers into the DSASignatureValue ???structure. Previously signed integers could be written depending on what ???the underlying module would produce. Addresses #122. ** libgnutls: backported X.509 unique ID functionality from later versions. ** libgnutls: Increased the maximum size of the handshake message hash. ???This will allow the library to cope better with larger packets, as ???the ones offered by current TLS 1.3 drafts. ** API and ABI modifications: gnutls_x509_crt_set_issuer_unique_id: Added gnutls_x509_crt_set_subject_unique_id: Added 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.25.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ? ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.25.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 n.mavrogiannopoulos at gmail.com Tue Oct 11 20:20:09 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Tue, 11 Oct 2016 20:20:09 +0200 Subject: [gnutls-devel] simplified DH interface and rfc7919 Message-ID: Hello, I've introduced an interface to ease the setting of DH primes, by including the FFDHE primes and generators in gnutls. This allows to introduce a simple interface to set the actual prime used. I was considering enabling a prime according to a predefined security level by default for a server, but that could unfortunately introduce regressions to servers which intentionally don't enable any DHE primes. Is someone interested on the feature to provide a review? [0] regards, Nikos [0]. https://gitlab.com/gnutls/gnutls/merge_requests/106 From n.mavrogiannopoulos at gmail.com Tue Oct 18 18:47:01 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Tue, 18 Oct 2016 18:47:01 +0200 Subject: [gnutls-devel] concerning RFC5114 and gnutls Message-ID: <1476809221.2091.18.camel@gmail.com> Hi, ?There is a paper called "Measuring small subgroup attacks against Diffie-Hellman", which contained quite several inaccuracies regarding the support of RFC5114 primes in GnuTLS. Note that RFC5114 parameters although are published by IETF, are believed to be backdoored by NSA. I have only checked the inaccuracies mentioned for GnuTLS not other libraries or other claims of the paper. ?* It mentions: "RFC 5114 Support:?Yes, configurable" That's misleading since GnuTLS doesn't include the RFC5114 primes, there is no configuration option to enable them. GnuTLS among other options, allows the application to specify arbitrary primes/groups for Diffie-Hellman. That got translated into the document as RFC5114 primes are supported.? ?* It mentions: "GnuTLS allows users to enter their own parameters rather than using randomly generated ones." That's also inaccurate. GnuTLS even on its basic server examples instructs applications to generate random parameters: http://bit.ly/2eiRtZM That's also apparent in the manual text:?http://bit.ly/2eiTWDP So while I understand the authors' pressure to show discovered issues, they shouldn't do that by spreading misinformation. GnuTLS does not support the RFC5114 parameters, any more than it supports applications broadcasting their sessions keys over the Internet. There was indeed an example of a GnuTLS application which explicitly used the RFC5114 parameters with GnuTLS (Exim), but that was an intentional application choice (not to generate random ones and copy parameters from an IETF published document). That is why why we are improving the interfaces to no longer require the application developers to consider DH parameter generation at all [0]. [0].?https://lists.gnupg.org/pipermail/gnutls-devel/2016-October/008197.html regards, Nikos From n.mavrogiannopoulos at gmail.com Wed Oct 19 08:41:05 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Wed, 19 Oct 2016 08:41:05 +0200 Subject: [gnutls-devel] FOSDEM 2017: security devroom CfP Message-ID: Next FOSDEM [1] will, again, have a security devroom, this time on the topic of "Theoretical and practical vulnerabilities and mitigation techniques for widely used protocols and software". We'd like to invite submissions of talks and presentations from developers, security researchers and other interested representatives of open source and free software and hardware projects. This is the call for talks and presentations that will take place in the Security devroom at FOSDEM 2017. Our topic this year: The topic of this years FOSDEM Security Devroom covers protocol and implementation vulnerabilities (and mitigation techniques) for widely used Internet protocols and software, and theoretical and practical cryptographic algorithms and techniques. For up-to-date submission and event information: https://github.com/security-devroom/fosdem-2017 The security devroom will be held on Saturday 4th or Sunday 5th of February 2017 in Brussels, Belgium at ULB. Feel free to forward this announcement to any relevant FOSS project mailing list. [1] https://fosdem.org/2017/ PS. If you have questions or would like a chat on gnutls or openconnect vpn server, let me know if you are around fosdem. From stbuehler at lighttpd.net Fri Oct 21 20:08:07 2016 From: stbuehler at lighttpd.net (=?UTF-8?Q?Stefan_B=c3=bchler?=) Date: Fri, 21 Oct 2016 20:08:07 +0200 Subject: [gnutls-devel] gnutls 3.5.5 In-Reply-To: <1476038045.32389.1.camel@gnutls.org> References: <1476038045.32389.1.camel@gnutls.org> Message-ID: Hi, On 10/09/2016 08:34 PM, Nikos Mavrogiannopoulos wrote: > Hello, > I've just released gnutls 3.5.5. This is an enhancements and > bugfix release for the 3.5.x branch. > > * Version 3.5.5 (released 2016-10-09) > [...] > > ** libgnutls: The gnutls_certificate_set_key* functions return an > index of the added chain. That index can be used either with > gnutls_certificate_set_ocsp_status_request_file(), or with > gnutls_certificate_get_crt_raw() and friends. > [...] > > ** API and ABI modifications: > gnutls_certificate_set_ocsp_status_request_function2: Added > gnutls_session_ext_register: Added > gnutls_session_supplemental_register: Added > GNUTLS_E_PK_INVALID_PUBKEY: Added > GNUTLS_E_PK_INVALID_PRIVKEY: Added I'd like to point out that gnutls_certificate_set_key* had an API incompatible change: they now might return integers > 0 when successful, which breaks previously documented behaviour of always returning GNUTLS_E_SUCCESS (i.e. 0). I already pointed this out when reviewing the change, see: https://gitlab.com/gnutls/gnutls/merge_requests/65#note_15134877 Nikos, how do you want to handle this in the future? Should I always check for `>= GNUTLS_E_SUCCESS` in my code when testing for success? If so this should be properly reflected throughout the documentation. regards, Stefan From nmav at gnutls.org Sat Oct 22 09:57:13 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 22 Oct 2016 09:57:13 +0200 Subject: [gnutls-devel] gnutls 3.5.5 In-Reply-To: References: <1476038045.32389.1.camel@gnutls.org> Message-ID: <1477123033.3298.9.camel@gnutls.org> On Fri, 2016-10-21 at 20:08 +0200, Stefan B?hler wrote: > I'd like to point out that gnutls_certificate_set_key* had an API > incompatible change: they now might return integers > 0 when > successful, > which breaks previously documented behaviour of always returning > GNUTLS_E_SUCCESS (i.e. 0). > > I already pointed this out when reviewing the change, see: > > ????https://gitlab.com/gnutls/gnutls/merge_requests/65#note_15134877 > > Nikos, how do you want to handle this in the future? Should I always > check for `>= GNUTLS_E_SUCCESS` in my code when testing for success? > > If so this should be properly reflected throughout the documentation. Hi Stefan, ?Thanks for bringing that up. I went through the documentation and the related changes, and they are indeed not sufficient for the documentation of such a change. I've tried to improve it at: https://gitlab.com/gnutls/gnutls/merge_requests/123 (comments welcome) My suggestion as you will see above in the merge request is for applications to use if (retval < 0) to check for errors rather than check for a specific success code. That cannot of course change past applications. My expectation was that few software will check for equality with zero, mainly due to the examples which use the <0 pattern, and that even if they did, the fact that the first certificate index would be zero, will mitigate any issue (most applications load a single certificate). Do you think this is going to cause issues? Most likely we can still revert the change by introducing a flag in gnutls_certificate_set_flags() which can enable the behavior of returning indexes, instead of returning them by default. regards, Nikos From stbuehler at lighttpd.net Sat Oct 22 10:22:05 2016 From: stbuehler at lighttpd.net (=?UTF-8?Q?Stefan_B=c3=bchler?=) Date: Sat, 22 Oct 2016 10:22:05 +0200 Subject: [gnutls-devel] gnutls 3.5.5 In-Reply-To: <1477123033.3298.9.camel@gnutls.org> References: <1476038045.32389.1.camel@gnutls.org> <1477123033.3298.9.camel@gnutls.org> Message-ID: <725f93be-7ccb-e828-9295-528b740a3a02@stbuehler.de> Hi Nikos, On 10/22/2016 09:57 AM, Nikos Mavrogiannopoulos wrote: > On Fri, 2016-10-21 at 20:08 +0200, Stefan B?hler wrote: > >> I'd like to point out that gnutls_certificate_set_key* had an API >> incompatible change: they now might return integers > 0 when >> successful, >> which breaks previously documented behaviour of always returning >> GNUTLS_E_SUCCESS (i.e. 0). >> >> I already pointed this out when reviewing the change, see: >> >> https://gitlab.com/gnutls/gnutls/merge_requests/65#note_15134877 >> >> Nikos, how do you want to handle this in the future? Should I always >> check for `>= GNUTLS_E_SUCCESS` in my code when testing for success? >> >> If so this should be properly reflected throughout the documentation. > > Hi Stefan, > Thanks for bringing that up. I went through the documentation and the > related changes, and they are indeed not sufficient for the > documentation of such a change. I've tried to improve it at: > https://gitlab.com/gnutls/gnutls/merge_requests/123 > (comments welcome) Documenting the API changes seems ok, although I'm not sure everyone who needs to know about will find it there :) > My suggestion as you will see above in the merge request is for > applications to use if (retval < 0) to check for errors rather than > check for a specific success code. That cannot of course change past > applications. > > My expectation was that few software will check for equality with zero, > mainly due to the examples which use the <0 pattern, and that even if > they did, the fact that the first certificate index would be zero, will > mitigate any issue (most applications load a single certificate). I don't think I've ever read the generic Error handling section; I only read the sections for single functions. I think those should be adapted as well, they simply don't read like you have to expect positive values as success too: On success, GNUTLS_E_SUCCESS (0) is returned, otherwise an error code is returned. Maybe something like this instead: On success, a value equal to or greater than GNUTLS_E_SUCCESS (0) is returned, otherwise a negative error code is returned. Gonna be a large patch though :) > Do you think this is going to cause issues? Most likely we can still > revert the change by introducing a flag in > gnutls_certificate_set_flags() which can enable the behavior of > returning indexes, instead of returning them by default. It did cause issues with lighttpd2; as there is no release and I fixed it in git HEAD I don't see any remaining issues in this case. I can't speak for other applications :) regards, Stefan From thomas2.klute at uni-dortmund.de Sat Oct 22 11:30:28 2016 From: thomas2.klute at uni-dortmund.de (Thomas Klute) Date: Sat, 22 Oct 2016 11:30:28 +0200 Subject: [gnutls-devel] gnutls 3.5.5 In-Reply-To: <725f93be-7ccb-e828-9295-528b740a3a02@stbuehler.de> References: <1476038045.32389.1.camel@gnutls.org> <1477123033.3298.9.camel@gnutls.org> <725f93be-7ccb-e828-9295-528b740a3a02@stbuehler.de> Message-ID: Am 22.10.2016 um 10:22 schrieb Stefan B?hler: > On 10/22/2016 09:57 AM, Nikos Mavrogiannopoulos wrote: >> My suggestion as you will see above in the merge request is for >> applications to use if (retval < 0) to check for errors rather than >> check for a specific success code. That cannot of course change past >> applications. >> >> My expectation was that few software will check for equality with zero, >> mainly due to the examples which use the <0 pattern, and that even if >> they did, the fact that the first certificate index would be zero, will >> mitigate any issue (most applications load a single certificate). > > I don't think I've ever read the generic Error handling section; I only > read the sections for single functions. I think those should be adapted > as well, they simply don't read like you have to expect positive values > as success too: > > On success, GNUTLS_E_SUCCESS (0) is returned, otherwise an error > code is returned. > > Maybe something like this instead: > > On success, a value equal to or greater than GNUTLS_E_SUCCESS (0) > is returned, otherwise a negative error code is returned. > > Gonna be a large patch though :) > >> Do you think this is going to cause issues? Most likely we can still >> revert the change by introducing a flag in >> gnutls_certificate_set_flags() which can enable the behavior of >> returning indexes, instead of returning them by default. > > It did cause issues with lighttpd2; as there is no release and I fixed > it in git HEAD I don't see any remaining issues in this case. > > I can't speak for other applications :) It is definitely a problem for mod_gnutls, which has a lot of "(==|!=) GNUTLS_E_SUCCESS" status checks. The one function affected by this API change should be easy enough to change, but I don't want to do a pattern change over the whole code base. The risk of unintended side effects seems low, but I wouldn't want to take the chance. Generally I think this change violates the principle of least surprise: If the API documentation says "returns GNUTLS_E_SUCCESS or an error code", checking for equality is the obviously safe thing to do. Of course if GnuTLS explicitly guarantees that error codes will always be negative that's no less safe, but not something I would've expected based on the old API doc. If there are similar changes in the future, all functions should be listed under "API and ABI modifications" to make it as easy as possible to find affected code. Without a complete list I'm still worried I might have missed something broken by the change in 3.5.5. Best regards, Thomas From ametzler at bebt.de Sat Oct 22 11:58:03 2016 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 22 Oct 2016 11:58:03 +0200 Subject: [gnutls-devel] gnutls 3.5.5 In-Reply-To: <1477123033.3298.9.camel@gnutls.org> References: <1476038045.32389.1.camel@gnutls.org> <1477123033.3298.9.camel@gnutls.org> Message-ID: <20161022095803.cuf5zaolxqm6mrxy@argenau.bebt.de> On 2016-10-22 Nikos Mavrogiannopoulos wrote: > On Fri, 2016-10-21 at 20:08 +0200, Stefan B?hler wrote: > > I'd like to point out that gnutls_certificate_set_key* had an API > > incompatible change: they now might return integers > 0 when > > successful, > > which breaks previously documented behaviour of always returning > > GNUTLS_E_SUCCESS (i.e. 0). [...] > My expectation was that few software will check for equality with zero, > mainly due to the examples which use the <0 pattern, and that even if > they did, the fact that the first certificate index would be zero, will > mitigate any issue (most applications load a single certificate). > Do you think this is going to cause issues? Most likely we can still > revert the change by introducing a flag in > gnutls_certificate_set_flags() which can enable the behavior of > returning indexes, instead of returning them by default. Hello, I have just started browsing over . While checking for ret < 0 is common some software does not: exim: #define exim_gnutls_err_check(Label) do { \ if (rc != GNUTLS_E_SUCCESS) { return tls_error((Label), gnutls_strerror(rc), host); } } while (0) [...] rc = gnutls_certificate_set_x509_key_file(state->x509_cred, CS state->exp_tls_certificate, CS state->exp_tls_privatekey, GNUTLS_X509_FMT_PEM); exim_gnutls_err_check( string_sprintf("cert/key setup: cert=%s key=%s", state->exp_tls_certificate, state->exp_tls_privatekey)); samba: ret = gnutls_certificate_set_x509_key_file(tlsp->x509_cred, cert_file, key_file, GNUTLS_X509_FMT_PEM); if (ret != GNUTLS_E_SUCCESS) { DEBUG(0,("TLS failed to initialise certfile %s and keyfile %s - %s\n", cert_file, key_file, gnutls_strerror(ret))); talloc_free(tlsp); return NT_STATUS_CANT_ACCESS_DOMAIN_INFO; } cups: status = gnutls_certificate_set_x509_key_file(*credentials, crtfile, keyfile, GNUTLS_X509_FMT_PEM); } if (!status) status = gnutls_credentials_set(http->tls, GNUTLS_CRD_CERTIFICATE, *credentials); I have no idea whether these support loading multiple certificates. 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 Sat Oct 22 14:57:29 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 22 Oct 2016 14:57:29 +0200 Subject: [gnutls-devel] gnutls 3.5.5 In-Reply-To: <20161022095803.cuf5zaolxqm6mrxy@argenau.bebt.de> References: <1476038045.32389.1.camel@gnutls.org> <1477123033.3298.9.camel@gnutls.org> <20161022095803.cuf5zaolxqm6mrxy@argenau.bebt.de> Message-ID: <1477141049.27281.4.camel@gnutls.org> On Sat, 2016-10-22 at 11:58 +0200, Andreas Metzler wrote: > > My expectation was that few software will check for equality with > > zero, > > mainly due to the examples which use the <0 pattern, and that even > > if > > they did, the fact that the first certificate index would be zero, > > will > > mitigate any issue (most applications load a single certificate). > > > > Do you think this is going to cause issues? Most likely we can > > still > > revert the change by introducing a flag in > > gnutls_certificate_set_flags() which can enable the behavior of > > returning indexes, instead of returning them by default. > Hello, > > I have just started browsing over > +%5D*key>. > While checking for ret < 0 is common some software does not: Thank you for checking that. Maybe in that case we should explicitly enable returning indexes. An idea is to make: gnutls_certificate_set_flags(cred,?GNUTLS_CERTIFICATE_API_V2); and then all the?gnutls_certificate_set_*key will return indexes instead of zero. That would be an inconvenience, but it may be better to keep the API identical to prevent such issues. regards, Nikos From nmav at gnutls.org Sat Oct 22 15:02:38 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 22 Oct 2016 15:02:38 +0200 Subject: [gnutls-devel] gnutls 3.5.5 In-Reply-To: References: <1476038045.32389.1.camel@gnutls.org> <1477123033.3298.9.camel@gnutls.org> <725f93be-7ccb-e828-9295-528b740a3a02@stbuehler.de> Message-ID: <1477141358.27281.9.camel@gnutls.org> On Sat, 2016-10-22 at 11:30 +0200, Thomas Klute wrote: > Do you think this is going to cause issues? Most likely we can > > > still > > > revert the change by introducing a flag in > > > gnutls_certificate_set_flags() which can enable the behavior of > > > returning indexes, instead of returning them by default. > > It did cause issues with lighttpd2; as there is no release and I > > fixed > > it in git HEAD I don't see any remaining issues in this case. > > > > I can't speak for other applications :) > It is definitely a problem for mod_gnutls, which has a lot of > "(==|!=) > GNUTLS_E_SUCCESS" status checks. The one function affected by this > API > change should be easy enough to change, but I don't want to do a > pattern > change over the whole code base. The risk of unintended side effects > seems low, but I wouldn't want to take the chance. > > Generally I think this change violates the principle of least > surprise: > If the API documentation says "returns GNUTLS_E_SUCCESS or an error > code", checking for equality is the obviously safe thing to do. Of > course if GnuTLS explicitly guarantees that error codes will always > be > negative that's no less safe, but not something I would've expected > based on the old API doc. > > If there are similar changes in the future, all functions should be > listed under "API and ABI modifications" to make it as easy as > possible > to find affected code. Without a complete list I'm still worried I > might > have missed something broken by the change in 3.5.5. The intention is to make 3.5.x once stabilized API compatible with the 3.x series and ABI compatible with the 3.4 branch. Thus it may make sense to revert that patch and require the application to perform an extra step to obtain these indexes. btw. In any case that API should be useful to mod_gnutls as well, since it will provide a way to associate local OCSP responses with certificates, something that is not possible today (with versions prior to 3.5.5 at least). regards, Nikos From ametzler at bebt.de Sat Oct 22 18:01:26 2016 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 22 Oct 2016 18:01:26 +0200 Subject: [gnutls-devel] gnutls 3.5.5 In-Reply-To: <1477141049.27281.4.camel@gnutls.org> References: <1476038045.32389.1.camel@gnutls.org> <1477123033.3298.9.camel@gnutls.org> <20161022095803.cuf5zaolxqm6mrxy@argenau.bebt.de> <1477141049.27281.4.camel@gnutls.org> Message-ID: <20161022160126.7i4iyit67jzxxync@argenau.bebt.de> On 2016-10-22 Nikos Mavrogiannopoulos wrote: [...] > That would be an inconvenience, but it may be better to keep the API > identical to prevent such issues. Yes, I think that would be the right thing to do. 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 Sun Oct 23 12:13:27 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 23 Oct 2016 12:13:27 +0200 Subject: [gnutls-devel] gnutls 3.5.5 In-Reply-To: <20161022160126.7i4iyit67jzxxync@argenau.bebt.de> References: <1476038045.32389.1.camel@gnutls.org> <1477123033.3298.9.camel@gnutls.org> <20161022095803.cuf5zaolxqm6mrxy@argenau.bebt.de> <1477141049.27281.4.camel@gnutls.org> <20161022160126.7i4iyit67jzxxync@argenau.bebt.de> Message-ID: <1477217607.10330.1.camel@gnutls.org> On Sat, 2016-10-22 at 18:01 +0200, Andreas Metzler wrote: > On 2016-10-22 Nikos Mavrogiannopoulos wrote: > [...] > > > > That would be an inconvenience, but it may be better to keep the > > API > > identical to prevent such issues. > Yes, I think that would be the right thing to do. My previously proposed reversal is at: https://gitlab.com/gnutls/gnutls/merge_requests/123 regards, Nikos From ametzler at bebt.de Wed Oct 26 13:12:13 2016 From: ametzler at bebt.de (Andreas Metzler) Date: Wed, 26 Oct 2016 13:12:13 +0200 Subject: [gnutls-devel] interoperability issue 3.3.x vs. 3.5.5 Message-ID: <20161026111213.34sbdxl3g3dzdyck@argenau.bebt.de> Hello, a gnutls server running 3.5.5 is not accessible by a client using GnuTLS 3.3.x. This popped up in Debian https://bugs.debian.org/841723 against 3.3.8 vs 3.5.5 but also applies to 3.3.25/3.5.5. It is reproducible with gnutls-serv and gnutls-cli without any special options (just --x509keyfile/--x509certfile). git bisect finds 6b76e0c899b1ff08df9bd9b41588f771f050be89 as the first bad commit. the failing client (3.3.8) log ends with: |<3>| ASSERT: gnutls_buffers.c:1104 |<10>| READ: Got 5 bytes from 0x4 |<10>| READ: read 5 bytes from 0x4 |<10>| RB: Have 0 bytes into buffer. Adding 5 bytes. |<10>| RB: Requested 5 bytes |<5>| REC[0x1ffb020]: SSL 3.3 Handshake packet received. Epoch 0, length: 445 |<5>| REC[0x1ffb020]: Expected Packet Handshake(22) |<5>| REC[0x1ffb020]: Received Packet Handshake(22) with length: 445 |<10>| READ: Got 445 bytes from 0x4 |<10>| READ: read 445 bytes from 0x4 |<10>| RB: Have 5 bytes into buffer. Adding 445 bytes. |<10>| RB: Requested 450 bytes |<5>| REC[0x1ffb020]: Decrypted Packet[2] Handshake(22) with length: 445 |<13>| BUF[REC]: Inserted 445 bytes of Data(22) |<4>| HSK[0x1ffb020]: SERVER KEY EXCHANGE (12) was received. Length 441[441], frag offset 0, frag length: 441, sequence: 0 |<3>| ASSERT: gnutls_buffers.c:1095 |<3>| ASSERT: gnutls_handshake.c:1428 |<3>| ASSERT: status_request.c:600 |<3>| ASSERT: gnutls_handshake.c:2728 *** Fatal error: An unexpected TLS handshake packet was received. |<5>| REC: Sending Alert[2|10] - Unexpected message |<5>| REC[0x1ffb020]: Preparing Packet Alert(21) with length: 2 and min pad: 0 |<9>| ENC[0x1ffb020]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 |<11>| WRITE: enqueued 7 bytes for 0x4. Total 7 bytes. |<11>| WRITE FLUSH: 7 bytes in buffer. |<11>| WRITE: wrote 7 bytes, 0 bytes left. |<5>| REC[0x1ffb020]: Sent Packet[2] Alert(21) in epoch 0 and length: 7 *** Handshake has failed GnuTLS error: An unexpected TLS handshake packet was received. |<5>| REC[0x1ffb020]: Start of epoch cleanup |<5>| REC[0x1ffb020]: End of epoch cleanup |<5>| REC[0x1ffb020]: Epoch #0 freed |<5>| REC[0x1ffb020]: Epoch #1 freed Server side log: |<5>| REC[0x55ce1ad22430]: SSL 3.3 Alert packet received. Epoch 0, length: 2 |<5>| REC[0x55ce1ad22430]: Expected Packet Handshake(22) |<5>| REC[0x55ce1ad22430]: Received Packet Alert(21) with length: 2 |<10>| READ: Got 2 bytes from 0x5 |<10>| READ: read 2 bytes from 0x5 |<10>| RB: Have 5 bytes into buffer. Adding 2 bytes. |<10>| RB: Requested 7 bytes |<5>| REC[0x55ce1ad22430]: Decrypted Packet[1] Alert(21) with length: 2 |<5>| REC[0x55ce1ad22430]: Alert[2|10] - Unexpected message - was received |<3>| ASSERT: record.c[record_add_to_buffers]:782 |<3>| ASSERT: record.c[record_add_to_buffers]:789 |<3>| ASSERT: record.c[_gnutls_recv_in_buffers]:1323 |<3>| ASSERT: buffers.c[_gnutls_handshake_io_recv_int]:1414 |<3>| ASSERT: handshake.c[_gnutls_recv_handshake]:1448 |<3>| ASSERT: handshake.c[handshake_server]:3277 Error in handshake |<5>| REC: Sending Alert[2|80] - Internal error |<5>| REC[0x55ce1ad22430]: Preparing Packet Alert(21) with length: 2 and min pad: 0 |<9>| ENC[0x55ce1ad22430]: cipher: NULL, MAC: MAC-NULL, Epoch: 0 |<11>| WRITE: enqueued 7 bytes for 0x5. Total 7 bytes. |<11>| WRITE FLUSH: 7 bytes in buffer. |<11>| WRITE: wrote 7 bytes, 0 bytes left. |<5>| REC[0x55ce1ad22430]: Sent Packet[6] Alert(21) in epoch 0 and length: 7 |<5>| REC[0x55ce1ad22430]: Start of epoch cleanup |<5>| REC[0x55ce1ad22430]: End of epoch cleanup |<5>| REC[0x55ce1ad22430]: Epoch #0 freed |<5>| REC[0x55ce1ad22430]: Epoch #1 freed Comparing successful and failing logs shows an addition of client: |<4>| EXT[0x00]: Parsing extension 'STATUS REQUEST/5' (0 bytes) server: |<4>| EXT[0x0]: Sending extension OCSP Status Request (0 bytes) 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 stbuehler at lighttpd.net Wed Oct 26 14:52:42 2016 From: stbuehler at lighttpd.net (=?UTF-8?Q?Stefan_B=c3=bchler?=) Date: Wed, 26 Oct 2016 14:52:42 +0200 Subject: [gnutls-devel] interoperability issue 3.3.x vs. 3.5.5 In-Reply-To: <20161026111213.34sbdxl3g3dzdyck@argenau.bebt.de> References: <20161026111213.34sbdxl3g3dzdyck@argenau.bebt.de> Message-ID: Hi, On 10/26/2016 01:12 PM, Andreas Metzler wrote: > Hello, > > a gnutls server running 3.5.5 is not accessible by a client using GnuTLS > 3.3.x. This popped up in Debian https://bugs.debian.org/841723 against > 3.3.8 vs 3.5.5 but also applies to 3.3.25/3.5.5. It is reproducible with > gnutls-serv and gnutls-cli without any special options (just > --x509keyfile/--x509certfile). I think the original bug in https://bugs.debian.org/841723 could be about something else; gnutls-cli.out in message #40 shows receiving "554 S" instead of a ServerHello - the reporter probably didn't actually use --starttls-proto=smtp, but without the real log it is hard to say. That said I also reproduced the issue; the fault is with the older version, as it requires a CertificateStatus message if ServerHello included the (empty) "status_request" extension, although RFC 6066 explicitly states: Note that a server MAY also choose not to send a "CertificateStatus" message, even if has received a "status_request" extension in the client hello message and has sent a "status_request" extension in the server hello message. So the new gnutls code doesn't do anything wrong by replying with an empty "status_request" extension, even if there is no chance of sending a CertificateStatus message, just the old versions can't handle it. The new version handles this by passing optional = 1 in the call to _gnutls_recv_handshake(GNUTLS_HANDSHAKE_CERTIFICATE_STATUS) in status_request.c. regards, Stefan From nmav at gnutls.org Wed Oct 26 15:46:19 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 26 Oct 2016 15:46:19 +0200 Subject: [gnutls-devel] interoperability issue 3.3.x vs. 3.5.5 In-Reply-To: References: <20161026111213.34sbdxl3g3dzdyck@argenau.bebt.de> Message-ID: On Wed, Oct 26, 2016 at 2:52 PM, Stefan B?hler wrote: > Hi, > On 10/26/2016 01:12 PM, Andreas Metzler wrote: >> Hello, >> a gnutls server running 3.5.5 is not accessible by a client using GnuTLS >> 3.3.x. This popped up in Debian https://bugs.debian.org/841723 against >> 3.3.8 vs 3.5.5 but also applies to 3.3.25/3.5.5. It is reproducible with >> gnutls-serv and gnutls-cli without any special options (just >> --x509keyfile/--x509certfile). > > I think the original bug in https://bugs.debian.org/841723 could be > about something else; gnutls-cli.out in message #40 shows receiving "554 > S" instead of a ServerHello - the reporter probably didn't actually use > --starttls-proto=smtp, but without the real log it is hard to say. > That said I also reproduced the issue; the fault is with the older > version, as it requires a CertificateStatus message if ServerHello > included the (empty) "status_request" extension, although RFC 6066 > explicitly states: > > Note that a server MAY also choose not to send a "CertificateStatus" > message, even if has received a "status_request" extension in the > client hello message and has sent a "status_request" extension in the > server hello message. Right. That was identified and fixed in the 3.4.x branch but it was never backported to 3.3.x. I've done it just now at: https://gitlab.com/gnutls/gnutls/compare/aaddef3787a7df83dc2bcfb3bd510535f1601b46...417a7934d66f907c1bb5a2cd285782345625b1ac > So the new gnutls code doesn't do anything wrong by replying with an > empty "status_request" extension, even if there is no chance of sending > a CertificateStatus message, just the old versions can't handle it. I think that I should revert that behavior, and make sure that the releases are compatible between them. An even better move would be to add an interop check between 3.3.x and the latest master. regards, Nikos From nmav at gnutls.org Wed Oct 26 18:05:51 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 26 Oct 2016 18:05:51 +0200 Subject: [gnutls-devel] interoperability issue 3.3.x vs. 3.5.5 In-Reply-To: References: <20161026111213.34sbdxl3g3dzdyck@argenau.bebt.de> Message-ID: On Wed, Oct 26, 2016 at 3:46 PM, Nikos Mavrogiannopoulos wrote: >> So the new gnutls code doesn't do anything wrong by replying with an >> empty "status_request" extension, even if there is no chance of sending >> a CertificateStatus message, just the old versions can't handle it. > I think that I should revert that behavior, and make sure that the > releases are compatible between them. An even better move would be to > add an interop check between 3.3.x and the latest master. It was not as straight-forward as I initially thought, but it was possible to revert the 3.5.5 behavior and keeping the semantics. An initial attempt is at: https://gitlab.com/gnutls/gnutls/merge_requests/128 regards, Nikos From n.mavrogiannopoulos at gmail.com Mon Oct 31 09:31:58 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Mon, 31 Oct 2016 09:31:58 +0100 Subject: [gnutls-devel] delaying the initialization of random generator Message-ID: Hi, Since version 3.5.3, gnutls uses the getrandom() system call on the kernels that it is available, replacing the /dev/urandom based initialization of the included RNG. However, that comes with few side-effects. Because getrandom() blocks prior to the linux kernel RNG being initialized (unlike /dev/urandom), that means that applications that load early on boot and link with gnutls will be blocked until that kernel initialization. This has been already been seen in VMs, on the cases linked by [0]. A work-around that can be applied to gnutls is delaying the internal RNG initialization to the first call of gnutls_rnd(). That will allow applications which do not use the RNG immediately to load faster, while on the other hand introduces some complexity and does not address the problem when for example the system is in FIPS140-2 mode which requires some on-library-load tests which need to call gnutls_rnd(). -(here I'm also worried about future additions that may require random numbers on library load and negate any fixes for that issue). Any opinions on that? The bottom line, is that we cannot completely solve the blocking issue, but we can improve it on the occasions mentioned above. Should we try and introduce some complexity, or should we ignore it and expect the kernel to address it? regards, Nikos [0]. https://gitlab.com/gnutls/gnutls/merge_requests/111 From jaak.ristioja at cyber.ee Mon Oct 31 09:58:50 2016 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Mon, 31 Oct 2016 10:58:50 +0200 Subject: [gnutls-devel] delaying the initialization of random generator In-Reply-To: References: Message-ID: <577a55cc-536f-107c-aa9c-821dd5bbc2cb@cyber.ee> On 31.10.2016 10:31, Nikos Mavrogiannopoulos wrote: > Hi, > Since version 3.5.3, gnutls uses the getrandom() system call on the > kernels that it is available, replacing the /dev/urandom based > initialization of the included RNG. However, that comes with few > side-effects. Because getrandom() blocks prior to the linux kernel RNG > being initialized (unlike /dev/urandom), that means that applications > that load early on boot and link with gnutls will be blocked until > that kernel initialization. > > This has been already been seen in VMs, on the cases linked by [0]. A > work-around that can be applied to gnutls is delaying the internal RNG > initialization to the first call of gnutls_rnd(). That will allow > applications which do not use the RNG immediately to load faster, > while on the other hand introduces some complexity and does not > address the problem when for example the system is in FIPS140-2 mode > which requires some on-library-load tests which need to call > gnutls_rnd(). -(here I'm also worried about future additions that may > require random numbers on library load and negate any fixes for that > issue). > > Any opinions on that? The bottom line, is that we cannot completely > solve the blocking issue, but we can improve it on the occasions > mentioned above. Should we try and introduce some complexity, or > should we ignore it and expect the kernel to address it? I'm no big expert on this issue, but I think that by delaying the blockage from link-time to application logic one risks blocking in mission critical application code. In my opinion, it would be better to let the kernel address it for both physical machines and VMs. I suspect that sooner or later they will (have to) address this anyway, e.g. by using paravirtualized RNGs in VMs or, on physical machines allow initialization of the entropy pool from some hardware RNG, or similar. Best regards, Jaak Ristioja