From parande1 at umbc.edu Fri Feb 5 01:15:40 2010 From: parande1 at umbc.edu (Mohammed Aziz Parande) Date: Thu, 4 Feb 2010 19:15:40 -0500 Subject: A Question About GNUTLS Message-ID: <00eb01caa5f8$5960f7c0$0c22e740$@edu> Hi, I am a graduate student in the Department of Information Systems at the University of Maryland, Baltimore County (UMBC). I am doing research in the area of software engineering. I would very much appreciate if you could answer the following questions of mine: 1. I was wondering if GNUTLS has gone under any major restructuring/redesign initiative in its history. Restructuring/redesign initiative can be defined as a concerted effort during a time period in which major changes were applied to the code base to improve software architecture/design while little or no functional enhancement was made. 2. If the project has gone under such an initiative, then would it be possible for you to give the dates or revision/release numbers that are "right before" and "right after" this structuring effort? I would like to checkout the source code from the repository to compare structural measurements that belong to "before" and "after" snapshots. Note that the dates and revision/release numbers should be right before and right after the initiative because I would like to be able to isolate and observe the effects of this effort. Your response will be very helpful in our research. Thank you very much for your time in advance. I look forward to hearing from you soon. Regards, Mohammed Aziz P.S. This research is solely performed for academic purposes. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wasiliyivanov at gmail.com Thu Feb 4 21:41:24 2010 From: wasiliyivanov at gmail.com (Vasiliy Ivanov) Date: Thu, 4 Feb 2010 22:41:24 +0200 Subject: Assertion failed Message-ID: <000601caa5da$6b36d690$41a483b0$@com> Hi! Please, help with libgnutls-26 on windows. It throw an assertion in ath.c (*locl == MUTEX_UNLOCKED) in version 2.9.9. Why I have assertion when libgnutls is a release(not debug) ? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Fri Feb 5 10:48:04 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 5 Feb 2010 10:48:04 +0100 Subject: Assertion failed In-Reply-To: <000601caa5da$6b36d690$41a483b0$@com> References: <000601caa5da$6b36d690$41a483b0$@com> Message-ID: Possibly you are using multiple threads and not initializing some lock functions. Check the manual on multithreaded applications. regards, Nikos On Thu, Feb 4, 2010 at 9:41 PM, Vasiliy Ivanov wrote: > Hi! Please, help with libgnutls-26 on windows. > > It throw an assertion in ath.c (*locl == MUTEX_UNLOCKED) in version 2.9.9. > > > > Why I have assertion when libgnutls is a release(not debug) ? > > > > Thanks! > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel > > From wk at gnupg.org Fri Feb 5 11:49:48 2010 From: wk at gnupg.org (Werner Koch) Date: Fri, 05 Feb 2010 11:49:48 +0100 Subject: Assertion failed In-Reply-To: (Nikos Mavrogiannopoulos's message of "Fri, 5 Feb 2010 10:48:04 +0100") References: <000601caa5da$6b36d690$41a483b0$@com> Message-ID: <87vdecj6sz.fsf@vigenere.g10code.de> > On Thu, Feb 4, 2010 at 9:41 PM, Vasiliy Ivanov wrote: >> Why I have assertion when libgnutls is a release(not debug) ? Because no sane developer would defined NDEBUG - assertions will only happen during real tests; which means in the field. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From simon at josefsson.org Fri Feb 5 13:50:52 2010 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 05 Feb 2010 13:50:52 +0100 Subject: A Question About GNUTLS In-Reply-To: <00eb01caa5f8$5960f7c0$0c22e740$@edu> (Mohammed Aziz Parande's message of "Thu, 4 Feb 2010 19:15:40 -0500") References: <00eb01caa5f8$5960f7c0$0c22e740$@edu> Message-ID: <87wryrsv6b.fsf@mocca.josefsson.org> "Mohammed Aziz Parande" writes: > > > Hi, > > > > I am a graduate student in the Department of Information Systems at the > University of Maryland, Baltimore County (UMBC). I am doing research in the > area of software engineering. I would very much appreciate if you could > answer the following questions of mine: > > > > 1. I was wondering if GNUTLS has gone under any major restructuring/redesign > initiative in its history. Restructuring/redesign initiative can be defined > as a concerted effort during a time period in which major changes were > applied to the code base to improve software architecture/design while > little or no functional enhancement was made. I don't recall any major such changes, maybe Nikos can tell more. There have been many minor and incremental changes, such as replacing parts with more portable code from gnulib, or switching to using a separate configure script in lib/ and libextra/. > 2. If the project has gone under such an initiative, then would it be > possible for you to give the dates or revision/release numbers that are > "right before" and "right after" this structuring effort? I would like to > checkout the source code from the repository to compare structural > measurements that belong to "before" and "after" snapshots. Note that the > dates and revision/release numbers should be right before and right after > the initiative because I would like to be able to isolate and observe the > effects of this effort. The changes that have been made have been fairly incremental and it is probably difficult to find two releases where there haven't been other changes too. /Simon > > > Your response will be very helpful in our research. Thank you very much for > your time in advance. I look forward to hearing from you soon. > > > > > > Regards, > > > > Mohammed Aziz > > > > P.S. This research is solely performed for academic purposes. > > > > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel From nmav at gnutls.org Fri Feb 5 15:49:37 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 05 Feb 2010 15:49:37 +0100 Subject: A Question About GNUTLS In-Reply-To: <87wryrsv6b.fsf@mocca.josefsson.org> References: <00eb01caa5f8$5960f7c0$0c22e740$@edu> <87wryrsv6b.fsf@mocca.josefsson.org> Message-ID: <4B6C3001.4080006@gnutls.org> Simon Josefsson wrote: > "Mohammed Aziz Parande" writes: > >> >> >> Hi, >> >> >> >> I am a graduate student in the Department of Information Systems at the >> University of Maryland, Baltimore County (UMBC). I am doing research in the >> area of software engineering. I would very much appreciate if you could >> answer the following questions of mine: >> >> >> >> 1. I was wondering if GNUTLS has gone under any major restructuring/redesign >> initiative in its history. Restructuring/redesign initiative can be defined >> as a concerted effort during a time period in which major changes were >> applied to the code base to improve software architecture/design while >> little or no functional enhancement was made. > I don't recall any major such changes, maybe Nikos can tell more. There > have been many minor and incremental changes, such as replacing parts > with more portable code from gnulib, or switching to using a separate > configure script in lib/ and libextra/. The only major change of this kind I remember was the separation of the crypto backend with the gnutls library. Even if libgcrypt was still used the code was modified to allow for any other crypto library to be used by gnutls by just registering hooks... I believe it is the only change of this kind so far. >> 2. If the project has gone under such an initiative, then would it be >> possible for you to give the dates or revision/release numbers that are >> "right before" and "right after" this structuring effort? I would like to >> checkout the source code from the repository to compare structural >> measurements that belong to "before" and "after" snapshots. Note that the >> dates and revision/release numbers should be right before and right after >> the initiative because I would like to be able to isolate and observe the >> effects of this effort. If you are interested in that change, check below... started: commit a1cd6fe1a072717d2c33fd5a20306741c86399ae Author: Nikos Date: Sun Mar 16 11:17:55 2008 +0200 Added functionality to override (register) a cipher. Initial functionality for MAC and digest algorithms. pretty much finished at: commit 3b39d296d802e3aa42c08f8d02db6e81d99a7e90 Author: Nikos Mavrogiannopoulos Date: Sun Sep 28 10:59:26 2008 +0300 changed crypto API to reduce probability of memory leaks during usage of pk_params. hower as Simon said before, if you go by dates the history is mixed with unrelated changes as well. regards, Nikos From wasiliyivanov at gmail.com Fri Feb 5 22:27:59 2010 From: wasiliyivanov at gmail.com (Vasiliy Ivanov) Date: Fri, 5 Feb 2010 23:27:59 +0200 Subject: Link error Message-ID: <001801caa6aa$17fce020$47f6a060$@com> Hi! Can you help me with linker error. error LNK2019: unresolved external symbol _gcry_control referenced in function I have linked my project with library libgnutls-26.lib. But no effect! It appears in this library is no such symbol. What can I do? P.S. Does gnutls has project for MS Viual Studio? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From vivanov at te.net.ua Sat Feb 13 09:32:35 2010 From: vivanov at te.net.ua (Vasiliy Ivanov) Date: Sat, 13 Feb 2010 10:32:35 +0200 Subject: gnutls_handshake crash on multithreading Message-ID: <000601caac87$18930090$49b901b0$@net.ua> I have called gcry_control( GCRYCTL_SET_THREAD_CBS, &gcry_threads_boost ); But program crashed inside of gnutls_handshake on Windows with ASSERT *lock == MUTEX_UNLOCK. What can I do? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Mon Feb 15 11:17:48 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 15 Feb 2010 11:17:48 +0100 Subject: Link error In-Reply-To: <001801caa6aa$17fce020$47f6a060$@com> (Vasiliy Ivanov's message of "Fri, 5 Feb 2010 23:27:59 +0200") References: <001801caa6aa$17fce020$47f6a060$@com> Message-ID: <87vddy950z.fsf@mocca.josefsson.org> "Vasiliy Ivanov" writes: > Hi! > > Can you help me with linker error. > > error LNK2019: unresolved external symbol _gcry_control referenced in > function > > > > I have linked my project with library libgnutls-26.lib. But no effect! > > It appears in this library is no such symbol. What can I do? It is a libgcrypt symbol, so you need to link with libgcrypt as well. Similarly, you may also need to link with libgpg-error. > P.S. Does gnutls has project for MS Viual Studio? Nope. If anyone wants to contribute them, that would be useful. /Simon From simon at josefsson.org Mon Feb 15 11:19:40 2010 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 15 Feb 2010 11:19:40 +0100 Subject: gnutls_handshake crash on multithreading In-Reply-To: <000601caac87$18930090$49b901b0$@net.ua> (Vasiliy Ivanov's message of "Sat, 13 Feb 2010 10:32:35 +0200") References: <000601caac87$18930090$49b901b0$@net.ua> Message-ID: <87r5om94xv.fsf@mocca.josefsson.org> "Vasiliy Ivanov" writes: > I have called gcry_control( GCRYCTL_SET_THREAD_CBS, &gcry_threads_boost ); > But program crashed inside of gnutls_handshake on Windows with ASSERT *lock > == MUTEX_UNLOCK. What can I do? Try switching order of the gcry_control call and gnutls_global_init? That's just guessing. Also, do you dynamically or statically link? /Simon From vivanov at te.net.ua Mon Feb 15 18:57:20 2010 From: vivanov at te.net.ua (Vasiliy Ivanov) Date: Mon, 15 Feb 2010 19:57:20 +0200 Subject: gnutls_handshake crash on multithreading In-Reply-To: <87r5om94xv.fsf@mocca.josefsson.org> References: <000601caac87$18930090$49b901b0$@net.ua> <87r5om94xv.fsf@mocca.josefsson.org> Message-ID: <000d01caae68$523b99f0$f6b2cdd0$@net.ua> No effect! This is last variant: gcry_check_version (GCRYPT_VERSION); gcry_control( GCRYCTL_SET_THREAD_CBS, &gcry_threads_boost ); gcry_control (GCRYCTL_SUSPEND_SECMEM_WARN); gcry_control (GCRYCTL_INIT_SECMEM, 16384, 0); gcry_control (GCRYCTL_RESUME_SECMEM_WARN); gcry_control (GCRYCTL_INITIALIZATION_FINISHED, 0); gcry_control (GCRYCTL_INITIALIZATION_FINISHED_P); gnutls_global_init(); I use .dll with .lib file linked. -----Original Message----- From: Simon Josefsson [mailto:simon at josefsson.org] Sent: Monday, February 15, 2010 12:20 PM To: Vasiliy Ivanov Cc: bug-gnutls at gnu.org Subject: Re: gnutls_handshake crash on multithreading "Vasiliy Ivanov" writes: > I have called gcry_control( GCRYCTL_SET_THREAD_CBS, &gcry_threads_boost ); > But program crashed inside of gnutls_handshake on Windows with ASSERT *lock > == MUTEX_UNLOCK. What can I do? Try switching order of the gcry_control call and gnutls_global_init? That's just guessing. Also, do you dynamically or statically link? /Simon From nmav at gnutls.org Mon Feb 15 19:54:40 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 15 Feb 2010 19:54:40 +0100 Subject: gnutls_handshake crash on multithreading In-Reply-To: <000d01caae68$523b99f0$f6b2cdd0$@net.ua> References: <000601caac87$18930090$49b901b0$@net.ua> <87r5om94xv.fsf@mocca.josefsson.org> <000d01caae68$523b99f0$f6b2cdd0$@net.ua> Message-ID: <4B799870.8020605@gnutls.org> Vasiliy Ivanov wrote: > No effect! > This is last variant: > > gcry_check_version (GCRYPT_VERSION); > gcry_control( GCRYCTL_SET_THREAD_CBS, &gcry_threads_boost ); > gcry_control (GCRYCTL_SUSPEND_SECMEM_WARN); > gcry_control (GCRYCTL_INIT_SECMEM, 16384, 0); > gcry_control (GCRYCTL_RESUME_SECMEM_WARN); > gcry_control (GCRYCTL_INITIALIZATION_FINISHED, 0); > gcry_control (GCRYCTL_INITIALIZATION_FINISHED_P); > > gnutls_global_init(); Did you try the example in the documentation? http://www.gnu.org/software/gnutls/manual/html_node/Multi_002dthreaded-applications.html From vivanov at te.net.ua Mon Feb 15 20:30:21 2010 From: vivanov at te.net.ua (Vasiliy Ivanov) Date: Mon, 15 Feb 2010 21:30:21 +0200 Subject: gnutls_handshake crash on multithreading In-Reply-To: <4B799870.8020605@gnutls.org> References: <000601caac87$18930090$49b901b0$@net.ua> <87r5om94xv.fsf@mocca.josefsson.org> <000d01caae68$523b99f0$f6b2cdd0$@net.ua> <4B799870.8020605@gnutls.org> Message-ID: <001101caae75$508d13b0$f1a73b10$@net.ua> Yes, my code from this documentation ... gcry_control( GCRYCTL_SET_THREAD_CBS, &gcry_threads_boost ); ... gnutls_global_init(); -----Original Message----- From: Nikos Mavrogiannopoulos [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos Sent: Monday, February 15, 2010 8:55 PM To: Vasiliy Ivanov Cc: 'Simon Josefsson'; bug-gnutls at gnu.org Subject: Re: gnutls_handshake crash on multithreading Vasiliy Ivanov wrote: > No effect! > This is last variant: > > gcry_check_version (GCRYPT_VERSION); > gcry_control( GCRYCTL_SET_THREAD_CBS, &gcry_threads_boost ); > gcry_control (GCRYCTL_SUSPEND_SECMEM_WARN); > gcry_control (GCRYCTL_INIT_SECMEM, 16384, 0); > gcry_control (GCRYCTL_RESUME_SECMEM_WARN); > gcry_control (GCRYCTL_INITIALIZATION_FINISHED, 0); > gcry_control (GCRYCTL_INITIALIZATION_FINISHED_P); > > gnutls_global_init(); Did you try the example in the documentation? http://www.gnu.org/software/gnutls/manual/html_node/Multi_002dthreaded-appli cations.html From nmav at gnutls.org Mon Feb 15 21:38:02 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 15 Feb 2010 21:38:02 +0100 Subject: gnutls_handshake crash on multithreading In-Reply-To: <001101caae75$508d13b0$f1a73b10$@net.ua> References: <000601caac87$18930090$49b901b0$@net.ua> <87r5om94xv.fsf@mocca.josefsson.org> <000d01caae68$523b99f0$f6b2cdd0$@net.ua> <4B799870.8020605@gnutls.org> <001101caae75$508d13b0$f1a73b10$@net.ua> Message-ID: <4B79B0AA.80906@gnutls.org> Vasiliy Ivanov wrote: > Yes, my code from this documentation > ... > gcry_control( GCRYCTL_SET_THREAD_CBS, &gcry_threads_boost ); > ... > gnutls_global_init(); And are you sure your gcry_threads_boost is acting correctly? From vivanov at te.net.ua Mon Feb 15 21:42:11 2010 From: vivanov at te.net.ua (Vasiliy Ivanov) Date: Mon, 15 Feb 2010 22:42:11 +0200 Subject: gnutls_handshake crash on multithreading In-Reply-To: <4B79B0AA.80906@gnutls.org> References: <000601caac87$18930090$49b901b0$@net.ua> <87r5om94xv.fsf@mocca.josefsson.org> <000d01caae68$523b99f0$f6b2cdd0$@net.ua> <4B799870.8020605@gnutls.org> <001101caae75$508d13b0$f1a73b10$@net.ua> <4B79B0AA.80906@gnutls.org> Message-ID: <001201caae7f$599f1d40$0cdd57c0$@net.ua> Yes. It methods calls at program starts, but not when program calls gnutls_handshake! I think, gnutls_handshake does not use mutex inside(( -----Original Message----- From: Nikos Mavrogiannopoulos [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos Sent: Monday, February 15, 2010 10:38 PM To: Vasiliy Ivanov Cc: 'Simon Josefsson'; bug-gnutls at gnu.org Subject: Re: gnutls_handshake crash on multithreading Vasiliy Ivanov wrote: > Yes, my code from this documentation > ... > gcry_control( GCRYCTL_SET_THREAD_CBS, &gcry_threads_boost ); ... > gnutls_global_init(); And are you sure your gcry_threads_boost is acting correctly? From nmav at gnutls.org Mon Feb 15 22:27:13 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 15 Feb 2010 22:27:13 +0100 Subject: gnutls_handshake crash on multithreading In-Reply-To: <001201caae7f$599f1d40$0cdd57c0$@net.ua> References: <000601caac87$18930090$49b901b0$@net.ua> <87r5om94xv.fsf@mocca.josefsson.org> <000d01caae68$523b99f0$f6b2cdd0$@net.ua> <4B799870.8020605@gnutls.org> <001101caae75$508d13b0$f1a73b10$@net.ua> <4B79B0AA.80906@gnutls.org> <001201caae7f$599f1d40$0cdd57c0$@net.ua> Message-ID: <4B79BC31.5000902@gnutls.org> Vasiliy Ivanov wrote: > Yes. It methods calls at program starts, but not when program calls > gnutls_handshake! > I think, gnutls_handshake does not use mutex inside(( gnutls is thread safe, does not need mutexes. The mutexes you set for the libgcrypt functions that are not thread safe. gnutls is quite tested with threads, thus I'd bet the problem is in your code (and your mutex handlers you give to libgcrypt). > -----Original Message----- > From: Nikos Mavrogiannopoulos [mailto:n.mavrogiannopoulos at gmail.com] On > Behalf Of Nikos Mavrogiannopoulos > Sent: Monday, February 15, 2010 10:38 PM > To: Vasiliy Ivanov > Cc: 'Simon Josefsson'; bug-gnutls at gnu.org > Subject: Re: gnutls_handshake crash on multithreading > > Vasiliy Ivanov wrote: >> Yes, my code from this documentation >> ... >> gcry_control( GCRYCTL_SET_THREAD_CBS, &gcry_threads_boost ); ... >> gnutls_global_init(); > > And are you sure your gcry_threads_boost is acting correctly? > From vivanov at te.net.ua Mon Feb 15 22:29:03 2010 From: vivanov at te.net.ua (Vasiliy Ivanov) Date: Mon, 15 Feb 2010 23:29:03 +0200 Subject: gnutls_handshake crash on multithreading In-Reply-To: <4B79BC31.5000902@gnutls.org> References: <000601caac87$18930090$49b901b0$@net.ua> <87r5om94xv.fsf@mocca.josefsson.org> <000d01caae68$523b99f0$f6b2cdd0$@net.ua> <4B799870.8020605@gnutls.org> <001101caae75$508d13b0$f1a73b10$@net.ua> <4B79B0AA.80906@gnutls.org> <001201caae7f$599f1d40$0cdd57c0$@net.ua> <4B79BC31.5000902@gnutls.org> Message-ID: <001f01caae85$e55f6c80$b01e4580$@net.ua> Can you write me a good example of mutex, that I need to pass in gcrypt_control ? Thanks! -----Original Message----- From: Nikos Mavrogiannopoulos [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos Sent: Monday, February 15, 2010 11:27 PM To: Vasiliy Ivanov Cc: 'Simon Josefsson'; bug-gnutls at gnu.org Subject: Re: gnutls_handshake crash on multithreading Vasiliy Ivanov wrote: > Yes. It methods calls at program starts, but not when program calls > gnutls_handshake! > I think, gnutls_handshake does not use mutex inside(( gnutls is thread safe, does not need mutexes. The mutexes you set for the libgcrypt functions that are not thread safe. gnutls is quite tested with threads, thus I'd bet the problem is in your code (and your mutex handlers you give to libgcrypt). > -----Original Message----- > From: Nikos Mavrogiannopoulos [mailto:n.mavrogiannopoulos at gmail.com] > On Behalf Of Nikos Mavrogiannopoulos > Sent: Monday, February 15, 2010 10:38 PM > To: Vasiliy Ivanov > Cc: 'Simon Josefsson'; bug-gnutls at gnu.org > Subject: Re: gnutls_handshake crash on multithreading > > Vasiliy Ivanov wrote: >> Yes, my code from this documentation >> ... >> gcry_control( GCRYCTL_SET_THREAD_CBS, &gcry_threads_boost ); ... >> gnutls_global_init(); > > And are you sure your gcry_threads_boost is acting correctly? > From nmav at gnutls.org Tue Feb 16 13:52:38 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 16 Feb 2010 13:52:38 +0100 Subject: gnutls_handshake crash on multithreading In-Reply-To: <001f01caae85$e55f6c80$b01e4580$@net.ua> References: <000601caac87$18930090$49b901b0$@net.ua> <87r5om94xv.fsf@mocca.josefsson.org> <000d01caae68$523b99f0$f6b2cdd0$@net.ua> <4B799870.8020605@gnutls.org> <001101caae75$508d13b0$f1a73b10$@net.ua> <4B79B0AA.80906@gnutls.org> <001201caae7f$599f1d40$0cdd57c0$@net.ua> <4B79BC31.5000902@gnutls.org> <001f01caae85$e55f6c80$b01e4580$@net.ua> Message-ID: Check the examples available from libgcrypt for posix threads. On Mon, Feb 15, 2010 at 10:29 PM, Vasiliy Ivanov wrote: > Can you write me a good example of mutex, that I need to pass in > gcrypt_control ? > Thanks! > > -----Original Message----- > From: Nikos Mavrogiannopoulos [mailto:n.mavrogiannopoulos at gmail.com] On > Behalf Of Nikos Mavrogiannopoulos > Sent: Monday, February 15, 2010 11:27 PM > To: Vasiliy Ivanov > Cc: 'Simon Josefsson'; bug-gnutls at gnu.org > Subject: Re: gnutls_handshake crash on multithreading > > Vasiliy Ivanov wrote: >> Yes. It methods calls at program starts, but not when program calls >> gnutls_handshake! >> I think, gnutls_handshake does not use mutex inside(( > > gnutls is thread safe, does not need mutexes. The mutexes you set for the > libgcrypt functions that are not thread safe. gnutls is quite tested with > threads, thus I'd bet the problem is in your code (and your mutex handlers > you give to libgcrypt). > >> -----Original Message----- >> From: Nikos Mavrogiannopoulos [mailto:n.mavrogiannopoulos at gmail.com] >> On Behalf Of Nikos Mavrogiannopoulos >> Sent: Monday, February 15, 2010 10:38 PM >> To: Vasiliy Ivanov >> Cc: 'Simon Josefsson'; bug-gnutls at gnu.org >> Subject: Re: gnutls_handshake crash on multithreading >> >> Vasiliy Ivanov wrote: >>> Yes, my code from this documentation >>> ... >>> gcry_control( GCRYCTL_SET_THREAD_CBS, &gcry_threads_boost ); ... >>> gnutls_global_init(); >> >> And are you sure your gcry_threads_boost is acting correctly? >> > > From tml at iki.fi Tue Feb 16 14:03:02 2010 From: tml at iki.fi (Tor Lillqvist) Date: Tue, 16 Feb 2010 15:03:02 +0200 Subject: gnutls_handshake crash on multithreading In-Reply-To: <000d01caae68$523b99f0$f6b2cdd0$@net.ua> References: <000601caac87$18930090$49b901b0$@net.ua> <87r5om94xv.fsf@mocca.josefsson.org> <000d01caae68$523b99f0$f6b2cdd0$@net.ua> Message-ID: > ? ? ? ? ? ? ? ?gcry_control( GCRYCTL_SET_THREAD_CBS, &gcry_threads_boost ); > I use .dll with .lib file linked. Where does gcry_threads_boost come from, if from a DLL are you sure it is imported correctly? --tml From vivek at collabora.co.uk Tue Feb 16 14:14:10 2010 From: vivek at collabora.co.uk (Vivek Dasmohapatra) Date: Tue, 16 Feb 2010 13:14:10 +0000 (GMT) Subject: GnuTLS, OpenSSL support for TLS1.1, 1.2 In-Reply-To: <4B631B75.8060508@gnutls.org> References: <094A73044298734FB7D58CAAA319E1D60226338D@UBIQ-SERV1.ubiquisys.local> <87tyu53x6y.fsf@mocca.josefsson.org> <87ljfh2ezk.fsf@mocca.josefsson.org> <4B631B75.8060508@gnutls.org> Message-ID: > Check also wireshark. It is quite detailed as well. I am aware of wireshark, but it's not (as far as I know) able to do a live man-in-the-middle dump of the protocol. From nmav at gnutls.org Tue Feb 16 17:00:46 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 16 Feb 2010 17:00:46 +0100 Subject: GnuTLS, OpenSSL support for TLS1.1, 1.2 In-Reply-To: References: <094A73044298734FB7D58CAAA319E1D60226338D@UBIQ-SERV1.ubiquisys.local> <87tyu53x6y.fsf@mocca.josefsson.org> <87ljfh2ezk.fsf@mocca.josefsson.org> <4B631B75.8060508@gnutls.org> Message-ID: <4B7AC12E.2070805@gnutls.org> Vivek Dasmohapatra wrote: >> Check also wireshark. It is quite detailed as well. > > I am aware of wireshark, but it's not (as far as I know) able to do > a live man-in-the-middle dump of the protocol. Actually that is what it does, so obviously you mean something different. What do you mean by the live man-in-the-middle dump of the protocol? From vivek at collabora.co.uk Tue Feb 16 20:34:40 2010 From: vivek at collabora.co.uk (Vivek Dasmohapatra) Date: Tue, 16 Feb 2010 19:34:40 +0000 (GMT) Subject: GnuTLS, OpenSSL support for TLS1.1, 1.2 In-Reply-To: <4B7AC12E.2070805@gnutls.org> References: <094A73044298734FB7D58CAAA319E1D60226338D@UBIQ-SERV1.ubiquisys.local> <87tyu53x6y.fsf@mocca.josefsson.org> <87ljfh2ezk.fsf@mocca.josefsson.org> <4B631B75.8060508@gnutls.org> <4B7AC12E.2070805@gnutls.org> Message-ID: I can fire it up quickly on the console, listening on an interface and port, and have it mitm-proxy for the real server the client is talking to, and dump out protocol related info as the handshake etc happens. From vivanov at te.net.ua Tue Feb 16 20:46:54 2010 From: vivanov at te.net.ua (Vasiliy Ivanov) Date: Tue, 16 Feb 2010 21:46:54 +0200 Subject: gnutls_handshake crash on multithreading In-Reply-To: References: <000601caac87$18930090$49b901b0$@net.ua> <87r5om94xv.fsf@mocca.josefsson.org> <000d01caae68$523b99f0$f6b2cdd0$@net.ua> Message-ID: <000901caaf40$cadd29e0$60977da0$@net.ua> No, it's my own structure(see below). It works at program start, but no methods are called at gnutls_handshake processing. static int boost_mutex_init(void **priv) { boost::mutex *lock = new boost::mutex(); if (!lock) return ENOMEM; *priv = lock; return 0; } static int boost_mutex_destroy(void **lock) { delete reinterpret_cast(*lock); return 0; } static int boost_mutex_lock(void **lock) { reinterpret_cast(*lock)->lock(); return 0; } static int boost_mutex_unlock(void **lock) { reinterpret_cast(*lock)->unlock(); return 0; } //static struct gcry_thread_cbs gcry_threads_other; static struct gcry_thread_cbs gcry_threads_boost = { GCRY_THREAD_OPTION_USER, NULL, boost_mutex_init, boost_mutex_destroy, boost_mutex_lock, boost_mutex_unlock }; -----Original Message----- From: tlillqvist at gmail.com [mailto:tlillqvist at gmail.com] On Behalf Of Tor Lillqvist Sent: Tuesday, February 16, 2010 3:03 PM To: Vasiliy Ivanov Cc: Simon Josefsson; bug-gnutls at gnu.org Subject: Re: gnutls_handshake crash on multithreading > gcry_control( GCRYCTL_SET_THREAD_CBS, > &gcry_threads_boost ); > I use .dll with .lib file linked. Where does gcry_threads_boost come from, if from a DLL are you sure it is imported correctly? --tml From nmav at gnutls.org Wed Feb 17 10:28:51 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 17 Feb 2010 10:28:51 +0100 Subject: gnutls_handshake crash on multithreading In-Reply-To: <000901caaf40$cadd29e0$60977da0$@net.ua> References: <000601caac87$18930090$49b901b0$@net.ua> <87r5om94xv.fsf@mocca.josefsson.org> <000d01caae68$523b99f0$f6b2cdd0$@net.ua> <000901caaf40$cadd29e0$60977da0$@net.ua> Message-ID: If noone from this list can help (i cannot), please try the gcrypt-devel or even the help-gnutls just in case someone has tried with custom mutex functions for libgcrypt. On Tue, Feb 16, 2010 at 8:46 PM, Vasiliy Ivanov wrote: > No, it's my own structure(see below). > It works at program start, but no methods are called at gnutls_handshake processing. > > static int boost_mutex_init(void **priv) > { > ? ? ? ?boost::mutex *lock = new boost::mutex(); > ? ? ? ?if (!lock) > ? ? ? ? ? ? ? ?return ENOMEM; > ? ? ? ?*priv = lock; > ? ? ? ?return 0; > } > > static int boost_mutex_destroy(void **lock) > { > ? ? ? ?delete reinterpret_cast(*lock); > ? ? ? ?return 0; > } > > static int boost_mutex_lock(void **lock) > { > ? ? ? ?reinterpret_cast(*lock)->lock(); > ? ? ? ?return 0; > } > > static int boost_mutex_unlock(void **lock) > { > ? ? ? ?reinterpret_cast(*lock)->unlock(); > ? ? ? ?return 0; > } > //static struct gcry_thread_cbs gcry_threads_other; > static struct gcry_thread_cbs gcry_threads_boost = > { > ? ? ? ?GCRY_THREAD_OPTION_USER, > ? ? ? ?NULL, > ? ? ? ?boost_mutex_init, > ? ? ? ?boost_mutex_destroy, > ? ? ? ?boost_mutex_lock, > ? ? ? ?boost_mutex_unlock > }; > > > > -----Original Message----- > From: tlillqvist at gmail.com [mailto:tlillqvist at gmail.com] On Behalf Of Tor Lillqvist > Sent: Tuesday, February 16, 2010 3:03 PM > To: Vasiliy Ivanov > Cc: Simon Josefsson; bug-gnutls at gnu.org > Subject: Re: gnutls_handshake crash on multithreading > >> ? ? ? ? ? ? ? ?gcry_control( GCRYCTL_SET_THREAD_CBS, >> &gcry_threads_boost ); > >> I use .dll with .lib file linked. > > Where does gcry_threads_boost come from, if from a DLL are you sure it is imported correctly? > > --tml > > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel > From nmav at gnutls.org Wed Feb 17 10:25:41 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 17 Feb 2010 10:25:41 +0100 Subject: GnuTLS, OpenSSL support for TLS1.1, 1.2 In-Reply-To: References: <094A73044298734FB7D58CAAA319E1D60226338D@UBIQ-SERV1.ubiquisys.local> <87tyu53x6y.fsf@mocca.josefsson.org> <87ljfh2ezk.fsf@mocca.josefsson.org> <4B631B75.8060508@gnutls.org> <4B7AC12E.2070805@gnutls.org> Message-ID: wireshark is like (and compatible with) tcpdump. It dumps all the packets passing through the network stack. You don't need to setup a proxy. On Tue, Feb 16, 2010 at 8:34 PM, Vivek Dasmohapatra wrote: > I can fire it up quickly on the console, listening on an interface and port, > and have it mitm-proxy for the real server the client is talking > to, and dump out protocol related info as the handshake etc happens. > > From nmav at gnutls.org Thu Feb 18 08:50:39 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 18 Feb 2010 08:50:39 +0100 Subject: gnutls_handshake crash on multithreading In-Reply-To: <000901caaf40$cadd29e0$60977da0$@net.ua> References: <000601caac87$18930090$49b901b0$@net.ua> <87r5om94xv.fsf@mocca.josefsson.org> <000d01caae68$523b99f0$f6b2cdd0$@net.ua> <000901caaf40$cadd29e0$60977da0$@net.ua> Message-ID: <4B7CF14F.8020704@gnutls.org> Vasiliy Ivanov wrote: > No, it's my own structure(see below). > It works at program start, but no methods are called at gnutls_handshake processing. Actually what is the return value of gcry_control when setting them? Are you sure that these functions are not called? I see here that you do: > gcry_check_version (GCRYPT_VERSION); > gcry_control( GCRYCTL_SET_THREAD_CBS, &gcry_threads_boost ); > gcry_control (GCRYCTL_SUSPEND_SECMEM_WARN); > gcry_control (GCRYCTL_INIT_SECMEM, 16384, 0); > gcry_control (GCRYCTL_RESUME_SECMEM_WARN); > gcry_control (GCRYCTL_INITIALIZATION_FINISHED, 0); > gcry_control (GCRYCTL_INITIALIZATION_FINISHED_P); > > gnutls_global_init(); and have no error checking whatsoever. Check gnutls_global_init() on how the initialization of libgcrypt is done. Otherwise you don't even know if these functions have any effect. regards, Nikos From simon at josefsson.org Thu Feb 18 09:19:06 2010 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 18 Feb 2010 09:19:06 +0100 Subject: Another renegotiation patch In-Reply-To: (Steve Dispensa's message of "Fri, 22 Jan 2010 14:57:49 -0600") References: <4B58BC18.7030100@gnutls.org> Message-ID: <873a0zklc5.fsf@mocca.josefsson.org> Steve, Nikos, are you happy with the safe renegotiation implementation in git master now? Do we have complete self-tests of this? Is it documented? Has there been any interop testing with other implementations? Any other concerns I should be aware of? I'd like to release 2.10.0 soon, and safe renegotiation will be one of the main features in that release. /Simon From thoger at redhat.com Thu Feb 18 12:52:41 2010 From: thoger at redhat.com (Tomas Hoger) Date: Thu, 18 Feb 2010 12:52:41 +0100 Subject: Another renegotiation patch In-Reply-To: <873a0zklc5.fsf@mocca.josefsson.org> References: <4B58BC18.7030100@gnutls.org> <873a0zklc5.fsf@mocca.josefsson.org> Message-ID: <20100218125241.0c826a70@redhat.com> Hi Simon! On Thu, 18 Feb 2010 09:19:06 +0100 Simon Josefsson wrote: > Steve, Nikos, are you happy with the safe renegotiation implementation > in git master now? Do we have complete self-tests of this? Is it > documented? Has there been any interop testing with other > implementations? Any other concerns I should be aware of? Few quick observations: - GnuTLS prefers RI to SCSV unless using SSL.3.0. New OpenSSL (and afaik NSS too) use SCSV in the initial client hellos even for TLS, to play more nicely with broken TLS servers that choke on TLS extensions. - gnutls-cli invoked with --disable-extensions still sends hello with extensions. - gnutls-cli fails to connect to servers not implementing RFC 5746. While this is required to fully address the issue on the client side, it's likely to cause major issues in short term. gnutls-cli(1) suggests safe initial negotiation should not be required by default (see %INITIAL_SAFE_RENEGOTIATION), %UNSAFE_RENEGOTIATION is required to connect. Note: Both OpenSSL and NSS will not require safe initial negotiation yet for interoperability reasons. - %INITIAL_SAFE_RENEGOTIATION name is somewhat confusing (renegotiation vs. negotiation). - %INITIAL_SAFE_RENEGOTIATION defaults are not documented properly (see client concern above). - I'd consider clarifying %DISABLE_SAFE_RENEGOTIATION description too. HTH th. From simon at josefsson.org Thu Feb 18 13:13:59 2010 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 18 Feb 2010 13:13:59 +0100 Subject: Require libgcrypt 1.4.4 or later? In-Reply-To: <4B7D1D6E.30607@nict.go.jp> (Sebastien Decugis's message of "Thu, 18 Feb 2010 19:58:54 +0900") References: <4B7B9C89.7020801@nict.go.jp> <4B7CE5A9.6050605@nict.go.jp> <4B7CEEB1.6020408@gnutls.org> <4B7D1D6E.30607@nict.go.jp> Message-ID: <87eikihhbs.fsf_-_@mocca.josefsson.org> Nikos pointed out that we could avoid some issues by requiring a newer libgcrypt version, and I agree. Looking at the libgcrypt NEWS file, it seems 1.4.4 contains some fixes for HMAC-SHA-2 that looks useful. It was released on 2009-01-22, so anyone contemplating installing the next stable release GnuTLS 2.10.x shouldn't find it too problematic to find it. Thus, unless I hear any objections, I will make GnuTLS require libgcrypt 1.4.4 or newer. To clarify, this has no relevance for 2.8.x. /Simon Sebastien Decugis writes: >> This shouldn't be needed unless you call GCRYCTL_INITIALIZATION_FINISHED >> in your program. gnutls_global_init() should take care of the functions >> you describe. Which version of libgcrypt do you use? (does it fix the >> issue if you use the latest?) >> > > I was using the Debian default version (1.4.1). I just tested with > latest (1.4.5) and the issue is gone. I think I will leave the command > in my code, so that it works even with the "bad" mix: gnutls 2.8.5 with > gcrypt 1.4.1. > > Thank you for the tip! > Best regards, > Sebastien. From simon at josefsson.org Thu Feb 18 13:32:30 2010 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 18 Feb 2010 13:32:30 +0100 Subject: Another renegotiation patch In-Reply-To: <20100218125241.0c826a70@redhat.com> (Tomas Hoger's message of "Thu, 18 Feb 2010 12:52:41 +0100") References: <4B58BC18.7030100@gnutls.org> <873a0zklc5.fsf@mocca.josefsson.org> <20100218125241.0c826a70@redhat.com> Message-ID: <87wryag1wh.fsf@mocca.josefsson.org> Tomas Hoger writes: > Hi Simon! > > On Thu, 18 Feb 2010 09:19:06 +0100 Simon Josefsson > wrote: > >> Steve, Nikos, are you happy with the safe renegotiation implementation >> in git master now? Do we have complete self-tests of this? Is it >> documented? Has there been any interop testing with other >> implementations? Any other concerns I should be aware of? > > Few quick observations: Thanks, this is really useful. > - GnuTLS prefers RI to SCSV unless using SSL.3.0. New OpenSSL (and > afaik NSS too) use SCSV in the initial client hellos even for TLS, to > play more nicely with broken TLS servers that choke on TLS > extensions. GnuTLS advertises a >1.0 version by default, which breaks most of these servers anyway. > - gnutls-cli invoked with --disable-extensions still sends hello with > extensions. This is actually an unrelated issue -- the parameter doesn't disable all extensions even on 2.8.x. > - gnutls-cli fails to connect to servers not implementing RFC 5746. > While this is required to fully address the issue on the client side, > it's likely to cause major issues in short term. gnutls-cli(1) > suggests safe initial negotiation should not be required by default > (see %INITIAL_SAFE_RENEGOTIATION), %UNSAFE_RENEGOTIATION is required > to connect. > Note: Both OpenSSL and NSS will not require safe initial negotiation > yet for interoperability reasons. Nikos, Steve, what do you think here? My preference is to not reject these servers, because the vulnerability exists theoretically in earlier GnuTLS versions anyway but because of the GnuTLS API is different from OpenSSL/NSS most if not all GnuTLS applications are not affected by this (renegotiation will fail with the majority of GnuTLS applications). > - %INITIAL_SAFE_RENEGOTIATION name is somewhat confusing (renegotiation > vs. negotiation). > - %INITIAL_SAFE_RENEGOTIATION defaults are not documented properly (see > client concern above). > - I'd consider clarifying %DISABLE_SAFE_RENEGOTIATION description too. Maybe the terms could be more aligned with RFC 5746 terminology? /Simon From thoger at redhat.com Thu Feb 18 15:04:55 2010 From: thoger at redhat.com (Tomas Hoger) Date: Thu, 18 Feb 2010 15:04:55 +0100 Subject: Another renegotiation patch In-Reply-To: <87wryag1wh.fsf@mocca.josefsson.org> References: <4B58BC18.7030100@gnutls.org> <873a0zklc5.fsf@mocca.josefsson.org> <20100218125241.0c826a70@redhat.com> <87wryag1wh.fsf@mocca.josefsson.org> Message-ID: <20100218150455.1a4d1195@redhat.com> On Thu, 18 Feb 2010 13:32:30 +0100 Simon Josefsson wrote: > > - gnutls-cli invoked with --disable-extensions still sends hello > > with extensions. > > This is actually an unrelated issue -- the parameter doesn't disable > all extensions even on 2.8.x. That's possible, I did not get to figure out why it does not work. I just tried to use it to force GnuTLS to use SCSV in TLS hellos. > > - gnutls-cli fails to connect to servers not implementing RFC 5746. > > While this is required to fully address the issue on the client > > side, it's likely to cause major issues in short term. > > gnutls-cli(1) suggests safe initial negotiation should not be > > required by default (see %INITIAL_SAFE_RENEGOTIATION), > > %UNSAFE_RENEGOTIATION is required to connect. > > Note: Both OpenSSL and NSS will not require safe initial > > negotiation yet for interoperability reasons. > > Nikos, Steve, what do you think here? Looks like the current behavior is intentional: http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=2a10542bf8f7cfbd5e6a4b17c8d502133da93fc5 I appologize for missing it previously. > My preference is to not reject these servers, because the > vulnerability exists theoretically in earlier GnuTLS versions anyway > but because of the GnuTLS API is different from OpenSSL/NSS most if > not all GnuTLS applications are not affected by this (renegotiation > will fail with the majority of GnuTLS applications). The above commit message should cover these too. I see NEWS explicitly mentions that clients need to use %UNSAFE_RENEGOTIATION. You may still wish to emphasize that in the release announcements. th. From vivanov at te.net.ua Thu Feb 18 20:32:59 2010 From: vivanov at te.net.ua (Vasiliy Ivanov) Date: Thu, 18 Feb 2010 21:32:59 +0200 Subject: gnutls_handshake crash on multithreading In-Reply-To: <4B7CF14F.8020704@gnutls.org> References: <000601caac87$18930090$49b901b0$@net.ua> <87r5om94xv.fsf@mocca.josefsson.org> <000d01caae68$523b99f0$f6b2cdd0$@net.ua> <000901caaf40$cadd29e0$60977da0$@net.ua> <4B7CF14F.8020704@gnutls.org> Message-ID: <000a01cab0d1$2e26d230$8a747690$@net.ua> >Actually what is the return value of gcry_control when setting them? gcry_control( GCRYCTL_SET_THREAD_CBS, &gcry_threads_boost ); returns 0x2000003c. What it means? -----Original Message----- From: Nikos Mavrogiannopoulos [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos Sent: Thursday, February 18, 2010 9:51 AM To: Vasiliy Ivanov Cc: 'Tor Lillqvist'; 'Simon Josefsson'; bug-gnutls at gnu.org Subject: Re: gnutls_handshake crash on multithreading Vasiliy Ivanov wrote: > No, it's my own structure(see below). > It works at program start, but no methods are called at gnutls_handshake processing. Actually what is the return value of gcry_control when setting them? Are you sure that these functions are not called? I see here that you do: > gcry_check_version (GCRYPT_VERSION); > gcry_control( GCRYCTL_SET_THREAD_CBS, &gcry_threads_boost ); > gcry_control (GCRYCTL_SUSPEND_SECMEM_WARN); > gcry_control (GCRYCTL_INIT_SECMEM, 16384, 0); > gcry_control (GCRYCTL_RESUME_SECMEM_WARN); > gcry_control (GCRYCTL_INITIALIZATION_FINISHED, 0); > gcry_control (GCRYCTL_INITIALIZATION_FINISHED_P); > > gnutls_global_init(); and have no error checking whatsoever. Check gnutls_global_init() on how the initialization of libgcrypt is done. Otherwise you don't even know if these functions have any effect. regards, Nikos From nmav at gnutls.org Sun Feb 21 09:55:33 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 21 Feb 2010 09:55:33 +0100 Subject: Another renegotiation patch In-Reply-To: <20100218150455.1a4d1195@redhat.com> References: <4B58BC18.7030100@gnutls.org> <873a0zklc5.fsf@mocca.josefsson.org> <20100218125241.0c826a70@redhat.com> <87wryag1wh.fsf@mocca.josefsson.org> <20100218150455.1a4d1195@redhat.com> Message-ID: <4B80F505.5010603@gnutls.org> Tomas Hoger wrote: >>> - gnutls-cli invoked with --disable-extensions still sends hello >>> with extensions. >> This is actually an unrelated issue -- the parameter doesn't disable >> all extensions even on 2.8.x. > > That's possible, I did not get to figure out why it does not work. > I just tried to use it to force GnuTLS to use SCSV in TLS hellos. Actually the disable-extensions option has no effect on the library itself. It is only for gnutls-cli to use some extensions or not. That is why it doesn't affect the SCSV. It is now only send when using SSL 3.0. I don't know how many servers do not work with extensions today, but if it proves to be a problem we might add sending it when the %COMPAT flag is given. >>> - gnutls-cli fails to connect to servers not implementing RFC 5746. >>> While this is required to fully address the issue on the client >>> side, it's likely to cause major issues in short term. >>> gnutls-cli(1) suggests safe initial negotiation should not be >>> required by default (see %INITIAL_SAFE_RENEGOTIATION), >>> %UNSAFE_RENEGOTIATION is required to connect. >>> Note: Both OpenSSL and NSS will not require safe initial >>> negotiation yet for interoperability reasons. >> Nikos, Steve, what do you think here? > > Looks like the current behavior is intentional: > > http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=2a10542bf8f7cfbd5e6a4b17c8d502133da93fc5 > > I appologize for missing it previously. Indeed the option was to be as secure by default on the client side, and backwards compatible on the server side (server is not really affected, but he could protect - by denying access - to clients that don't support secure renegotiation). >> My preference is to not reject these servers, because the >> vulnerability exists theoretically in earlier GnuTLS versions anyway >> but because of the GnuTLS API is different from OpenSSL/NSS most if >> not all GnuTLS applications are not affected by this (renegotiation >> will fail with the majority of GnuTLS applications). > > The above commit message should cover these too. I see NEWS explicitly > mentions that clients need to use %UNSAFE_RENEGOTIATION. You may still > wish to emphasize that in the release announcements. I think it is good practice to warn the user about an insecure server and let him force the unsafe_renegotiation flag. regards, Nikos From thoger at redhat.com Wed Feb 24 17:06:48 2010 From: thoger at redhat.com (Tomas Hoger) Date: Wed, 24 Feb 2010 17:06:48 +0100 Subject: Another renegotiation patch In-Reply-To: <20100218150455.1a4d1195@redhat.com> References: <4B58BC18.7030100@gnutls.org> <873a0zklc5.fsf@mocca.josefsson.org> <20100218125241.0c826a70@redhat.com> <87wryag1wh.fsf@mocca.josefsson.org> <20100218150455.1a4d1195@redhat.com> Message-ID: <20100224170648.11c5c9bb@redhat.com> On Thu, 18 Feb 2010 15:04:55 +0100 Tomas Hoger wrote: > Looks like the current behavior is intentional: > > http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=2a10542bf8f7cfbd5e6a4b17c8d502133da93fc5 Can you have a look at the attached diff. It moves GNUTLS_CLIENT test, so that the "Allowing/Denying unsafe initial negotiation" message is logged instead of "Allowing/Denying unsafe renegotiation" on initial client connection. It also add HANDSHAKE_FAILURE alert for unsafe initial negotiation (client), which is required by RFC 5746, 4.1. Though I'm wondering if this is the right place to generate this alert. If gnutls-serv refuses initial connection from the unpatched client, HANDSHAKE_FAILURE alert is generated, but it's from application rather than library. Should those alerts be generated by applications or library? I'd also consider removing %INITIAL_SAFE_RENEGOTIATION from gnutls-cli.1 (always enforced) and mention client/server defaults in gnutls_priority_init.3. Should I try submitting changes proposal? th. -------------- next part -------------- A non-text attachment was scrubbed... Name: gnutls-hsfail-alert.diff Type: text/x-patch Size: 1500 bytes Desc: not available URL: From thoger at redhat.com Thu Feb 25 11:38:17 2010 From: thoger at redhat.com (Tomas Hoger) Date: Thu, 25 Feb 2010 11:38:17 +0100 Subject: Another renegotiation patch In-Reply-To: <20100224170648.11c5c9bb@redhat.com> References: <4B58BC18.7030100@gnutls.org> <873a0zklc5.fsf@mocca.josefsson.org> <20100218125241.0c826a70@redhat.com> <87wryag1wh.fsf@mocca.josefsson.org> <20100218150455.1a4d1195@redhat.com> <20100224170648.11c5c9bb@redhat.com> Message-ID: <20100225113817.4d001f85@redhat.com> On Wed, 24 Feb 2010 17:06:48 +0100 Tomas Hoger wrote: > It also add HANDSHAKE_FAILURE alert for unsafe initial negotiation > (client), which is required by RFC 5746, 4.1. Though I'm wondering if > this is the right place to generate this alert. If gnutls-serv > refuses initial connection from the unpatched client, > HANDSHAKE_FAILURE alert is generated, but it's from application > rather than library. Should those alerts be generated by > applications or library? Related to this... gnutls-cli currently does not break connection and exit when handshake error occurs during server-requested renegotiation (check_rehandshake() only prints rehandshake result). This can be tested as: $ gnutls-cli -p 666 ssltls.de ... - Simple Client Mode: GET /otherciphers/ HTTP/1.0 *** Non fatal error: Rehandshake was requested by the peer. *** Received rehandshake request *** Fatal error: Safe renegotiation failed. *** Rehandshake Failed. No handshake_failure alert is sent, connection is not terminated. th. From vincent.torri at gmail.com Fri Feb 26 12:57:46 2010 From: vincent.torri at gmail.com (Vincent Torri) Date: Fri, 26 Feb 2010 12:57:46 +0100 Subject: wrong gnutls.pc Message-ID: <222ade941002260357p1cede669jf4cf204525460de3@mail.gmail.com> Hey, compiling libcurl on Windows with MinGW leads to undefined symbols. The problem is in a bug in gnutls.pc. Indeed libgcrypt is a required dependency (btw, it is not checked in gnutls/lib/configure.ac. I think that it must be checked there. The library has a libgcrypt-config to get cflags and libs). Hence, -lgcrypt must appear in the Libs.private field of gnutls.pc Also: * in Libs.private of gnutls.pc.in, @LIBGNUTLS_LIBS@ is added, which means, according to its definition, that -lgnutls appears in Libs.private, which is useless. * libtasn1 is not checked with pkg-config if it exists (well, i don't see anything in gnutls/lib/configure.ac). If it exists, 'libtasn1' must appear in the Requires.private field (or Requires field if you support pkg-config < 0.22). If it does not exists, i think that you link directly against your own libtasn2 code, so @LTLIBTASN1@ should not appear in Libs.private So gnutls.pc.in should be: Name: GnuTLS Description: Transport Security Layer implementation for the GNU system URL: http://www.gnu.org/software/gnutls/ Version: @VERSION@ Requires.private: @requirement_libtasn1@ Libs: -L${libdir} -lgnutls Libs.private: -lgcrypt @requirement_zlib@ Cflags: -I${includedir} where : * requirement_libtasn1 is set to libtasn1 if libtasn1 is installed * requirement_zlib is set to -lz if zlib is found. cheers Vincent Torri -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.torri at gmail.com Fri Feb 26 18:20:39 2010 From: vincent.torri at gmail.com (Vincent Torri) Date: Fri, 26 Feb 2010 18:20:39 +0100 Subject: link error Message-ID: <222ade941002260920i3ad1158hf07699dad922a7f7@mail.gmail.com> >"Vasiliy Ivanov"