From nmav at gnutls.org Thu May 1 00:03:48 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 01 May 2014 00:03:48 +0200 Subject: [gnutls-help] "x509.c", line 2894: warning: argument #3 is incompatible with prototype: In-Reply-To: <1596608598.47451.1398885101835.JavaMail.vpopmail@webmail2.networksolutionsemail.com> References: <1655514655.45280.1398883035932.JavaMail.vpopmail@webmail2.networksolutionsemail.com> <536144AC.5000205@fifthhorseman.net> <1596608598.47451.1398885101835.JavaMail.vpopmail@webmail2.networksolutionsemail.com> Message-ID: <1398895428.30886.12.camel@nomad.lan> On Wed, 2014-04-30 at 15:11 -0400, dev wrote: $ diff ./lib/includes/gnutls/x509-ext.h_backup ./lib/includes/gnutls/x509-ext.h 65c65 > < unsigned int *type, > --- > > gnutls_x509_subject_alt_name_t > *type, Unfortunately that can't be changed as it is already part of the API. There could be a cast inside the function though. > Also when I run into little things like this : > CCLD libgnutls-openssl.la > Undefined first referenced > symbol in file > nanosleep .libs/gnutls_openssl.o > (symbol belongs to implicit dependency /lib/64/librt.so.1) > ld: fatal: symbol referencing errors. > No output written to .libs/libgnutls-openssl.so.27.0.2 > gmake[3]: *** [libgnutls-openssl.la] Error 2 > I know that the fix won't be in the code because nanosleep on Solaris > needs -lrt in the link stage and I have to hack Makefile like so : There is a check for nanosleep in librt in configure.ac which should define NEEDS_LIBRT, and Makefile.am should append -lrt. What was the output of the check? You should see NEEDS_LIBRT_TRUE= something in your config.log, and the link flag should be in LTLIBRT. regards, Nikos From nmav at gnutls.org Thu May 1 00:09:37 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 01 May 2014 00:09:37 +0200 Subject: [gnutls-help] "x509.c", line 2894: warning: argument #3 is incompatible with prototype: In-Reply-To: <1563781636.57798.1398894343505.JavaMail.vpopmail@webmail2.networksolutionsemail.com> References: <1655514655.45280.1398883035932.JavaMail.vpopmail@webmail2.networksolutionsemail.com> <536144AC.5000205@fifthhorseman.net> <1563781636.57798.1398894343505.JavaMail.vpopmail@webmail2.networksolutionsemail.com> Message-ID: <1398895777.30886.17.camel@nomad.lan> On Wed, 2014-04-30 at 17:45 -0400, dev wrote: > I have hit a head scratch moment where I am trying to figure out > what the intent was in src/libopts/compat/compat.h : > > gmake[4]: Entering directory > `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_001/src/libopts' > CC libopts_la-libopts.lo > "./compat/compat.h", line 188: error: invalid type combination I don't quite get why the compiler complains, but I've forwarded your mail to the autogen author of which libopts is part of. Note that the libopts/ and gl/ directories are from the autogen and gnulib projects, and are mostly auto-generated, so any patches there have to be forwarded to the respective projects or will be overwritten on the next update. regards, Nikos From dev at cor0.com Thu May 1 07:13:18 2014 From: dev at cor0.com (dev) Date: Thu, 1 May 2014 01:13:18 -0400 (EDT) Subject: [gnutls-help] "certtool-cfg.c", line 1022: error: void function cannot return value Message-ID: <1065482677.80864.1398921199149.JavaMail.vpopmail@webmail2.networksolutionsemail.com> I apologize .. but I have a nearly perfectly clean compile here with Oracle Studio 12.3 compiler and I am using c99 and -Xc pedantic and strict compliance mode. So, here is another of those little nits : CC certtool-cfg.lo "certtool-cfg.c", line 1022: error: void function cannot return value "certtool-cfg.c", line 1133: error: void function cannot return value c99: acomp failed for certtool-cfg.c gmake[4]: *** [certtool-cfg.lo] Error 1 gmake[4]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/src' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/src' gmake[2]: *** [all] Error 2 gmake[2]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002' gmake: *** [all] Error 2 node002$ diff -u src/certtool-cfg.c_backup src/certtool-cfg.c --- src/certtool-cfg.c_backup Wed Apr 16 16:52:40 2014 +++ src/certtool-cfg.c Thu May 1 05:02:07 2014 @@ -1019,7 +1019,7 @@ void get_serial(unsigned char* serial, size_t * size) { - return get_rand_int_value(serial, size, cfg.serial, "Enter the certificate's serial number in decimal"); + get_rand_int_value(serial, size, cfg.serial, "Enter the certificate's serial number in decimal"); } static @@ -1130,7 +1130,7 @@ void get_crl_number(unsigned char* serial, size_t * size) { - return get_rand_int_value(serial, size, cfg.crl_number, "CRL Number"); + get_rand_int_value(serial, size, cfg.crl_number, "CRL Number"); } int get_path_len(void) That fixes that one. With -Xc and all warnings and using the C99 compiler I am seeing all manner of little things, such as : CC cli-debug.o "cli-debug.c", line 86: warning: dubious escape: \% So I will just keep doing what I am doing here. Mostly cosmetic and without doing any damage. I switched over to using c99 because of the oddity with stdbool.h which requires the define symbol _STDC_C99. So I switched over to using CC=/opt/solarisstudio12.3/bin/c99 as well as obscenely stringent CFLAGS and at the moment everything compiles and the manpages are being created. The real test here will be the test suite. No pun intended. Dennis ps: I do have a set of patches. All minor. However I will wait until I see the testsuite run. From nmav at gnutls.org Thu May 1 16:19:50 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 01 May 2014 16:19:50 +0200 Subject: [gnutls-help] "certtool-cfg.c", line 1022: error: void function cannot return value In-Reply-To: <1065482677.80864.1398921199149.JavaMail.vpopmail@webmail2.networksolutionsemail.com> References: <1065482677.80864.1398921199149.JavaMail.vpopmail@webmail2.networksolutionsemail.com> Message-ID: <1398953990.13466.0.camel@nomad.lan> On Thu, 2014-05-01 at 01:13 -0400, dev wrote: > I apologize .. but I have a nearly perfectly clean compile here with > Oracle Studio 12.3 compiler and I am using c99 and -Xc pedantic and > strict compliance mode. > > So, here is another of those little nits : > "certtool-cfg.c", line 1022: error: void function cannot return value > "certtool-cfg.c", line 1133: error: void function cannot return value Thanks, it's now fixed. regards, Nikos From jgh at wizmail.org Thu May 1 17:39:04 2014 From: jgh at wizmail.org (Jeremy Harris) Date: Thu, 01 May 2014 16:39:04 +0100 Subject: [gnutls-help] segfault in gnutls_handshake Message-ID: <53626A98.4010004@wizmail.org> gnutls-3.1.16-1.fc20.x86_64 Can anyone point where to go next with this: Program terminated with signal SIGSEGV, Segmentation fault. #0 __GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:66 66 unsigned int type = PTHREAD_MUTEX_TYPE_ELISION (mutex); (gdb) bt #0 __GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:66 #1 0x00000030a944520c in gnutls_system_mutex_lock (priv=) at system.c:234 #2 0x00000030a94d7b22 in wrap_nettle_rnd (_ctx=, level=0, data=0x96818c, datasize=28) at rnd.c:432 #3 0x00000030a942c978 in _gnutls_rnd (len=28, data=0x96818c, level=GNUTLS_RND_NONCE) at ./random.h:38 #4 _gnutls_tls_create_random (dst=0x968188 "SbeE") at gnutls_handshake.c:190 #5 0x00000030a942ccd3 in _gnutls_set_client_random (session=0x0, rnd=0x0) at gnutls_handshake.c:219 #6 0x00000030a9430048 in _gnutls_send_client_hello (again=, session=0x968140) at gnutls_handshake.c:1940 #7 _gnutls_send_hello (session=session at entry=0x968140, again=) at gnutls_handshake.c:2134 #8 0x00000030a94306d0 in _gnutls_handshake_client (session=0x968140) at gnutls_handshake.c:2618 #9 gnutls_handshake (session=0x968140) at gnutls_handshake.c:2480 #10 0x000000000047a015 in tls_client_start () #11 0x000000000049b99a in smtp_deliver () #12 0x000000000049e77c in smtp_transport_entry () #13 0x00000000004271f5 in do_remote_deliveries () #14 0x000000000042a914 in deliver_message () #15 0x0000000000453571 in queue_run () #16 0x0000000000434326 in main () I can reproduce this on demand. It is the first TLS connection this process makes; a previous child of the mutual parent has made a good connection, closed it and terminated. -- Thanks, Jeremy From polinaa at image-vault.com Thu May 1 19:10:22 2014 From: polinaa at image-vault.com (Polina Abramov) Date: Thu, 1 May 2014 17:10:22 +0000 Subject: [gnutls-help] GNUTLS_E_PREMATURE_TERMINATION error Message-ID: <846200f2b66646dab7c05bdc03384efb@DM2PR08MB527.namprd08.prod.outlook.com> Hi All, I need help with GNUTLS_E_PREMATURE_TERMINATION error code that is returned by gnutls_record_recv() function. I have a simple smtp client that all it does is sending emails. When I use gmail or hotmail smtp servers I keep getting GNUTLS_E_PREMATURE_TERMINATION and I can't figure out what causes it. I don't get this error with yahoo smtp server. Any ideas about what can be a reason for GNUTLS_E_PREMATURE_TERMINATION error? Thanks a lot! P.A. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Thu May 1 19:42:00 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 01 May 2014 19:42:00 +0200 Subject: [gnutls-help] segfault in gnutls_handshake In-Reply-To: <53626A98.4010004@wizmail.org> References: <53626A98.4010004@wizmail.org> Message-ID: <1398966120.32280.2.camel@nomad.lan> On Thu, 2014-05-01 at 16:39 +0100, Jeremy Harris wrote: > gnutls-3.1.16-1.fc20.x86_64 > > Can anyone point where to go next with this: > Program terminated with signal SIGSEGV, Segmentation fault. > #0 __GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:66 The mutex cannot be null after gnutls_global_init() is called. Do you use gnutls from a dlopened object that links to pthreads while the main application isn't linked to it (i.e., could there be a mix of the glibc pthread stubs and the normal pthread functions)? regards, Nikos From nmav at gnutls.org Thu May 1 19:44:03 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 01 May 2014 19:44:03 +0200 Subject: [gnutls-help] GNUTLS_E_PREMATURE_TERMINATION error In-Reply-To: <846200f2b66646dab7c05bdc03384efb@DM2PR08MB527.namprd08.prod.outlook.com> References: <846200f2b66646dab7c05bdc03384efb@DM2PR08MB527.namprd08.prod.outlook.com> Message-ID: <1398966243.32280.4.camel@nomad.lan> On Thu, 2014-05-01 at 17:10 +0000, Polina Abramov wrote: > Hi All, > I need help with GNUTLS_E_PREMATURE_TERMINATION error code that is > returned by gnutls_record_recv() function. > I have a simple smtp client that all it does is sending emails. When > I use gmail or hotmail smtp servers I keep getting > GNUTLS_E_PREMATURE_TERMINATION and I can?t figure out what causes it. > I don?t get this error with yahoo smtp server. Hello, The peer has terminated the TLS session using a TCP RST (i.e., called close()). Since gnutls cannot distinguish that termination from an attacker terminating the session it warns you with this error code. regards, Nikos From polinaa at image-vault.com Thu May 1 20:20:40 2014 From: polinaa at image-vault.com (Polina Abramov) Date: Thu, 1 May 2014 18:20:40 +0000 Subject: [gnutls-help] GNUTLS_E_PREMATURE_TERMINATION error In-Reply-To: <1398966243.32280.4.camel@nomad.lan> References: <846200f2b66646dab7c05bdc03384efb@DM2PR08MB527.namprd08.prod.outlook.com> <1398966243.32280.4.camel@nomad.lan> Message-ID: <8d5a6abbdb004c4186538f0737414c40@DM2PR08MB527.namprd08.prod.outlook.com> Thanks! I ran wireshark and it looks like at some point my client issues Encrypted Alert 21. Is it something I should be worried about? Based on my check this alert means that the decryption has failed and that could be a reason for server to terminate the connection. Is my understanding correct? The question is why would the decryption fail after it had already received and successfully decrypted previous data. Any ideas? P.A. -----Original Message----- From: Nikos Mavrogiannopoulos [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos Sent: Thursday, May 01, 2014 1:44 PM To: Polina Abramov Cc: gnutls-help at lists.gnutls.org Subject: Re: [gnutls-help] GNUTLS_E_PREMATURE_TERMINATION error On Thu, 2014-05-01 at 17:10 +0000, Polina Abramov wrote: > Hi All, > I need help with GNUTLS_E_PREMATURE_TERMINATION error code that is > returned by gnutls_record_recv() function. > I have a simple smtp client that all it does is sending emails. When > I use gmail or hotmail smtp servers I keep getting > GNUTLS_E_PREMATURE_TERMINATION and I can?t figure out what causes it. > I don?t get this error with yahoo smtp server. Hello, The peer has terminated the TLS session using a TCP RST (i.e., called close()). Since gnutls cannot distinguish that termination from an attacker terminating the session it warns you with this error code. regards, Nikos -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgh at wizmail.org Thu May 1 21:09:58 2014 From: jgh at wizmail.org (Jeremy Harris) Date: Thu, 01 May 2014 20:09:58 +0100 Subject: [gnutls-help] segfault in gnutls_handshake In-Reply-To: <1398966120.32280.2.camel@nomad.lan> References: <53626A98.4010004@wizmail.org> <1398966120.32280.2.camel@nomad.lan> Message-ID: <53629C06.6020708@wizmail.org> On 01/05/14 18:42, Nikos Mavrogiannopoulos wrote: > On Thu, 2014-05-01 at 16:39 +0100, Jeremy Harris wrote: >> gnutls-3.1.16-1.fc20.x86_64 >> >> Can anyone point where to go next with this: >> Program terminated with signal SIGSEGV, Segmentation fault. >> #0 __GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:66 > > The mutex cannot be null after gnutls_global_init() is called. Do you > use gnutls from a dlopened object that links to pthreads while the main > application isn't linked to it (i.e., could there be a mix of the glibc > pthread stubs and the normal pthread functions)? I'm not knowingly using pthreads at all. will there be any trace of its use in the coredump? -- Thanks, Jeremy From jgh at wizmail.org Thu May 1 21:45:41 2014 From: jgh at wizmail.org (Jeremy Harris) Date: Thu, 01 May 2014 20:45:41 +0100 Subject: [gnutls-help] segfault in gnutls_handshake [SOLVED] In-Reply-To: <1398966120.32280.2.camel@nomad.lan> References: <53626A98.4010004@wizmail.org> <1398966120.32280.2.camel@nomad.lan> Message-ID: <5362A465.6070404@wizmail.org> On 01/05/14 18:42, Nikos Mavrogiannopoulos wrote: > On Thu, 2014-05-01 at 16:39 +0100, Jeremy Harris wrote: >> gnutls-3.1.16-1.fc20.x86_64 >> >> Can anyone point where to go next with this: >> Program terminated with signal SIGSEGV, Segmentation fault. >> #0 __GI___pthread_mutex_lock (mutex=0x0) at ../nptl/pthread_mutex_lock.c:66 > > The mutex cannot be null after gnutls_global_init() is called. Do you > use gnutls from a dlopened object that links to pthreads while the main > application isn't linked to it (i.e., could there be a mix of the glibc > pthread stubs and the normal pthread functions)? Solved; I was calling global_deinit too many times. Thanks for the help. -- Jeremy From dev at cor0.com Thu May 1 22:01:42 2014 From: dev at cor0.com (dev) Date: Thu, 1 May 2014 16:01:42 -0400 (EDT) Subject: [gnutls-help] Testsuite summary for GnuTLS 3.3.1 FAIL: 42 Message-ID: <430589133.33174.1398974502355.JavaMail.vpopmail@webmail2.networksolutionsemail.com> This was somewhat heart breaking :-( I have a completely clean compile now from top to bottom with a C99 strict compliance compiler ( Oracle Studio 12.3 ) and the end result is a big pile of fail. So not sure how to even begin with this. I may revert back to ye old stable release and repeat the process hoping to get better results with rev 3.2.13. For the record : $ gmake check Making check in gl gmake[1]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl' /usr/local/bin/gmake check-recursive gmake[2]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl' Making check in tests gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl/tests' /usr/local/bin/gmake check-recursive gmake[4]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl/tests' Making check in . gmake[5]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl/tests' /usr/local/bin/gmake libtests.a test-alloca-opt test-base64 test-binary-io test-byteswap test-c-ctype test-errno test-fcntl-h test-fdopen test-fgetc test-float test-fputc test-fread test-fstat test-ftell test-ftell3 test-ftello test-ftello3 test-ftello4 test-func test-fwrite test-getdelim test-getline test-gettimeofday test-iconv test-intprops test-inttypes test-memchr test-netdb test-netinet_in test-read-file test-snprintf test-stdalign test-stdbool test-stddef test-stdint test-stdio test-stdlib test-string test-strings test-strnlen test-strverscmp test-sys_socket test-sys_stat test-sys_time test-sys_types test-sys_uio test-time test-u64 test-unistd test-vasnprintf test-vasprintf test-verify test-vsnprintf test-wchar gmake[6]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl/tests' CC binary-io.o AR libtests.a CC test-alloca-opt.o CCLD test-alloca-opt CC test-base64.o CCLD test-base64 CC test-binary-io.o CCLD test-binary-io CC test-byteswap.o CCLD test-byteswap CC test-c-ctype.o CCLD test-c-ctype CC test-errno.o CCLD test-errno CC test-fcntl-h.o CCLD test-fcntl-h CC test-fdopen.o CCLD test-fdopen CC test-fgetc.o CCLD test-fgetc CC test-float.o CCLD test-float CC test-fputc.o CCLD test-fputc CC test-fread.o CCLD test-fread CC test-fstat.o CCLD test-fstat CC test-ftell.o CCLD test-ftell CC test-ftell3.o CCLD test-ftell3 CC test-ftello.o CCLD test-ftello CC test-ftello3.o CCLD test-ftello3 CC test-ftello4.o CCLD test-ftello4 CC test-func.o CCLD test-func CC test-fwrite.o CCLD test-fwrite CC test-getdelim.o CCLD test-getdelim CC test-getline.o CCLD test-getline CC test-gettimeofday.o CCLD test-gettimeofday CC test-iconv.o CCLD test-iconv ld: warning: file /usr/local/lib/libiconv.so: attempted multiple inclusion of file CC test-intprops.o CCLD test-intprops CC test-inttypes.o CCLD test-inttypes CC test-memchr.o CCLD test-memchr CC test-netdb.o CCLD test-netdb CC test-netinet_in.o CCLD test-netinet_in CC test-read-file.o CCLD test-read-file CC test-snprintf.o CCLD test-snprintf CC test-stdalign.o CCLD test-stdalign CC test-stdbool.o "test-stdbool.c", line 56: warning: nonportable bit-field type "test-stdbool.c", line 99: warning: improper pointer/integer combination: op "=" CCLD test-stdbool CC test-stddef.o CCLD test-stddef CC test-stdint.o CCLD test-stdint CC test-stdio.o CCLD test-stdio CC test-stdlib.o CCLD test-stdlib CC test-string.o CCLD test-string CC test-strings.o CCLD test-strings CC test-strnlen.o CCLD test-strnlen CC test-strverscmp.o CCLD test-strverscmp CC test-sys_socket.o CCLD test-sys_socket CC test-sys_stat.o CCLD test-sys_stat CC test-sys_time.o CCLD test-sys_time CC test-sys_types.o CCLD test-sys_types CC test-sys_uio.o CCLD test-sys_uio CC test-time.o CCLD test-time CC test-u64.o CCLD test-u64 CC test-unistd.o CCLD test-unistd CC test-vasnprintf.o CCLD test-vasnprintf CC test-vasprintf.o CCLD test-vasprintf CC test-verify.o CCLD test-verify CC test-vsnprintf.o CCLD test-vsnprintf CC test-wchar.o CCLD test-wchar gmake[6]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl/tests' /usr/local/bin/gmake check-TESTS gmake[6]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl/tests' gmake[7]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl/tests' PASS: test-alloca-opt PASS: test-base64 PASS: test-binary-io.sh PASS: test-byteswap PASS: test-c-ctype PASS: test-errno PASS: test-fcntl-h PASS: test-fdopen PASS: test-fgetc SKIP: test-float PASS: test-fputc PASS: test-fread PASS: test-fstat PASS: test-ftell.sh PASS: test-ftell2.sh PASS: test-ftell3 PASS: test-ftello.sh PASS: test-ftello2.sh PASS: test-ftello3 PASS: test-ftello4.sh PASS: test-func PASS: test-fwrite PASS: test-getdelim PASS: test-getline PASS: test-gettimeofday PASS: test-iconv PASS: test-intprops PASS: test-inttypes PASS: test-memchr PASS: test-netdb PASS: test-netinet_in PASS: test-read-file PASS: test-snprintf SKIP: test-stdalign PASS: test-stdbool PASS: test-stddef PASS: test-stdint PASS: test-stdio PASS: test-stdlib PASS: test-string PASS: test-strings PASS: test-strnlen PASS: test-strverscmp PASS: test-sys_socket PASS: test-sys_stat PASS: test-sys_time PASS: test-sys_types PASS: test-sys_uio PASS: test-init.sh PASS: test-time PASS: test-u64 PASS: test-unistd PASS: test-vasnprintf PASS: test-vasprintf SKIP: test-vc-list-files-git.sh SKIP: test-vc-list-files-cvs.sh PASS: test-verify PASS: test-verify.sh PASS: test-vsnprintf PASS: test-wchar gmake[8]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl/tests' /usr/local/bin/gmake all-recursive gmake[9]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl/tests' Making all in . gmake[10]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl/tests' gmake[10]: Nothing to be done for `all-am'. gmake[10]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl/tests' gmake[9]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl/tests' gmake[8]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl/tests' ============================================================================ Testsuite summary for GnuTLS 3.3.1 ============================================================================ # TOTAL: 60 # PASS: 56 # SKIP: 4 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 ============================================================================ gmake[7]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl/tests' gmake[6]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl/tests' gmake[5]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl/tests' gmake[4]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl/tests' gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl/tests' gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl' gmake[3]: Nothing to be done for `check-am'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl' gmake[2]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl' gmake[1]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/gl' Making check in lib gmake[1]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib' /usr/local/bin/gmake check-recursive gmake[2]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib' Making check in includes gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/includes' gmake[3]: Nothing to be done for `check'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/includes' Making check in x509 gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/x509' gmake[3]: Nothing to be done for `check'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/x509' Making check in auth gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/auth' gmake[3]: Nothing to be done for `check'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/auth' Making check in ext gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/ext' gmake[3]: Nothing to be done for `check'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/ext' Making check in algorithms gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/algorithms' gmake[3]: Nothing to be done for `check'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/algorithms' Making check in extras gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/extras' gmake[3]: Nothing to be done for `check'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/extras' Making check in accelerated gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/accelerated' gmake[4]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/accelerated' gmake[4]: Nothing to be done for `check-am'. gmake[4]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/accelerated' gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/accelerated' Making check in minitasn1 gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/minitasn1' gmake[3]: Nothing to be done for `check'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/minitasn1' Making check in opencdk gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/opencdk' gmake[3]: Nothing to be done for `check'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/opencdk' Making check in openpgp gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/openpgp' gmake[3]: Nothing to be done for `check'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/openpgp' Making check in nettle gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/nettle' gmake[3]: Nothing to be done for `check'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/nettle' gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib' gmake[3]: Nothing to be done for `check-am'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib' gmake[2]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib' gmake[1]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib' Making check in extra gmake[1]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/extra' Making check in includes gmake[2]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/extra/includes' gmake[2]: Nothing to be done for `check'. gmake[2]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/extra/includes' gmake[2]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/extra' gmake[2]: Nothing to be done for `check-am'. gmake[2]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/extra' gmake[1]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/extra' Making check in po gmake[1]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/po' gmake[1]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/po' Making check in src gmake[1]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/src' /usr/local/bin/gmake check-recursive gmake[2]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/src' Making check in gl gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/src/gl' /usr/local/bin/gmake check-recursive gmake[4]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/src/gl' gmake[5]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/src/gl' gmake[5]: Nothing to be done for `check-am'. gmake[5]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/src/gl' gmake[4]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/src/gl' gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/src/gl' Making check in libopts gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/src/libopts' gmake[3]: Nothing to be done for `check'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/src/libopts' gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/src' gmake[3]: Nothing to be done for `check-am'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/src' gmake[2]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/src' gmake[1]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/src' Making check in doc gmake[1]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc' /usr/local/bin/gmake check-recursive gmake[2]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc' Making check in examples gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc/examples' gmake[3]: Nothing to be done for `check'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc/examples' Making check in cyclo gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc/cyclo' gmake[3]: Nothing to be done for `check'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc/cyclo' Making check in scripts gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc/scripts' gmake[3]: Nothing to be done for `check'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc/scripts' Making check in manpages gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc/manpages' gmake[3]: Nothing to be done for `check'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc/manpages' Making check in credentials gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc/credentials' Making check in openpgp gmake[4]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc/credentials/openpgp' gmake[4]: Nothing to be done for `check'. gmake[4]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc/credentials/openpgp' Making check in srp gmake[4]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc/credentials/srp' gmake[4]: Nothing to be done for `check'. gmake[4]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc/credentials/srp' Making check in x509 gmake[4]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc/credentials/x509' gmake[4]: Nothing to be done for `check'. gmake[4]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc/credentials/x509' gmake[4]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc/credentials' gmake[4]: Nothing to be done for `check-am'. gmake[4]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc/credentials' gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc/credentials' Making check in latex gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc/latex' gmake[3]: Nothing to be done for `check'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc/latex' gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc' gmake[3]: Nothing to be done for `check-am'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc' gmake[2]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc' gmake[1]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/doc' Making check in tests gmake[1]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests' Making check in . gmake[2]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests' /usr/local/bin/gmake mini-record-2 simple gc set_pkcs12_cred certder certuniqueid mpi certificate_set_x509_crl dn parse_ca moredn record-sizes hostname-check cve-2008-4989 pkcs12_s2k chainverify record-sizes-range crq_key_id x509sign-verify cve-2009-1415 cve-2009-1416 crq_apis init_roundtrip pkcs12_s2k_pem dn2 mini-eagain nul-in-x509-names x509_altname pkcs12_encode mini-x509 mini-rehandshake rng-fork mini-eagain-dtls resume-dtls x509cert x509cert-tl infoaccess mini-dtls-hello-verify mini-tdb mini-dtls-rehandshake mini-alpn mini-dtls-large mini-termination mini-x509-cas mini-x509-2 pkcs12_simple mini-emsgsize-dtls chainverify-unsorted mini-overhead mini-dtls-heartbeat mini-x509-callbacks key-openssl priorities mini-dtls-srtp rsa-encrypt-decrypt mini-loss-time mini-record mini-dtls-record mini-handshake-timeout mini-record-range mini-cert-status mini-rsa-psk global-init sec-params fips-test mini-global-load name-constraints x509-extensions ocsp openssl openpgp-auth openpgp-auth2 openpgp-keyring pgps2kgnu x509self x509dn anonself pskself dhepskself resume setcredcrash openpgpself \ rfc2253-escape-test gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests' CC mini-record-2.o CCLD mini-record-2 CC simple.o CCLD simple CC gc.o CCLD gc CC set_pkcs12_cred.o CCLD set_pkcs12_cred CC certder.o CCLD certder CC certuniqueid.o CCLD certuniqueid CC mpi.o CCLD mpi CC certificate_set_x509_crl.o CCLD certificate_set_x509_crl CC dn.o CCLD dn CC parse_ca.o CCLD parse_ca CC moredn.o CCLD moredn CC record-sizes.o CCLD record-sizes CC hostname-check.o CCLD hostname-check CC cve-2008-4989.o CCLD cve-2008-4989 CC pkcs12_s2k.o CCLD pkcs12_s2k CC chainverify.o CCLD chainverify CC record-sizes-range.o CCLD record-sizes-range CC crq_key_id.o CCLD crq_key_id CC x509sign-verify.o CCLD x509sign-verify CC cve-2009-1415.o CCLD cve-2009-1415 CC cve-2009-1416.o CCLD cve-2009-1416 CC crq_apis.o CCLD crq_apis CC init_roundtrip.o CCLD init_roundtrip CC pkcs12_s2k_pem.o CCLD pkcs12_s2k_pem CC dn2.o CCLD dn2 CC mini-eagain.o CCLD mini-eagain CC nul-in-x509-names.o CCLD nul-in-x509-names CC x509_altname.o CCLD x509_altname CC pkcs12_encode.o CCLD pkcs12_encode CC mini-x509.o CCLD mini-x509 CC mini-rehandshake.o CCLD mini-rehandshake CC rng-fork.o CCLD rng-fork CC mini-eagain-dtls.o CCLD mini-eagain-dtls CC resume-dtls.o "resume-dtls.c", line 336: warning: implicit function declaration: kill CCLD resume-dtls CC x509cert.o CCLD x509cert CC x509cert-tl.o CCLD x509cert-tl CC infoaccess.o CCLD infoaccess CC mini-dtls-hello-verify.o "mini-dtls-hello-verify.c", line 170: warning: implicit function declaration: kill CCLD mini-dtls-hello-verify CC mini-tdb.o CCLD mini-tdb CC mini-dtls-rehandshake.o "mini-dtls-rehandshake.c", line 223: warning: implicit function declaration: kill CCLD mini-dtls-rehandshake CC mini-alpn.o "mini-alpn.c", line 163: warning: implicit function declaration: kill CCLD mini-alpn CC mini-dtls-large.o "mini-dtls-large.c", line 151: warning: implicit function declaration: kill CCLD mini-dtls-large CC mini-termination.o CCLD mini-termination CC mini-x509-cas.o CCLD mini-x509-cas CC mini-x509-2.o CCLD mini-x509-2 CC pkcs12_simple.o CCLD pkcs12_simple CC mini-emsgsize-dtls.o CCLD mini-emsgsize-dtls CC chainverify-unsorted.o CCLD chainverify-unsorted CC mini-overhead.o CCLD mini-overhead CC mini-dtls-heartbeat.o "mini-dtls-heartbeat.c", line 208: warning: implicit function declaration: kill CCLD mini-dtls-heartbeat CC mini-x509-callbacks.o CCLD mini-x509-callbacks CC key-openssl.o CCLD key-openssl CC priorities.o CCLD priorities CC mini-dtls-srtp.o "mini-dtls-srtp.c", line 187: warning: implicit function declaration: kill CCLD mini-dtls-srtp CC rsa-encrypt-decrypt.o CCLD rsa-encrypt-decrypt CC mini-loss-time.o CCLD mini-loss-time CC mini-record.o CCLD mini-record CC mini-dtls-record.o "mini-dtls-record.c", line 280: warning: implicit function declaration: kill CCLD mini-dtls-record CC mini-handshake-timeout.o CCLD mini-handshake-timeout CC mini-record-range.o CCLD mini-record-range CC mini-cert-status.o CCLD mini-cert-status CC mini-rsa-psk.o CCLD mini-rsa-psk CC global-init.o CCLD global-init CC sec-params.o CCLD sec-params CC fips-test.o CCLD fips-test CC mini-global-load.o CCLD mini-global-load CC name-constraints.o CCLD name-constraints CC x509-extensions.o CCLD x509-extensions CC ocsp.o CCLD ocsp CC openssl.o CCLD openssl ld: warning: file ../lib/.libs/libgnutls.so: linked to /usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/lib/.libs/libgnutls.so: attempted multiple inclusion of file CC openpgp-auth.o CCLD openpgp-auth CC openpgp-auth2.o CCLD openpgp-auth2 CC openpgp-keyring.o CCLD openpgp-keyring CC pgps2kgnu.o CCLD pgps2kgnu CC x509self.o CCLD x509self CC x509dn.o CCLD x509dn CC anonself.o CCLD anonself CC pskself.o CCLD pskself CC dhepskself.o CCLD dhepskself CC resume.o "resume.c", line 336: warning: implicit function declaration: kill CCLD resume CC setcredcrash.o CCLD setcredcrash CC openpgpself.o CCLD openpgpself gmake[3]: Nothing to be done for `rfc2253-escape-test'. gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests' /usr/local/bin/gmake check-TESTS gmake[3]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests' gmake[4]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests' ../build-aux/test-driver: line 107: 1784 Killed "$@" > $log_file 2>&1 FAIL: mini-record-2 FAIL: simple PASS: gc PASS: set_pkcs12_cred PASS: certder PASS: certuniqueid ../build-aux/test-driver: line 107: 1821 Bus Error (core dumped) "$@" > $log_file 2>&1 FAIL: mpi PASS: certificate_set_x509_crl PASS: dn PASS: parse_ca PASS: moredn PASS: record-sizes FAIL: hostname-check PASS: cve-2008-4989 PASS: pkcs12_s2k FAIL: chainverify PASS: record-sizes-range PASS: crq_key_id FAIL: x509sign-verify PASS: cve-2009-1415 PASS: cve-2009-1416 PASS: crq_apis PASS: init_roundtrip PASS: pkcs12_s2k_pem PASS: dn2 PASS: mini-eagain PASS: nul-in-x509-names PASS: x509_altname PASS: pkcs12_encode ../build-aux/test-driver: line 107: 1960 Killed "$@" > $log_file 2>&1 FAIL: mini-x509 PASS: mini-rehandshake FAIL: rng-fork PASS: mini-eagain-dtls ../build-aux/test-driver: line 107: 1986 Killed "$@" > $log_file 2>&1 FAIL: resume-dtls PASS: x509cert ../build-aux/test-driver: line 107: 1999 Killed "$@" > $log_file 2>&1 FAIL: x509cert-tl PASS: infoaccess ../build-aux/test-driver: line 107: 2011 Killed "$@" > $log_file 2>&1 FAIL: mini-dtls-hello-verify PASS: mini-tdb ../build-aux/test-driver: line 107: 2025 Killed "$@" > $log_file 2>&1 FAIL: mini-dtls-rehandshake ../build-aux/test-driver: line 107: 2032 Killed "$@" > $log_file 2>&1 FAIL: mini-alpn ../build-aux/test-driver: line 107: 2039 Killed "$@" > $log_file 2>&1 FAIL: mini-dtls-large ../build-aux/test-driver: line 107: 2046 Killed "$@" > $log_file 2>&1 FAIL: mini-termination PASS: mini-x509-cas ../build-aux/test-driver: line 107: 2059 Killed "$@" > $log_file 2>&1 FAIL: mini-x509-2 PASS: pkcs12_simple FAIL: mini-emsgsize-dtls PASS: chainverify-unsorted ../build-aux/test-driver: line 107: 2083 Killed "$@" > $log_file 2>&1 FAIL: mini-overhead ../build-aux/test-driver: line 107: 2090 Killed "$@" > $log_file 2>&1 FAIL: mini-dtls-heartbeat ../build-aux/test-driver: line 107: 2097 Killed "$@" > $log_file 2>&1 FAIL: mini-x509-callbacks PASS: key-openssl ../build-aux/test-driver: line 107: 2109 Killed "$@" > $log_file 2>&1 FAIL: priorities ../build-aux/test-driver: line 107: 2115 Killed "$@" > $log_file 2>&1 FAIL: mini-dtls-srtp PASS: rsa-encrypt-decrypt ../build-aux/test-driver: line 107: 2128 Killed "$@" > $log_file 2>&1 FAIL: mini-loss-time ../build-aux/test-driver: line 107: 2135 Killed "$@" > $log_file 2>&1 FAIL: mini-record ../build-aux/test-driver: line 107: 2142 Killed "$@" > $log_file 2>&1 FAIL: mini-dtls-record ../build-aux/test-driver: line 107: 2149 Killed "$@" > $log_file 2>&1 FAIL: mini-handshake-timeout SKIP: mini-record-range ../build-aux/test-driver: line 107: 2162 Killed "$@" > $log_file 2>&1 FAIL: mini-cert-status ../build-aux/test-driver: line 107: 2169 Killed "$@" > $log_file 2>&1 FAIL: mini-rsa-psk PASS: global-init FAIL: sec-params ../build-aux/test-driver: line 107: 2188 Killed "$@" > $log_file 2>&1 FAIL: fips-test ../build-aux/test-driver: line 107: 2194 Segmentation Fault (core dumped) "$@" > $log_file 2>&1 FAIL: mini-global-load ../build-aux/test-driver: line 107: 2200 Killed "$@" > $log_file 2>&1 FAIL: name-constraints ../build-aux/test-driver: line 107: 2206 Killed "$@" > $log_file 2>&1 FAIL: x509-extensions PASS: ocsp PASS: openssl ../build-aux/test-driver: line 107: 2224 Killed "$@" > $log_file 2>&1 FAIL: openpgp-auth ../build-aux/test-driver: line 107: 2231 Killed "$@" > $log_file 2>&1 FAIL: openpgp-auth2 PASS: openpgp-keyring PASS: pgps2kgnu ../build-aux/test-driver: line 107: 2250 Killed "$@" > $log_file 2>&1 FAIL: x509self ../build-aux/test-driver: line 107: 2257 Killed "$@" > $log_file 2>&1 FAIL: x509dn ../build-aux/test-driver: line 107: 2264 Killed "$@" > $log_file 2>&1 FAIL: anonself ../build-aux/test-driver: line 107: 2271 Killed "$@" > $log_file 2>&1 FAIL: pskself ../build-aux/test-driver: line 107: 2278 Killed "$@" > $log_file 2>&1 FAIL: dhepskself ../build-aux/test-driver: line 107: 2285 Killed "$@" > $log_file 2>&1 FAIL: resume PASS: setcredcrash ../build-aux/test-driver: line 107: 2298 Killed "$@" > $log_file 2>&1 FAIL: openpgpself PASS: rfc2253-escape-test gmake[5]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests' Making all in . gmake[6]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests' gmake[6]: Nothing to be done for `all-am'. gmake[6]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests' Making all in rsa-md5-collision gmake[6]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/rsa-md5-collision' gmake[6]: Nothing to be done for `all'. gmake[6]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/rsa-md5-collision' Making all in pkcs1-padding gmake[6]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/pkcs1-padding' gmake[6]: Nothing to be done for `all'. gmake[6]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/pkcs1-padding' Making all in pkcs8-decode gmake[6]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/pkcs8-decode' gmake[6]: Nothing to be done for `all'. gmake[6]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/pkcs8-decode' Making all in pkcs12-decode gmake[6]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/pkcs12-decode' gmake[6]: Nothing to be done for `all'. gmake[6]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/pkcs12-decode' Making all in userid gmake[6]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/userid' gmake[6]: Nothing to be done for `all'. gmake[6]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/userid' Making all in cert-tests gmake[6]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/cert-tests' gmake[6]: Nothing to be done for `all'. gmake[6]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/cert-tests' Making all in key-tests gmake[6]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/key-tests' gmake[6]: Nothing to be done for `all'. gmake[6]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/key-tests' Making all in sha2 gmake[6]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/sha2' gmake[6]: Nothing to be done for `all'. gmake[6]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/sha2' Making all in safe-renegotiation gmake[6]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/safe-renegotiation' gmake[6]: Nothing to be done for `all'. gmake[6]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/safe-renegotiation' Making all in dsa gmake[6]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/dsa' gmake[6]: Nothing to be done for `all'. gmake[6]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/dsa' Making all in scripts gmake[6]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/scripts' gmake[6]: Nothing to be done for `all'. gmake[6]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/scripts' Making all in ecdsa gmake[6]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/ecdsa' gmake[6]: Nothing to be done for `all'. gmake[6]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/ecdsa' Making all in slow gmake[6]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/slow' gmake[6]: Nothing to be done for `all'. gmake[6]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/slow' Making all in dtls gmake[6]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/dtls' gmake[6]: Nothing to be done for `all'. gmake[6]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/dtls' Making all in srp gmake[6]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/srp' gmake[6]: Nothing to be done for `all'. gmake[6]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/srp' Making all in openpgp-certs gmake[6]: Entering directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/openpgp-certs' gmake[6]: Nothing to be done for `all'. gmake[6]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests/openpgp-certs' gmake[5]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests' ============================================================================ Testsuite summary for GnuTLS 3.3.1 ============================================================================ # TOTAL: 83 # PASS: 40 # SKIP: 1 # XFAIL: 0 # FAIL: 42 # XPASS: 0 # ERROR: 0 ============================================================================ See tests/test-suite.log Please report to bugs at gnutls.org ============================================================================ gmake[4]: *** [test-suite.log] Error 1 gmake[4]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests' gmake[3]: *** [check-TESTS] Error 2 gmake[3]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests' gmake[2]: *** [check-am] Error 2 gmake[2]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests' gmake[1]: *** [check-recursive] Error 1 gmake[1]: Leaving directory `/usr/local/build/gnutls-3.3.1_SunOS5.10_sparcv9_002/tests' gmake: *** [check-recursive] Error 1 node002$ Two of the above tests result in core files and they point to fairly serious memory alignment error or an outright deref of a null pointer : node002$ dbx ./tests/mpi time_1398923727-pid_1821-uid_16411-gid_20002-fid_mpi.core Reading mpi core file header read successfully Reading ld.so.1 Reading libgnutls.so.28.16.1 Reading libz.so.1.2.7 Reading librt.so.1 Reading libnettle.so.4.7 Reading libhogweed.so.2.5 Reading libgmp.so.10.2.0 Reading libsocket.so.1 Reading libnsl.so.1 Reading libintl.so.8.1.1 Reading libiconv.so.2.5.1 Reading libc.so.1 Reading libgen.so.1 Reading libpthread.so.1 Reading libaio.so.1 Reading libmd.so.1 Reading libgcc_s.so.1 Reading libc_psr.so.1 t at 1 (l at 1) program terminated by signal BUS (invalid address alignment) 0xffffffff7e43454c: __gmpz_sizeinbase+0x0024: ld [%g1 + 4], %g1 Current function is wrap_nettle_mpi_get_nbits 204 return mpz_sizeinbase (*((mpz_t *) a), 2); (dbx) where current thread: t at 1 [1] __gmpz_sizeinbase(0x2, 0x2, 0x0, 0x0, 0x0, 0xffffffff7fffe498), at 0xffffffff7e43454c =>[2] wrap_nettle_mpi_get_nbits(a = 0x2), line 204 in "mpi.c" [3] wrap_nettle_mpi_addm(w = (nil), a = 0x2, b = 0xffffffff7fffe488, m = 0xffffffff7fffe480), line 247 in "mpi.c" [4] doit(), line 55 in "mpi.c" [5] main(argc = 0, argv = 0xffffffff7fffe638), line 146 in "utils.c" (dbx) quit So that's not good. This is worse : node002$ dbx ./tests/mini-global-load time_1398923762-pid_2194-uid_16411-gid_20002-fid_mini-global-load.core Reading mini-global-load dbx: warning: core object name "mini-global-loa" matches object name "mini-global-load" within the limit of 14. assuming they match core file header read successfully Reading ld.so.1 Reading libgnutls.so.28.16.1 Reading libz.so.1.2.7 Reading librt.so.1 Reading libnettle.so.4.7 Reading libhogweed.so.2.5 Reading libgmp.so.10.2.0 Reading libsocket.so.1 Reading libnsl.so.1 Reading libintl.so.8.1.1 Reading libiconv.so.2.5.1 Reading libc.so.1 Reading libgen.so.1 Reading libpthread.so.1 Reading libaio.so.1 Reading libmd.so.1 Reading libgcc_s.so.1 Reading libc_psr.so.1 t at 1 (l at 1) program terminated by signal SEGV (no mapping at the fault address) 0xffffffff7d8d1010: mutex_lock_impl+0x007c: ldub [%i4 + 5], %l0 Current function is gnutls_system_mutex_lock 232 if (pthread_mutex_lock ((pthread_mutex_t *) * priv)) (dbx) where current thread: t at 1 [1] mutex_lock_impl(0xffffffff7cf00200, 0x0, 0x16d060, 0x0, 0x0, 0xffffffff7da4a300), at 0xffffffff7d8d1010 =>[2] gnutls_system_mutex_lock(priv = 0xffffffff7f13e650), line 232 in "system.c" [3] wrap_nettle_rnd(_ctx = (nil), level = 0, data = 0xffffffff7fffe004, datasize = 28U), line 439 in "rnd.c" [4] _gnutls_rnd(level = GNUTLS_RND_NONCE, data = 0xffffffff7fffe004, len = 28U), line 38 in "random.h" [5] _gnutls_tls_create_random(dst = 0xffffffff7fffe000 "Sa\xe1\xf2"), line 322 in "gnutls_handshake.c" [6] _gnutls_send_client_hello(session = 0x100136600, again = 0), line 1870 in "gnutls_handshake.c" [7] _gnutls_send_hello(session = 0x100136600, again = 0), line 2061 in "gnutls_handshake.c" [8] _gnutls_handshake_client(session = 0x100136600), line 2539 in "gnutls_handshake.c" [9] gnutls_handshake(session = 0x100136600), line 2401 in "gnutls_handshake.c" [10] doit(), line 132 in "mini-global-load.c" [11] main(argc = 0, argv = 0xffffffff7fffe548), line 146 in "utils.c" (dbx) x 0xffffffff7f13e650 0xffffffff7f13e650: rnd_mutex : 0x00000000 Well that's a big fat null. So I'll go down a rev and give it a whirl. Dennis From nmav at gnutls.org Fri May 2 09:25:28 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 2 May 2014 09:25:28 +0200 Subject: [gnutls-help] Testsuite summary for GnuTLS 3.3.1 FAIL: 42 In-Reply-To: <430589133.33174.1398974502355.JavaMail.vpopmail@webmail2.networksolutionsemail.com> References: <430589133.33174.1398974502355.JavaMail.vpopmail@webmail2.networksolutionsemail.com> Message-ID: On Thu, May 1, 2014 at 10:01 PM, dev wrote: > > This was somewhat heart breaking :-( > I have a completely clean compile now from top to bottom with > a C99 strict compliance compiler ( Oracle Studio 12.3 ) and the > end result is a big pile of fail. The issues aren't many though. You're almost there. > t at 1 (l at 1) program terminated by signal BUS (invalid address alignment) > 0xffffffff7e43454c: __gmpz_sizeinbase+0x0024: ld [%g1 + 4], %g1 > Current function is wrap_nettle_mpi_get_nbits > 204 return mpz_sizeinbase (*((mpz_t *) a), 2); That's an ugly cast. It also exists on the stable branch, but I've quite simplified it now on the repository. You could check whether the new code works better. > t at 1 (l at 1) program terminated by signal SEGV (no mapping at the fault > address) > 0xffffffff7d8d1010: mutex_lock_impl+0x007c: ldub [%i4 + 5], %l0 > Current function is gnutls_system_mutex_lock > 232 if (pthread_mutex_lock ((pthread_mutex_t *) * priv)) [...] > (dbx) x 0xffffffff7f13e650 > 0xffffffff7f13e650: rnd_mutex : 0x00000000 > Well that's a big fat null. That could be in the most recent branch only. You need to verify that gnutls_global_init() was called, and that the mutex was initialized. regards, Nikos From nmav at gnutls.org Fri May 2 09:30:17 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 2 May 2014 09:30:17 +0200 Subject: [gnutls-help] GNUTLS_E_PREMATURE_TERMINATION error In-Reply-To: <8d5a6abbdb004c4186538f0737414c40@DM2PR08MB527.namprd08.prod.outlook.com> References: <846200f2b66646dab7c05bdc03384efb@DM2PR08MB527.namprd08.prod.outlook.com> <1398966243.32280.4.camel@nomad.lan> <8d5a6abbdb004c4186538f0737414c40@DM2PR08MB527.namprd08.prod.outlook.com> Message-ID: On Thu, May 1, 2014 at 8:20 PM, Polina Abramov wrote: > Thanks! > I ran wireshark and it looks like at some point my client issues Encrypted > Alert 21. Is it something I should be worried about? How did you see the alert type? (it is encrypted) What you've seen is probably the alert message type which is also 21. In that case it is most probably that you're sending the close notify alert, that is the proper way to signal the termination of the TLS session. If that's the case you could ignore the premature termination errors are you already intended to terminate it. regards, Nikos From nouatzi at gmail.com Fri May 2 17:26:12 2014 From: nouatzi at gmail.com (Frederic Nivor) Date: Fri, 2 May 2014 17:26:12 +0200 Subject: [gnutls-help] GnuTLS / OpenSSL / Certificate Installation HowTo Message-ID: I would like to create a TCP client/server scenario: - a simple C server on a VPS - a simple C client on another device And I would like to secure the TCP connection between them. GnuTLS seems to be a good choice (they also propose some client/server samples). My web hosting provider gave me a SSL certificate. So from now, I don't know how to install and configure everything in order to work properly: - from the SSL certificate installation (if I need to), - how to use GnuTLS in my client/server program with those certificates (if needed), - ... Can somebody explain the all thing please ? Thanks. B.R. From dkg at fifthhorseman.net Fri May 2 22:11:22 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 02 May 2014 16:11:22 -0400 Subject: [gnutls-help] GnuTLS / OpenSSL / Certificate Installation HowTo In-Reply-To: References: Message-ID: <5363FBEA.5080306@fifthhorseman.net> On 05/02/2014 11:26 AM, Frederic Nivor wrote: > I would like to create a TCP client/server scenario: > - a simple C server on a VPS > - a simple C client on another device > And I would like to secure the TCP connection between them. GnuTLS > seems to be a good choice (they also propose some client/server > samples). > My web hosting provider gave me a SSL certificate. So from now, I > don't know how to install and configure everything in order to work > properly: > - from the SSL certificate installation (if I need to), > - how to use GnuTLS in my client/server program with those > certificates (if needed), > - ... > Can somebody explain the all thing please ? You're probably interested in the GnuTLS documentation and examples about X.509 certificate use and verification: http://www.gnutls.org/manual/gnutls.html#X_002e509-certificates http://www.gnutls.org/manual/gnutls.html#Echo-server-with-X_002e509-authentication http://www.gnutls.org/manual/gnutls.html#Verifying-a-certificate If you want to experiment without writing your own client yet, you can also use the gnutls-serv and and gnutls-cli command-line clients to set up a connection using the keys (search for x509 in the man pages for these tools for details about how to select a different certificate for them). Your subject line also mentions OpenSSL, but your question doesn't; but this is probably the wrong list for OpenSSL support; OpenSSL is a different library that implements some of the same protocols that GnuTLS implements. hope this helps, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From polinaa at image-vault.com Mon May 5 15:27:13 2014 From: polinaa at image-vault.com (Polina Abramov) Date: Mon, 5 May 2014 13:27:13 +0000 Subject: [gnutls-help] GNUTLS_E_PREMATURE_TERMINATION error In-Reply-To: References: <846200f2b66646dab7c05bdc03384efb@DM2PR08MB527.namprd08.prod.outlook.com> <1398966243.32280.4.camel@nomad.lan> <8d5a6abbdb004c4186538f0737414c40@DM2PR08MB527.namprd08.prod.outlook.com> Message-ID: <2dddbabda75445ef8c815bbb098548a0@DM2PR08MB527.namprd08.prod.outlook.com> You are right, it was the alert message type, not the alert type. After some more investigation I now see what is happening but it is still unclear why. When my smtp client is done sending the email it issues smtp QUIT message and waits for 221 reply which the server should issue based on SMTP standard. However for some unknown reason the client never receives that 221 reply, instead gnutls_record_recv() function returns GNUTLS_E_PREMATURE_TERMINATION. Seems like the server starts termination process without notifying the client. As a result of not receiving the expected 221 reply, our TLS session times out and that's when the alert to close the session is issued. So the alert that I am seeing is an expected behavior. The only thing that is unclear here is why don't I receive 221 reply to my QUIT message from gmail and hotmail servers. Any ideas about that? Thanks, P.A. -----Original Message----- From: n.mavrogiannopoulos at gmail.com [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos Sent: Friday, May 02, 2014 3:30 AM To: Polina Abramov Cc: gnutls-help at lists.gnutls.org Subject: Re: [gnutls-help] GNUTLS_E_PREMATURE_TERMINATION error On Thu, May 1, 2014 at 8:20 PM, Polina Abramov wrote: > Thanks! > I ran wireshark and it looks like at some point my client issues > Encrypted Alert 21. Is it something I should be worried about? How did you see the alert type? (it is encrypted) What you've seen is probably the alert message type which is also 21. In that case it is most probably that you're sending the close notify alert, that is the proper way to signal the termination of the TLS session. If that's the case you could ignore the premature termination errors are you already intended to terminate it. regards, Nikos From lavr at ncbi.nlm.nih.gov Mon May 5 15:51:26 2014 From: lavr at ncbi.nlm.nih.gov (Lavrentiev, Anton (NIH/NLM/NCBI) [C]) Date: Mon, 5 May 2014 13:51:26 +0000 Subject: [gnutls-help] GNUTLS_E_PREMATURE_TERMINATION error In-Reply-To: <2dddbabda75445ef8c815bbb098548a0@DM2PR08MB527.namprd08.prod.outlook.com> References: <846200f2b66646dab7c05bdc03384efb@DM2PR08MB527.namprd08.prod.outlook.com> <1398966243.32280.4.camel@nomad.lan> <8d5a6abbdb004c4186538f0737414c40@DM2PR08MB527.namprd08.prod.outlook.com> <2dddbabda75445ef8c815bbb098548a0@DM2PR08MB527.namprd08.prod.outlook.com> Message-ID: <5F8AAC04F9616747BC4CC0E803D5907D0C8E33B2@MLBXv04.nih.gov> Just theorizing: It may be that the SMTP server "optimizes" on connection closure immediately following the 221 goodbye response (could you prove there was no 221 issued by the server at all?): if the closure is not graceful (which otherwise would leave a TIME_WAIT'd port per TCP, and thus not to be to the server's advantage), the alternative is TCP abort, which injects TCP RST. The RST may clobber the sequence on the receiving end (the mail client), and cause all preceding pending data dropped (SSL data with the encoded 221), and EOF seen immediately. So you get the premature termination. P.S. The server should have waited to see EOF from the client end in response to the issued 221, then close the connection (regular close in this case would not have hurt: no TIME_WAIT on close acknowledgement). P.P.S. You may be able to check the above scenario by using unencrypted connection (if server allows), or by tracing the server execution (if have access to the server software). Anton Lavrentiev Contractor NIH/NLM/NCBI > -----Original Message----- > From: Polina Abramov [mailto:polinaa at image-vault.com] > Sent: Monday, May 05, 2014 9:27 AM > To: Nikos Mavrogiannopoulos > Cc: gnutls-help at lists.gnutls.org > Subject: Re: [gnutls-help] GNUTLS_E_PREMATURE_TERMINATION error > > You are right, it was the alert message type, not the alert type. > After some more investigation I now see what is happening but it is > still unclear why. > > When my smtp client is done sending the email it issues smtp QUIT > message and waits for 221 reply which the server should issue based on > SMTP standard. However for some unknown reason > the client never receives that 221 reply, instead gnutls_record_recv() > function returns GNUTLS_E_PREMATURE_TERMINATION. Seems like the server > starts termination process without notifying the client. > As a result of not receiving the expected 221 reply, our TLS session > times out and that's when the alert to close the session is issued. So > the alert that I am seeing is an expected behavior. > The only thing that is unclear here is why don't I receive 221 reply to > my QUIT message from gmail and hotmail servers. > Any ideas about that? > > Thanks, > P.A. > > > -----Original Message----- > From: n.mavrogiannopoulos at gmail.com > [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos > Mavrogiannopoulos > Sent: Friday, May 02, 2014 3:30 AM > To: Polina Abramov > Cc: gnutls-help at lists.gnutls.org > Subject: Re: [gnutls-help] GNUTLS_E_PREMATURE_TERMINATION error > > On Thu, May 1, 2014 at 8:20 PM, Polina Abramov > wrote: > > Thanks! > > I ran wireshark and it looks like at some point my client issues > > Encrypted Alert 21. Is it something I should be worried about? > > How did you see the alert type? (it is encrypted) What you've seen is > probably the alert message type which is also 21. > > In that case it is most probably that you're sending the close notify > alert, that is the proper way to signal the termination of the TLS > session. If that's the case you could ignore the premature termination > errors are you already intended to terminate it. > > regards, > Nikos > > _______________________________________________ > Gnutls-help mailing list > Gnutls-help at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-help From nmav at gnutls.org Tue May 6 21:37:01 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 06 May 2014 21:37:01 +0200 Subject: [gnutls-help] gnutls 3.1.24 Message-ID: <1399405021.14966.1.camel@nomad.lan> Hello, I've just released gnutls 3.1.24. This is a bug fix release on the old stable branch. * Version 3.1.24 (released 2014-05-06) ** libgnutls: Fixed issue with the check of incoming data when two different recv and send pointers have been specified. Reported and investigated by JMRecio. ** libgnutls: Several small bug fixes identified using valgrind and the Codenomicon TLS test suite. ** libgnutls: Several small bug fixes found by coverity. ** libgnutls-dane: Accept a certificate using DANE if there is at least one entry that matches the certificate. Patch by simon [at] arlott.org. ** certtool: The ECDSA keys generated by default use the SECP256R1 curve which is supported more widely than the previously used SECP224R1. ** 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.24.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.24.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.24.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.24.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 Tue May 6 21:38:47 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 06 May 2014 21:38:47 +0200 Subject: [gnutls-help] gnutls 3.2.14 Message-ID: <1399405127.14966.3.camel@nomad.lan> Hello, I've just released gnutls 3.2.14. This is a bugfix release on the current stable branch. * Version 3.2.14 (released 2014-05-06) ** libgnutls: Fixed issue with the check of incoming data when two different recv and send pointers have been specified. Reported and investigated by JMRecio. ** libgnutls: Fixed issue in the RSA-PSK key exchange, which would result to illegal memory access if a server hint was provided. ** libgnutls: Fixed client memory leak in the PSK key exchange, if a server hint was provided. ** libgnutls: Several small bug fixes identified using valgrind and the Codenomicon TLS test suite. ** libgnutls: Several small bug fixes found by coverity. ** libgnutls-dane: Accept a certificate using DANE if there is at least one entry that matches the certificate. Patch by simon [at] arlott.org. ** configure: Added --with-nettle-mini option, which allows linking with a libnettle that contains gmp. ** certtool: The ECDSA keys generated by default use the SECP256R1 curve which is supported more widely than the previously used SECP224R1. ** 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.14.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.14.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.14.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.14.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 Tue May 6 21:41:07 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 06 May 2014 21:41:07 +0200 Subject: [gnutls-help] gnutls 3.3.2 Message-ID: <1399405267.14966.4.camel@nomad.lan> Hello, I've just released gnutls 3.3.2. This is a bugfix release on the next stable branch. * Version 3.3.2 (released 2014-05-06) ** libgnutls: Added the 'very weak' certificate verification profile that corresponds to 64-bit security level. ** libgnutls: Corrected file descriptor leak on random generator initialization. ** libgnutls: Corrected file descriptor leak on PSK password file reading. Issue identified using the Codenomicon TLS test suite. ** libgnutls: Avoid deinitialization if initialization has failed. ** libgnutls: null-terminate othername alternative names. ** libgnutls: gnutls_x509_trust_list_get_issuer() will operate correctly on a PKCS #11 trust list. ** libgnutls: Several small bug fixes identified using valgrind and the Codenomicon TLS test suite. ** libgnutls-dane: Accept a certificate using DANE if there is at least one entry that matches the certificate. Patch by simon [at] arlott.org. ** libgnutls-guile: Fixed compilation issue. ** certtool: Allow exporting a CRL on DER format. ** certtool: The ECDSA keys generated by default use the SECP256R1 curve which is supported more widely than the previously used SECP224R1. ** API and ABI modifications: GNUTLS_PROFILE_VERY_WEAK: Added 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.2.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.2.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.2.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.2.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 kris.veldhuyzen at uleth.ca Wed May 7 05:54:29 2014 From: kris.veldhuyzen at uleth.ca (Veldhuyzen, Kris) Date: Tue, 6 May 2014 21:54:29 -0600 Subject: [gnutls-help] trouble with X509 communication Message-ID: Hi, I'm hoping to get some help on testing and getting TLS communication working. Using Certtool I've made a CA, client certificate and server certificate. Each has a certificate/private key pair and I think they are correct. The CA is self signed and the client and server are signed by the CA. I've made some simple client and server programmers to test communication based on the documentation and examples on gnutls.org. The client and the server both load their respective certs/privkey and the CA cert without issue and attempt to handshake the communication. When that happens the server immediately fails with GNUTLS_E_UNKNOWN_CIPHER_SUITE "Could not negotiate a supported cipher suite" and the client fails with "Error in the pull function." I've kicked up the debug level in gnutls and I saw an error on both client and server that looks potentially bad (|<9>| ENC[006DABD8]: cipher: NULL, MAC: MAC-NULL, Epoch: 0) but most of the other reported lines don't seem critical (to me at least). In both client and server the the programs use gnutls_priority_set_direct with a string "NORMAL:+KX-ALL" and the function succeeds. I've tried re-mkaing the certificates numerous times thinking that I have mis-created these somehow but I am not sure what. Any advice for what I can check would be greatly appreciated! From nmav at gnutls.org Wed May 7 14:16:27 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 7 May 2014 14:16:27 +0200 Subject: [gnutls-help] gnutls 3.3.2 In-Reply-To: <1399405267.14966.4.camel@nomad.lan> References: <1399405267.14966.4.camel@nomad.lan> Message-ID: On Tue, May 6, 2014 at 9:41 PM, Nikos Mavrogiannopoulos wrote: > ** libgnutls: Corrected file descriptor leak on PSK password file > reading. Issue identified using the Codenomicon TLS test suite. > ** libgnutls: Several small bug fixes identified using valgrind and > the Codenomicon TLS test suite. I should have mentioned that Codenomicon offered its TLS test suite to check GnuTLS. It is fuzz testing suite, which allows to test the not so often executed error code paths. regards, Nikos From jw at raven.inka.de Wed May 14 15:37:14 2014 From: jw at raven.inka.de (Josef Wolf) Date: Wed, 14 May 2014 15:37:14 +0200 Subject: [gnutls-help] Creating password protected private keys with certtool? Message-ID: <20140514133714.GB9503@raven.inka.de> Hello everybody, I am trying to create password protected private keys with the following command: certtool --generate-privkey --outfile x509-ca-key.pem --password "secret" but the resulting file don't seem to be encrypted. Then I tried the --ask-pass option, but certtool complains that the --ask-pass option is unknown. Any hints how to generate a password protected private key? -- Josef Wolf jw at raven.inka.de From dkg at fifthhorseman.net Wed May 14 16:35:44 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 14 May 2014 10:35:44 -0400 Subject: [gnutls-help] Creating password protected private keys with certtool? In-Reply-To: <20140514133714.GB9503@raven.inka.de> References: <20140514133714.GB9503@raven.inka.de> Message-ID: <53737F40.30205@fifthhorseman.net> On 05/14/2014 09:37 AM, Josef Wolf wrote: > I am trying to create password protected private keys with the following > command: > > certtool --generate-privkey --outfile x509-ca-key.pem --password "secret" > > but the resulting file don't seem to be encrypted. What version of certtool are you using? how can you tell that the file is not encrypted? it seems to work for me: 0 dkg at alice:~$ certtool --version certtool 3.2.14 Copyright (C) 2000-2014 Free Software Foundation, and others, all rights reserved. This is free software. It is licensed for use, modification and redistribution under the terms of the GNU General Public License, version 3 or later Please send bug reports to: 0 dkg at alice:~$ certtool --generate-privkey --outfile x.pem --password x Assuming PKCS #8 format... Generating a 2432 bit RSA private key... 0 dkg at alice:~$ certtool --key-info < x.pem Encrypted structure detected... Enter password: Public Key Info: Public Key Algorithm: RSA Key Security Level: Normal (2432 bits) [...] If you give more information, we can help debug better. All the best, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From jw at raven.inka.de Wed May 14 16:58:04 2014 From: jw at raven.inka.de (Josef Wolf) Date: Wed, 14 May 2014 16:58:04 +0200 Subject: [gnutls-help] Creating password protected private keys with certtool? In-Reply-To: <53737F40.30205@fifthhorseman.net> References: <20140514133714.GB9503@raven.inka.de> <53737F40.30205@fifthhorseman.net> Message-ID: <20140514145804.GA22643@raven.inka.de> On Wed, May 14, 2014 at 10:35:44AM -0400, Daniel Kahn Gillmor wrote: Thanks for the quick response, Daniel! > On 05/14/2014 09:37 AM, Josef Wolf wrote: > > certtool --generate-privkey --outfile x509-ca-key.pem --password "secret" > > What version of certtool are you using? how can you tell that the file > is not encrypted? I'm using 3.0.28, as it comes with opensuse-12.3. I assume it is not encrypted because it don't ask me for the password when I use it for anything: jw at raven:/m/s/rep/git/catool$ certtool --version certtool 3.0.28 [ ... ] jw at raven:/m/s/rep/git/catool$ certtool --generate-privkey --outfile x.pem --password x Generating a 2432 bit RSA private key... jw at raven:/m/s/rep/git/catool$ certtool --key-info < x.pem | head -5 Public Key Info: Public Key Algorithm: RSA Key Security Level: Normal I just noticed that I get encrypted keys when I use the --pkcs8 option. But then, certtool insists to read the password from the keyboard. Is it possible to provide the password on stdin or something? -- Josef Wolf jw at raven.inka.de From jw at raven.inka.de Wed May 14 18:47:00 2014 From: jw at raven.inka.de (Josef Wolf) Date: Wed, 14 May 2014 18:47:00 +0200 Subject: [gnutls-help] Creating password protected private keys with certtool? In-Reply-To: <20140514145804.GA22643@raven.inka.de> References: <20140514133714.GB9503@raven.inka.de> <53737F40.30205@fifthhorseman.net> <20140514145804.GA22643@raven.inka.de> Message-ID: <20140514164700.GB22643@raven.inka.de> On Wed, May 14, 2014 at 04:58:04PM +0200, Josef Wolf wrote: > I just noticed that I get encrypted keys when I use the --pkcs8 option. But > then, certtool insists to read the password from the keyboard. Is it possible > to provide the password on stdin or something? Unfortunately, --generate-self-signed don't seem to be able to handle encrypted keys: $ certtool --pkcs8 --generate-privkey --sec-param=high --outfile x509-ca-key.pem Generating a 3248 bit RSA private key... Enter password: $ certtool --pkcs8 --generate-self-signed --template ca.templ --load-privkey x509-ca-key.pem --outfile x509-ca.pem Generating a self signed certificate... certtool: importing --load-privkey: x509-ca-key.pem: Decryption has failed. Note that --generate-self-signed don't ask for the password. This time 3.2.4 from opensuse-13.1 -- Josef Wolf jw at raven.inka.de From rogerdpack2 at gmail.com Wed May 14 20:57:14 2014 From: rogerdpack2 at gmail.com (Roger Pack) Date: Wed, 14 May 2014 12:57:14 -0600 Subject: [gnutls-help] warning message Message-ID: Hello. As a note, with 3.2.14 I get this (somewhat annoying) error message when linking against gnutls static: /home/rogerdpack/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/i686-w64-mingw32/lib/libgnutls.a(sha256-ssse3-x86.o): warning: multiple common of `_gnutls_x86_cpuid_s' /home/rogerdpack/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/i686-w64-mingw32/lib/libgnutls.a(x86-common.o): warning: previous common is here /home/rogerdpack/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/i686-w64-mingw32/lib/libgnutls.a(sha256-ssse3-x86.o): warning: multiple common of `_gnutls_x86_cpuid_s' /home/rogerdpack/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/i686-w64-mingw32/lib/libgnutls.a(x86-common.o): warning: previous common is here LD ffprobe_g.exe /home/rogerdpack/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/i686-w64-mingw32/lib/libgnutls.a(sha256-ssse3-x86.o): warning: multiple common of `_gnutls_x86_cpuid_s' /home/rogerdpack/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/i686-w64-mingw32/lib/libgnutls.a(x86-common.o): warning: previous common is here Just noting it. -roger- From nmav at gnutls.org Wed May 14 22:00:30 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 14 May 2014 22:00:30 +0200 Subject: [gnutls-help] Creating password protected private keys with certtool? In-Reply-To: <20140514164700.GB22643@raven.inka.de> References: <20140514133714.GB9503@raven.inka.de> <53737F40.30205@fifthhorseman.net> <20140514145804.GA22643@raven.inka.de> <20140514164700.GB22643@raven.inka.de> Message-ID: <1400097630.13258.1.camel@nomad.lan> On Wed, 2014-05-14 at 18:47 +0200, Josef Wolf wrote: > On Wed, May 14, 2014 at 04:58:04PM +0200, Josef Wolf wrote: > > I just noticed that I get encrypted keys when I use the --pkcs8 option. But > > then, certtool insists to read the password from the keyboard. Is it possible > > to provide the password on stdin or something? > > Unfortunately, --generate-self-signed don't seem to be able to handle > encrypted keys: > > $ certtool --pkcs8 --generate-privkey --sec-param=high --outfile x509-ca-key.pem > Generating a 3248 bit RSA private key... > Enter password: > $ certtool --pkcs8 --generate-self-signed --template ca.templ --load-privkey x509-ca-key.pem --outfile x509-ca.pem > Generating a self signed certificate... > certtool: importing --load-privkey: x509-ca-key.pem: Decryption has failed. > Note that --generate-self-signed don't ask for the password. If you use a template certtool enters non-interactive mode (batch mode). Then you can only specify the password in the template or use --ask-pass (in the latest versions). regards, Nikos From jw at raven.inka.de Thu May 15 11:47:05 2014 From: jw at raven.inka.de (Josef Wolf) Date: Thu, 15 May 2014 11:47:05 +0200 Subject: [gnutls-help] Creating password protected private keys with certtool? In-Reply-To: <1400097630.13258.1.camel@nomad.lan> References: <20140514133714.GB9503@raven.inka.de> <53737F40.30205@fifthhorseman.net> <20140514145804.GA22643@raven.inka.de> <20140514164700.GB22643@raven.inka.de> <1400097630.13258.1.camel@nomad.lan> Message-ID: <20140515094704.GC22643@raven.inka.de> On Wed, May 14, 2014 at 10:00:30PM +0200, Nikos Mavrogiannopoulos wrote: > On Wed, 2014-05-14 at 18:47 +0200, Josef Wolf wrote: > > Note that --generate-self-signed don't ask for the password. > > If you use a template certtool enters non-interactive mode (batch mode). > Then you can only specify the password in the template or use --ask-pass > (in the latest versions). Oh, I see. Is there any other way to non-interactively pass the password? Passing via --password makes it visible to the ps command. Passing via file makes it readable in the case of crashes, when the removal of the file might fail. I tried the usual unix convention to pass the template on stdin by giving '-', but certtool tries to open a file named '-' then. I know, I can play tricks like deleting the file before writing to it and pass /proc/xxx/fd/yy as filename to certtool. But that would be highly unportable. -- Josef Wolf jw at raven.inka.de From jw at raven.inka.de Thu May 15 12:08:06 2014 From: jw at raven.inka.de (Josef Wolf) Date: Thu, 15 May 2014 12:08:06 +0200 Subject: [gnutls-help] certtool: Serial number only 31 bit? Message-ID: <20140515100805.GD22643@raven.inka.de> Hello, I am currently trying to use UUIDs (as Bignum) for the serial number of certificates. AFAIK, the RFC 5280 allows up to 20 octets. But I have a hard time to specify more than 31 bits in the template file. With a prefix of 0x (indicating hex number), I get serial number 0. Ough! Given as a decimal number, the number is truncated to 0x7fffffff. Is this a limitation in certtool or am I missing something? -- Josef Wolf jw at raven.inka.de From noel at familie-kuntze.de Thu May 15 11:52:31 2014 From: noel at familie-kuntze.de (Noel Kuntze) Date: Thu, 15 May 2014 11:52:31 +0200 Subject: [gnutls-help] Creating password protected private keys with certtool? In-Reply-To: <20140515094704.GC22643@raven.inka.de> References: <20140514133714.GB9503@raven.inka.de> <53737F40.30205@fifthhorseman.net> <20140514145804.GA22643@raven.inka.de> <20140514164700.GB22643@raven.inka.de> <1400097630.13258.1.camel@nomad.lan> <20140515094704.GC22643@raven.inka.de> Message-ID: <53748E5F.6070301@familie-kuntze.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello Josef, You can pass /dev/stdin instead of the file. /dev/stdin is a special device on *nix systems pointing to the program's standard input. If certtool doesn't do seeks on the file, it should work fine. Regards, Noel Kuntze Am 15.05.2014 11:47, schrieb Josef Wolf: > On Wed, May 14, 2014 at 10:00:30PM +0200, Nikos Mavrogiannopoulos wrote: >> On Wed, 2014-05-14 at 18:47 +0200, Josef Wolf wrote: >>> Note that --generate-self-signed don't ask for the password. >> >> If you use a template certtool enters non-interactive mode (batch mode). >> Then you can only specify the password in the template or use --ask-pass >> (in the latest versions). > > Oh, I see. > > Is there any other way to non-interactively pass the password? > > Passing via --password makes it visible to the ps command. > > Passing via file makes it readable in the case of crashes, when the removal of > the file might fail. > > I tried the usual unix convention to pass the template on stdin by giving '-', > but certtool tries to open a file named '-' then. > > I know, I can play tricks like deleting the file before writing to it and pass > /proc/xxx/fd/yy as filename to certtool. But that would be highly unportable. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTdI5fAAoJEDg5KY9j7GZYvS8QAJ5a7UGCO+Jm4zreOkeIAc1r iN6holOlTMOJONUq42d/+42UhQaACJzh4IS9BvJSiquDPHJ9hO+xcTyAWYt2Mnku 3GtybtUaOzH0jCK2Lyx+NEZiLpqJvuSBavTxN27AjMn1aQL9+lCQ108PtyCFlSbZ Qu9Xaaek/nuK0hbFAulzGwC+VLlQMsH3PQuRUDeO/eEx+xx1uTKVHILM6ThA9L+x 3KZHPJYubrQ6bSyRznJu37OAXgxuHiKZMwvhbcJaABpI+tDfJ2xbHGkonRbjLJxg kwd7zZ/dInCO35tiJqAY5DdOsR0zSdJk1ER6HOHRB7uO3j0t6+stWcEsye7pvkN4 bkVnCJ2Uo41qBEYIQpFhndQ4SItjcn8vqK9KGm7jyxlZYCFFNMSfURLHEjAl7PCb r76gY9cpclww0WF6dGDWqFtzopXRfNkFtEZhdLaSOcRYPxVS1YdCCJgz4IfS/l1d DYCDNMTv3pqCfo4TC3uqbS3TQAL6DthDEL+gtVo7ggWQP/tauGn6zdBLU34BcN2L hxtGwOlNN1tQs5mD1YO6LHQtVggTQWwVdOEAnZGXMgS+KXfIKD+lNnZNkDIXUBfJ wrNpXg7l9sGjxA1ma2oRF9D8IxXGtODtN4QnaK+xqnXUlT7fx9mVaxXbgwGKG9mY yjKH+5FHKrhPKBWnmAII =IKw1 -----END PGP SIGNATURE----- From jw at raven.inka.de Thu May 15 13:06:21 2014 From: jw at raven.inka.de (Josef Wolf) Date: Thu, 15 May 2014 13:06:21 +0200 Subject: [gnutls-help] Creating password protected private keys with certtool? In-Reply-To: <53748E5F.6070301@familie-kuntze.de> References: <20140514133714.GB9503@raven.inka.de> <53737F40.30205@fifthhorseman.net> <20140514145804.GA22643@raven.inka.de> <20140514164700.GB22643@raven.inka.de> <1400097630.13258.1.camel@nomad.lan> <20140515094704.GC22643@raven.inka.de> <53748E5F.6070301@familie-kuntze.de> Message-ID: <20140515110621.GE22643@raven.inka.de> On Thu, May 15, 2014 at 11:52:31AM +0200, Noel Kuntze wrote: > You can pass /dev/stdin instead of the file. > /dev/stdin is a special device on *nix systems pointing to the program's standard input. > If certtool doesn't do seeks on the file, it should work fine. Noel, this sounds reasonable. But certtool insists to get a regular file: $ certtool --pkcs8 --template /dev/stdin --generate-privkey --outfile CA-key.pem fs error 22 (Invalid argument) on stat-ing for regular file /dev/stdin for option template Looks like I am stuck to something like: sub with_template { my ($template_contents, $certtool_args) = @_; use File::Temp qw(tempfile tempdir); File::Temp->safe_level (File::Temp::HIGH); my ($newfh, $newfn) = tempfile (UNLINK=>1); unlink $newfn; print $newfh join ("\n", @$template_contents, ""); &certtool("--template"=>"/proc/$$/fd/".fileno($newfh), @$certtool_args); close $newfh; } -- Josef Wolf jw at raven.inka.de From nmav at gnutls.org Thu May 15 13:49:14 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 15 May 2014 13:49:14 +0200 Subject: [gnutls-help] certtool: Serial number only 31 bit? In-Reply-To: <20140515100805.GD22643@raven.inka.de> References: <20140515100805.GD22643@raven.inka.de> Message-ID: On Thu, May 15, 2014 at 12:08 PM, Josef Wolf wrote: > Hello, > I am currently trying to use UUIDs (as Bignum) for the serial number of > certificates. AFAIK, the RFC 5280 allows up to 20 octets. But I have a hard > time to specify more than 31 bits in the template file. > With a prefix of 0x (indicating hex number), I get serial number 0. Ough! > Given as a decimal number, the number is truncated to 0x7fffffff. > Is this a limitation in certtool or am I missing something? It was a limitation. Support for up to 63-bit serial numbers was added in 3.3.0. regards, Nikos From nmav at gnutls.org Thu May 15 14:05:35 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 15 May 2014 14:05:35 +0200 Subject: [gnutls-help] Creating password protected private keys with certtool? In-Reply-To: <20140515110621.GE22643@raven.inka.de> References: <20140514133714.GB9503@raven.inka.de> <53737F40.30205@fifthhorseman.net> <20140514145804.GA22643@raven.inka.de> <20140514164700.GB22643@raven.inka.de> <1400097630.13258.1.camel@nomad.lan> <20140515094704.GC22643@raven.inka.de> <53748E5F.6070301@familie-kuntze.de> <20140515110621.GE22643@raven.inka.de> Message-ID: On Thu, May 15, 2014 at 1:06 PM, Josef Wolf wrote: > On Thu, May 15, 2014 at 11:52:31AM +0200, Noel Kuntze wrote: >> You can pass /dev/stdin instead of the file. >> /dev/stdin is a special device on *nix systems pointing to the program's standard input. >> If certtool doesn't do seeks on the file, it should work fine. > Noel, this sounds reasonable. But certtool insists to get a regular file: > $ certtool --pkcs8 --template /dev/stdin --generate-privkey --outfile CA-key.pem > fs error 22 (Invalid argument) on stat-ing for regular file /dev/stdin for option template Good to know. It was imposed by autogen's file option. I've now lifted that limitation. regards, Nikos From nmav at gnutls.org Thu May 15 14:12:01 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 15 May 2014 14:12:01 +0200 Subject: [gnutls-help] warning message In-Reply-To: References: Message-ID: On Wed, May 14, 2014 at 8:57 PM, Roger Pack wrote: > Hello. As a note, with 3.2.14 I get this (somewhat annoying) error > message when linking against gnutls static: > /home/rogerdpack/dev/ffmpeg-windows-build-helpers/sandbox/mingw-w64-i686/i686-w64-mingw32/lib/libgnutls.a(sha256-ssse3-x86.o): > warning: multiple common of `_gnutls_x86_cpuid_s' I don't see any obvious multiple definition on these files. It could be an issue I couldn't figure though, if it is, a fix is welcome. regards, Nikos From jw at raven.inka.de Thu May 15 14:22:17 2014 From: jw at raven.inka.de (Josef Wolf) Date: Thu, 15 May 2014 14:22:17 +0200 Subject: [gnutls-help] Creating password protected private keys with certtool? In-Reply-To: References: <20140514133714.GB9503@raven.inka.de> <53737F40.30205@fifthhorseman.net> <20140514145804.GA22643@raven.inka.de> <20140514164700.GB22643@raven.inka.de> <1400097630.13258.1.camel@nomad.lan> <20140515094704.GC22643@raven.inka.de> <53748E5F.6070301@familie-kuntze.de> <20140515110621.GE22643@raven.inka.de> Message-ID: <20140515122217.GF22643@raven.inka.de> On Thu, May 15, 2014 at 02:05:35PM +0200, Nikos Mavrogiannopoulos wrote: > On Thu, May 15, 2014 at 1:06 PM, Josef Wolf wrote: > > On Thu, May 15, 2014 at 11:52:31AM +0200, Noel Kuntze wrote: > >> You can pass /dev/stdin instead of the file. > >> /dev/stdin is a special device on *nix systems pointing to the program's standard input. > >> If certtool doesn't do seeks on the file, it should work fine. > > Noel, this sounds reasonable. But certtool insists to get a regular file: > > $ certtool --pkcs8 --template /dev/stdin --generate-privkey --outfile CA-key.pem > > fs error 22 (Invalid argument) on stat-ing for regular file /dev/stdin for option template > > Good to know. It was imposed by autogen's file option. I've now lifted > that limitation. Nikos, I'm not really sure whether this is a good idea. After all, insisting on regular files prevents against symlink attacks. Maybe a better solution would be to go for the unix tradition and special-case the '-' to mean stdin/stdout (depending on context) -- Josef Wolf jw at raven.inka.de From nmav at gnutls.org Thu May 15 18:14:03 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 15 May 2014 18:14:03 +0200 Subject: [gnutls-help] Creating password protected private keys with certtool? In-Reply-To: <20140515122217.GF22643@raven.inka.de> References: <20140514133714.GB9503@raven.inka.de> <53737F40.30205@fifthhorseman.net> <20140514145804.GA22643@raven.inka.de> <20140514164700.GB22643@raven.inka.de> <1400097630.13258.1.camel@nomad.lan> <20140515094704.GC22643@raven.inka.de> <53748E5F.6070301@familie-kuntze.de> <20140515110621.GE22643@raven.inka.de> <20140515122217.GF22643@raven.inka.de> Message-ID: On Thu, May 15, 2014 at 2:22 PM, Josef Wolf wrote: >> Good to know. It was imposed by autogen's file option. I've now lifted >> that limitation. > Nikos, I'm not really sure whether this is a good idea. After all, insisting > on regular files prevents against symlink attacks. > Maybe a better solution would be to go for the unix tradition and special-case > the '-' to mean stdin/stdout (depending on context) I'm not sure it's worth the effort checking for proper files. About the '-' addition it sounds good, but it's quite a big change with quite some side-effects. Inr your use-case specifically i think that --ask-pass is more useful than '-'. regards, Nikos From jw at raven.inka.de Thu May 15 22:49:49 2014 From: jw at raven.inka.de (Josef Wolf) Date: Thu, 15 May 2014 22:49:49 +0200 Subject: [gnutls-help] certtool: Serial number only 31 bit? In-Reply-To: References: <20140515100805.GD22643@raven.inka.de> Message-ID: <20140515204949.GG22643@raven.inka.de> On Thu, May 15, 2014 at 01:49:14PM +0200, Nikos Mavrogiannopoulos wrote: > On Thu, May 15, 2014 at 12:08 PM, Josef Wolf wrote: > > Hello, > > I am currently trying to use UUIDs (as Bignum) for the serial number of > > certificates. AFAIK, the RFC 5280 allows up to 20 octets. But I have a hard > > time to specify more than 31 bits in the template file. > > With a prefix of 0x (indicating hex number), I get serial number 0. Ough! > > Given as a decimal number, the number is truncated to 0x7fffffff. > > Is this a limitation in certtool or am I missing something? > > It was a limitation. Support for up to 63-bit serial numbers was added in 3.3.0. Well, I don't think the limitation is really removed. The RFC specifies this field to 20 octets. That would be 160 bits, right? To store a UUID, 128 bits would be needed. For me, it's not a big deal. I don't expect to ever need more that 10 certificates per CA. 31 random bits would be more than enough for me. In the case of a collision, re-generating the certificate would be no big deal. But for real-world applications, defaulting to (internal generated) UUID instead of time-based serials would be a _big_ win. IMHO. -- Josef Wolf jw at raven.inka.de From dkg at fifthhorseman.net Fri May 16 15:31:18 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 16 May 2014 07:31:18 -0600 Subject: [gnutls-help] Creating password protected private keys with certtool? In-Reply-To: <20140515122217.GF22643@raven.inka.de> References: <20140514133714.GB9503@raven.inka.de> <53737F40.30205@fifthhorseman.net> <20140514145804.GA22643@raven.inka.de> <20140514164700.GB22643@raven.inka.de> <1400097630.13258.1.camel@nomad.lan> <20140515094704.GC22643@raven.inka.de> <53748E5F.6070301@familie-kuntze.de> <20140515110621.GE22643@raven.inka.de> <20140515122217.GF22643@raven.inka.de> Message-ID: <53761326.1040008@fifthhorseman.net> On 05/15/2014 06:22 AM, Josef Wolf wrote: > Nikos, I'm not really sure whether this is a good idea. After all, insisting > on regular files prevents against symlink attacks. can you describe what symlink attack you're concerned about in the context of reading a password from a file? If the attacker is in control of the certtool invocation, they can already specify an arbitrary file. If the attacker is *not* in control of the invocation, then the user should be able to responsibly choose the file that they're interested in without certtool risking opening the wrong one. So i don't see how a symlink attack works in this context. Can you explain? --dkg PS i also like the idea of being able to set it to a fifo, so that a wrapper script around certtool can set up a program that feeds its input to the fifo and the password never hits the disk. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Sat May 17 21:22:21 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 17 May 2014 21:22:21 +0200 Subject: [gnutls-help] certtool: Serial number only 31 bit? In-Reply-To: <20140515204949.GG22643@raven.inka.de> References: <20140515100805.GD22643@raven.inka.de> <20140515204949.GG22643@raven.inka.de> Message-ID: <1400354541.16731.3.camel@nomad.lan> On Thu, 2014-05-15 at 22:49 +0200, Josef Wolf wrote: > On Thu, May 15, 2014 at 01:49:14PM +0200, Nikos Mavrogiannopoulos wrote: > > On Thu, May 15, 2014 at 12:08 PM, Josef Wolf wrote: > > > Hello, > > > I am currently trying to use UUIDs (as Bignum) for the serial number of > > > certificates. AFAIK, the RFC 5280 allows up to 20 octets. But I have a hard > > > time to specify more than 31 bits in the template file. > > > With a prefix of 0x (indicating hex number), I get serial number 0. Ough! > > > Given as a decimal number, the number is truncated to 0x7fffffff. > > > Is this a limitation in certtool or am I missing something? > > > > It was a limitation. Support for up to 63-bit serial numbers was added in 3.3.0. > > Well, I don't think the limitation is really removed. The RFC specifies this > field to 20 octets. That would be 160 bits, right? To store a UUID, 128 bits > would be needed. That is the maximum number allowed, not a recommended value or so. > For me, it's not a big deal. I don't expect to ever need more that 10 > certificates per CA. 31 random bits would be more than enough for me. In the > case of a collision, re-generating the certificate would be no big deal. > But for real-world applications, defaulting to (internal generated) UUID > instead of time-based serials would be a _big_ win. IMHO. The purpose of certtool is to provide an easy way to generate certificates for simple purposes and a 64-bit serial number seemed sufficient at the moment. I'd certainly consider though any enhancement patch that allows for arbitrary serial numbers. regards, Nikos From DouglasAtkinson at my.unt.edu Sun May 18 06:42:34 2014 From: DouglasAtkinson at my.unt.edu (Atkinson, Douglas) Date: Sun, 18 May 2014 04:42:34 +0000 Subject: [gnutls-help] Installing GnuTLS on a Raspberry Pi Message-ID: <1400388154589.15393@my.unt.edu> Hi, I am hoping someone who reads this will have successfully installed GnuTLS on a Raspberry Pi and is willing to walk me through it. I am trying to install the latest version of GnuTLS on a Raspberry Pi. Entering the following command $ ./configure --prefix=/usr ends by telling my that Libnettle 2.7 was not found. However, I know I have installed nettle. I double checked and sure enough I have both libnettle.so.4 and libnettle.so.4.3 located in /usr/lib/arm-linux-gnueablihf/ I am wondering if it has something to do with the location of the library. The location seems unusual to me, but this is where all the libraries appear to be located. Any help at all would be greatly appreciated. Sincerely, Douglas Atkinson -------------- next part -------------- An HTML attachment was scrubbed... URL: From bavariasound at chiemgau-net.de Sun May 18 08:33:26 2014 From: bavariasound at chiemgau-net.de (Alexander Ausserstorfer) Date: Sun, 18 May 2014 08:33:26 +0200 Subject: [gnutls-help] Installing GnuTLS on a Raspberry Pi In-Reply-To: <1400388154589.15393@my.unt.edu> References: <1400388154589.15393@my.unt.edu> Message-ID: <53785436.4070902@chiemgau-net.de> Am 18.05.2014 06:42, schrieb Atkinson, Douglas: > I am hoping someone who reads this will have successfully installed GnuTLS on a Raspberry Pi and is willing to walk me through it. Just for notice, the instruction for RISC OS will be found at: http://www.arcsite.de/magazin/praxis/gnutls/index.html A. -- http://home.chiemgau-net.de/ausserstorfer/ From jw at raven.inka.de Mon May 19 11:36:51 2014 From: jw at raven.inka.de (Josef Wolf) Date: Mon, 19 May 2014 11:36:51 +0200 Subject: [gnutls-help] Creating password protected private keys with certtool? In-Reply-To: <53761326.1040008@fifthhorseman.net> References: <53737F40.30205@fifthhorseman.net> <20140514145804.GA22643@raven.inka.de> <20140514164700.GB22643@raven.inka.de> <1400097630.13258.1.camel@nomad.lan> <20140515094704.GC22643@raven.inka.de> <53748E5F.6070301@familie-kuntze.de> <20140515110621.GE22643@raven.inka.de> <20140515122217.GF22643@raven.inka.de> <53761326.1040008@fifthhorseman.net> Message-ID: <20140519093651.GH22643@raven.inka.de> On Fri, May 16, 2014 at 07:31:18AM -0600, Daniel Kahn Gillmor wrote: > On 05/15/2014 06:22 AM, Josef Wolf wrote: > > Nikos, I'm not really sure whether this is a good idea. After all, insisting > > on regular files prevents against symlink attacks. > > can you describe what symlink attack you're concerned about in the > context of reading a password from a file? > > If the attacker is in control of the certtool invocation, they can > already specify an arbitrary file. For a symlink attack, the attacker don't need to have control of the invocation of the tool. Instead, the attacker needs to guess the file name you are going to write to and create a link for that name that points to some place where you won't delete it. For example: if I happen to know that your wrapping script will write the template to e.g. /pki/CA/cert.cfg, I would create a symlink /pki/CA/cert.cfg -> /var/tmp/some-innocent-looking-filename Now you invoke your wrapping script and write the password to /var/tmp/some-innocent-looking-filename. When done, your wrapping script deletes the symlink instead of the file the link points to and the password is left for me to read when I come back the next time. With the check for regular files, you'd at least get a warning from certtool. Granted, I need write access to /PKI/CA for this attack to work. You might argue that once an attacker has FS-access everything is lost anyway. But this is exactly what the passphrase is good for: protecting the private key in the case somebody has FS-access. > If the attacker is *not* in control > of the invocation, then the user should be able to responsibly choose > the file that they're interested in without certtool risking opening the > wrong one. The problem here is the word "responsibly". For sure, _some_ people will think hard about it. But most people won't think at all about it. And even for those who think hard about it, certtool don't have a proper solution. All the examples of certtool invocation google finds are using fixed names for the template file. Even the example on www.gnutls.org/manual/html_node/certtool-Invocation.html uses a fixed filename for the template file! So I'd be willing to bet that 90% of the users won't think about randomizing the filename and make sure the file don't exist before they write to it. Not a single invocation example google finds even _mentions_ mktemp or something. You can bet that at least _some_ people will blindly follow recipes like they find them on the internet (e.g. blog.tremily.us/posts/X.509_certificates/) without even thinking about it. Please remember that security always has to deal with highly intelligent attackers and clueless or dumb users. This doesn't mean that all users are dumb. But _some_ definitely are. Call me paranoid, but in general, I don't think it is a good idea to store a password in a file. Even _if_ you do all sorts of checks and delete the file before actually writing to it: in the worst case the password can end up in unallocated blocks on the disk. > PS i also like the idea of being able to set it to a fifo, so that a > wrapper script around certtool can set up a program that feeds its input > to the fifo and the password never hits the disk. Named pipes? Please note that there's still a race condition here. The attacker might replace the fifo with a symlink after creation and before certtool-invocation. To prevent races, you need to pass an already-opened filehandle. Every program gets an already-opened filehandle passed for reading at startup: stdin. I'd rather pipe to stdin. This way, the attacker would have to attack either my wrapper or certtool directly. Or the OS. But that's a totally different story. -- Josef Wolf jw at raven.inka.de From bavariasound at chiemgau-net.de Mon May 19 20:38:26 2014 From: bavariasound at chiemgau-net.de (Alexander Ausserstorfer) Date: Mon, 19 May 2014 20:38:26 +0200 Subject: [gnutls-help] Installing GnuTLS on a Raspberry Pi In-Reply-To: <1400417635343.15721@my.unt.edu> References: <1400388154589.15393@my.unt.edu> <53785436.4070902@chiemgau-net.de> <1400417635343.15721@my.unt.edu> Message-ID: <7185600a54.Alex@bavariasound.chiemgau-net.de> In message <1400417635343.15721 at my.unt.edu> you wrote: > Thank you for the reply. The link you included goes to b a page in > German which I do not read. You would not happen to know if there is > a version of this page in English. I posted also an article (in English) to the newsgroup comp.sys.acorn.programmer if it helps you but I couldn't find it on my current machine yet. It seems that I had used another machine for it. It may be that you can find it in one of the Usenet archives, may be Google group. It isn't such a long time I posted it there, one month or so. Keep in mind that the information I posted there are for RISC OS, the native and fast operating system for ARM, not Unix. This is why I thought it isn't so important or helpful to you. I found two e-mails now with more information about it: > Here are the links to the libraries you'll need to download. You'll also > need GCC 4.1.2 to build it natively on RISC OS. > > http://www.riscos.info/packages/arm/Library/libgnutls-dev_2.12.20-1.zip > http://www.riscos.info/packages/arm/Library/libgmp-dev_5.0.5+dfsg-1.zip > http://www.riscos.info/packages/arm/Library/libgpg-error-dev_1.10-1.zip > http://www.riscos.info/packages/arm/Library/libnettle-dev_2.4-1.zip > http://www.riscos.info/packages/arm/Library/libtasn1-dev_2.14-1.zip > http://www.riscos.info/packages/arm/Library/zlib1g-dev_1.2.8-1.zip > http://www.riscos.info/packages/arm/Library/libgettext-dev_0.18.1.1-1.zip To build the code, you have to call !GCC with > wimpslot 6000k > gcc -O3 -static gnutls.c -ognutls -ILibGNUTLS: -LLibGMP: -lgmp -LLibGNUTLS: -lgnutls -LLibGPGError: -lgpg-error -LLibNettle: -lhogweed -lnettle -LLibTASN1: -ltasn1 -LZlib1g: -lz -LLibGetText: -lintl > elf2aif gnutls And then, there was a problem with older hardware (StrongARM): > I had a closer look at the libraries involved and that code belongs to > the libgmp library which contains a large set of ARM assembler routines > which use "BX" despite that library claiming to support ARMv4. > > Luckily enough, this is easy to fix so I've uploaded a new LibGMP-Dev > library for you (6.0.0+dfsg-2) which should fix your problem after a > relink : http://www.riscos.info/packages/LibraryDetails.html#LibGMP-Dev It is an older version of GnuTLS we're using on RISC OS at the moment. Hope this helps. Alex -- http://home.chiemgau-net.de/ausserstorfer/ Sent wirelessly from RISC OS per LTE From mydexterid at gmail.com Wed May 21 11:12:39 2014 From: mydexterid at gmail.com (DEXTER) Date: Wed, 21 May 2014 11:12:39 +0200 Subject: [gnutls-help] Interrupt and continue handshake from gnutls_handshake_set_post_client_hello_function() Message-ID: Hi, I'm trying to write a gnutls server where I can suspend the handshake procedure and then continue. What I'm trying to achieve is to get the SNI from the client, suspend the handshake, do something else depending on the SNI, then come back to the handshake and continue. So I connected a callback with gnutls_handshake_set_post_client_hello_function() and got the servername in the callback then return with GNUTLS_E_AGAIN. This will cause the gnutls_handshake(session) function to return with GNUTLS_E_AGAIN, so I can continue doing some other things. Also I save the data from the client into a temp buffer. Then some time later I call the gnutl_handshake(session) again, which causes the the pull_function to be called.(I have pull/push functions to read/write from sockets) In this function I simply give the data from the temp buffer (and when the buffer is empty, I continue reading from the client socket). The handshake continues, but at the end I receive: "An error was encountered at the TLS Finished packet calculation." Also.. if I simply deinit, then init the session again before continuing the handshake with the client, then I don't get the abovementioned error. The question is that is this the way one should do to continue a suspended handshake, or is there another way to do it? Thanks. Tdev -------------- next part -------------- An HTML attachment was scrubbed... URL: From mydexterid at gmail.com Wed May 21 16:28:20 2014 From: mydexterid at gmail.com (DEXTER) Date: Wed, 21 May 2014 16:28:20 +0200 Subject: [gnutls-help] deleting an extension from a x509 certificate Message-ID: Hi, Is there a way to delete an extension from an x509 certificate? I found no API to do that, only get/set apis. Also found a very old patch here: http://marc.info/?l=gnupg-commit-watchers&m=108192753710809 removing the ability to delete an extension. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Thu May 22 08:54:35 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 22 May 2014 08:54:35 +0200 Subject: [gnutls-help] Interrupt and continue handshake from gnutls_handshake_set_post_client_hello_function() In-Reply-To: References: Message-ID: On Wed, May 21, 2014 at 11:12 AM, DEXTER wrote: > Hi, > > I'm trying to write a gnutls server where I can suspend the handshake > procedure and then continue. > What I'm trying to achieve is to get the SNI from the client, suspend the > handshake, do something else depending on the SNI, then come back to the > handshake and continue. Hello, Why not do everything you need in the callback? As it is now the callback is not designed to allow interruption as you describe it. > The question is that is this the way one should do to continue a suspended > handshake, or is there another way to do it? Not that I know of. The best you can do is use the callback mechanisms. regards, Nikos From nmav at gnutls.org Thu May 22 09:03:25 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 22 May 2014 09:03:25 +0200 Subject: [gnutls-help] deleting an extension from a x509 certificate In-Reply-To: References: Message-ID: On Wed, May 21, 2014 at 4:28 PM, DEXTER wrote: > Hi, > > Is there a way to delete an extension from an x509 certificate? > I found no API to do that, only get/set apis. > Also found a very old patch here: > http://marc.info/?l=gnupg-commit-watchers&m=108192753710809 > removing the ability to delete an extension. It was never part of the API, as it is designed around the generate and read use-cases. Could you describe your use case for that functionality? regards, Nikos From mydexterid at gmail.com Thu May 22 11:42:38 2014 From: mydexterid at gmail.com (DEXTER) Date: Thu, 22 May 2014 11:42:38 +0200 Subject: [gnutls-help] deleting an extension from a x509 certificate In-Reply-To: References: Message-ID: Sure. In a proxy firewall environment, you have the server's certificate, and you want to copy that cert exactly as is, but you want to remove some of the extensions and show that to the client. In case of OpenSSL you have an api for that: int idx = X509_get_ext_by_NID( cert, nid, -1 ); //get the index X509_EXTENSION *ext = X509_get_ext(cert, idx); //get the extensionif (ext != NULL){ //check that the extension was found X509_delete_ext(cert, idx); //delete the extension X509_EXTENSION_free(ext); //free the memory} It would be great if GnuTLS had this functionality too. Without this api, can you tell me what is the way to copy a certificate and only remove some of the extensions from it? Thanks. On Thu, May 22, 2014 at 9:03 AM, Nikos Mavrogiannopoulos wrote: > On Wed, May 21, 2014 at 4:28 PM, DEXTER wrote: > > Hi, > > > > Is there a way to delete an extension from an x509 certificate? > > I found no API to do that, only get/set apis. > > Also found a very old patch here: > > http://marc.info/?l=gnupg-commit-watchers&m=108192753710809 > > removing the ability to delete an extension. > > It was never part of the API, as it is designed around the generate > and read use-cases. Could you describe your use case for that > functionality? > > regards, > Nikos > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mydexterid at gmail.com Thu May 22 13:00:29 2014 From: mydexterid at gmail.com (DEXTER) Date: Thu, 22 May 2014 13:00:29 +0200 Subject: [gnutls-help] Interrupt and continue handshake from gnutls_handshake_set_post_client_hello_function() In-Reply-To: References: Message-ID: The main reason is that in a proxying environment when you get the sni from the client, you need to connect to the server first, get the certificate, and send that certificate back to the client. You see that this is only possible if I suspend the handshake with the client and continue with the server, and after I got the certificate I can continue with the client. The callback mechanism in GnuTLS would be good if I could return from it with something like (SUSPEND, or even E_AGAIN, E_INTERRUPT), and next time I call the gnutls_handshake function it would continue where it left off. On Thu, May 22, 2014 at 8:54 AM, Nikos Mavrogiannopoulos wrote: > On Wed, May 21, 2014 at 11:12 AM, DEXTER wrote: > > Hi, > > > > I'm trying to write a gnutls server where I can suspend the handshake > > procedure and then continue. > > What I'm trying to achieve is to get the SNI from the client, suspend the > > handshake, do something else depending on the SNI, then come back to the > > handshake and continue. > > Hello, > Why not do everything you need in the callback? As it is now the > callback is not designed to allow interruption as you describe it. > > > The question is that is this the way one should do to continue a > suspended > > handshake, or is there another way to do it? > > Not that I know of. The best you can do is use the callback mechanisms. > > regards, > Nikos > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Thu May 22 17:28:36 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 22 May 2014 17:28:36 +0200 Subject: [gnutls-help] deleting an extension from a x509 certificate In-Reply-To: References: Message-ID: On Thu, May 22, 2014 at 11:42 AM, DEXTER wrote: > Sure. In a proxy firewall environment, you have the server's certificate, > and you want to copy that cert exactly as is, but you want to remove some of > the extensions and show that to the client. > In case of OpenSSL you have an api for that: > int idx = X509_get_ext_by_NID( cert, nid, -1 ); //get the index > X509_EXTENSION *ext = X509_get_ext(cert, idx); //get the extension > if (ext != NULL){ //check that the extension was found > X509_delete_ext(cert, idx); //delete the extension > X509_EXTENSION_free(ext); //free the memory > } > > It would be great if GnuTLS had this functionality too. > Without this api, can you tell me what is the way to copy a certificate and > only remove some of the extensions from it? As it is now you have to create a new certificate and copy everything you need there. In 3.3.x it is a bit simpler as you can simply copy the DER-encoded extensions, but there is no API to manipulate certificates, other than add elements. What you specify can be indeed useful to have, but I don't plan to work on it any time soon. I'd certainly consider adding that if you contribute the needed pieces. regards, Nikos From nmav at gnutls.org Thu May 22 19:41:52 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 22 May 2014 19:41:52 +0200 Subject: [gnutls-help] Interrupt and continue handshake from gnutls_handshake_set_post_client_hello_function() In-Reply-To: References: Message-ID: On Thu, May 22, 2014 at 1:00 PM, DEXTER wrote: > The main reason is that in a proxying environment when you get the sni from > the client, you need to connect to the server first, get the certificate, > and send that certificate back to the client. > You see that this is only possible if I suspend the handshake with the > client and continue with the server, and after I got the certificate I can > continue with the client. That could be possible to add in 3.3.x. I'll check it out. regards, Nikos From mydexterid at gmail.com Fri May 23 10:45:29 2014 From: mydexterid at gmail.com (DEXTER) Date: Fri, 23 May 2014 10:45:29 +0200 Subject: [gnutls-help] deleting an extension from a x509 certificate In-Reply-To: References: Message-ID: I see. We haven't decided yet whether to use GnuTLS or OpenSSL, but if we decide to go with GnuTLS I'll certainly make that patch. Thank you. On Thu, May 22, 2014 at 5:28 PM, Nikos Mavrogiannopoulos wrote: > On Thu, May 22, 2014 at 11:42 AM, DEXTER wrote: > > Sure. In a proxy firewall environment, you have the server's certificate, > > and you want to copy that cert exactly as is, but you want to remove > some of > > the extensions and show that to the client. > > In case of OpenSSL you have an api for that: > > int idx = X509_get_ext_by_NID( cert, nid, -1 ); //get the index > > X509_EXTENSION *ext = X509_get_ext(cert, idx); //get the extension > > if (ext != NULL){ //check that the extension was found > > X509_delete_ext(cert, idx); //delete the extension > > X509_EXTENSION_free(ext); //free the memory > > } > > > > It would be great if GnuTLS had this functionality too. > > Without this api, can you tell me what is the way to copy a certificate > and > > only remove some of the extensions from it? > > As it is now you have to create a new certificate and copy everything > you need there. In 3.3.x it is a bit simpler as you can simply copy > the DER-encoded extensions, but there is no API to manipulate > certificates, other than add elements. What you specify can be indeed > useful to have, but I don't plan to work on it any time soon. I'd > certainly consider adding that if you contribute the needed pieces. > > regards, > Nikos > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mydexterid at gmail.com Fri May 23 10:46:04 2014 From: mydexterid at gmail.com (DEXTER) Date: Fri, 23 May 2014 10:46:04 +0200 Subject: [gnutls-help] Interrupt and continue handshake from gnutls_handshake_set_post_client_hello_function() In-Reply-To: References: Message-ID: Thank you. On Thu, May 22, 2014 at 7:41 PM, Nikos Mavrogiannopoulos wrote: > On Thu, May 22, 2014 at 1:00 PM, DEXTER wrote: > > The main reason is that in a proxying environment when you get the sni > from > > the client, you need to connect to the server first, get the certificate, > > and send that certificate back to the client. > > You see that this is only possible if I suspend the handshake with the > > client and continue with the server, and after I got the certificate I > can > > continue with the client. > > That could be possible to add in 3.3.x. I'll check it out. > > regards, > Nikos > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vittorio.giovara at savoirfairelinux.com Sat May 24 01:20:53 2014 From: vittorio.giovara at savoirfairelinux.com (Vittorio Giovara) Date: Fri, 23 May 2014 19:20:53 -0400 Subject: [gnutls-help] decoding memory buffers in a tls session Message-ID: <537FD7D5.8070000@savoirfairelinux.com> Hello everyone, I am in the process of implementing a GnuTLS backend to PJSIP, a popular voip/sip library, and I started off by editing the OpenSSL backend. Normally the library uses a complex callback mechanism that informs the underlying secure socket layer that data has been read from the (normal) socket and then it waits for the callback return value containing the decrypted data. With openssl this is implemented by heavy use of BIO_read/BIO_write functions, however it is where I am stuck during my porting. As far as I understand the gnutls logic, everything must go through gnutls_record_send and gnutls_record_recv, but there is no way to use the session information to decrypt a raw memory buffer isn't there? I have tried to hack things around saving the externally-received buffer and hijacking the _recv function so that it would decrypt that buffer only, instead of waiting to receive on the socket, but I must be doing something wrong as I always get a 'tls packet with wrong length'. If anyone could give some advice I'd really appreciate that; the currently WIP code is here if anyone want to look https://github.com/kodabb/pjproject/blob/gnutls/pjlib/src/pj/ssl_sock_ossl.c Thanks for any suggestions, Vittorio From nmav at gnutls.org Sat May 24 09:40:16 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 24 May 2014 09:40:16 +0200 Subject: [gnutls-help] decoding memory buffers in a tls session In-Reply-To: <537FD7D5.8070000@savoirfairelinux.com> References: <537FD7D5.8070000@savoirfairelinux.com> Message-ID: <1400917216.19659.11.camel@nomad.lan> On Fri, 2014-05-23 at 19:20 -0400, Vittorio Giovara wrote: > Hello everyone, > I am in the process of implementing a GnuTLS backend to PJSIP, a popular > voip/sip library, and I started off by editing the OpenSSL backend. > > Normally the library uses a complex callback mechanism that informs the > underlying secure socket layer that data has been read from the (normal) > socket and then it waits for the callback return value containing the > decrypted data. With openssl this is implemented by heavy use of > BIO_read/BIO_write functions, however it is where I am stuck during my > porting. > As far as I understand the gnutls logic, everything must go through > gnutls_record_send and gnutls_record_recv, but there is no way to use > the session information to decrypt a raw memory buffer isn't there? Hello, You could replace the pull function to read from memory, and then gnutls_record_recv() would decrypt from memory (and I see that's what you actually do). > I > have tried to hack things around saving the externally-received buffer > and hijacking the _recv function so that it would decrypt that buffer > only, instead of waiting to receive on the socket, but I must be doing > something wrong as I always get a 'tls packet with wrong length'. > if (ssock->hack) { > data = ssock->hack; Shouldn't you do a memcpy there? regards, Nikos From vittorio.giovara at savoirfairelinux.com Tue May 27 00:31:59 2014 From: vittorio.giovara at savoirfairelinux.com (Vittorio Giovara) Date: Mon, 26 May 2014 18:31:59 -0400 Subject: [gnutls-help] decoding memory buffers in a tls session In-Reply-To: <1400917216.19659.11.camel@nomad.lan> References: <537FD7D5.8070000@savoirfairelinux.com> <1400917216.19659.11.camel@nomad.lan> Message-ID: <5383C0DF.3050802@savoirfairelinux.com> On 2014-05-24 03:40, Nikos Mavrogiannopoulos wrote: > On Fri, 2014-05-23 at 19:20 -0400, Vittorio Giovara wrote: >> As far as I understand the gnutls logic, everything must go through >> gnutls_record_send and gnutls_record_recv, but there is no way to use >> the session information to decrypt a raw memory buffer isn't there? > Hello, > You could replace the pull function to read from memory, and then > gnutls_record_recv() would decrypt from memory (and I see that's what > you actually do). Hello, I actually got it working that way: my mistake was that I had thought that my data_pull() received the same length parameter as gnutls_record_recv() while instead it was performing two separate reads (header and packet). > >> if (ssock->hack) { >> data = ssock->hack; > Shouldn't you do a memcpy there? Indeed, thanks for spotting it. Vittorio > regards, > Nikos > > From nmav at gnutls.org Fri May 30 07:25:49 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 30 May 2014 07:25:49 +0200 Subject: [gnutls-help] gnutls 3.1.25 Message-ID: <1401427549.2644.2.camel@nomad.lan> Hello, I've just released gnutls 3.1.25. This is a bug fix release on the old stable branch, which addresses the http://www.gnutls.org/security.html#GNUTLS-SA-2014-3 security advisory. * Version 3.1.25 (released 2014-05-30) ** libgnutls: Eliminated memory corruption issue in Server Hello parsing. Issue reported by Joonas Kuorilehto of Codenomicon. ** libgnutls: Increased the maximum certificate size buffer in the PKCS #11 subsystem. ** libgnutls: Check the return code of getpwuid_r() instead of relying on the result value. That avoids issue in certain systems, when using tofu authentication and the home path cannot be determined. Issue reported by Viktor Dukhovni. ** ocsptool: Include path in ocsp request. This resolves #108582 (https://savannah.gnu.org/support/?108582), reported by Matt McCutchen. ** 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.25.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.25.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.25.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.25.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 Fri May 30 07:27:12 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 30 May 2014 07:27:12 +0200 Subject: [gnutls-help] gnutls 3.2.15 Message-ID: <1401427632.2644.4.camel@nomad.lan> Hello, I've just released gnutls 3.2.15. This is a bugfix release on the current stable branch, which addresses the http://www.gnutls.org/security.html#GNUTLS-SA-2014-3 security advisory. * Version 3.2.15 (released 2014-05-30) ** libgnutls: Eliminated memory corruption issue in Server Hello parsing. Issue reported by Joonas Kuorilehto of Codenomicon. ** libgnutls: Several memory leaks caused by error conditions were fixed. The leaks were identified using valgrind and the Codenomicon TLS test suite. ** libgnutls: Increased the maximum certificate size buffer in the PKCS #11 subsystem. ** libgnutls: Check the return code of getpwuid_r() instead of relying on the result value. That avoids issue in certain systems, when using tofu authentication and the home path cannot be determined. Issue reported by Viktor Dukhovni. ** gnutls-cli: if dane is requested but not PKIX verification, then only do verify the end certificate. ** ocsptool: Include path in ocsp request. This resolves #108582 (https://savannah.gnu.org/support/?108582), reported by Matt McCutchen. ** 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.15.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.15.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.15.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.15.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 Fri May 30 07:28:26 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 30 May 2014 07:28:26 +0200 Subject: [gnutls-help] gnutls 3.3.3 Message-ID: <1401427706.2644.5.camel@nomad.lan> Hello, I've just released gnutls 3.3.3. This is a bugfix release on the next stable branch, which addresses the http://www.gnutls.org/security.html#GNUTLS-SA-2014-3 security advisory. * Version 3.3.3 (released 2014-05-30) ** libgnutls: Eliminated memory corruption issue in Server Hello parsing. Issue reported by Joonas Kuorilehto of Codenomicon. ** libgnutls: gnutls_global_set_mutex() was modified to operate with the new initialization process. ** libgnutls: Increased the maximum certificate size buffer in the PKCS #11 subsystem. ** libgnutls: Check the return code of getpwuid_r() instead of relying on the result value. That avoids issue in certain systems, when using tofu authentication and the home path cannot be determined. Issue reported by Viktor Dukhovni. ** libgnutls-dane: Improved dane_verify_session_crt(), which now attempts to create a full chain. This addresses points from https://savannah.gnu.org/support/index.php?108552 ** gnutls-cli: --dane will only check the end certificate if PKIX validation has been disabled. ** gnutls-cli: --benchmark-soft-ciphers has been removed. That option cannot be emulated with the implicit initialization of gnutls. ** certtool: Allow multiple organizations and organizational unit names to be specified in a template. ** certtool: Warn when invalid configuration options are set to a template. ** ocsptool: Include path in ocsp request. This resolves #108582 (https://savannah.gnu.org/support/?108582), reported by Matt McCutchen. ** API and ABI modifications: gnutls_credentials_get: Added 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.3.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.3.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.3.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.3.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 vittorio.giovara at savoirfairelinux.com Fri May 30 23:37:01 2014 From: vittorio.giovara at savoirfairelinux.com (Vittorio Giovara) Date: Fri, 30 May 2014 17:37:01 -0400 Subject: [gnutls-help] decoding memory buffers in a tls session In-Reply-To: <1400917216.19659.11.camel@nomad.lan> References: <537FD7D5.8070000@savoirfairelinux.com> <1400917216.19659.11.camel@nomad.lan> Message-ID: <5388F9FD.2060203@savoirfairelinux.com> On 2014-05-24 03:40, Nikos Mavrogiannopoulos wrote: > On Fri, 2014-05-23 at 19:20 -0400, Vittorio Giovara wrote: >> Hello everyone, >> I am in the process of implementing a GnuTLS backend to PJSIP, a popular >> voip/sip library, and I started off by editing the OpenSSL backend. >> >> Normally the library uses a complex callback mechanism that informs the >> underlying secure socket layer that data has been read from the (normal) >> socket and then it waits for the callback return value containing the >> decrypted data. With openssl this is implemented by heavy use of >> BIO_read/BIO_write functions, however it is where I am stuck during my >> porting. >> As far as I understand the gnutls logic, everything must go through >> gnutls_record_send and gnutls_record_recv, but there is no way to use >> the session information to decrypt a raw memory buffer isn't there? > Hello, > You could replace the pull function to read from memory, and then > gnutls_record_recv() would decrypt from memory (and I see that's what > you actually do). Hello again, This method works fine for normal data transmission, but since I've tried to remove the do {} while loop when doing handshake (and rely on the application loop to retry the connection) I can't seem to find a way to complete the handshake. In fact when data from the callback is available and I hook it up the my record_recv callbacks they will fail instead of asking for more data (invalidating the session in the meantime). Is it possible to do a partial handshake, wait for some more data and then resume it again? Thanks, Vittorio > > From nmav at gnutls.org Sat May 31 10:43:39 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 31 May 2014 10:43:39 +0200 Subject: [gnutls-help] gnutls 3.3.4 Message-ID: <1401525819.4466.1.camel@nomad.lan> Hello, I've just released gnutls 3.3.4. This is fixes an issue on the hardware acceleration on certain CPUs that was introduced in the previous release. * Version 3.3.4 (released 2014-05-31) ** libgnutls: Updated Andy Polyakov's assembly code. That prevents a crash on certain CPUs. ** 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.4.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.4.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.4.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.4.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 Sat May 31 10:45:40 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 31 May 2014 10:45:40 +0200 Subject: [gnutls-help] decoding memory buffers in a tls session In-Reply-To: <5388F9FD.2060203@savoirfairelinux.com> References: <537FD7D5.8070000@savoirfairelinux.com> <1400917216.19659.11.camel@nomad.lan> <5388F9FD.2060203@savoirfairelinux.com> Message-ID: <1401525940.4466.3.camel@nomad.lan> On Fri, 2014-05-30 at 17:37 -0400, Vittorio Giovara wrote: > Hello again, > This method works fine for normal data transmission, but since I've > tried to remove the do {} while loop when doing handshake (and rely on > the application loop to retry the connection) I can't seem to find a way > to complete the handshake. > In fact when data from the callback is available and I hook it up the my > record_recv callbacks they will fail instead of asking for more data > (invalidating the session in the meantime). When you have no data you could return -1 and set errno to EAGAIN, i.e., emulate recv(). regards, Nikos