From nmav at gnutls.org Fri Feb 1 09:18:06 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 1 Feb 2013 09:18:06 +0100 Subject: [gnutls-devel] Errors building GnuTLS In-Reply-To: <51079891.4090807@cyber.ee> References: <5103B3DB.7070602@cyber.ee> <5103D382.6090200@gnutls.org> <5106501F.5030601@cyber.ee> <51079891.4090807@cyber.ee> Message-ID: Thank you for the patch. Do you think that allowing the disable of individual applications is needed? I thought it would be better to have a global option disable-tools to disable all of them. regards, Nikos On Tue, Jan 29, 2013 at 10:38 AM, Jaak Ristioja wrote: > On 28.01.2013 13:11, Nikos Mavrogiannopoulos wrote: >> On Mon, Jan 28, 2013 at 11:17 AM, Jaak Ristioja wrote: >>> On 26.01.2013 15:00, Nikos Mavrogiannopoulos wrote: >>>> On 01/26/2013 11:45 AM, Jaak Ristioja wrote: >>>>> I'm trying to build GnuTLS (currently from git master), but I'm getting >>>>> some errors. Maybe I'm doing it wrong, but I did >> [...] >>>> I've now fixed the issue you quote. For other issues, or when in doubt >>>> feel free to ask. >>> Thanks! The fix worked for that error. :) Here's what I get next on one >>> of my systems: >>> make[4]: Entering directory `/home/jotik/develop/gnutls/gnutls.git/src' >>> CCLD danetool >>> CCLD certtool >>> danetool.o: In function `dane_info': >> [...] >>> In addition is there a way to ./configure GnuTLS not to build these >>> tools? My goal is just to build a simple library. >> >> There is no option to disable the programs, but I would accept any >> patches for that. >> However, you can just ignore these errors and install the libraries >> you're interested at (e.g., cd lib && make install) > > I'm not very proficient with autotools, but here's my attempt to provide > some patches for this: > > https://gitorious.org/gnutls/gnutls/merge_requests/2 > > Best regards, > Jaak > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-devel From jaak.ristioja at cyber.ee Fri Feb 1 10:27:36 2013 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Fri, 01 Feb 2013 11:27:36 +0200 Subject: [gnutls-devel] Errors building GnuTLS In-Reply-To: References: <5103B3DB.7070602@cyber.ee> <5103D382.6090200@gnutls.org> <5106501F.5030601@cyber.ee> <51079891.4090807@cyber.ee> Message-ID: <510B8A88.4080301@cyber.ee> At first I thought the same, but when I started hacking on it, it actually proved to be easier to implement it this way, because previously whether a tool (e.g. srptool) is built or not was dependent on whether certain feature (e.g. SRP) was enabled or not. Additionally, I already have a usecase where I need to install just some of the tools (i.e. certtool). If I only had --disable-tools, I'd have to work around it using other means (i.e. integrate some sed/patching capabilities to my automatic building tools). Of course it is possible to implement a --disable-tools, but then the Makefile.am files might require even more conditional checking (e.g. for srptool, this would mean checking for --disable-tools, --disable-srp and --disable-srptool). My proposed changes don't make the build system perfect in this matter, but they're simple and sufficient for most use cases, I think. Best regards, Jaak On 01.02.2013 10:18, Nikos Mavrogiannopoulos wrote: > Thank you for the patch. Do you think that allowing the disable of > individual applications is needed? I thought it would be better to > have a global option disable-tools to disable all of them. > > regards, > Nikos > > On Tue, Jan 29, 2013 at 10:38 AM, Jaak Ristioja wrote: >> On 28.01.2013 13:11, Nikos Mavrogiannopoulos wrote: >>> On Mon, Jan 28, 2013 at 11:17 AM, Jaak Ristioja wrote: >>>> On 26.01.2013 15:00, Nikos Mavrogiannopoulos wrote: >>>>> On 01/26/2013 11:45 AM, Jaak Ristioja wrote: >>>>>> I'm trying to build GnuTLS (currently from git master), but I'm getting >>>>>> some errors. Maybe I'm doing it wrong, but I did >>> [...] >>>>> I've now fixed the issue you quote. For other issues, or when in doubt >>>>> feel free to ask. >>>> Thanks! The fix worked for that error. :) Here's what I get next on one >>>> of my systems: >>>> make[4]: Entering directory `/home/jotik/develop/gnutls/gnutls.git/src' >>>> CCLD danetool >>>> CCLD certtool >>>> danetool.o: In function `dane_info': >>> [...] >>>> In addition is there a way to ./configure GnuTLS not to build these >>>> tools? My goal is just to build a simple library. >>> >>> There is no option to disable the programs, but I would accept any >>> patches for that. >>> However, you can just ignore these errors and install the libraries >>> you're interested at (e.g., cd lib && make install) >> >> I'm not very proficient with autotools, but here's my attempt to provide >> some patches for this: >> >> https://gitorious.org/gnutls/gnutls/merge_requests/2 >> >> Best regards, >> Jaak >> >> >> _______________________________________________ >> Gnutls-devel mailing list >> Gnutls-devel at lists.gnutls.org >> http://lists.gnupg.org/mailman/listinfo/gnutls-devel From nmav at gnutls.org Fri Feb 1 11:25:12 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 1 Feb 2013 11:25:12 +0100 Subject: [gnutls-devel] Errors building GnuTLS In-Reply-To: <510B8A88.4080301@cyber.ee> References: <5103B3DB.7070602@cyber.ee> <5103D382.6090200@gnutls.org> <5106501F.5030601@cyber.ee> <51079891.4090807@cyber.ee> <510B8A88.4080301@cyber.ee> Message-ID: On Fri, Feb 1, 2013 at 10:27 AM, Jaak Ristioja wrote: > At first I thought the same, but when I started hacking on it, it > actually proved to be easier to implement it this way, because > previously whether a tool (e.g. srptool) is built or not was dependent > on whether certain feature (e.g. SRP) was enabled or not. Maybe then wouldn't it be easier if disable-srp also disables srptool (and the same for ocsp, psk, and pkcs11)? This would simplify things and only build what can be built. What do you think? regards, Nikos From jouko.orava at helsinki.fi Fri Feb 1 12:02:29 2013 From: jouko.orava at helsinki.fi (Jouko Orava) Date: Fri, 1 Feb 2013 13:02:29 +0200 (EET) Subject: [gnutls-devel] [RFC] Relaxing cipher suite (priority) string requirements In-Reply-To: References: <5102ECF2.80801@gnutls.org> <5103AEE6.6050605@gnutls.org> <5103D9E5.5030303@gnutls.org> <5105D1BC.5020904@gnutls.org> <5107887E.7040708@gnutls.org> Message-ID: > > Consider > > PERFORMANCE:-EXPORT > > for those who really dislike the ciphers in the export level. > EXPORT isn't a subset of PERFORMANCE, so this string would pretty > much be identical to PERFORMANCE. Ah, bad example, then. It just seems that "Performant algorithms, but none of that export crap" and similar configuration strings seem very intuitive for users. I can see no downside in supporting that (assuming my view that users do find that intuitive and useful is correct). > I don't know what you mean with a closed set here. In all types of the > supplied strings you must have one (at least one cipher/mac etc.). I understand. I believe users see it differently, as an extra option that can be added; not an integral feature. At least it surprised the heck out of me when I realized I must explicitly enable no compression. It just felt unexpected and weird to me. > Nevertheless I understand that this is an complication for many, so > there could be a new level that contains it? Right; that sounds much better than changing existing behaviour. I feel a bit silly for not realizing that earlier .. :) > As I understand from your previous description, you add the > ciphersuite name in addition to all existing options, plus some > changes regarding the '+'? Couldn't this be added over the current > priority string format? Lets see. Assume we keep the current behaviour regarding priority strings, but with cipher, key exchange, and MAC priority lists converted to cipher suite priority list at the end of gnutls_priority_init(). Make "+" prefix optional, so we have ::= "+" | nothing ::= "-" | "!" Allow to remove cipher suites present in , making it easier for users to combine levels. (Even if the levels do not overlap, it may be useful in non-technical terms for the user to be able to specify that. For example, using "PERFORMANCE:!EXPORT" you can unequivocably state to pointy-haired-bosses that weak export-grade ciphers are not used, even if technically "PERFORMANCE" by itself already does that.) Allow to add and remove cipher suites. Thus far this looks excellent to me. One issue remains: How should the interact with the cipher suites? I think I have a workable suggestion: When removing a cipher, mac, or key exchange, apply the removal directly to BOTH the internal priority list, and existing cipher suite list. Consider, for example: SECURE256:!AES_256_CBC:TLS_RSA_AES_256_CBC_SHA1 This would result in allowing TLS_RSA_AES_256_CBC_SHA1, but not allowing any other cipher suite using AES_256_CBC cipher. Very logical and intuitive, in my opinion. Better yet, this can be proven to not change the interpretation of current configurations! I would be happy to write a more detailed logical spec of this to the list, if you think this is a possible avenue to go forward with. Do you prefer BNF, or free-form/human readable? Best regards, Jouko From nmav at gnutls.org Fri Feb 1 14:36:09 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 1 Feb 2013 14:36:09 +0100 Subject: [gnutls-devel] [RFC] Relaxing cipher suite (priority) string requirements In-Reply-To: References: <5102ECF2.80801@gnutls.org> <5103AEE6.6050605@gnutls.org> <5103D9E5.5030303@gnutls.org> <5105D1BC.5020904@gnutls.org> <5107887E.7040708@gnutls.org> Message-ID: On Fri, Feb 1, 2013 at 12:02 PM, Jouko Orava wrote: >> > Consider >> > PERFORMANCE:-EXPORT >> > for those who really dislike the ciphers in the export level. >> EXPORT isn't a subset of PERFORMANCE, so this string would pretty >> much be identical to PERFORMANCE. > Ah, bad example, then. It just seems that > "Performant algorithms, but none of that export crap" > and similar configuration strings seem very intuitive for users. > I can see no downside in supporting that (assuming my view that users > do find that intuitive and useful is correct). [...] > (Even if the levels do not overlap, it may be useful > in non-technical terms for the user to be able to > specify that. For example, using "PERFORMANCE:!EXPORT" > you can unequivocably state to pointy-haired-bosses that > weak export-grade ciphers are not used, > even if technically "PERFORMANCE" by itself already does that.) I do believe that this will cause more confusion with the currently available levels, but could be useful when we have more levels that act more like a group of ciphers. >> As I understand from your previous description, you add the >> ciphersuite name in addition to all existing options, plus some >> changes regarding the '+'? Couldn't this be added over the current >> priority string format? > Lets see. > Assume we keep the current behaviour regarding priority strings, > but with cipher, key exchange, and MAC priority lists converted > to cipher suite priority list at the end of gnutls_priority_init(). > Make "+" prefix optional, so we have > ::= "+" | nothing > ::= "-" | "!" > Allow > > to remove cipher suites present in , > making it easier for users to combine levels. Let's then rename level to cipher-group (or ciphersuite-group) to signify better it's purpose. > One issue remains: How should the > > > > interact with the cipher suites? > I think I have a workable suggestion: > When removing a cipher, mac, or key exchange, > apply the removal directly to BOTH the internal > priority list, and existing cipher suite list. > Consider, for example: > SECURE256:!AES_256_CBC:TLS_RSA_AES_256_CBC_SHA1 > This would result in allowing TLS_RSA_AES_256_CBC_SHA1, > but not allowing any other cipher suite using AES_256_CBC cipher. > Very logical and intuitive, in my opinion. Indeed. > I would be happy to write a more detailed logical spec of this > to the list, if you think this is a possible avenue to go forward > with. Do you prefer BNF, or free-form/human readable? I think the best would be a description that could be part of the manual (so that there is no double work to port it there). However, would you be interested in implementing it? I could help with that if needed. regards, Nikos From jouko.orava at helsinki.fi Fri Feb 1 18:55:45 2013 From: jouko.orava at helsinki.fi (Jouko Orava) Date: Fri, 1 Feb 2013 19:55:45 +0200 (EET) Subject: [gnutls-devel] [RFC] Relaxing cipher suite (priority) string requirements In-Reply-To: References: <5102ECF2.80801@gnutls.org> <5103AEE6.6050605@gnutls.org> <5103D9E5.5030303@gnutls.org> <5105D1BC.5020904@gnutls.org> <5107887E.7040708@gnutls.org> Message-ID: > > For example, using "PERFORMANCE:!EXPORT" > > I do believe that this will cause more confusion with the currently > available levels, but could be useful when we have more levels that > act more like a group of ciphers. Fully agreed. > Let's then rename level to cipher-group (or ciphersuite-group) to > signify better it's purpose. Yes, this sounds very sensible and good to me. > I think the best would be a description that could be part of the > manual (so that there is no double work to port it there). However, > would you be interested in implementing it? I could help with that if > needed. Absolutely; it has been my intention all along to write the necessary code. I just didn't want to write it first, then find out the overall logic is completely unacceptable, or worse: worthless, unusable. I'll write some patches, include the description on the functionality in the patch descriptions, and submit them to the list for further development. (Give me a few days, though, as I need to set up a test environment first, to test the priority strings and resulting connection properties easier.) I expect the patches will need some work (at least to better integrate to the style and flow of the GnuTLS code overall, as I'm not as familiar with the codebase yet as I'd like), so the more eyes and minds, the better. Best regards, Jouko From dkg at fifthhorseman.net Sun Feb 3 19:27:13 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 03 Feb 2013 13:27:13 -0500 Subject: [gnutls-devel] Memory leak in initialize_automatic_p11_kit() In-Reply-To: <4F45EE74.2060103@gnutls.org> References: <4F45EE74.2060103@gnutls.org> Message-ID: <87halt45j2.fsf@alice.fifthhorseman.net> On Thu 2012-02-23 02:44:52 -0500, Nikos Mavrogiannopoulos wrote: > On 02/23/2012 12:13 AM, Sam Varshavchik wrote: > >> Valgrind is complaining about a minor memory leak. Looks like it's >> happening only once, on initialization. But, it's still a leak. >> >> ==21602== at 0x4A074CD: malloc (vg_replace_malloc.c:236) >> ==21602== by 0x33D4486A81: strdup (in /lib64/libc-2.14.90.so) >> ==21602== by 0x33DB805907: p11_kit_registered_module_to_name (in >> /usr/lib64/libp11-kit.so.0.0.0) >> ==21602== by 0x3F70C48524: gnutls_pkcs11_init (in >> /usr/lib64/libgnutls.so.26.21.8) >> >> Looking at the code, p11_kit_registered_module_to_name() returns a >> malloced buffer, which the caller seems to be responsible for freeing, >> and initialize_automatic_p11_kit() does not do that. > > > Thank you. Corrected. I've just corrected this leak on the gnutls_2_12_x branch in git as well. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 965 bytes Desc: not available URL: From nmav at gnutls.org Mon Feb 4 10:28:11 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 04 Feb 2013 10:28:11 +0100 Subject: [gnutls-devel] gnutls 3.0.28 Message-ID: <510F7F2B.5060208@gnutls.org> Hello, I've just released gnutls 3.0.28. This is a bug-fix release on the previous stable branch. * Version 3.0.28 (2012-02-04) ** libgnutls: Fixes in server side of DTLS-0.9. ** libgnutls: Corrected gnutls_cipher_decrypt2() when used with AEAD ciphers (i.e., AES-GCM). ** libgnutls: Fixes in record padding parsing to prevent a timing attack. Issue reported by Kenny Patterson and Nadhem Alfardan. ** libgnutls: DN variable 'T' was expanded to 'title'. ** 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.0/gnutls-3.0.28.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-3.0.28.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-3.0.28.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-3.0.28.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Mon Feb 4 10:29:34 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 04 Feb 2013 10:29:34 +0100 Subject: [gnutls-devel] gnutls 2.12.23 Message-ID: <510F7F7E.4060003@gnutls.org> Hello, I've just released gnutls 2.12.22. This is a bug-fix release on the previous stable branch. Version 2.12.23 (released 2012-02-04) ** libgnutls: Eliminated memory leak in PCKS #11 initialization. Report and fix by Sam Varshavchik. ** libgnutls: Fixes in record padding parsing to prevent a timing attack. Issue reported by Kenny Patterson and Nadhem Alfardan. ** libgnutls: DN variable 'T' was expanded to 'title'. ** 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 compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v2.12/gnutls-2.12.23.tar.bz2 Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.0/gnutls-2.12.23.tar.bz2.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Mon Feb 4 11:25:43 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 04 Feb 2013 11:25:43 +0100 Subject: [gnutls-devel] gnutls 3.1.7 Message-ID: <510F8CA7.6090203@gnutls.org> Hello, I've just released gnutls 3.1.7. This is a new release on the current stable branch. Note that this release includes a new gnutls-xssl library which provides a very simple API to use. The new API is demonstrated in [0]. We welcome comments on the new API. [0]. http://www.gnutls.org/manual/html_node/XSSL-examples.html#XSSL-examples * Version 3.1.7 (released 2012-02-04) ** certtool: Added option "dn" which allows to directly set the DN in a template from an RFC4514 string. ** danetool: Added options: --dlv and --insecure. Suggested by Paul Wouters. ** libgnutls-xssl: Added a new library to simplify GnuTLS usage. ** libgnutls-dane: Added function to specify a DLV file. ** libgnutls: Heartbeat code was made optional. ** libgnutls: Fixes in server side of DTLS-0.9. ** libgnutls: DN variable 'T' was expanded to 'title'. ** libgnutls: Fixes in record padding parsing to prevent a timing attack. Issue reported by Kenny Paterson and Nadhem Alfardan. ** libgnutls: Added functions to directly set the DN in a certificate or request from an RFC4514 string. ** libgnutls: Optimizations in the random generator. The re-seeding of it is now explicitly done on every session deinit. ** libgnutls: Simplified the DTLS sliding window implementation. ** libgnutls: The minimum DH bits accepted by a client are now set by the specified priority string. The current values correspond to the previous defaults (727 bits), except for the SECURE128 and SECURE192 strings which increase the minimum to 1248 and 1776 respectively. ** libgnutls: Added the gnutls_record_cork() and uncork API to enable buffering in sending application data. ** libgnutls: Removed default random padding, and added a length-hiding interface instead. Both the server and the client must support this extension. Whether length-hiding can be used on a given session can be checked using gnutls_record_can_use_length_hiding(). Contributed by Alfredo Pironti. ** libgnutls: Added the experimental %NEW_PADDING priority string. It enables a new padding mechanism in TLS allowing arbitrary padding in TLS records in all ciphersuites, which makes length-hiding more efficient and solves the issues with timing attacks on CBC ciphersuites. ** libgnutls: Corrected gnutls_cipher_decrypt2() when used with AEAD ciphers (i.e., AES-GCM). Reported by William McGovern. ** API and ABI modifications: gnutls_db_check_entry_time: Added gnutls_record_set_timeout: Added gnutls_record_get_random_padding_status: Added gnutls_x509_crt_set_dn: Added gnutls_x509_crt_set_issuer_dn: Added gnutls_x509_crq_set_dn: Added gnutls_record_cork: Added gnutls_record_uncork: Added gnutls_range_split: Added gnutls_record_send_range: Added gnutls_record_set_max_empty_records: Added gnutls_record_can_use_length_hiding: Added gnutls_rnd_refresh: Added xssl_deinit: Added xssl_flush: Added xssl_read: Added xssl_getdelim: Added xssl_write: Added xssl_printf: Added xssl_sinit: Added xssl_client_init: Added xssl_server_init: Added xssl_get_session: Added xssl_get_verify_status: Added xssl_cred_init: Added xssl_cred_deinit: Added dane_state_set_dlv_file: Added GNUTLS_SEC_PARAM_EXPORT: Added GNUTLS_SEC_PARAM_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.1/gnutls-3.1.7.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.7.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.7.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.7.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Mon Feb 4 12:40:38 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 04 Feb 2013 12:40:38 +0100 Subject: [gnutls-devel] end of life of 2.12 and possible relicense on 3.1 Message-ID: <510F9E36.6000100@gnutls.org> Hello, Unless someone else steps up and is willing to maintain 2.12.x I no longer plan to maintain it. The code base differs significantly with 3.x and backporting takes too much time. Also I am considering into having the next releases in 3.1.x under LGPLv2.1 instead of LGPLv3. This is a first step to solve the compatibility issues of gnutls with GPLv2 programs. However, to completely solve that issue, one would also need to use an older gmp library also licensed under LGPLv2.1. (I have not tested that scenario, but in the worst case it may require small changes in nettle or gnutls). For the relicensing to happen the authors of contributed code after the relicense to LGPLv3 date (2011-06-08) have to agree. Note that is only about the authors of library code, no relicensing happens on documentation (FDL) or the included programs (GPLv3). After checking the history in the repository, I've contacted the following authors and asked them whether they would agree to relicense their code under LGPLv2.1: David Woodhouse: Agreed Ilya Tumaykin: Agreed Ludwig Nussel: Agreed Martin Storsjo: Agreed Stef Walter: Agreed Collabra (Guy Lunardi): Agreed Simon Josefsson: Agreed Olga Smolenchuk: Didn't agree I've tried to check the history carefully, but it is quite a long period, so if I have missed any author of code you are aware of please let me know. If the above is correct, then the heartbeat handling code (which is based on Olga's contribution) will be made optional (it is already optional on the current release), and the library compiled by default will be available under LGPLv2.1. best regards, Nikos From mabrand at mabrand.nl Mon Feb 4 15:49:52 2013 From: mabrand at mabrand.nl (Mark Brand) Date: Mon, 04 Feb 2013 15:49:52 +0100 Subject: [gnutls-devel] gnutls 3.1.7 In-Reply-To: <510F8CA7.6090203@gnutls.org> References: <510F8CA7.6090203@gnutls.org> Message-ID: <510FCA90.9060503@mabrand.nl> Nikos Mavrogiannopoulos wrote: > Hello, > I've just released gnutls 3.1.7. This is a new release on the current > stable branch. Hi, I think there is unmatched ) here: rnd.c: In function 'do_device_source': rnd.c:167:94: error: expected statement before ')' token regards, Mark From eliz at gnu.org Mon Feb 4 16:56:38 2013 From: eliz at gnu.org (Eli Zaretskii) Date: Mon, 04 Feb 2013 17:56:38 +0200 Subject: [gnutls-devel] end of life of 2.12 and possible relicense on 3.1 In-Reply-To: <510F9E36.6000100@gnutls.org> References: <510F9E36.6000100@gnutls.org> Message-ID: <83sj5c9io9.fsf@gnu.org> > Date: Mon, 04 Feb 2013 12:40:38 +0100 > From: Nikos Mavrogiannopoulos > Cc: Stef Walter , Olya , > Guy Lunardi , > David Woodhouse > > Also I am considering into having the next releases in 3.1.x under > LGPLv2.1 instead of LGPLv3. This is a first step to solve the > compatibility issues of gnutls with GPLv2 programs. However, to > completely solve that issue, one would also need to use an older gmp > library also licensed under LGPLv2.1. (I have not tested that scenario, > but in the worst case it may require small changes in nettle or gnutls). > > For the relicensing to happen the authors of contributed code after the > relicense to LGPLv3 date (2011-06-08) have to agree. Note that is only > about the authors of library code, no relicensing happens on > documentation (FDL) or the included programs (GPLv3). > > After checking the history in the repository, I've contacted the > following authors and asked them whether they would agree to relicense > their code under LGPLv2.1: > > David Woodhouse: Agreed > Ilya Tumaykin: Agreed > Ludwig Nussel: Agreed > Martin Storsjo: Agreed > Stef Walter: Agreed > Collabra (Guy Lunardi): Agreed > Simon Josefsson: Agreed > Olga Smolenchuk: Didn't agree > > I've tried to check the history carefully, but it is quite a long > period, so if I have missed any author of code you are aware of please > let me know. > > If the above is correct, then the heartbeat handling code (which is > based on Olga's contribution) will be made optional (it is already > optional on the current release), and the library compiled by default > will be available under LGPLv2.1. What will all this mean for Emacs, which can be optionally be built with GnuTLS and uses GPLv3? From branko at majic.rs Mon Feb 4 17:18:38 2013 From: branko at majic.rs (Branko Majic) Date: Mon, 4 Feb 2013 17:18:38 +0100 Subject: [gnutls-devel] end of life of 2.12 and possible relicense on 3.1 In-Reply-To: <510F9E36.6000100@gnutls.org> References: <510F9E36.6000100@gnutls.org> Message-ID: <20130204171838.751bdbbe@zetkin.primekey.se> On Mon, 04 Feb 2013 12:40:38 +0100 Nikos Mavrogiannopoulos wrote: > Also I am considering into having the next releases in 3.1.x under > LGPLv2.1 instead of LGPLv3. This is a first step to solve the > compatibility issues of gnutls with GPLv2 programs. Would this be with a "or later" clause, or fixed to LGPLv2.1? Has there been a lot of programs out there that had been affected by this license incompatibility? Best regards -- Branko Majic Jabber: branko at majic.rs Please use only Free formats when sending attachments to me. ?????? ????? ?????: branko at majic.rs ????? ??? ?? ??????? ?????? ????????? ? ????????? ?????????. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From nmav at gnutls.org Mon Feb 4 18:11:31 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 04 Feb 2013 18:11:31 +0100 Subject: [gnutls-devel] end of life of 2.12 and possible relicense on 3.1 In-Reply-To: <83sj5c9io9.fsf@gnu.org> References: <510F9E36.6000100@gnutls.org> <83sj5c9io9.fsf@gnu.org> Message-ID: <510FEBC3.9080009@gnutls.org> On 02/04/2013 04:56 PM, Eli Zaretskii wrote: >> If the above is correct, then the heartbeat handling code (which is >> based on Olga's contribution) will be made optional (it is already >> optional on the current release), and the library compiled by default >> will be available under LGPLv2.1. > > What will all this mean for Emacs, which can be optionally be built > with GnuTLS and uses GPLv3? It will be LGPLv2.1 or later, so it will be compatible with all FSF range of licenses. regards, Nikos From nmav at gnutls.org Mon Feb 4 18:21:04 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 04 Feb 2013 18:21:04 +0100 Subject: [gnutls-devel] advisory GNUTLS-SA-2013-1 Message-ID: <510FEE00.8090502@gnutls.org> Hello, I've put online a security advisory on the "lucky 13" CBC ciphersuite attack in [0]. The advisory can be found at: http://www.gnutls.org/security.html#GNUTLS-SA-2013-1 [0]. http://www.isg.rhul.ac.uk/tls/ regards, Nikos From eliz at gnu.org Mon Feb 4 19:07:25 2013 From: eliz at gnu.org (Eli Zaretskii) Date: Mon, 04 Feb 2013 20:07:25 +0200 Subject: [gnutls-devel] end of life of 2.12 and possible relicense on 3.1 In-Reply-To: <510FEBC3.9080009@gnutls.org> References: <510F9E36.6000100@gnutls.org> <83sj5c9io9.fsf@gnu.org> <510FEBC3.9080009@gnutls.org> Message-ID: <83mwvk9cma.fsf@gnu.org> > Date: Mon, 04 Feb 2013 18:11:31 +0100 > From: Nikos Mavrogiannopoulos > CC: gnutls-devel at lists.gnutls.org > > On 02/04/2013 04:56 PM, Eli Zaretskii wrote: > > >> If the above is correct, then the heartbeat handling code (which is > >> based on Olga's contribution) will be made optional (it is already > >> optional on the current release), and the library compiled by default > >> will be available under LGPLv2.1. > > > > What will all this mean for Emacs, which can be optionally be built > > with GnuTLS and uses GPLv3? > > > It will be LGPLv2.1 or later, so it will be compatible with all FSF > range of licenses. IANAL, so please forgive me my ignorance. I'm worried by this wording: When we say that GPLv2 and GPLv3 are incompatible, it means there is no legal way to combine code under GPLv2 with code under GPLv3 in a single program. which can be found at the beginning of this page: http://www.gnu.org/licenses/rms-why-gplv3.html It talks about GPLv2, not LGPLv2.1, but it still isn't clear to me whether linking a GPLv3 Emacs against LGPLv2.1 GnuTLS library is possible. From flameeyes at flameeyes.eu Mon Feb 4 19:10:47 2013 From: flameeyes at flameeyes.eu (=?UTF-8?B?RGllZ28gRWxpbyBQZXR0ZW7Dsg==?=) Date: Mon, 04 Feb 2013 19:10:47 +0100 Subject: [gnutls-devel] end of life of 2.12 and possible relicense on 3.1 In-Reply-To: <83mwvk9cma.fsf@gnu.org> References: <510F9E36.6000100@gnutls.org> <83sj5c9io9.fsf@gnu.org> <510FEBC3.9080009@gnutls.org> <83mwvk9cma.fsf@gnu.org> Message-ID: <510FF9A7.4060804@flameeyes.eu> On 04/02/2013 19:07, Eli Zaretskii wrote: > It talks about GPLv2, not LGPLv2.1, but it still isn't clear to me > whether linking a GPLv3 Emacs against LGPLv2.1 GnuTLS library is > possible. If as Nikos say it's going to be "LGPLv2.1 or later", it auto-promotes itself to LGPLv3 when linked against GPLv3 software. -- Diego Elio Petten? ? Flameeyes flameeyes at flameeyes.eu ? http://blog.flameeyes.eu/ From cloos at jhcloos.com Mon Feb 4 19:36:52 2013 From: cloos at jhcloos.com (James Cloos) Date: Mon, 04 Feb 2013 13:36:52 -0500 Subject: [gnutls-devel] end of life of 2.12 and possible relicense on 3.1 In-Reply-To: <83mwvk9cma.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 04 Feb 2013 20:07:25 +0200") References: <510F9E36.6000100@gnutls.org> <83sj5c9io9.fsf@gnu.org> <510FEBC3.9080009@gnutls.org> <83mwvk9cma.fsf@gnu.org> Message-ID: >>>>> "EZ" == Eli Zaretskii writes: >> It will be LGPLv2.1 or later, so it will be compatible with all FSF >> range of licenses. EZ> It talks about GPLv2, not LGPLv2.1, but it still isn't clear to me EZ> whether linking a GPLv3 Emacs against LGPLv2.1 GnuTLS library is EZ> possible. I believe that page talks about v2-only vs v3-only. That issue does indeed apply, according to every opinion posted since v3 came out, for lgpl-v2-only vs lgpl-v3-only vs gpl-v2-only vs gpl-v3-only. But, given that, if it changes, gnutls will be LGPLv2.1 or later (as noted above), Emacs can use gnutls under the or later clause as LGPL3 and avoid all of those issues. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From nmav at gnutls.org Mon Feb 4 22:45:51 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 04 Feb 2013 22:45:51 +0100 Subject: [gnutls-devel] gnutls 3.1.7 In-Reply-To: <510FCA90.9060503@mabrand.nl> References: <510F8CA7.6090203@gnutls.org> <510FCA90.9060503@mabrand.nl> Message-ID: <51102C0F.7080208@gnutls.org> On 02/04/2013 03:49 PM, Mark Brand wrote: > > Nikos Mavrogiannopoulos wrote: >> Hello, >> I've just released gnutls 3.1.7. This is a new release on the current >> stable branch. > Hi, > > I think there is unmatched ) here: > > rnd.c: In function 'do_device_source': > rnd.c:167:94: error: expected statement before ')' token Thanks. It's now fixed. regards, Nikos From flameeyes at flameeyes.eu Tue Feb 5 02:31:41 2013 From: flameeyes at flameeyes.eu (=?UTF-8?B?RGllZ28gRWxpbyBQZXR0ZW7Dsg==?=) Date: Tue, 05 Feb 2013 02:31:41 +0100 Subject: [gnutls-devel] gnutls 3.1.7 In-Reply-To: <51102C0F.7080208@gnutls.org> References: <510F8CA7.6090203@gnutls.org> <510FCA90.9060503@mabrand.nl> <51102C0F.7080208@gnutls.org> Message-ID: <511060FD.1030704@flameeyes.eu> On 04/02/2013 22:45, Nikos Mavrogiannopoulos wrote: > > Thanks. It's now fixed. Please don't tell me you just re-rolled the tarball... -- Diego Elio Petten? ? Flameeyes flameeyes at flameeyes.eu ? http://blog.flameeyes.eu/ From dwmw2 at infradead.org Mon Feb 4 13:00:29 2013 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 04 Feb 2013 12:00:29 +0000 Subject: [gnutls-devel] end of life of 2.12 and possible relicense on 3.1 In-Reply-To: <510F9E36.6000100@gnutls.org> References: <510F9E36.6000100@gnutls.org> Message-ID: <1359979229.23632.52.camel@shinybook.infradead.org> On Mon, 2013-02-04 at 12:40 +0100, Nikos Mavrogiannopoulos wrote: > Also I am considering into having the next releases in 3.1.x under > LGPLv2.1 instead of LGPLv3. This is a first step to solve the > compatibility issues of gnutls with GPLv2 programs. However, to > completely solve that issue, one would also need to use an older gmp > library also licensed under LGPLv2.1. (I have not tested that > scenario, but in the worst case it may require small changes in nettle > or gnutls). There are some distributions who would still baulk at shipping GnuTLS v3 even if it's relicensed, because of the EC support. This ought to be mostly an educational issue ? RFC6090 should have settled the matter as far as GnuTLS goes. But legal departments move slowly, and GnuTLS v3 wouldn't get into Fedora or Red Hat with EC support yet. It would make some sense to make it optional too. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6171 bytes Desc: not available URL: From Erik.Jensen at pnnl.gov Tue Feb 5 01:33:10 2013 From: Erik.Jensen at pnnl.gov (Jensen, Erik A) Date: Mon, 4 Feb 2013 16:33:10 -0800 Subject: [gnutls-devel] gnutls_pubkey_get_verify_algorithm fails with RSA keys of over 1536 bits Message-ID: <575C3EA07346E84D8AA1800447AE8AD30105B683BADD@EMAIL05.pnl.gov> Calling gnutls_pubkey_get_verify_algorithm with an RSA signature of more than 192 bytes results in GNUTLS_E_PK_SIG_VERIFY_FAILED. This means that usage with keys with a modulus of over 1536 bits is impossible. I tracked the problem down to line 1064 of lib/nettle/pk.c: uint8_t digest_info[MAX_HASH_SIZE*3] which, along with 1011: if (key->size == 0 || *length < key->size) results in the error. MAX_HASH_SIZE is 64, so only 192 bytes are allocated. I would expect the function to be able at least to handle the 15424 bit (1928 byte) RSA keys generated by certtool when sec-param is set to ultra (and their corresponding signatures), but it'd be nice not to have a restriction at all. This bug also causes the deprecated gnutls_pubkey_verify_hash function always to fail when using RSA keys of over 1536 bits. From nmav at gnutls.org Tue Feb 5 09:06:08 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 05 Feb 2013 09:06:08 +0100 Subject: [gnutls-devel] gnutls 3.1.7 In-Reply-To: <511060FD.1030704@flameeyes.eu> References: <510F8CA7.6090203@gnutls.org> <510FCA90.9060503@mabrand.nl> <51102C0F.7080208@gnutls.org> <511060FD.1030704@flameeyes.eu> Message-ID: <5110BD70.1000801@gnutls.org> On 02/05/2013 02:31 AM, Diego Elio Petten? wrote: >> Thanks. It's now fixed. > > Please don't tell me you just re-rolled the tarball... The tarball is the same as before. The fix is in the repository (the issue pointed was in win32 code). regards, Nikos From INVALID.NOREPLY at gnu.org Tue Feb 5 11:46:33 2013 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Tue, 05 Feb 2013 10:46:33 +0000 Subject: [gnutls-devel] [sr #108246] compilation error for mingw64 on gnutls-3.1.7 Message-ID: <20130205-104632.sv0.22503@savannah.gnu.org> URL: Summary: compilation error for mingw64 on gnutls-3.1.7 Project: GnuTLS Submitted by: None Submitted on: Tue 05 Feb 2013 10:46:32 AM UTC Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: we use gmplib-5.1.0, nettle-2.6, gnutls-3.1.7 and compile with mingw64. During compilation of 3.1.7 version the following error appears: ... CC pk.lo CC mpi.lo CC mac.lo CC cipher.lo CC rnd.lo ../../../lib/nettle/rnd.c: In function 'do_device_source': ../../../lib/nettle/rnd.c:167:94: error: expected statement before ')' token _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From jaak.ristioja at cyber.ee Tue Feb 5 16:59:34 2013 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Tue, 05 Feb 2013 17:59:34 +0200 Subject: [gnutls-devel] Waiting for input data Message-ID: <51112C66.30003@cyber.ee> Hello! How does one wait for data to become available for reading with gnutls_record_recv without actually reading any of it? I tried to use gnutls_record_check_pending in a wait loop but it failed. The obvious reason for it was that gnutls_record_check_pending is basically only a getter and does not read any data from the transport layer even thou there might be some available. Can this behaviour be changed so that GnuTLS tries to pull and process data from the transport layer first? I need something like this because I want my thread to sleep (most of the time) until either (1) data becomes available or (2) another thread signals the thread to stop waiting for any data. Please help! Best regards, Jaak From jaak.ristioja at cyber.ee Tue Feb 5 17:23:31 2013 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Tue, 05 Feb 2013 18:23:31 +0200 Subject: [gnutls-devel] Casting from int to (void *) Message-ID: <51113203.7030300@cyber.ee> Hello! According to the documentation GnuTLS functions like gnutls_transport_set_ptr can also be used for berkeley style sockets descriptors, but unfortunately converting between int and void * types is not always good thing to do: https://www.securecoding.cert.org/confluence/display/seccode/INT11-C.+Converting+a+pointer+to+integer+or+integer+to+pointer https://www.securecoding.cert.org/confluence/display/cplusplus/INT11-CPP.+Take+care+when+converting+from+pointer+to+integer+or+integer+to+pointer Compilers like GCC and Clang also complain about casting the (int) socket descriptors to void * types. Perhaps it were better to provide a gnutls_transport_set_berkeley function which would accept berkeley-style (int) socket descriptors instead. The idea is that if gnutls_transport_set_ptr or gnutls_transport_set_ptr2 is used the push and pull callbacks must also be set, but if gnutls_transport_set_berkeley is used, the callbacks are not used. Afaik using intptr_t could also be an option, but in that case one has to verify that all values of type int fit into intptr_t. Best regards, Jaak From jouko.orava at helsinki.fi Tue Feb 5 17:49:27 2013 From: jouko.orava at helsinki.fi (Jouko Orava) Date: Tue, 5 Feb 2013 18:49:27 +0200 (EET) Subject: [gnutls-devel] Waiting for input data In-Reply-To: <51112C66.30003@cyber.ee> References: <51112C66.30003@cyber.ee> Message-ID: Hello! On Tue, 5 Feb 2013, Jaak Ristioja wrote: > I want my thread to sleep (most of the time) until either (1) data > becomes available or (2) another thread signals the thread to stop > waiting for any data. Have you simply set the socket descriptor to nonblocking? fcntl(sd, F_SETFL, O_NONBLOCK); At a quick look, GnuTLS should return GNUTLS_E_AGAIN if there is no data pending on a nonblocking socket [so underlying recv() returns EAGAIN]. You can use select()/epoll()/etc. on the socket descriptor (sd) to check if there might be data available (gnutls_record_recv() may still return GNUTLS_E_AGAIN). Another option is to keep the socket blocking, but use an empty-body signal handler to interrupt the gnutls_record_recv(), i.e. via pthread_kill(thread, signum); or pthread_sigqueue(thread, signum, value); The delivery of the signal to the target thread will interrupt blocking I/O calls; the body of the signal handler can be empty. Note, however, that gnutls_record_recv() may return with data even if the signal was fired, if sufficient data arrives in a big enough clump. That means you must not rely on always noticing the signal (by receiving an error from gnutls_record_recv()); you must have a secondary flag (semaphore, or atomic flag) to indicate that there is extra processing needed to be done. I haven't done this with GnuTLS, but I'm very familiar with the underlying low-level I/O in Linux. Regards, Jouko Orava From nmav at gnutls.org Tue Feb 5 19:18:49 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 05 Feb 2013 19:18:49 +0100 Subject: [gnutls-devel] gnutls_pubkey_get_verify_algorithm fails with RSA keys of over 1536 bits In-Reply-To: <575C3EA07346E84D8AA1800447AE8AD30105B683BADD@EMAIL05.pnl.gov> References: <575C3EA07346E84D8AA1800447AE8AD30105B683BADD@EMAIL05.pnl.gov> Message-ID: <51114D09.4030403@gnutls.org> On 02/05/2013 01:33 AM, Jensen, Erik A wrote: > Calling gnutls_pubkey_get_verify_algorithm with an RSA signature of more than 192 bytes results in GNUTLS_E_PK_SIG_VERIFY_FAILED. This means that usage with keys with a modulus of over 1536 bits is impossible. > > I tracked the problem down to line 1064 of lib/nettle/pk.c: > uint8_t digest_info[MAX_HASH_SIZE*3] > which, along with 1011: > if (key->size == 0 || *length < key->size) > results in the error. > > MAX_HASH_SIZE is 64, so only 192 bytes are allocated. I would expect the function to be able at least to handle the 15424 bit (1928 byte) RSA keys generated by certtool when sec-param is set to ultra (and their corresponding signatures), but it'd be nice not to have a restriction at all. > > This bug also causes the deprecated gnutls_pubkey_verify_hash function always to fail when using RSA keys of over 1536 bits. Hello, Thank you for the report. I have committed the attached fix to the issue. However, you should switch to verify_hash2() instead because the verify_hash() function relies on the algorithm information in the signature to be correct (and you never know if there is some possible cross-algorithm collision attack). regards, Nikos -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch.txt URL: From nmav at gnutls.org Wed Feb 6 12:40:17 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 6 Feb 2013 12:40:17 +0100 Subject: [gnutls-devel] end of life of 2.12 and possible relicense on 3.1 In-Reply-To: <1359979229.23632.52.camel@shinybook.infradead.org> References: <510F9E36.6000100@gnutls.org> <1359979229.23632.52.camel@shinybook.infradead.org> Message-ID: On Mon, Feb 4, 2013 at 1:00 PM, David Woodhouse wrote: > There are some distributions who would still baulk at shipping GnuTLS v3 > even if it's relicensed, because of the EC support. > This ought to be mostly an educational issue ? RFC6090 should have > settled the matter as far as GnuTLS goes. But legal departments move > slowly, and GnuTLS v3 wouldn't get into Fedora or Red Hat with EC > support yet. It would make some sense to make it optional too. I cannot say what is the current situation with gnutls3 in fedora, because I don't know. However, the approach is followed in gnutls, is not to add algorithms that are known to be patented (this doesn't mean that the code is patent-free, there is no way anyone can guarantee that). If someone for his own reasons would like to disable some code, that's fine with me, I'll accept any patches that provide an option for that code. regards, Nikos From nmav at gnutls.org Thu Feb 7 09:34:13 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 7 Feb 2013 09:34:13 +0100 Subject: [gnutls-devel] Casting from int to (void *) In-Reply-To: <51113203.7030300@cyber.ee> References: <51113203.7030300@cyber.ee> Message-ID: On Tue, Feb 5, 2013 at 5:23 PM, Jaak Ristioja wrote: > Hello! > According to the documentation GnuTLS functions like > gnutls_transport_set_ptr can also be used for berkeley style sockets > descriptors, but unfortunately converting between int and void * types > is not always good thing to do: Hello, What we actually need is for the compiler to be able to do (int->ptr) and then (ptr->int) in a way that no information is lost (i.e., the last int will be the same as the first). The current approach is, if the callbacks are set, then the provided pointer is passed to them, and if not, the transport pointer is casted to an integer and provided to send(). If there was an issue a function like you describe could be used and the the value to a union, but is it really needed? Do you think there will be systems where the current behavior will not be tolerated? (such a set_berkeley function would solve the warning issue though) regards, Nikos From hilberg at kernelconcepts.de Thu Feb 7 10:10:44 2013 From: hilberg at kernelconcepts.de (Christian Hilberg) Date: Thu, 7 Feb 2013 10:10:44 +0100 Subject: [gnutls-devel] Casting from int to (void *) In-Reply-To: References: <51113203.7030300@cyber.ee> Message-ID: <201302071010.51549.hilberg@kernelconcepts.de> Hi, Am Donnerstag 07 Februar 2013, um 09:34:13 schrieb Nikos Mavrogiannopoulos: > On Tue, Feb 5, 2013 at 5:23 PM, Jaak Ristioja wrote: > > Hello! > > According to the documentation GnuTLS functions like > > gnutls_transport_set_ptr can also be used for berkeley style sockets > > descriptors, but unfortunately converting between int and void * types > > is not always good thing to do: > > Hello, > What we actually need is for the compiler to be able to do (int->ptr) > and then (ptr->int) in a way that no information is lost (i.e., the > last int will be the same as the first). The current approach is, if > the callbacks are set, then the provided pointer is passed to them, > and if not, the transport pointer is casted to an integer and provided > to send(). If there was an issue a function like you describe could be > used and the the value to a union, but is it really needed? Do you > think there will be systems where the current behavior will not be > tolerated? (such a set_berkeley function would solve the warning issue > though) Maybe have a look at the GLib GINT_TO_POINTER and GPOINTER_TO_INT macros. Possibly there's some inspiration available there, although I'm not currently sure whether they do much magic there. (Bye)^2, Christian -- kernel concepts GmbH Tel: +49-271-771091-11 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From jaak.ristioja at cyber.ee Thu Feb 7 15:10:34 2013 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Thu, 07 Feb 2013 16:10:34 +0200 Subject: [gnutls-devel] Casting from int to (void *) In-Reply-To: References: <51113203.7030300@cyber.ee> Message-ID: <5113B5DA.2030504@cyber.ee> Hi! On 07.02.2013 10:34, Nikos Mavrogiannopoulos wrote: > What we actually need is for the compiler to be able to do (int->ptr) > and then (ptr->int) in a way that no information is lost (i.e., the > last int will be the same as the first). The compilers try to follow the language standards on these matters and trying to change the compiler or the language standards is probably not an option. According to C99 it is undefined behavior if the value of pointer can't be represented by the respective integer type. The result of converting an integer to a pointer and vice versa is implementation-defined. As far as I know this might mean that converting there and back again might not be result in the original input, i.e. (x != (int)(void *) x) might hold for integer x. > The current approach is, if > the callbacks are set, then the provided pointer is passed to them, > and if not, the transport pointer is casted to an integer and provided > to send(). If there was an issue a function like you describe could be > used and the the value to a union, but is it really needed? Do you > think there will be systems where the current behavior will not be > tolerated? (such a set_berkeley function would solve the warning issue > though) The current solution probably works for most x86 setups, but not for all. The compiler warning is completely reasonable, as it points out something which might not work properly on some platforms. I suspect this behavior can't be corrected without breaking the ABI/API. I think stuff with actual (void *) pointers still works if the respective callbacks are properly set. When designing a new API one has to consider that we currently have at least three different types of situations: 1) Berkeley socket descriptor and standard recv/send/select.. as pull/push/pull_timeout functions 2) Custom transport pointer (void *) and custom pull/push/pull_timeout functions 3) Two custom transport pointers (void *) and custom pull/push/pull_timeout functions I guess one of the simplest solutions would be to define only one new function like the following: int gnutls_set_transport_berkeley(gnutls_session_t session, int sd); Something like this would prevent unportable int<->ptr conversions (or only warnings for users compiling against your library, if you decide to use such conversions inside GnuTLS anyway). Inside the library you can either have separate transport objects for "Berkeley" and "Custom", or an union of some kind or whatever. For other custom transports, gnutls_transport_set_ptr and gnutls_transport_set_ptr2 can still be used. Of course the semantics for the callback functions also need to be changed. Namely that the callback functions should only be called when a custom transport is set. If a berkeley transport is set with gnutls_set_transport_berkeley, then the callbacks (which take a gnutls_transport_ptr_t a.k.a void * argument) are not called. This is my proposal. Best regards, Jaak From nmav at gnutls.org Thu Feb 7 19:06:35 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 07 Feb 2013 19:06:35 +0100 Subject: [gnutls-devel] Casting from int to (void *) In-Reply-To: <5113B5DA.2030504@cyber.ee> References: <51113203.7030300@cyber.ee> <5113B5DA.2030504@cyber.ee> Message-ID: <5113ED2B.90606@gnutls.org> On 02/07/2013 03:10 PM, Jaak Ristioja wrote: > The current solution probably works for most x86 setups, but not for > all. The compiler warning is completely reasonable, as it points out > something which might not work properly on some platforms. > I suspect this behavior can't be corrected without breaking the ABI/API. > I think stuff with actual (void *) pointers still works if the > respective callbacks are properly set. Hello, I by change to the ABI you mean adding a new function, that's not a high cost. However, my main concern is whether there is an actual system where the current approach causes a problem in order to justify any action (at least from my part, if you submit a patch for that, that's another story). > I guess one of the simplest solutions would be to define only one new > function like the following: > > int gnutls_set_transport_berkeley(gnutls_session_t session, int sd); > > Something like this would prevent unportable int<->ptr conversions (or > only warnings for users compiling against your library, if you decide to > use such conversions inside GnuTLS anyway). Inside the library you can Why you need to use such conversions? I'd add a union for that, and possibly a type indicator. > Of course the semantics for the callback functions also need to be > changed. Namely that the callback functions should only be called when a > custom transport is set. If a berkeley transport is set with > gnutls_set_transport_berkeley, then the callbacks (which take a > gnutls_transport_ptr_t a.k.a void * argument) are not called. As you described before the typical cases are 3, I would just describe the behavior when improperly mixing the transport function as undefined :) regards, Nikos From stefw at gnome.org Thu Feb 7 21:43:06 2013 From: stefw at gnome.org (Stef Walter) Date: Thu, 07 Feb 2013 21:43:06 +0100 Subject: [gnutls-devel] Casting from int to (void *) In-Reply-To: <5113ED2B.90606@gnutls.org> References: <51113203.7030300@cyber.ee> <5113B5DA.2030504@cyber.ee> <5113ED2B.90606@gnutls.org> Message-ID: <511411DA.1040806@gnome.org> On 02/07/2013 07:06 PM, Nikos Mavrogiannopoulos wrote: > On 02/07/2013 03:10 PM, Jaak Ristioja wrote: > >> The current solution probably works for most x86 setups, but not for >> all. The compiler warning is completely reasonable, as it points out >> something which might not work properly on some platforms. >> I suspect this behavior can't be corrected without breaking the ABI/API. >> I think stuff with actual (void *) pointers still works if the >> respective callbacks are properly set. > > > Hello, > I by change to the ABI you mean adding a new function, that's not a > high cost. > > However, my main concern is whether there is an actual system where the > current approach causes a problem in order to justify any action (at > least from my part, if you submit a patch for that, that's another story). FWIW, Glib has has macros for putting ints into pointers, and taking them back out: GUINT_TO_POINTER GPOINTER_TO_UINT GINT_TO_POINTER GPOINTER_TO_INT I mention this because I believe the general consensus is that there is no relevant platform for which you can't store 32-bits of integer in a pointer. Cheers, Stef From cve-assign at mitre.org Wed Feb 6 02:08:44 2013 From: cve-assign at mitre.org (cve-assign at mitre.org) Date: Tue, 5 Feb 2013 20:08:44 -0500 (EST) Subject: [gnutls-devel] [oss-security] CVE request: TLS CBC padding timing flaw in various SSL / TLS implementations In-Reply-To: <201302052332.r15NW0wj022388@linus.mitre.org> Message-ID: <201302060108.r1618iQJ023669@linus.mitre.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If you are interested in the CVE name assignments for the recent TLS and DTLS disclosure at http://www.isg.rhul.ac.uk/tls/TLStiming.pdf please see: http://openwall.com/lists/oss-security/2013/02/05/24 This references: Mozilla Network Security Services (NSS) CVE-2013-1620 GnuTLS CVE-2013-1619 PolarSSL three CVEs (see below) PolarSSL - TLS and DTLS protocol issue: CVE-2013-0169 PolarSSL - out-of-bounds comparisons: CVE-2013-1621 PolarSSL - lack of MAC check in some cases: CVE-2013-1622 and other products. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (SunOS) iQEcBAEBAgAGBQJREanXAAoJEGvefgSNfHMdRSkH/jDVd3wagUKNvjO2mTVo1Jdy MYvKStezZTgVDMw4f5zLJcEM7Cm/74tvbst/DdIgHiMI188z9v1CZ5XgBCft3LSm DninOatvTcB/8CHhJ80q4vRH7EqiAVVWdq+SAPSU0v+e43rxIE1S1z+axOkG4xpt O6vxiXeaD9jZcNJx93nbBVceC6fphmq7Oz/eWdcYMf/BKsADxinxpTpLX/8U9vJH cdBAG4I5PUAgnWbHj/Fk/oeVKjYGLmiejMO9WU+/5NpxILUJP2hHz4Fqz8qR4Ovq eME40QIIfaumyJ1puY5jJ0jTmbxMkPT7irmZ/YlHnLB5s9CfwJEec0tfkCZcBgM= =2FcO -----END PGP SIGNATURE----- From tim.ruehsen at gmx.de Fri Feb 8 10:16:42 2013 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Fri, 8 Feb 2013 10:16:42 +0100 Subject: [gnutls-devel] Casting from int to (void *) In-Reply-To: <511411DA.1040806@gnome.org> References: <51113203.7030300@cyber.ee> <5113ED2B.90606@gnutls.org> <511411DA.1040806@gnome.org> Message-ID: <201302081016.42770.tim.ruehsen@gmx.de> Am Thursday 07 February 2013 schrieb Stef Walter: > On 02/07/2013 07:06 PM, Nikos Mavrogiannopoulos wrote: > > On 02/07/2013 03:10 PM, Jaak Ristioja wrote: > >> The current solution probably works for most x86 setups, but not for > >> all. The compiler warning is completely reasonable, as it points out > >> something which might not work properly on some platforms. > >> I suspect this behavior can't be corrected without breaking the ABI/API. > >> I think stuff with actual (void *) pointers still works if the > >> respective callbacks are properly set. > > > > Hello, > > > > I by change to the ABI you mean adding a new function, that's not a > > > > high cost. > > > > However, my main concern is whether there is an actual system where the > > current approach causes a problem in order to justify any action (at > > least from my part, if you submit a patch for that, that's another > > story). > > FWIW, Glib has has macros for putting ints into pointers, and taking > them back out: > > GUINT_TO_POINTER > GPOINTER_TO_UINT > GINT_TO_POINTER > GPOINTER_TO_INT > > I mention this because I believe the general consensus is that there is > no relevant platform for which you can't store 32-bits of integer in a > pointer. IMHO, the glib is still pretty Gnome centric. That would mean "relevant platform" = "Desktop platform", well a bit simplified. BTW, the mentioned macros are just simple chains of casts that are made to silence the compiler. You can do that 'void *p = (void *)(ssize_t)i' and back with int i = (int)(ssize_t)p; But this is not elegant and looks like a hack, if you use macros or not (well, it IS a hack). There might be some (obscure, embedded ?) platforms where this doesn't work. E.g. having 16-bit pointers and/or platforms with non-flat memory models where NULL is not 0. Or function pointers having a different size than memory/void pointers. Are these platforms relevant to GnuTLS !? As long as no one comes along having real (not just theoretical) serious problems, the only reason to change anything is of 'code elegance' and to calm down 'security experts' (I read this C article of securecoding.cert.org - it is correct in general, but doesn't fit for the special case of gnutls_transport_set/get_ptr). But then, 'code elegance' might be an important thing (at least to me). And providing a ..._set/get_int() (I personally wouldn't call it _berkeley) wouldn't really hurt, would it. Regards, Tim From thoger at redhat.com Fri Feb 8 10:59:04 2013 From: thoger at redhat.com (Tomas Hoger) Date: Fri, 8 Feb 2013 10:59:04 +0100 Subject: [gnutls-devel] advisory GNUTLS-SA-2013-1 In-Reply-To: <510FEE00.8090502@gnutls.org> References: <510FEE00.8090502@gnutls.org> Message-ID: <20130208105904.02131007@redhat.com> Hi Nikos! On Mon, 04 Feb 2013 18:21:04 +0100 Nikos Mavrogiannopoulos wrote: > I've put online a security advisory on the "lucky 13" CBC ciphersuite > attack in [0]. The advisory can be found at: > http://www.gnutls.org/security.html#GNUTLS-SA-2013-1 > > [0]. http://www.isg.rhul.ac.uk/tls/ It seems a part of the fix did not get backported to 2.12 properly. Both 2.x and 3.x sources include the following comment: * Note that we access all 256 bytes of ciphertext for padding check * because there is a timing channel in that memory access (in certain CPUs). However, what is described did not get implemented in 2.x, see: https://gitorious.org/gnutls/gnutls/blobs/gnutls_2_12_x/lib/gnutls_cipher.c#line564 vs. https://gitorious.org/gnutls/gnutls/blobs/master/lib/gnutls_cipher.c#line740 It's unclear to me if this mitigation was omitted from 2.x backport intentionally, given that the code comment suggests it should be there and hence was likely left out by mistake. Can you clarify? Thank you! -- Tomas Hoger / Red Hat From jaak.ristioja at cyber.ee Fri Feb 8 14:42:16 2013 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Fri, 08 Feb 2013 15:42:16 +0200 Subject: [gnutls-devel] Waiting for input data In-Reply-To: References: <51112C66.30003@cyber.ee> Message-ID: <511500B8.2070204@cyber.ee> Hi! On 05.02.2013 18:49, Jouko Orava wrote: > On Tue, 5 Feb 2013, Jaak Ristioja wrote: >> I want my thread to sleep (most of the time) until either (1) data >> becomes available or (2) another thread signals the thread to stop >> waiting for any data. > > Have you simply set the socket descriptor to nonblocking? > fcntl(sd, F_SETFL, O_NONBLOCK); Yes. > At a quick look, GnuTLS should return GNUTLS_E_AGAIN if there is no data > pending on a nonblocking socket [so underlying recv() returns EAGAIN]. > > You can use select()/epoll()/etc. on the socket > descriptor (sd) to check if there might be data available > (gnutls_record_recv() may still return GNUTLS_E_AGAIN). > Another option is to keep the socket blocking, but use an empty-body > signal handler to interrupt the gnutls_record_recv(), i.e. via > pthread_kill(thread, signum); > or > pthread_sigqueue(thread, signum, value); > > The delivery of the signal to the target thread will interrupt blocking > I/O calls; the body of the signal handler can be empty. > > Note, however, that gnutls_record_recv() may return with data even if the > signal was fired, if sufficient data arrives in a big enough clump. > That means you must not rely on always noticing the signal (by receiving > an error from gnutls_record_recv()); you must have a secondary flag > (semaphore, or atomic flag) to indicate that there is extra processing > needed to be done. Hmm... no thanks. Messing with signals is complicated at least. I think the main issue is that GnuTLS does not provide functions alike poll/select. I can't poll for data available without reading it. I think gnutls_record_check_pending should try to receive data from the underlying transport! FYI, the following does not work: while (!needToStop() && gnutls_record_check_pending(session) <= 0) sleepMs(5); But it would greatly simplify using GnuTLS if it did do so. I haven't tried to call gnutls_record_recv(session, NULL, 0u)... would calling it before each gnutls_record_check_pending call make the example above work? I don't see anything about this mentioned in the documentation. Best regards, Jaak From tim.ruehsen at gmx.de Fri Feb 8 14:54:24 2013 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Fri, 8 Feb 2013 14:54:24 +0100 Subject: [gnutls-devel] Waiting for input data In-Reply-To: <511500B8.2070204@cyber.ee> References: <51112C66.30003@cyber.ee> <511500B8.2070204@cyber.ee> Message-ID: <201302081454.24612.tim.ruehsen@gmx.de> Maybe this code snippet/example from libmget (License LGPL3+) may help you: It assumes a non-blocking socket descriptor set by gnutls_transport_set_ptr(session, (void *)(ssize_t)sockfd); ssize_t mget_ssl_read_timeout(void *session, char *buf, size_t count, int timeout) { ssize_t nbytes; int rc; for (;;) { if (gnutls_record_check_pending(session) <= 0 && (rc=_ready_2_read(session, timeout)) <= 0) return rc; nbytes=gnutls_record_recv(session, buf, count); if (nbytes >= 0 || nbytes != GNUTLS_E_AGAIN) break; } return nbytes < -1 ? -1 : nbytes; } static int _ready_2_read(gnutls_session_t session, int timeout) { return _ready_2_transfer(session, timeout, POLLIN); } static int _ready_2_transfer(gnutls_session_t session, int timeout, int mode) { // 0: no timeout / immediate // -1: INFINITE timeout if (timeout) { int sockfd = (int)(ssize_t)gnutls_transport_get_ptr(session); int rc; // wait for socket to be ready to read struct pollfd pollfd[1] = { { sockfd, mode, 0}}; if ((rc = poll(pollfd, 1, timeout)) <= 0) return rc < 0 ? -1 : 0; if (!(pollfd[0].revents & mode)) return -1; } return 1; } Regards, Tim From jaak.ristioja at cyber.ee Fri Feb 8 15:08:48 2013 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Fri, 08 Feb 2013 16:08:48 +0200 Subject: [gnutls-devel] Waiting for input data In-Reply-To: <201302081454.24612.tim.ruehsen@gmx.de> References: <51112C66.30003@cyber.ee> <511500B8.2070204@cyber.ee> <201302081454.24612.tim.ruehsen@gmx.de> Message-ID: <511506F0.7090604@cyber.ee> On 08.02.2013 15:54, Tim Ruehsen wrote: > Maybe this code snippet/example from libmget (License LGPL3+) may help you: > It assumes a non-blocking socket descriptor set by > gnutls_transport_set_ptr(session, (void *)(ssize_t)sockfd); Well I have used (void *)(intptr_t) sockfd, but it doesn't solve the real issue here, it just silences the compiler. When converted back using (int)(intptr_t), it might not compare equal to the original. Best regards, Jaak From tim.ruehsen at gmx.de Fri Feb 8 15:25:13 2013 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Fri, 8 Feb 2013 15:25:13 +0100 Subject: [gnutls-devel] Waiting for input data In-Reply-To: <511506F0.7090604@cyber.ee> References: <51112C66.30003@cyber.ee> <201302081454.24612.tim.ruehsen@gmx.de> <511506F0.7090604@cyber.ee> Message-ID: <201302081525.14067.tim.ruehsen@gmx.de> Am Friday 08 February 2013 schrieb Jaak Ristioja: > On 08.02.2013 15:54, Tim Ruehsen wrote: > > Maybe this code snippet/example from libmget (License LGPL3+) may help > > you: It assumes a non-blocking socket descriptor set by > > > > gnutls_transport_set_ptr(session, (void *)(ssize_t)sockfd); > > Well I have used (void *)(intptr_t) sockfd, but it doesn't solve the > real issue here, it just silences the compiler. When converted back > using (int)(intptr_t), it might not compare equal to the original. That was not the point of my mail, but it is interesting. If I got you right, your question was: how can I read from a non-blocking socket (using gnutls_record_check_pending()). My answer just said, how I do it. It might be of help, but maybe not. If casting from int to void * and back doesn't work on your machine, I would be interested in the output of #include void main(void) { int x=1; void *p=(void *)(ssize_t)x; x=(int)(ssize_t)p; printf("%p %d\n",p,x); return 0; } Regards, Tim From jaak.ristioja at cyber.ee Fri Feb 8 15:37:42 2013 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Fri, 08 Feb 2013 16:37:42 +0200 Subject: [gnutls-devel] Waiting for input data In-Reply-To: <201302081525.14067.tim.ruehsen@gmx.de> References: <51112C66.30003@cyber.ee> <201302081454.24612.tim.ruehsen@gmx.de> <511506F0.7090604@cyber.ee> <201302081525.14067.tim.ruehsen@gmx.de> Message-ID: <51150DB6.5080201@cyber.ee> On 08.02.2013 16:25, Tim Ruehsen wrote: > If I got you right, your question was: how can I read from a non-blocking > socket (using gnutls_record_check_pending()). > > My answer just said, how I do it. > It might be of help, but maybe not. If the transport has data available for reading doesn't automatically mean that I can get any data out of gnutls_record_recv when it reads that data from the transport layer. I need to poll (level-trigerred) GnuTLS directly to detect whether I can read data using gnutls_record_recv. It were better if GnuTLS would be a complete layer between the transport layer and the application layer so that the application layer wouldn't have to poll the transport layer directly, but could poll GnuTLS for available data directly. Best regards, Jaak From tim.ruehsen at gmx.de Fri Feb 8 15:38:37 2013 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Fri, 8 Feb 2013 15:38:37 +0100 Subject: [gnutls-devel] Waiting for input data In-Reply-To: <511506F0.7090604@cyber.ee> References: <51112C66.30003@cyber.ee> <201302081454.24612.tim.ruehsen@gmx.de> <511506F0.7090604@cyber.ee> Message-ID: <201302081538.37102.tim.ruehsen@gmx.de> Am Friday 08 February 2013 schrieb Jaak Ristioja: > On 08.02.2013 15:54, Tim Ruehsen wrote: > > Maybe this code snippet/example from libmget (License LGPL3+) may help > > you: It assumes a non-blocking socket descriptor set by > > > > gnutls_transport_set_ptr(session, (void *)(ssize_t)sockfd); > > Well I have used (void *)(intptr_t) sockfd, but it doesn't solve the > real issue here, it just silences the compiler. When converted back > using (int)(intptr_t), it might not compare equal to the original. Couldn't you use a pointer to your 'socket'. gnutls_transport_set_ptr(session, &sockfd); and reading back with int sockfd = *(int *)gnutls_transport_get_ptr(session); If your sockfd is of type 'int'. If not, use a different type. Regards, Tim R?hsen From jaak.ristioja at cyber.ee Fri Feb 8 15:40:47 2013 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Fri, 08 Feb 2013 16:40:47 +0200 Subject: [gnutls-devel] Waiting for input data In-Reply-To: <201302081538.37102.tim.ruehsen@gmx.de> References: <51112C66.30003@cyber.ee> <201302081454.24612.tim.ruehsen@gmx.de> <511506F0.7090604@cyber.ee> <201302081538.37102.tim.ruehsen@gmx.de> Message-ID: <51150E6F.9090101@cyber.ee> On 08.02.2013 16:38, Tim Ruehsen wrote: > Am Friday 08 February 2013 schrieb Jaak Ristioja: >> On 08.02.2013 15:54, Tim Ruehsen wrote: >>> Maybe this code snippet/example from libmget (License LGPL3+) may help >>> you: It assumes a non-blocking socket descriptor set by >>> >>> gnutls_transport_set_ptr(session, (void *)(ssize_t)sockfd); >> >> Well I have used (void *)(intptr_t) sockfd, but it doesn't solve the >> real issue here, it just silences the compiler. When converted back >> using (int)(intptr_t), it might not compare equal to the original. > > Couldn't you use a pointer to your 'socket'. > > gnutls_transport_set_ptr(session, &sockfd); > > and reading back with > int sockfd = *(int *)gnutls_transport_get_ptr(session); > > If your sockfd is of type 'int'. If not, use a different type. No I can't. The variable sockfd might go out of scope or get destroyed otherwise, effectively invalidating the pointer. Jaak From tim.ruehsen at gmx.de Fri Feb 8 16:15:19 2013 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Fri, 8 Feb 2013 16:15:19 +0100 Subject: [gnutls-devel] Waiting for input data In-Reply-To: <51150E6F.9090101@cyber.ee> References: <51112C66.30003@cyber.ee> <201302081538.37102.tim.ruehsen@gmx.de> <51150E6F.9090101@cyber.ee> Message-ID: <201302081615.19443.tim.ruehsen@gmx.de> Am Friday 08 February 2013 schrieb Jaak Ristioja: > On 08.02.2013 16:38, Tim Ruehsen wrote: > > Am Friday 08 February 2013 schrieb Jaak Ristioja: > >> On 08.02.2013 15:54, Tim Ruehsen wrote: > >>> Maybe this code snippet/example from libmget (License LGPL3+) may help > >>> you: It assumes a non-blocking socket descriptor set by > >>> > >>> gnutls_transport_set_ptr(session, (void *)(ssize_t)sockfd); > >> > >> Well I have used (void *)(intptr_t) sockfd, but it doesn't solve the > >> real issue here, it just silences the compiler. When converted back > >> using (int)(intptr_t), it might not compare equal to the original. > > > > Couldn't you use a pointer to your 'socket'. > > > > gnutls_transport_set_ptr(session, &sockfd); > > > > and reading back with > > > > int sockfd = *(int *)gnutls_transport_get_ptr(session); > > > > If your sockfd is of type 'int'. If not, use a different type. > > No I can't. The variable sockfd might go out of scope or get destroyed > otherwise, effectively invalidating the pointer. If you don't use threads, just use a static variable to store your sockfd. With threads, you just malloc a store for sockfd sockfd_ptr = malloc(sizeof(sockfd)); *sockfd_ptr = sockfd; gnutls_transport_set_ptr(session, sockfd_ptr); when closing the session, you have to free it: free(gnutls_transport_get_ptr(session)); Mit freundlichem Gru? Tim R?hsen From nmav at gnutls.org Fri Feb 8 18:46:30 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 08 Feb 2013 18:46:30 +0100 Subject: [gnutls-devel] advisory GNUTLS-SA-2013-1 In-Reply-To: <20130208105904.02131007@redhat.com> References: <510FEE00.8090502@gnutls.org> <20130208105904.02131007@redhat.com> Message-ID: <511539F6.2010209@gnutls.org> On 02/08/2013 10:59 AM, Tomas Hoger wrote: > It seems a part of the fix did not get backported to 2.12 properly. > Both 2.x and 3.x sources include the following comment: > > * Note that we access all 256 bytes of ciphertext for padding check > * because there is a timing channel in that memory access (in certain CPUs). [...] > https://gitorious.org/gnutls/gnutls/blobs/master/lib/gnutls_cipher.c#line740 > It's unclear to me if this mitigation was omitted from 2.x backport > intentionally, given that the code comment suggests it should be there > and hence was likely left out by mistake. Can you clarify? Hello Tomas, Indeed I left it out intentionally to reduce the code that was changed. In my measurements that change affected on a very low scale the overall timings. The comment above may exaggerate a bit, because initially I had attributed to this code some other (unrelated) delay I encountered. So to summarize, in master branch a more careful (with respect to timing attacks) re-organization took place, and the other branches took just enough code to avoid the attack in the paper. regards, Nikos From emile at vanbergen.name Fri Feb 8 12:34:42 2013 From: emile at vanbergen.name (Emile van Bergen) Date: Fri, 08 Feb 2013 12:34:42 +0100 Subject: [gnutls-devel] Casting from int to (void *) In-Reply-To: <201302081016.42770.tim.ruehsen@gmx.de> References: <51113203.7030300@cyber.ee> <5113ED2B.90606@gnutls.org> <511411DA.1040806@gnome.org> <201302081016.42770.tim.ruehsen@gmx.de> Message-ID: Hi, Am I correct in that you effectively need the reverse of an intptr_t (C99, an integer with sufficient size to hold a pointer), namely a pointer having a width that is guaranteed to be sufficient to hold an ordinary integer? In that case the assumption that sizeof(int) <= sizeof(void *) is probably safe on all platforms that GnuTLS runs on. For sizeof(long) this may not be the case. Aside, to avoid direct casting between pointers and integers, an option may be to write void *p = (char *)0 + i, exploiting the fact that sizeof(char) == 1 by ISO definition. The only cast is the null pointer; otherwise there is only the implicit cast from char * to void *. You go the other way around by writing i = (char *)p - (char *)0; Note however that for this construct too, the compiler is not likely to warn you on platforms where sizeof(int) > sizeof(void *). Kind regards, Emile. From jouko.orava at helsinki.fi Fri Feb 8 20:38:54 2013 From: jouko.orava at helsinki.fi (Jouko Orava) Date: Fri, 8 Feb 2013 21:38:54 +0200 (EET) Subject: [gnutls-devel] Waiting for input data In-Reply-To: <511506F0.7090604@cyber.ee> References: <51112C66.30003@cyber.ee> <511500B8.2070204@cyber.ee> <201302081454.24612.tim.ruehsen@gmx.de> <511506F0.7090604@cyber.ee> Message-ID: On Fri, 8 Feb 2013, Jaak Ristioja wrote: > Well I have used (void *)(intptr_t) sockfd, but it doesn't solve the > real issue here, it just silences the compiler. When converted back > using (int)(intptr_t), it might not compare equal to the original. There are no architectures that support C99 where that happens. Furthermore, you can always do this: gnutls_transport_ptr_t sockptr = (void *)(intptr_t)sockfd; if ((int)(intptr_t)(void *)sockptr != sockfd) { /* UNSUPPORTED ARCHITECTURE ERROR, ABORT! */ } gnutls_transport_set_ptr(session, sockptr); or, if you use separate send/receive descriptors, gnutls_transport_ptr_t recvptr = (void *)(intptr_t)recvfd; gnutls_transport_ptr_t sendptr = (void *)(intptr_t)sendfd; if ((int)(intptr_t)(void *)recvptr != recvfd || (int)(intptr_t)(void *)sendptr != sendfd) { /* UNSUPPORTED ARCHITECTURE ERROR, ABORT! */ } gnutls_transport_set_ptr2(session, recvptr, sendptr); The idea here is that you can always *verify* the conversions retain the required value, and catch the case you fear might someday happen. There are a few reasons why the error will never happen, even if you replace 'intptr_t' with 'long' (which is what most C code with similar operations do). One is that the Linux kernel, which runs on basically every imaginable architecture you might wish to compile GnuTLS for, makes that assumption internally very extensively. The most practical reason is that valid descriptors are always small positive integers. Even if theoretically they do not have to be, the C function interfaces (select et al.) make it a practical necessity. The hardest to prove, but still true, is that there are no architectures even theoretically capable of compiling GnuTLS, where sizeof (int) > sizeof (void *) or sizeof (void *) > sizeof (long) They all have either sizeof (int) == sizeof (void *) or sizeof (long) == sizeof (void *) and have no "padding bits" (as the C standard calls them) in int or long. For example, you can compile to a 8-bit AVR microcontroller, but still have sizeof (int) == sizeof (void *) == sizeof (long) == 2, or even ... == 4, depending on compiler options. The C compiler will simply generate the necessary "emulation" or extra code, even when native integer types are smaller. Regards, Jouko Orava From flameeyes at flameeyes.eu Sat Feb 9 13:20:15 2013 From: flameeyes at flameeyes.eu (=?UTF-8?B?RGllZ28gRWxpbyBQZXR0ZW7Dsg==?=) Date: Sat, 09 Feb 2013 13:20:15 +0100 Subject: [gnutls-devel] GnuTLS 3.1.7 can't connect to Google Talk Message-ID: <51163EFF.204@flameeyes.eu> This I reported in Gentoo's bugzilla last night: https://bugs.gentoo.org/show_bug.cgi?id=456250 and somebody later reported that the problem affects specifically version 3.1.7. flame at saladin ~ % gnutls-cli -p 5223 talk.google.com Processed 160 CA certificate(s). Resolving 'talk.google.com'... Connecting to '173.194.65.125:5223'... - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject `C=US,ST=California,L=Mountain View,O=Google Inc,CN=talk.google.com', issuer `C=US,O=Google Inc,CN=Google Internet Authority', RSA key 1024 bits, signed using RSA-SHA1, activated `2012-06-05 00:53:35 UTC', expires `2013-06-05 01:03:35 UTC', SHA-1 fingerprint `7833da4b3a1642e680d7f8e58fd99ed31493b790' Public Key Id: 92b4709209e60147dc572dc02c85c45cdc456ade Public key's random art: +--[ RSA 1024]----+ |.+*=.B++.+o | | +.o*o= o.. | | . =oo o. | | = = . | | + S E | | . | | | | | | | +-----------------+ - Certificate[1] info: - subject `C=US,O=Google Inc,CN=Google Internet Authority', issuer `C=US,O=Equifax,OU=Equifax Secure Certificate Authority', RSA key 1024 bits, signed using RSA-SHA1, activated `2009-06-08 20:43:27 UTC', expires `2013-06-07 19:43:27 UTC', SHA-1 fingerprint `dd7a7f131ddba33d3e8670179483e6fea6987d6a' - Status: The certificate is trusted. *** Fatal error: The Diffie-Hellman prime sent by the server is not acceptable (not long enough). *** Handshake has failed GnuTLS error: The Diffie-Hellman prime sent by the server is not acceptable (not long enough). Not sure what the problem is exactly, but so it happens that Telepathy users with 3.1.7 can't connect to Google Talk at all. Hope somebody has an idea :) -- Diego Elio Petten? ? Flameeyes flameeyes at flameeyes.eu ? http://blog.flameeyes.eu/ From flameeyes at flameeyes.eu Sat Feb 9 13:20:15 2013 From: flameeyes at flameeyes.eu (=?UTF-8?B?RGllZ28gRWxpbyBQZXR0ZW7Dsg==?=) Date: Sat, 09 Feb 2013 13:20:15 +0100 Subject: [gnutls-devel] GnuTLS 3.1.7 can't connect to Google Talk Message-ID: <51163EFF.204@flameeyes.eu> This I reported in Gentoo's bugzilla last night: https://bugs.gentoo.org/show_bug.cgi?id=456250 and somebody later reported that the problem affects specifically version 3.1.7. flame at saladin ~ % gnutls-cli -p 5223 talk.google.com Processed 160 CA certificate(s). Resolving 'talk.google.com'... Connecting to '173.194.65.125:5223'... - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject `C=US,ST=California,L=Mountain View,O=Google Inc,CN=talk.google.com', issuer `C=US,O=Google Inc,CN=Google Internet Authority', RSA key 1024 bits, signed using RSA-SHA1, activated `2012-06-05 00:53:35 UTC', expires `2013-06-05 01:03:35 UTC', SHA-1 fingerprint `7833da4b3a1642e680d7f8e58fd99ed31493b790' Public Key Id: 92b4709209e60147dc572dc02c85c45cdc456ade Public key's random art: +--[ RSA 1024]----+ |.+*=.B++.+o | | +.o*o= o.. | | . =oo o. | | = = . | | + S E | | . | | | | | | | +-----------------+ - Certificate[1] info: - subject `C=US,O=Google Inc,CN=Google Internet Authority', issuer `C=US,O=Equifax,OU=Equifax Secure Certificate Authority', RSA key 1024 bits, signed using RSA-SHA1, activated `2009-06-08 20:43:27 UTC', expires `2013-06-07 19:43:27 UTC', SHA-1 fingerprint `dd7a7f131ddba33d3e8670179483e6fea6987d6a' - Status: The certificate is trusted. *** Fatal error: The Diffie-Hellman prime sent by the server is not acceptable (not long enough). *** Handshake has failed GnuTLS error: The Diffie-Hellman prime sent by the server is not acceptable (not long enough). Not sure what the problem is exactly, but so it happens that Telepathy users with 3.1.7 can't connect to Google Talk at all. Hope somebody has an idea :) -- Diego Elio Petten? ? Flameeyes flameeyes at flameeyes.eu ? http://blog.flameeyes.eu/ From nmav at gnutls.org Sat Feb 9 18:48:45 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 09 Feb 2013 18:48:45 +0100 Subject: [gnutls-devel] GnuTLS 3.1.7 can't connect to Google Talk In-Reply-To: <51163EFF.204@flameeyes.eu> References: <51163EFF.204@flameeyes.eu> Message-ID: <51168BFD.6060702@gnutls.org> On 02/09/2013 01:20 PM, Diego Elio Petten? wrote: > This I reported in Gentoo's bugzilla last night: > https://bugs.gentoo.org/show_bug.cgi?id=456250 and somebody later > reported that the problem affects specifically version 3.1.7. > > flame at saladin ~ % gnutls-cli -p 5223 talk.google.com > Processed 160 CA certificate(s). > Resolving 'talk.google.com'... > Connecting to '173.194.65.125:5223'... [...] > *** Fatal error: The Diffie-Hellman prime sent by the server is not > acceptable (not long enough). Ouch. The security level chosen (i.e. NORMAL in that case), enforces limits in the DH prime as well starting from 3.1.7. I added a debugging message which now mentions for that site: * Received a prime of 768 bits, limit is 816 So the DHE prime used is pretty low. A quick workaround is to use the PERFORMANCE security level (if the application allows you to switch). The work-around will not reduce the acceptable security level, but it would prefer the RSA ciphersuites and their level depends only on the RSA key in the certificate (which is of acceptable size). regards, Nikos From nmav at gnutls.org Sat Feb 9 18:48:45 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 09 Feb 2013 18:48:45 +0100 Subject: [gnutls-devel] GnuTLS 3.1.7 can't connect to Google Talk In-Reply-To: <51163EFF.204@flameeyes.eu> References: <51163EFF.204@flameeyes.eu> Message-ID: <51168BFD.6060702@gnutls.org> On 02/09/2013 01:20 PM, Diego Elio Petten? wrote: > This I reported in Gentoo's bugzilla last night: > https://bugs.gentoo.org/show_bug.cgi?id=456250 and somebody later > reported that the problem affects specifically version 3.1.7. > > flame at saladin ~ % gnutls-cli -p 5223 talk.google.com > Processed 160 CA certificate(s). > Resolving 'talk.google.com'... > Connecting to '173.194.65.125:5223'... [...] > *** Fatal error: The Diffie-Hellman prime sent by the server is not > acceptable (not long enough). Ouch. The security level chosen (i.e. NORMAL in that case), enforces limits in the DH prime as well starting from 3.1.7. I added a debugging message which now mentions for that site: * Received a prime of 768 bits, limit is 816 So the DHE prime used is pretty low. A quick workaround is to use the PERFORMANCE security level (if the application allows you to switch). The work-around will not reduce the acceptable security level, but it would prefer the RSA ciphersuites and their level depends only on the RSA key in the certificate (which is of acceptable size). regards, Nikos From flameeyes at flameeyes.eu Sat Feb 9 20:37:53 2013 From: flameeyes at flameeyes.eu (=?UTF-8?B?RGllZ28gRWxpbyBQZXR0ZW7Dsg==?=) Date: Sat, 09 Feb 2013 20:37:53 +0100 Subject: [gnutls-devel] GnuTLS 3.1.7 can't connect to Google Talk In-Reply-To: <51168BFD.6060702@gnutls.org> References: <51163EFF.204@flameeyes.eu> <51168BFD.6060702@gnutls.org> Message-ID: <5116A591.5010700@flameeyes.eu> On 09/02/2013 18:48, Nikos Mavrogiannopoulos wrote: > So the DHE prime used is pretty low. A quick workaround is to use the > PERFORMANCE security level (if the application allows you to switch). In all honestly, my workaround was to change telepathy-gabble to use OpenSSL that works. Do note that telepathy-gabble (which is used by KDE4's preferred Jabber implementation) defaults to GnuTLS first, and Pidgin also supports GnuTLS... I don't know about other Jabber clients TBH, but for sure it's a bother if the defaults in GnuTLS make them break. (I haven't checked what binary distributions use for these two, Gentoo allows you to switch on Pidgin, and I've asked the same to happen for gabble). -- Diego Elio Petten? ? Flameeyes flameeyes at flameeyes.eu ? http://blog.flameeyes.eu/ From flameeyes at flameeyes.eu Sat Feb 9 20:37:53 2013 From: flameeyes at flameeyes.eu (=?UTF-8?B?RGllZ28gRWxpbyBQZXR0ZW7Dsg==?=) Date: Sat, 09 Feb 2013 20:37:53 +0100 Subject: [gnutls-devel] GnuTLS 3.1.7 can't connect to Google Talk In-Reply-To: <51168BFD.6060702@gnutls.org> References: <51163EFF.204@flameeyes.eu> <51168BFD.6060702@gnutls.org> Message-ID: <5116A591.5010700@flameeyes.eu> On 09/02/2013 18:48, Nikos Mavrogiannopoulos wrote: > So the DHE prime used is pretty low. A quick workaround is to use the > PERFORMANCE security level (if the application allows you to switch). In all honestly, my workaround was to change telepathy-gabble to use OpenSSL that works. Do note that telepathy-gabble (which is used by KDE4's preferred Jabber implementation) defaults to GnuTLS first, and Pidgin also supports GnuTLS... I don't know about other Jabber clients TBH, but for sure it's a bother if the defaults in GnuTLS make them break. (I haven't checked what binary distributions use for these two, Gentoo allows you to switch on Pidgin, and I've asked the same to happen for gabble). -- Diego Elio Petten? ? Flameeyes flameeyes at flameeyes.eu ? http://blog.flameeyes.eu/ From nmav at gnutls.org Sun Feb 10 12:57:43 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 10 Feb 2013 12:57:43 +0100 Subject: [gnutls-devel] gnutls 3.1.8 Message-ID: <51178B37.9040009@gnutls.org> Hello, I've just released gnutls 3.1.8. This is bug fix release on the current stable branch. GnuTLS 3.1.7 inadvertently increased the security level of the priority string NORMAL. This release restores it to the levels of GnuTLS 3.1.6. * Version 3.1.8 (released 2013-02-10) ** libgnutls: Fixed issue in gnutls_x509_privkey_import2() which didn't return GNUTLS_E_DECRYPTION_FAILED in all cases, and affect certtool operation with encrypted keys. Reported by Yan Fiz. ** libgnutls: The minimum DH bits accepted by priorities NORMAL and PERFORMANCE was set to previous defaults 727 bits. Reported by Diego Elio Petteno. ** libgnutls: Corrected issue which prevented gnutls_pubkey_verify_hash() to operate with long keys. Reported by Erik A Jensen. ** 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.8.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.8.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.8.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.8.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From tim.ruehsen at gmx.de Mon Feb 11 08:44:43 2013 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Mon, 11 Feb 2013 08:44:43 +0100 Subject: [gnutls-devel] Waiting for input data In-Reply-To: References: <51112C66.30003@cyber.ee> <511506F0.7090604@cyber.ee> Message-ID: <201302110844.43762.tim.ruehsen@gmx.de> Thanks, Jouko. IMHO, the most valuable post in this thread ! Regards, Tim From INVALID.NOREPLY at gnu.org Wed Feb 13 14:12:35 2013 From: INVALID.NOREPLY at gnu.org (Ochir) Date: Wed, 13 Feb 2013 13:12:35 +0000 Subject: [gnutls-devel] [sr #108246] compilation error for mingw64 on gnutls-3.1.7 In-Reply-To: <20130205-104632.sv0.22503@savannah.gnu.org> References: <20130205-104632.sv0.22503@savannah.gnu.org> Message-ID: <20130213-131235.sv89409.146@savannah.gnu.org> Follow-up Comment #1, sr #108246 (project gnutls): this bug is not actual because 3.1.8 is available, please, close it _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Feb 13 14:14:43 2013 From: INVALID.NOREPLY at gnu.org (Ochir) Date: Wed, 13 Feb 2013 13:14:43 +0000 Subject: [gnutls-devel] [sr #108255] Cannot export _gnutls_send_int: symbol not defined Message-ID: <20130213-131441.sv89409.84300@savannah.gnu.org> URL: Summary: Cannot export _gnutls_send_int: symbol not defined Project: GnuTLS Submitted by: ochir Submitted on: Wed 13 Feb 2013 01:14:41 PM GMT Category: Core library Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: during compilation of gnutls-3.1.8 with mingw-64 we get the following error: .... copying selected object files to avoid basename conflicts... CC xssl.lo CC xssl_getline.lo CCLD libgnutls-xssl.la make[1]: Leaving directory `/var/lib/jenkins/jobs/Gnutls4Win/workspace/build/gnutls-3.1.8/build-32/lib' make: Leaving directory `/var/lib/jenkins/jobs/Gnutls4Win/workspace/build/gnutls-3.1.8/build-32/lib' Cannot export _gnutls_send_int: symbol not defined _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From cloos at jhcloos.com Thu Feb 14 19:02:08 2013 From: cloos at jhcloos.com (James Cloos) Date: Thu, 14 Feb 2013 13:02:08 -0500 Subject: [gnutls-devel] cert verificaion failure with 3.1.8 Message-ID: I just tested gnutls-cli to one of my servers, and where deb's 3.0.22 worked, gentoo's 3.1.8 failed. The cert has the bare domain in CN, and both that and a wildcard in subj alt name. Ie, akin to: CN=example.com SubjAltName:DNSName=example.com SubjAltName:DNSName=example.com SubjAltName:DNSName=*.example.com (Yes, it is doubled, certtool(1) must add the CN the SubjAltName on its own, even when it is explicitly entered at the prompt?) 3.1.8 balked at verifying the cert, looking only at the CN. Or maybe giving up because of the doubled DNS Names? I don't recall this from 3.1.7, but the wildcard cert is new on that box and I may have ugraded to 3.1.8 before adding it. The server in question has only that cert, so sni should be an issue, yes? 3.0.22 prints: - The hostname in the certificate matches 'host.example.com'. whereas 3.1.8 does not, even for a server/cert tuple they both do verify. Otherwise, for tuples which they both verify or fail, the output of the two versions contains the same data. 3.1.8 does work when the wildcard is in the CN, such as with google.com or code.google.com (which, unlike www.google.com, seem to use the same wildcard cert with CN=*.google.com and many dns names in subjaltname, including *.google.com and google.com). For comparison, openssl-1.0.1c's s_client is happy with the wildcard in the subjaltname. Is there a best practices note on a cert for both the bare domain and a wildcard thereunder? Last I tried apache's mod_ssl insisted on the CN matching the virtual's ServerName, although nginx seems happy with the servername only in subjaltname. ??? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From INVALID.NOREPLY at gnu.org Fri Feb 15 10:01:59 2013 From: INVALID.NOREPLY at gnu.org (Ochir) Date: Fri, 15 Feb 2013 09:01:59 +0000 Subject: [gnutls-devel] [sr #108255] Cannot export _gnutls_send_int: symbol not defined In-Reply-To: <20130213-131441.sv89409.84300@savannah.gnu.org> References: <20130213-131441.sv89409.84300@savannah.gnu.org> Message-ID: <20130215-090159.sv89409.42748@savannah.gnu.org> Follow-up Comment #1, sr #108255 (project gnutls): error was found in outdated libgnutls.def, sorry for inconvenience _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From dkg at fifthhorseman.net Sat Feb 16 06:38:04 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 16 Feb 2013 00:38:04 -0500 Subject: [gnutls-devel] memory leak within p11-kit from gnutls_pkcs11_init() Message-ID: <87txpclsxv.fsf@alice.fifthhorseman.net> hi gnutls folks-- There are a couple per-process memory leaks in gnutls's pkcs11 stack. I've just committed a fix for them to the gnutls master branch: diff --git a/lib/pkcs11.c b/lib/pkcs11.c index ecddf99..68f8bd9 100644 --- a/lib/pkcs11.c +++ b/lib/pkcs11.c @@ -625,6 +625,7 @@ gnutls_pkcs11_deinit (void) { if (providers[i].initialized) p11_kit_finalize_module (providers[i].module); + gnutls_free (providers[i].slots); } active_providers = 0; @@ -634,6 +635,8 @@ gnutls_pkcs11_deinit (void) gnutls_pkcs11_set_pin_function (NULL, NULL); gnutls_pkcs11_set_token_function (NULL, NULL); + p11_kit_pin_unregister_callback (P11_KIT_PIN_FALLBACK, p11_kit_pin_file_callback, + NULL); } /** These are not of high importance -- they're per library load, not per-TLS session; and only when PKCS#11 is enabled (and even then one of them only leaks when there are actually PKCS#11 modules configured). But cleaning up minor memory leaks like this should make it easier to hunt down other memory leaks without them being lost in the noise. Nikos, i'm not sure if this commit was verbose enough, or if you want me to commit a comparable fix to the gnutls_3_0_x-2 or gnutls_2_12_x branches. please let me know if you'd like me to do so, or if you have any other concerns about the commit. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 965 bytes Desc: not available URL: From n.mavrogiannopoulos at gmail.com Sat Feb 16 10:12:49 2013 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Sat, 16 Feb 2013 10:12:49 +0100 Subject: [gnutls-devel] memory leak within p11-kit from gnutls_pkcs11_init() In-Reply-To: <87txpclsxv.fsf@alice.fifthhorseman.net> References: <87txpclsxv.fsf@alice.fifthhorseman.net> Message-ID: <511F4D91.10105@gmail.com> On 02/16/2013 06:38 AM, Daniel Kahn Gillmor wrote: > Nikos, i'm not sure if this commit was verbose enough, or if you want me > to commit a comparable fix to the gnutls_3_0_x-2 or gnutls_2_12_x > branches. please let me know if you'd like me to do so, or if you have > any other concerns about the commit. Thanks the commit looks fine. regards, Nikos From INVALID.NOREPLY at gnu.org Sat Feb 16 12:47:22 2013 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sat, 16 Feb 2013 11:47:22 +0000 Subject: [gnutls-devel] [sr #108255] Cannot export _gnutls_send_int: symbol not defined In-Reply-To: <20130215-090159.sv89409.42748@savannah.gnu.org> References: <20130213-131441.sv89409.84300@savannah.gnu.org> <20130215-090159.sv89409.42748@savannah.gnu.org> Message-ID: <20130216-134722.sv707.61464@savannah.gnu.org> Update of sr #108255 (project gnutls): Open/Closed: Open => Closed _______________________________________________________ Follow-up Comment #2: No problem. Note however, that this bug tracker isn't used very often. You may report bugs at bugs at gnutls.org _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sat Feb 16 12:47:39 2013 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sat, 16 Feb 2013 11:47:39 +0000 Subject: [gnutls-devel] [sr #108246] compilation error for mingw64 on gnutls-3.1.7 In-Reply-To: <20130213-131235.sv89409.146@savannah.gnu.org> References: <20130205-104632.sv0.22503@savannah.gnu.org> <20130213-131235.sv89409.146@savannah.gnu.org> Message-ID: <20130216-134738.sv707.4735@savannah.gnu.org> Update of sr #108246 (project gnutls): Open/Closed: Open => Closed _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sat Feb 16 12:49:13 2013 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sat, 16 Feb 2013 11:49:13 +0000 Subject: [gnutls-devel] [sr #108219] Build with automake-1.13 broken (fix included) In-Reply-To: <20130103-061328.sv90165.25532@savannah.gnu.org> References: <20130103-061328.sv90165.25532@savannah.gnu.org> Message-ID: <20130216-134913.sv707.23404@savannah.gnu.org> Update of sr #108219 (project gnutls): Status: None => Done Assigned to: None => nmav Open/Closed: Open => Closed _______________________________________________________ Follow-up Comment #1: Hello, I don't remember if I replied earlier but this should have been fixed in the latest versions of gnutls. Thank you. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sat Feb 16 12:49:35 2013 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sat, 16 Feb 2013 11:49:35 +0000 Subject: [gnutls-devel] [sr #108206] certtool --generate-request error handling In-Reply-To: <20121215-225926.sv89344.53053@savannah.gnu.org> References: <20121213-064336.sv89344.47694@savannah.gnu.org> <20121215-121537.sv707.63699@savannah.gnu.org> <20121215-225926.sv89344.53053@savannah.gnu.org> Message-ID: <20130216-134935.sv707.20582@savannah.gnu.org> Update of sr #108206 (project gnutls): Open/Closed: Open => Closed _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sat Feb 16 12:49:48 2013 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sat, 16 Feb 2013 11:49:48 +0000 Subject: [gnutls-devel] [sr #108189] gnutls_x509_crt_init(1) returns null in neon In-Reply-To: <20121128-103313.sv89857.55816@savannah.gnu.org> References: <20121127-094008.sv89857.7151@savannah.gnu.org> <20121127-120537.sv707.20025@savannah.gnu.org> <20121127-125118.sv89857.81956@savannah.gnu.org> <20121127-191124.sv707.49479@savannah.gnu.org> <20121127-203432.sv89857.67400@savannah.gnu.org> <20121128-011750.sv707.61689@savannah.gnu.org> <20121128-013047.sv707.62519@savannah.gnu.org> <20121128-103313.sv89857.55816@savannah.gnu.org> Message-ID: <20130216-134948.sv707.43558@savannah.gnu.org> Update of sr #108189 (project gnutls): Open/Closed: Open => Closed _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From tg at tgbit.net Sun Feb 17 17:09:49 2013 From: tg at tgbit.net (Gabor Toth) Date: Sun, 17 Feb 2013 17:09:49 +0100 Subject: [gnutls-devel] DANE validation Message-ID: <87ppzyapma.wl%tg@tgbit.net> Hi, I've taken a brief look at the DANE validation functionality GnuTLS provides. It seems incomplete, even though from the documentation one might assume otherwise. Problematic points I found so far: - it does not do PKIX path validation, not even certificate signatures are verified in the chain. - in case of usage 0 & 2, only the direct issuer is checked instead of the whole chain As described in the RFC[1], PKIX path validation should be performed either using the trust anchor specified in the TLSA record (usage 2), or using the system trust anchors (usage 0 & 1) -tg [1] https://tools.ietf.org/html/rfc6698#section-2.1.1 From nmav at gnutls.org Sun Feb 17 20:32:51 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 17 Feb 2013 20:32:51 +0100 Subject: [gnutls-devel] DANE validation In-Reply-To: <87ppzyapma.wl%tg@tgbit.net> References: <87ppzyapma.wl%tg@tgbit.net> Message-ID: On Sun, Feb 17, 2013 at 5:09 PM, Gabor Toth wrote: > Hi, > > I've taken a brief look at the DANE validation functionality GnuTLS provides. > It seems incomplete, even though from the documentation one might assume > otherwise. Problematic points I found so far: Hello Gabor, What you consider an issue, is intentional. The DANE protocol (which is supposedly DNS-Based Authentication of Named Entities), tries to enforce methods of authentication that are unrelated to DNS. The DANE implementation of gnutls is restricted to the DNS validation aspect only. If one would like to do PKIX validation he can do it, but not through the DANE subsystem. You may see reasoning behind that at: http://nmav.gnutls.org/2012/10/some-thoughts-on-dane-protocol.html > - in case of usage 0 & 2, only the direct issuer is checked instead of the > whole chain That's also intentional. What scenario do you have in mind that is not covered by the current case? > As described in the RFC[1], PKIX path validation should be performed either using the > trust anchor specified in the TLSA record (usage 2), or using the system trust > anchors (usage 0 & 1) In gnutls DANE validation is independent to other certificate validation methods. One can do PKIX validation, DANE (as DNS-based), TOFU (trust on first use) or any combination of them. One could of course strictly follow the DANE RFC validation methods if he needs to. regards, Nikos From home_pw at msn.com Sun Feb 17 21:30:09 2013 From: home_pw at msn.com (Peter Williams) Date: Sun, 17 Feb 2013 20:30:09 +0000 Subject: [gnutls-devel] =?utf-8?q?DANE_validation?= Message-ID: out of interest, if a PKIX Chain validation has occurred signaling invalidity of an leaf issuer and THEN an issuer-only (non-PKIX) check is made on the next protocol run, does GNU-TLS regard the issuer as invalidated? Who controls - the authenticated DNS zone that may continue to confirm the issuer or the evidence collected from a previous chain validation? Sent from Windows Mail From: Nikos Mavrogiannopoulos Sent: ?February? ?17?, ?2013 ?11?:?40? ?AM To: Gabor Toth CC: gnutls-devel Subject: Re: [gnutls-devel] DANE validation On Sun, Feb 17, 2013 at 5:09 PM, Gabor Toth wrote: > Hi, > > I've taken a brief look at the DANE validation functionality GnuTLS provides. > It seems incomplete, even though from the documentation one might assume > otherwise. Problematic points I found so far: Hello Gabor, What you consider an issue, is intentional. The DANE protocol (which is supposedly DNS-Based Authentication of Named Entities), tries to enforce methods of authentication that are unrelated to DNS. The DANE implementation of gnutls is restricted to the DNS validation aspect only. If one would like to do PKIX validation he can do it, but not through the DANE subsystem. You may see reasoning behind that at: http://nmav.gnutls.org/2012/10/some-thoughts-on-dane-protocol.html > - in case of usage 0 & 2, only the direct issuer is checked instead of the > whole chain That's also intentional. What scenario do you have in mind that is not covered by the current case? > As described in the RFC[1], PKIX path validation should be performed either using the > trust anchor specified in the TLSA record (usage 2), or using the system trust > anchors (usage 0 & 1) In gnutls DANE validation is independent to other certificate validation methods. One can do PKIX validation, DANE (as DNS-based), TOFU (trust on first use) or any combination of them. One could of course strictly follow the DANE RFC validation methods if he needs to. regards, Nikos _______________________________________________ Gnutls-devel mailing list Gnutls-devel at lists.gnutls.org http://lists.gnupg.org/mailman/listinfo/gnutls-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From tg at tgbit.net Sun Feb 17 22:20:50 2013 From: tg at tgbit.net (Gabor Toth) Date: Sun, 17 Feb 2013 22:20:50 +0100 Subject: [gnutls-devel] DANE validation In-Reply-To: References: <87ppzyapma.wl%tg@tgbit.net> Message-ID: <87obfiab7x.wl%tg@tgbit.net> >>>>> On Sun, 17 Feb 2013 20:32:51 +0100, Nikos Mavrogiannopoulos said: > On Sun, Feb 17, 2013 at 5:09 PM, Gabor Toth wrote: >> - in case of usage 0 & 2, only the direct issuer is checked instead of the >> whole chain > That's also intentional. What scenario do you have in mind that is not > covered by the current case? The RFC does not limit it to the immediate issuer, for instance a TLSA record could contain a root CA certificate instead of an immediate issuer, which is not checked by the current implementation. >> As described in the RFC[1], PKIX path validation should be performed either using the >> trust anchor specified in the TLSA record (usage 2), or using the system trust >> anchors (usage 0 & 1) > In gnutls DANE validation is independent to other certificate > validation methods. One can do PKIX validation, DANE (as DNS-based), > TOFU (trust on first use) or any combination of them. In this case the documentation should explicitly mention that PKIX path validation is not performed and should be done separately to avoid confusion. > One could of course strictly follow the DANE RFC validation methods if > he needs to. The current API does not make it easy to do that. In case of usage 2, the trust anchor specified in the TLSA record should be used for PKIX path validation. In this case dane_verify_crt() could return the index of the certificate in the chain that matched as trust anchor, so that PKIX path validation could be performed up to that certificate in the chain, possibly using gnutls_x509_crt_verify() with the returned trust anchor as the CA_list argument. -tg From nmav at gnutls.org Mon Feb 18 12:02:01 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 18 Feb 2013 12:02:01 +0100 Subject: [gnutls-devel] DANE validation In-Reply-To: <87obfiab7x.wl%tg@tgbit.net> References: <87ppzyapma.wl%tg@tgbit.net> <87obfiab7x.wl%tg@tgbit.net> Message-ID: On Sun, Feb 17, 2013 at 10:20 PM, Gabor Toth wrote: >> That's also intentional. What scenario do you have in mind that is not >> covered by the current case? > The RFC does not limit it to the immediate issuer, for instance a TLSA record > could contain a root CA certificate instead of an immediate issuer, which is not > checked by the current implementation. Yes but I see the RFC behavior as open to abuse. One needs only to make a path that would finish on the CA in question, which is much easier than getting an actual certificate from that CA for that name. If there is patch that enables the behavior you mention (but only when an additional flag is specified), I'd add it. >> In gnutls DANE validation is independent to other certificate >> validation methods. One can do PKIX validation, DANE (as DNS-based), >> TOFU (trust on first use) or any combination of them. > In this case the documentation should explicitly mention that PKIX path > validation is not performed and should be done separately to avoid confusion. Indeed, that should be fixed. >> One could of course strictly follow the DANE RFC validation methods if >> he needs to. > The current API does not make it easy to do that. In case of usage 2, the trust > anchor specified in the TLSA record should be used for PKIX path validation. In > this case dane_verify_crt() could return the index of the certificate in the > chain that matched as trust anchor, so that PKIX path validation could be > performed up to that certificate in the chain, possibly using > gnutls_x509_crt_verify() with the returned trust anchor as the CA_list argument. Thanks for reporting these. It looks like a limitation I didn't see. I'll try to see what can be done about it. regards, Nikos From jaak.ristioja at cyber.ee Tue Feb 19 10:10:28 2013 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Tue, 19 Feb 2013 11:10:28 +0200 Subject: [gnutls-devel] gnutls_certificate_verify_peers* question Message-ID: <51234184.4010003@cyber.ee> Hello! If I use the gnutls_certificate_verify_peers2() or gnutls_certificate_verify_peers3() functions in the callback set using gnutls_certificate_set_verify_function(), do those functions also verify that the peer has the private key corresponding to the public key in the certificate, or is it done elsewhere outside of the callback? The goal is to setup a connection, where both endpoints authenticate only using their key pairs (i.e. give access iff peer has public key A; ignoring any certification chain) and I'm wondering whether calling a gnutls_certificate_verify_peers* function is needed at all. Best regards, Jaak From nmav at gnutls.org Tue Feb 19 13:05:33 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 19 Feb 2013 13:05:33 +0100 Subject: [gnutls-devel] gnutls_certificate_verify_peers* question In-Reply-To: <51234184.4010003@cyber.ee> References: <51234184.4010003@cyber.ee> Message-ID: On Tue, Feb 19, 2013 at 10:10 AM, Jaak Ristioja wrote: > Hello! > If I use the gnutls_certificate_verify_peers2() or > gnutls_certificate_verify_peers3() functions in the callback set using > gnutls_certificate_set_verify_function(), do those functions also verify > that the peer has the private key corresponding to the public key in the > certificate, or is it done elsewhere outside of the callback? Hello, For simplicity I'll focus on the signing ciphersuites. In that case, during the handshake you receive a message from the peer that contains handshake parameters (it is the random nonces and DH params in server side) that are signed. This message is verified in gnutls_handshake() directly (i.e. you have no say on that). If that succeeds the callback takes control and verifies whether the parameters (i.e. the certificate) used in the previous signature verification are acceptable. > The goal is to setup a connection, where both endpoints authenticate > only using their key pairs (i.e. give access iff peer has public key A; > ignoring any certification chain) and I'm wondering whether calling a > gnutls_certificate_verify_peers* function is needed at all. If you need authentication of the peers and/or verify the name of the peer, then they are needed. If you use fixed public keys, that would be the place to verify that they correspond to the expected ones. regards, Nikos From jaak.ristioja at cyber.ee Tue Feb 19 14:49:54 2013 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Tue, 19 Feb 2013 15:49:54 +0200 Subject: [gnutls-devel] gnutls_certificate_verify_peers* question In-Reply-To: References: <51234184.4010003@cyber.ee> Message-ID: <51238302.7090608@cyber.ee> On 19.02.2013 14:05, Nikos Mavrogiannopoulos wrote: > On Tue, Feb 19, 2013 at 10:10 AM, Jaak Ristioja wrote: >> Hello! >> If I use the gnutls_certificate_verify_peers2() or >> gnutls_certificate_verify_peers3() functions in the callback set using >> gnutls_certificate_set_verify_function(), do those functions also verify >> that the peer has the private key corresponding to the public key in the >> certificate, or is it done elsewhere outside of the callback? > > Hello, > For simplicity I'll focus on the signing ciphersuites. In that case, > during the handshake you receive a message from the peer that contains > handshake parameters (it is the random nonces and DH params in server > side) that are signed. This message is verified in gnutls_handshake() > directly (i.e. you have no say on that). If that succeeds the callback > takes control and verifies whether the parameters (i.e. the > certificate) used in the previous signature verification are > acceptable. Do I understand it correctly, that once the callback (set using gnutls_certificate_set_verify_function) is called during handshake, it has already been verified that the peer holds the private key for the public key in the certificate the peer provides? Thanks, Jaak From home_pw at msn.com Tue Feb 19 14:59:19 2013 From: home_pw at msn.com (Peter Williams) Date: Tue, 19 Feb 2013 13:59:19 +0000 Subject: [gnutls-devel] =?utf-8?q?gnutls=5Fcertificate=5Fverify=5Fpeers*_q?= =?utf-8?q?uestion?= Message-ID: not in security theory. The peers in SSL are mutually suspicions - which means that before the state transition that define ?security? each peer must be assumed to be spoofing by the other. In SSL, the last 2 pairwise messages of the handshake are those that prove that the handshake messages themselves are authentic, and thus the handshake is authentic. Only at that point is the entity authentication service of SSL actually delivered. For example, if client release its last message but fails to receive that from the server, there was proof of nothing - and the suspicion remains. in SSL, there are no states depending on message-evidence that so and so holds a private key. If you go to a math exam and show 30m worth of workings but make a tiny adding error at the last step getting the wrong answer, you still get 0 points on the score. There are no points for correct workings. The bridge fell down. Sent from Windows Mail From: Jaak Ristioja Sent: ?February? ?19?, ?2013 ?5?:?50? ?AM To: Nikos Mavrogiannopoulos CC: gnutls-devel Subject: Re: [gnutls-devel] gnutls_certificate_verify_peers* question On 19.02.2013 14:05, Nikos Mavrogiannopoulos wrote: > On Tue, Feb 19, 2013 at 10:10 AM, Jaak Ristioja wrote: >> Hello! >> If I use the gnutls_certificate_verify_peers2() or >> gnutls_certificate_verify_peers3() functions in the callback set using >> gnutls_certificate_set_verify_function(), do those functions also verify >> that the peer has the private key corresponding to the public key in the >> certificate, or is it done elsewhere outside of the callback? > > Hello, > For simplicity I'll focus on the signing ciphersuites. In that case, > during the handshake you receive a message from the peer that contains > handshake parameters (it is the random nonces and DH params in server > side) that are signed. This message is verified in gnutls_handshake() > directly (i.e. you have no say on that). If that succeeds the callback > takes control and verifies whether the parameters (i.e. the > certificate) used in the previous signature verification are > acceptable. Do I understand it correctly, that once the callback (set using gnutls_certificate_set_verify_function) is called during handshake, it has already been verified that the peer holds the private key for the public key in the certificate the peer provides? Thanks, Jaak _______________________________________________ Gnutls-devel mailing list Gnutls-devel at lists.gnutls.org http://lists.gnupg.org/mailman/listinfo/gnutls-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From juhovh at iki.fi Tue Feb 19 16:07:42 2013 From: juhovh at iki.fi (=?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?=) Date: Tue, 19 Feb 2013 17:07:42 +0200 Subject: [gnutls-devel] gnutls_certificate_verify_peers* question In-Reply-To: References: Message-ID: <3B3CCCD1-7AA3-47F1-884E-BBBD85858B90@iki.fi> I completely agree that the identities in TLS are not verified until both ends have finished verifying each others' verify messages. However, I simply can't resist commenting on this (originally already a bit off-topic) analogy: On 19.2.2013, at 15.59, Peter Williams wrote: > If you go to a math exam and show 30m worth of workings but make a tiny adding error at the last step getting the wrong answer, you still get 0 points on the score. There are no points for correct workings. The bridge fell down. It depends a lot on the case, but I would say in the general math exam case this kind of grading should be at least questioned. 30m of correct workings should show on the answer and therefore it would be reasonable for it to result in some small amount of points. Especially if the counterexample of accidentally correct answer with wrong process had any chance of getting more than 0 points (even if it's because of a mistake by the person doing grading), I would say the exam is pedagogically questionable. In cryptography (and naturally in some other areas as well) getting full points every time is crucial, but in most areas of life not so much. In schools I have gone to, there indeed are points for correct workings, and that has had no notable negative effect on the quality of education. Just bringing this up in case you weren't aware. Juho -------------- next part -------------- An HTML attachment was scrubbed... URL: From home_pw at msn.com Tue Feb 19 17:52:00 2013 From: home_pw at msn.com (Peter Williams) Date: Tue, 19 Feb 2013 16:52:00 +0000 Subject: [gnutls-devel] =?utf-8?q?gnutls=5Fcertificate=5Fverify=5Fpeers*_q?= =?utf-8?q?uestion?= Message-ID: Well lets bring it back mostly on topic, without getting put against the wall and shot. SSL is split between the bearer for such as the handshake protocol, XYZ protocol, the application protocol AND the (SSL framing) bearer. SSL messages then go over an assume reliable transport, or unreliable datagram service (these days, when using the right key management and cipher mode). Assume that an implicit layer 7 signal - indicating verified/validated client cert/chain - gets raised only upon completion of handshake protocol. SInce SSL is extensible, one may insert an XYZ protocol - defined to be completed before the first byte of any message on the application protocol is sent or handled by client. Assume XYZ has authorization semantics, building upon the entity authentication service delivered by the handshake. Assume that the semantics are verified themselves using the verified/validated cert chain event, as raised by the SSL handshake protocol. Given the certs are authentic and authenticated in the context of the running macs of the record-layer - which provides integrity evidence regarding the [correct] sequencing of protocol units on what is a multi-protocol, multi-channel bearer framing layer design intended for hardware pipelining - the security labels attached to one of the keys within the certs may be consulted. Some security label algebra may then be computed - such as the classical no-write-down MAC/MLS policy logic. The labels from the 2 (or more certs) and the labels from the PDUs on the wire go into the (verified correct) algebra calculator that ?decides? - mostly to open the client?s gate that permits it to have a looksee (only now) at the application protocol PDUs. What I didn't get from DANE?s security engineers, and I certainly don't get form the discussion here about the custom profile of DANE, is how the cert/chain validation semantics are supposed to be interacting WITH a correctness arguments concerning SSL various formal security services - as found in higher assurance engineering. Its not just a question of swapping the MIB used for trust anchors from local trusted store to a authenticated DNS zone. Sent from Windows Mail From: Juho V?h?-Herttua Sent: ?February? ?19?, ?2013 ?7?:?07? ?AM To: Peter Williams CC: Jaak Ristioja, gnutls-devel Subject: Re: [gnutls-devel] gnutls_certificate_verify_peers* question I completely agree that the identities in TLS are not verified until both ends have finished verifying each others' verify messages. However, I simply can't resist commenting on this (originally already a bit off-topic) analogy: On 19.2.2013, at 15.59, Peter Williams wrote: If you go to a math exam and show 30m worth of workings but make a tiny adding error at the last step getting the wrong answer, you still get 0 points on the score. There are no points for correct workings. The bridge fell down. It depends a lot on the case, but I would say in the general math exam case this kind of grading should be at least questioned. 30m of correct workings should show on the answer and therefore it would be reasonable for it to result in some small amount of points. Especially if the counterexample of accidentally correct answer with wrong process had any chance of getting more than 0 points (even if it's because of a mistake by the person doing grading), I would say the exam is pedagogically questionable. In cryptography (and naturally in some other areas as well) getting full points every time is crucial, but in most areas of life not so much. In schools I have gone to, there indeed are points for correct workings, and that has had no notable negative effect on the quality of education. Just bringing this up in case you weren't aware. Juho -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaak.ristioja at cyber.ee Wed Feb 20 11:56:07 2013 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Wed, 20 Feb 2013 12:56:07 +0200 Subject: [gnutls-devel] Errors building GnuTLS In-Reply-To: <5106501F.5030601@cyber.ee> References: <5103B3DB.7070602@cyber.ee> <5103D382.6090200@gnutls.org> <5106501F.5030601@cyber.ee> Message-ID: <5124ABC7.4000205@cyber.ee> Hi, On 28.01.2013 12:17, Jaak Ristioja wrote: > make[4]: Entering directory `/home/jotik/develop/gnutls/gnutls.git/src' > CCLD danetool > CCLD certtool > danetool.o: In function `dane_info': > /home/jotik/develop/gnutls/gnutls.git/src/danetool.c:397: undefined > reference to `gnutls_hex_encode' > certtool-common.o: In function `load_secret_key': > /home/jotik/develop/gnutls/gnutls.git/src/certtool-common.c:97: > undefined reference to `gnutls_hex_decode' > collect2: ld returned 1 exit status > make[4]: *** [danetool] Error 1 > make[4]: *** Waiting for unfinished jobs.... > certtool.o: In function `detailed_verification': > /home/jotik/develop/gnutls/gnutls.git/src/certtool.c:1989: undefined > reference to `gnutls_hex_encode' > certtool-common.o: In function `load_secret_key': > /home/jotik/develop/gnutls/gnutls.git/src/certtool-common.c:97: > undefined reference to `gnutls_hex_decode' > collect2: ld returned 1 exit status > make[4]: *** [certtool] Error 1 To work around this GnuTLS compile error, you might instead want to cherry-pick this commit into master: https://gitorious.org/~jotik/gnutls/jotiks-gnutls/commit/d09d07db56eeebbe4a789d70c4e49e679d383b45 Best regards, Jaak From jaak.ristioja at cyber.ee Wed Feb 20 15:42:05 2013 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Wed, 20 Feb 2013 16:42:05 +0200 Subject: [gnutls-devel] Cloning GnuTLS objects Message-ID: <5124E0BD.2010309@cyber.ee> Hello! What is the fastest way clone GnuTLS objects like gnutls_pubkey_t or gnutls_x509_crt_t? Are there no clone or copy functions? Are the _import/_export functions my only option and it's impossible to avoid double copying? Best regards, Jaak From jaak.ristioja at cyber.ee Wed Feb 20 16:40:15 2013 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Wed, 20 Feb 2013 17:40:15 +0200 Subject: [gnutls-devel] Use of uninitialized data in gnutls_pubkey_deinit ? Message-ID: <5124EE5F.50501@cyber.ee> Hi! Please note that in lib/gnutls_pubkey.c in the definition of function gnutls_pubkey_init the "params" field of struct gnutls_pubkey_st is not explicitly initialized, but this field is used in gnutls_pubkey_deinit. Does the call to gnutls_calloc in gnutls_pubkey_init return a pointer to memory already initialized to zeroes? Best regards, Jaak From dkg at fifthhorseman.net Wed Feb 20 16:49:09 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 20 Feb 2013 10:49:09 -0500 Subject: [gnutls-devel] Use of uninitialized data in gnutls_pubkey_deinit ? In-Reply-To: <5124EE5F.50501@cyber.ee> References: <5124EE5F.50501@cyber.ee> Message-ID: <5124F075.50305@fifthhorseman.net> On 02/20/2013 10:40 AM, Jaak Ristioja wrote: > Please note that in lib/gnutls_pubkey.c in the definition of function > gnutls_pubkey_init the "params" field of struct gnutls_pubkey_st is not > explicitly initialized, but this field is used in gnutls_pubkey_deinit. > Does the call to gnutls_calloc in gnutls_pubkey_init return a pointer to > memory already initialized to zeroes? yes, gnutls_calloc is guaranteed to initialize the allocated buffer to 0. By default, gnutls_calloc is just set to libc's calloc(), which initializes the buffer to 0. If the library's user overrides the default memory management with gnutls_global_set_mem_functions(), then gnutls_calloc calls the configured gnutls_malloc function and then manually memset's the contents of buffer to all zeros. You can see this in lib/gnutls_mem.c and lib/gnutls_global.c hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Wed Feb 20 17:24:19 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 20 Feb 2013 17:24:19 +0100 Subject: [gnutls-devel] gnutls_certificate_verify_peers* question In-Reply-To: <51238302.7090608@cyber.ee> References: <51234184.4010003@cyber.ee> <51238302.7090608@cyber.ee> Message-ID: <5124F8B3.3070906@gnutls.org> On 02/19/2013 02:49 PM, Jaak Ristioja wrote: >> Hello, For simplicity I'll focus on the signing ciphersuites. In >> that case, during the handshake you receive a message from the peer >> that contains handshake parameters (it is the random nonces and DH >> params in server side) that are signed. This message is verified in >> gnutls_handshake() directly (i.e. you have no say on that). If that >> succeeds the callback takes control and verifies whether the >> parameters (i.e. the certificate) used in the previous signature >> verification are acceptable. > Do I understand it correctly, that once the callback (set using > gnutls_certificate_set_verify_function) is called during handshake, > it has already been verified that the peer holds the private key for > the public key in the certificate the peer provides? No you don't know that. What you know is that after the handshake is completed successfully a certain proof of the peer holding the private key has been received (e.g., the signature). That is, there are no guarantees on when the function to verify the certificate will be called. regards, Nikos From nmav at gnutls.org Wed Feb 20 17:31:16 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 20 Feb 2013 17:31:16 +0100 Subject: [gnutls-devel] Cloning GnuTLS objects In-Reply-To: <5124E0BD.2010309@cyber.ee> References: <5124E0BD.2010309@cyber.ee> Message-ID: <5124FA54.6030704@gnutls.org> On 02/20/2013 03:42 PM, Jaak Ristioja wrote: > Hello! > > What is the fastest way clone GnuTLS objects like gnutls_pubkey_t or > gnutls_x509_crt_t? Are there no clone or copy functions? Are the > _import/_export functions my only option and it's impossible to avoid > double copying? Unless there is some explicit _cpy function you cannot. regards, Nikos From cloos at jhcloos.com Wed Feb 20 23:10:18 2013 From: cloos at jhcloos.com (James Cloos) Date: Wed, 20 Feb 2013 17:10:18 -0500 Subject: [gnutls-devel] type in certtool(1) Message-ID: I noticed this in certtool(8): --ecc This is an alias for the ecc option. right after the entry for the --ecc option. :) I presume that should be --ecdsa is an alias for --ecc? -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From n.mavrogiannopoulos at gmail.com Thu Feb 21 00:12:02 2013 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Thu, 21 Feb 2013 00:12:02 +0100 Subject: [gnutls-devel] DANE validation Message-ID: If I understood correctly your question, the answer is no because there is no state kept between verifications. Regards, Nikos Peter Williams wrote: >out of interest, if a PKIX Chain validation has occurred signaling invalidity of an leaf issuer and THEN an issuer-only (non-PKIX) check is made on the next protocol run, does GNU-TLS regard the issuer as invalidated? > > > >Who controls - the authenticated DNS zone that may continue to confirm the issuer or the evidence collected from a previous chain validation? > > > > > > > >Sent from Windows Mail > > >From: Nikos Mavrogiannopoulos >Sent: ?February? ?17?, ?2013 ?11?:?40? ?AM >To: Gabor Toth >CC: gnutls-devel >Subject: Re: [gnutls-devel] DANE validation > > > >On Sun, Feb 17, 2013 at 5:09 PM, Gabor Toth wrote: >> Hi, >> >> I've taken a brief look at the DANE validation functionality GnuTLS provides. >> It seems incomplete, even though from the documentation one might assume >> otherwise. Problematic points I found so far: > >Hello Gabor, > What you consider an issue, is intentional. The DANE protocol (which >is supposedly DNS-Based Authentication of Named Entities), tries to >enforce methods of authentication that are unrelated to DNS. The DANE >implementation of gnutls is restricted to the DNS validation aspect >only. If one would like to do PKIX validation he can do it, but not >through the DANE subsystem. > >You may see reasoning behind that at: >http://nmav.gnutls.org/2012/10/some-thoughts-on-dane-protocol.html > >> - in case of usage 0 & 2, only the direct issuer is checked instead of the >> whole chain > >That's also intentional. What scenario do you have in mind that is not >covered by the current case? > >> As described in the RFC[1], PKIX path validation should be performed either using the >> trust anchor specified in the TLSA record (usage 2), or using the system trust >> anchors (usage 0 & 1) > >In gnutls DANE validation is independent to other certificate >validation methods. One can do PKIX validation, DANE (as DNS-based), >TOFU (trust on first use) or any combination of them. > >One could of course strictly follow the DANE RFC validation methods if >he needs to. > >regards, >Nikos > >_______________________________________________ >Gnutls-devel mailing list >Gnutls-devel at lists.gnutls.org >http://lists.gnupg.org/mailman/listinfo/gnutls-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From home_pw at msn.com Thu Feb 21 02:50:30 2013 From: home_pw at msn.com (peter williams) Date: Wed, 20 Feb 2013 17:50:30 -0800 Subject: [gnutls-devel] DANE validation Message-ID: If you go back to the granddaddy specs of rfc 1421/1422, the world was envisioned as a local store of verification keys, including the public variety. A cert chain basically acted to update the ( file ) store , introducing new keys into the mib or marking others. A public key verified by one cert chain could be "marked" by another chain for example. For all if matters, the file can be trusted zone on your windows dns server, if thats the way you swing, signed using a dnsec verification key known only to the public key using apps that leverage this embodiment of the security mib (vs a file in the unix home directory) This was a user centric Concept (consistent with the NIST "privacy enhancing" semantics expected for personal crypto in the late 1970s/1980s). You keep your file, given hints from authorities. Your app was yours however, and not the controlled item that other (nsa, doe) philosophies used limiting your app to being a mere remote-enforcement node in their network, controlled centrally and without your discretion. Im not sure which side of the fence dane sits. I think its the latter, pretending to deliver the culture the former. It seems to undermine it however, by laying all the tracks for reducing appz to remote enforcement of policy set by 10 (dns vectored) authorities regulated formally by icann (which is just a proxy for dept of commerce). Nikos Mavrogiannopoulos wrote: >If I understood correctly your question, the answer is no because there is no state kept between verifications. > >Regards, >Nikos > >Peter Williams wrote: > >out of interest, if a PKIX Chain validation has occurred signaling invalidity of an leaf issuer and THEN an issuer-only (non-PKIX) check is made on the next protocol run, does GNU-TLS regard the issuer as invalidated? > >? > >Who controls - the authenticated DNS zone that may continue to confirm the issuer or the evidence collected from a previous chain validation? > >? > >? > >? > >Sent from Windows Mail > >? > > > > From:?Nikos Mavrogiannopoulos > Sent:??February? ?17?, ?2013 ?11?:?40? ?AM > To:?Gabor Toth > CC:?gnutls-devel > Subject:?Re: [gnutls-devel] DANE validation > > > > >? > >On Sun, Feb 17, 2013 at 5:09 PM, Gabor Toth wrote: >> Hi, >> >> I've taken a brief look at the DANE validation functionality GnuTLS provides. >> It seems incomplete, even though from the documentation one might assume >> otherwise. Problematic points I found so far: > >Hello Gabor, >?What you consider an issue, is intentional. The DANE protocol (which >is supposedly DNS-Based Authentication of Named Entities), tries to >enforce methods of authentication that are unrelated to DNS. The DANE >implementation of gnutls is restricted to the DNS validation aspect >only. If one would like to do PKIX validation he can do it, but not >through the DANE subsystem. > >You may see reasoning behind that at: >http://nmav.gnutls.org/2012/10/some-thoughts-on-dane-protocol.html > >> - in case of usage 0 & 2, only the direct issuer is checked instead of the >>?? whole chain > >That's also intentional. What scenario do you have in mind that is not >covered by the current case? > >> As described in the RFC[1], PKIX path validation should be performed either using the >> trust anchor specified in the TLSA record (usage 2), or using the system trust >> anchors (usage 0 & 1) > >In gnutls DANE validation is independent to other certificate >validation methods. One can do PKIX validation, DANE (as DNS-based), >TOFU (trust on first use) or any combination of them. > >One could of course strictly follow the DANE RFC validation methods if >he needs to. > >regards, >Nikos > >_______________________________________________ >Gnutls-devel mailing list >Gnutls-devel at lists.gnutls.org >http://lists.gnupg.org/mailman/listinfo/gnutls-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaak.ristioja at cyber.ee Thu Feb 21 10:02:38 2013 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Thu, 21 Feb 2013 11:02:38 +0200 Subject: [gnutls-devel] gnutls_certificate_verify_peers* question In-Reply-To: <5124F8B3.3070906@gnutls.org> References: <51234184.4010003@cyber.ee> <51238302.7090608@cyber.ee> <5124F8B3.3070906@gnutls.org> Message-ID: <5125E2AE.9010702@cyber.ee> On 20.02.2013 18:24, Nikos Mavrogiannopoulos wrote: > On 02/19/2013 02:49 PM, Jaak Ristioja wrote: > >>> Hello, For simplicity I'll focus on the signing ciphersuites. In >>> that case, during the handshake you receive a message from the peer >>> that contains handshake parameters (it is the random nonces and DH >>> params in server side) that are signed. This message is verified in >>> gnutls_handshake() directly (i.e. you have no say on that). If that >>> succeeds the callback takes control and verifies whether the >>> parameters (i.e. the certificate) used in the previous signature >>> verification are acceptable. >> Do I understand it correctly, that once the callback (set using >> gnutls_certificate_set_verify_function) is called during handshake, >> it has already been verified that the peer holds the private key for >> the public key in the certificate the peer provides? > > > No you don't know that. What you know is that after the handshake is > completed successfully a certain proof of the peer holding the private > key has been received (e.g., the signature). That is, there are no > guarantees on when the function to verify the certificate will be > called. Thank you, this clarifies it. Best regards, Jaak From jaak.ristioja at cyber.ee Thu Feb 21 10:04:43 2013 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Thu, 21 Feb 2013 11:04:43 +0200 Subject: [gnutls-devel] Cloning GnuTLS objects In-Reply-To: <5124FA54.6030704@gnutls.org> References: <5124E0BD.2010309@cyber.ee> <5124FA54.6030704@gnutls.org> Message-ID: <5125E32B.9090505@cyber.ee> On 20.02.2013 18:31, Nikos Mavrogiannopoulos wrote: > On 02/20/2013 03:42 PM, Jaak Ristioja wrote: >> What is the fastest way clone GnuTLS objects like gnutls_pubkey_t or >> gnutls_x509_crt_t? Are there no clone or copy functions? Are the >> _import/_export functions my only option and it's impossible to avoid >> double copying? > > Unless there is some explicit _cpy function you cannot. Are there any plans to provide such functions in the future? Best regards, Jaak From nmav at gnutls.org Thu Feb 21 16:32:56 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 21 Feb 2013 16:32:56 +0100 Subject: [gnutls-devel] Errors building GnuTLS In-Reply-To: <5124ABC7.4000205@cyber.ee> References: <5103B3DB.7070602@cyber.ee> <5103D382.6090200@gnutls.org> <5106501F.5030601@cyber.ee> <5124ABC7.4000205@cyber.ee> Message-ID: On Wed, Feb 20, 2013 at 11:56 AM, Jaak Ristioja wrote: > Hi, [...] > To work around this GnuTLS compile error, you might instead want to > cherry-pick this commit into master: > https://gitorious.org/~jotik/gnutls/jotiks-gnutls/commit/d09d07db56eeebbe4a789d70c4e49e679d383b45 Thanks, I'll try to check it soon. Note that sending the patches as attachments to the list is preferred (it is easier to comment on them and apply them). regards, Nikos From nmav at gnutls.org Thu Feb 21 16:33:51 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 21 Feb 2013 16:33:51 +0100 Subject: [gnutls-devel] type in certtool(1) In-Reply-To: References: Message-ID: On Wed, Feb 20, 2013 at 11:10 PM, James Cloos wrote: > I noticed this in certtool(8): > --ecc This is an alias for the ecc option. > right after the entry for the --ecc option. :) > I presume that should be --ecdsa is an alias for --ecc? Hello, That's pretty strange since that's automatically generated. Which version of gnutls is that? regards, Nikos From nmav at gnutls.org Thu Feb 21 16:36:32 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 21 Feb 2013 16:36:32 +0100 Subject: [gnutls-devel] Cloning GnuTLS objects In-Reply-To: <5125E32B.9090505@cyber.ee> References: <5124E0BD.2010309@cyber.ee> <5124FA54.6030704@gnutls.org> <5125E32B.9090505@cyber.ee> Message-ID: On Thu, Feb 21, 2013 at 10:04 AM, Jaak Ristioja wrote: >> Unless there is some explicit _cpy function you cannot. > Are there any plans to provide such functions in the future? I don't plan to work on it but I would apply any patches that do that (there are some objects that can't easily be copied though - e.g. the gnutls_privkey_t keys which may be stored in a smart card). However, do you really need to copy them? I remember I considered it some time ago and I realized that copying those objects wasn't that common use case. regards, Nikos From cloos at jhcloos.com Fri Feb 22 08:02:05 2013 From: cloos at jhcloos.com (James Cloos) Date: Fri, 22 Feb 2013 02:02:05 -0500 Subject: [gnutls-devel] type in certtool(1) In-Reply-To: (Nikos Mavrogiannopoulos's message of "Thu, 21 Feb 2013 16:33:51 +0100") References: Message-ID: >>>>> "NM" == Nikos Mavrogiannopoulos writes: NM> Hello, NM> That's pretty strange since that's automatically generated. Which NM> version of gnutls is that? 3.1.8. -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From nmav at gnutls.org Fri Feb 22 20:01:40 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 22 Feb 2013 20:01:40 +0100 Subject: [gnutls-devel] Errors building GnuTLS In-Reply-To: <5124ABC7.4000205@cyber.ee> References: <5103B3DB.7070602@cyber.ee> <5103D382.6090200@gnutls.org> <5106501F.5030601@cyber.ee> <5124ABC7.4000205@cyber.ee> Message-ID: <5127C094.5070201@gnutls.org> On 02/20/2013 11:56 AM, Jaak Ristioja wrote: >> make[4]: *** [danetool] Error 1 >> make[4]: *** Waiting for unfinished jobs.... >> certtool.o: In function `detailed_verification': >> /home/jotik/develop/gnutls/gnutls.git/src/certtool.c:1989: undefined >> reference to `gnutls_hex_encode' >> certtool-common.o: In function `load_secret_key': >> /home/jotik/develop/gnutls/gnutls.git/src/certtool-common.c:97: >> undefined reference to `gnutls_hex_decode' >> collect2: ld returned 1 exit status >> make[4]: *** [certtool] Error 1 > > To work around this GnuTLS compile error, you might instead want to > cherry-pick this commit into master: > > https://gitorious.org/~jotik/gnutls/jotiks-gnutls/commit/d09d07db56eeebbe4a789d70c4e49e679d383b45 Applied, thanks. regards, Nikos From nmav at gnutls.org Sun Feb 24 12:19:26 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 24 Feb 2013 12:19:26 +0100 Subject: [gnutls-devel] DANE validation In-Reply-To: <87obfiab7x.wl%tg@tgbit.net> References: <87ppzyapma.wl%tg@tgbit.net> <87obfiab7x.wl%tg@tgbit.net> Message-ID: <5129F73E.5090201@gnutls.org> On 02/17/2013 10:20 PM, Gabor Toth wrote: >> One could of course strictly follow the DANE RFC validation methods if >> he needs to. > The current API does not make it easy to do that. In case of usage 2, the trust > anchor specified in the TLSA record should be used for PKIX path validation. In > this case dane_verify_crt() could return the index of the certificate in the > chain that matched as trust anchor, so that PKIX path validation could be > performed up to that certificate in the chain, possibly using > gnutls_x509_crt_verify() with the returned trust anchor as the CA_list argument. I've checked it a bit further and I don't think that what you mention above is needed. The DANE check verifies that the given chain satisfies the DANE constraints (either certificate or CA). Then you can use normal PKIX verification in the chain. Unless you need it for optimization purposes, you don't need to know any index to perform the verification. regards, Nikos From dkg at fifthhorseman.net Tue Feb 26 00:03:48 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 25 Feb 2013 15:03:48 -0800 Subject: [gnutls-devel] type in certtool(1) In-Reply-To: References: Message-ID: <512BEDD4.9090601@fifthhorseman.net> On 02/21/2013 11:02 PM, James Cloos wrote: >>>>>> "NM" == Nikos Mavrogiannopoulos writes: > > NM> Hello, > NM> That's pretty strange since that's automatically generated. Which > NM> version of gnutls is that? > > 3.1.8. I can confirm this in /usr/share/man/man1/certtool.1.gz from debian's gnutls-bin 3.1.8-1. i haven't sorted out why it's happening, though. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From cloos at jhcloos.com Tue Feb 26 00:27:29 2013 From: cloos at jhcloos.com (James Cloos) Date: Mon, 25 Feb 2013 18:27:29 -0500 Subject: [gnutls-devel] typo in certtool(1) In-Reply-To: <512BEDD4.9090601@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 25 Feb 2013 15:03:48 -0800") References: <512BEDD4.9090601@fifthhorseman.net> Message-ID: Hmmph. What a stereotype. A (now corrected) typo in my $Subject reporting a typo. ;^/ -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From nmav at gnutls.org Tue Feb 26 09:51:27 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 26 Feb 2013 09:51:27 +0100 Subject: [gnutls-devel] type in certtool(1) In-Reply-To: <512BEDD4.9090601@fifthhorseman.net> References: <512BEDD4.9090601@fifthhorseman.net> Message-ID: On Tue, Feb 26, 2013 at 12:03 AM, Daniel Kahn Gillmor wrote: >> NM> Hello, >> NM> That's pretty strange since that's automatically generated. Which >> NM> version of gnutls is that? >> 3.1.8. > I can confirm this in /usr/share/man/man1/certtool.1.gz from debian's > gnutls-bin 3.1.8-1. i haven't sorted out why it's happening, though. I saw that too, but couldn't figure out the issue. It looks like a bug in the autogen version used. regards, Nikos From ametzler at downhill.at.eu.org Tue Feb 26 19:46:12 2013 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Tue, 26 Feb 2013 19:46:12 +0100 Subject: [gnutls-devel] type in certtool(1) In-Reply-To: References: <512BEDD4.9090601@fifthhorseman.net> Message-ID: <20130226184612.GA3174@downhill.g.la> On 2013-02-26 Nikos Mavrogiannopoulos wrote: > On Tue, Feb 26, 2013 at 12:03 AM, Daniel Kahn Gillmor > wrote: [...] > > I can confirm this in /usr/share/man/man1/certtool.1.gz from debian's > > gnutls-bin 3.1.8-1. i haven't sorted out why it's happening, though. > I saw that too, but couldn't figure out the issue. It looks like a bug > in the autogen version used. Hello, I think you are right. The buggy autogen version is the one the gnutls-tarball was built with, 5.16. If I force a regeneration of the manpage with 5.17.1 by deleting doc/manpages/certtool.1 I get this change (among others): ------------- @@ -245,8 +245,8 @@ Generate ECC (ECDSA) key. .sp When combined with \--generate-privkey generates an elliptic curve private key to be used with ECDSA. .TP -.BR \-\-ecc -This is an alias for the ecc option. +.BR \-\-ecdsa +This is an alias for the \fI--ecc\fR option. .TP .BR \-\-hash "=\fIstring\fP" Hash algorithm to use for signing.. ------------- cu and- wondering whether forcing regeneration of all autogen-ed anpages in the Debian build is a good idea -reas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From nmav at gnutls.org Wed Feb 27 19:27:10 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 27 Feb 2013 19:27:10 +0100 Subject: [gnutls-devel] type in certtool(1) In-Reply-To: <20130226184612.GA3174@downhill.g.la> References: <512BEDD4.9090601@fifthhorseman.net> <20130226184612.GA3174@downhill.g.la> Message-ID: <512E4FFE.9040009@gnutls.org> On 02/26/2013 07:46 PM, Andreas Metzler wrote: > I think you are right. The buggy autogen version is the one the > gnutls-tarball was built with, 5.16. If I force a regeneration of the > manpage with 5.17.1 by deleting doc/manpages/certtool.1 I get this > change (among others): Nice. I'll not upgrade autogen now for that, in order to avoid upgrading libopts. regards, Nikos From nmav at gnutls.org Wed Feb 27 20:10:16 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 27 Feb 2013 20:10:16 +0100 Subject: [gnutls-devel] gnutls 3.1.9 Message-ID: <512E5A18.9040703@gnutls.org> Hello, I've just released gnutls 3.1.9. This is bug fix release on the current stable branch. * Version 3.1.9 (released 2013-02-27) ** certtool: Option --to-p12 will now ask for a password to generate a PKCS #12 file from an encrypted key file. Reported by Yan Fiz. ** libgnutls: Corrected issue in gnutls_pubkey_verify_data(). ** libgnutls: Corrected parsing issue in XMPP within a subject alternative name. Reported by James Cloos. ** libgnutls: gnutls_pkcs11_reinit() will reinitialize all PKCS #11 modules, and not only the ones loaded via p11-kit. ** libgnutls: Added function to check whether the private key is still available (inserted). ** libgnutls: Try to detect fork even during nonce generation. ** API and ABI modifications: gnutls_handshake_set_random: Added gnutls_transport_set_int2: Added gnutls_transport_get_int2: Added gnutls_transport_get_int: Added gnutls_record_cork: Exported gnutls_record_uncork: Exported gnutls_pkcs11_privkey_status: 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.1/gnutls-3.1.9.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.9.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.9.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.9.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 Thu Feb 28 08:34:16 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 28 Feb 2013 08:34:16 +0100 Subject: [gnutls-devel] gnutls 3.1.9 In-Reply-To: <512E5A18.9040703@gnutls.org> References: <512E5A18.9040703@gnutls.org> Message-ID: <512F0878.6000605@gnutls.org> On 02/27/2013 08:10 PM, Nikos Mavrogiannopoulos wrote: > Hello, > I've just released gnutls 3.1.9. This is bug fix release on the current > stable branch. Note that I've replaced this release with 3.1.9.1 few minutes after the announcement. The changes were tiny to warrant a proper release, but also important to wait for the next one (one new function wasn't exported by LD script). The replaced release is at: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/removed/ regards, Nikos From deryni at gmail.com Wed Feb 27 18:14:29 2013 From: deryni at gmail.com (Etan Reisner) Date: Wed, 27 Feb 2013 17:14:29 -0000 Subject: [gnutls-devel] Typo: _CONSTRAINS_ as used in DANE API should be _CONSTRAINTS_ Message-ID: Constrains is a verb and means to limit or hold-back. Constraints is a noun and is a liimtation. As such constrainTs constrain available choices/options and when one violates something the thing which is being violated is a constrainT. -Etan