From INVALID.NOREPLY at gnu.org Wed Jul 2 13:51:58 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Wed, 02 Jul 2014 11:51:58 +0000 Subject: [gnutls-devel] [sr #108550] It is impractical to call dane_verify_session_crt() from the gnutls_certificate_set_verify_function() In-Reply-To: <20140629-191005.sv0.52744@savannah.gnu.org> References: <20140419-152442.sv0.8040@savannah.gnu.org> <20140419-161906.sv0.73978@savannah.gnu.org> <20140428-123927.sv707.14646@savannah.gnu.org> <20140629-191005.sv0.52744@savannah.gnu.org> Message-ID: <20140702-145158.sv707.53124@savannah.gnu.org> Follow-up Comment #4, sr #108550 (project gnutls): You can do the following: dane_state_init() dane_raw_tlsa(): After you do the resolving you place the DANE there dane_verify_crt_raw(): You use the result to verify the certificate _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From mohamed2two at hotmail.fr Fri Jul 4 12:11:59 2014 From: mohamed2two at hotmail.fr (mohamed2two at hotmail.fr) Date: Fri, 4 Jul 2014 12:11:59 +0200 Subject: [gnutls-devel] Gnutls extension handling error Message-ID: Hello, I'm trying to create a new TLS extension with Gnutls, so i've install "gnutls-3.3.4" with all their dependencies, when i make "make check" i've got no error and all is well. After i've followed this tutorial (http://gnutls.org/manual/html_node/TLS-Extension-Handling.html) to make the necessary modifications, but when i execute the new code with "make" commande after done "./configure --enable-myExtension" i got some errors messages, for exemple: .... /gnutls_int.h:726:3: error: unknown type name 'gnutls_buffer_st' .... gnutls_int.h:782:3: error: unknown type name 'gnutls_buffer_st' ..... myExtension.c 15:11 : error: unknown type name 'opaque' const opaque * data, ............ From hammi_mohamed_tahar at hotmail.fr Fri Jul 4 12:40:08 2014 From: hammi_mohamed_tahar at hotmail.fr (hammi_mohamed_tahar at hotmail.fr) Date: Fri, 4 Jul 2014 12:40:08 +0200 Subject: [gnutls-devel] Gnutls handling extension error Message-ID: Hello, I'm trying to create a new TLS extension with Gnutls, so i've install "gnutls-3.3.4" with all their dependencies, when i make "make check" i've got no error and all is well. After i've followed this tutorial (http://gnutls.org/manual/html_node/TLS-Extension-Handling.html) to make the necessary modifications, but when i compile the new code with "make" commande after done "./configure --enable-myExtension" i got some errors messages, for exemple: .... /gnutls_int.h:726:3: error: unknown type name 'gnutls_buffer_st' .... gnutls_int.h:782:3: error: unknown type name 'gnutls_buffer_st' ..... myExtension.c 15:11 : error: unknown type name 'opaque' const opaque * data, ............ if someone can help me to resolve this problem, I will be very grateful. From nmav at gnutls.org Sat Jul 5 12:27:00 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 05 Jul 2014 12:27:00 +0200 Subject: [gnutls-devel] Gnutls handling extension error In-Reply-To: References: Message-ID: <1404556020.4443.1.camel@nomad.lan> On Fri, 2014-07-04 at 12:40 +0200, hammi_mohamed_tahar at hotmail.fr wrote: > Hello, > I'm trying to create a new TLS extension with Gnutls, so i've install > "gnutls-3.3.4" with all their dependencies, when i make "make check" > i've got no error and all is well. After i've followed this tutorial > (http://gnutls.org/manual/html_node/TLS-Extension-Handling.html) to make > the necessary modifications, but when i compile the new code with "make" > commande after done "./configure --enable-myExtension" i got some errors > messages, for exemple: > .... > /gnutls_int.h:726:3: error: unknown type name 'gnutls_buffer_st' > .... > gnutls_int.h:782:3: error: unknown type name 'gnutls_buffer_st' > ..... > myExtension.c 15:11 : error: unknown type name 'opaque' > const opaque * data, How did you try to compile it? These will be defined if you have a normal gnutls built. Check how the other extensions are defined/used, and if there is something missing from the documentation let us know. regards, Nikos From INVALID.NOREPLY at gnu.org Sat Jul 5 23:07:55 2014 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Sat, 05 Jul 2014 21:07:55 +0000 Subject: [gnutls-devel] [sr #108550] It is impractical to call dane_verify_session_crt() from the gnutls_certificate_set_verify_function() In-Reply-To: <20140702-145158.sv707.53124@savannah.gnu.org> References: <20140419-152442.sv0.8040@savannah.gnu.org> <20140419-161906.sv0.73978@savannah.gnu.org> <20140428-123927.sv707.14646@savannah.gnu.org> <20140629-191005.sv0.52744@savannah.gnu.org> <20140702-145158.sv707.53124@savannah.gnu.org> Message-ID: <20140705-210755.sv0.73310@savannah.gnu.org> Follow-up Comment #5, sr #108550 (project gnutls): If I call dane_query_tlsa() (from a forked process to allow for it being blocking) there isn't an easy way to copy the dane_query_t data from one process to another and reuse it with dane_raw_tlsa(). I'll have to call dane_query_status(), dane_query_entries(), dane_query_data() and then put it all back together. A function that converted a dane_query_t into the parameters needed for dane_raw_tlsa() would reduce the chance of implementation errors. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Jul 6 14:17:03 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sun, 06 Jul 2014 12:17:03 +0000 Subject: [gnutls-devel] [sr #108550] It is impractical to call dane_verify_session_crt() from the gnutls_certificate_set_verify_function() In-Reply-To: <20140705-210755.sv0.73310@savannah.gnu.org> References: <20140419-152442.sv0.8040@savannah.gnu.org> <20140419-161906.sv0.73978@savannah.gnu.org> <20140428-123927.sv707.14646@savannah.gnu.org> <20140629-191005.sv0.52744@savannah.gnu.org> <20140702-145158.sv707.53124@savannah.gnu.org> <20140705-210755.sv0.73310@savannah.gnu.org> Message-ID: <20140706-151703.sv707.17886@savannah.gnu.org> Follow-up Comment #6, sr #108550 (project gnutls): Ok it seems I understand what do you need there and that seem reasonable. I'll add it to the todo list, but providing a patch for that would speed up the process. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From ametzler at bebt.de Sun Jul 6 18:29:52 2014 From: ametzler at bebt.de (Andreas Metzler) Date: Sun, 6 Jul 2014 18:29:52 +0200 Subject: [gnutls-devel] Expected timeline for GnuTLS 3.3 to be declared stable Message-ID: <20140706162952.GC1249@downhill.g.la> Hello, since Debian's next new stable release is beginning to take form (at least in deadlines) I am wondering what would be GnuTLS version to aim for. At the current timeline[1] I will need to have gnutls ready on November 5th, i.e. if things worked perfectly my last chance for uploading a new GnuTLS upstream version would be on October 26th. Given that things usually do not work perfectly when they need to the hard deadline is probably more like October 15th. I would like to try for latest GnuTLS stable and am therefore wondering about GnuTLS 3.3 release plans. Do you know when it might be declared stable? (It is probably a little bit early for asking this, since currently we are trying to move to 3.2 from 2.12.) thanks, cu Andreas [1] https://lists.debian.org/20140705073757.F2A4A20D8 at thykier.net -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From nmav at gnutls.org Sun Jul 6 19:16:31 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 06 Jul 2014 19:16:31 +0200 Subject: [gnutls-devel] Expected timeline for GnuTLS 3.3 to be declared stable In-Reply-To: <20140706162952.GC1249@downhill.g.la> References: <20140706162952.GC1249@downhill.g.la> Message-ID: <1404666991.13119.29.camel@nomad.lan> On Sun, 2014-07-06 at 18:29 +0200, Andreas Metzler wrote: > Hello, > since Debian's next new stable release is beginning to take form (at > least in deadlines) I am wondering what would be GnuTLS version to aim > for. > At the current timeline[1] I will need to have gnutls ready on November > 5th, i.e. if things worked perfectly my last chance for uploading a > new GnuTLS upstream version would be on October 26th. Given that > things usually do not work perfectly when they need to the hard > deadline is probably more like October 15th. > I would like to try for latest GnuTLS stable and am therefore > wondering about GnuTLS 3.3 release plans. Do you know when it might be > declared stable? Hello Andreas, The plan is to make it stable as soon as possible. No new features that require significant changes will be included, and my plan is to have it replace 3.2 by end of summer. > (It is probably a little bit early for asking this, since currently we > are trying to move to 3.2 from 2.12.) There shouldn't be any issue with the move to 3.3 from 3.2. Out of curiosity, what is the major obstacle from abolishing 2.12? Don't programs compile out of the box with 3.2? regards, Nikos From INVALID.NOREPLY at gnu.org Sun Jul 6 21:27:00 2014 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Sun, 06 Jul 2014 19:27:00 +0000 Subject: [gnutls-devel] [sr #108610] dane_verify_crt_raw() does not check chain_size Message-ID: <20140706-192659.sv0.21639@savannah.gnu.org> URL: Summary: dane_verify_crt_raw() does not check chain_size Project: GnuTLS Submitted by: None Submitted on: Sun 06 Jul 2014 19:26:59 UTC Category: Extra library Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: bugs.gnutls.simon at arlott.org Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: dane_verify_crt_raw() does not check chain_size before dereferencing chain[0] in a call to verify_ee(). chain_size could be 0 (it is only checked in dane_verify_session_crt()). For consistency, dane_verify_crt() and dane_verify_crt_raw() should both return DANE_E_NO_CERT if chain_size is 0. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Jul 6 21:34:08 2014 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Sun, 06 Jul 2014 19:34:08 +0000 Subject: [gnutls-devel] [sr #108611] verify_ca() bypasses DANE checking if there are fewer than 2 certificates Message-ID: <20140706-193407.sv0.89922@savannah.gnu.org> URL: Summary: verify_ca() bypasses DANE checking if there are fewer than 2 certificates Project: GnuTLS Submitted by: None Submitted on: Sun 06 Jul 2014 19:34:07 UTC Category: Extra library Priority: 5 - Normal Severity: 6 - Security Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: If there are fewer than 2 certificates (i.e. 1) then the call to verify_ca() will return DANE_E_INVALID_REQUEST causing the client to ignore the TLSA records instead of rejecting the certificate (e.g. when there are only TLSA records with usage CA). _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Jul 6 21:39:06 2014 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Sun, 06 Jul 2014 19:39:06 +0000 Subject: [gnutls-devel] [sr #108612] Both verify_ca() and verify_ee() abort DANE processing with DANE_E_UNKNOWN_DANE_DATA for unrecognised types Message-ID: <20140706-193905.sv0.41002@savannah.gnu.org> URL: Summary: Both verify_ca() and verify_ee() abort DANE processing with DANE_E_UNKNOWN_DANE_DATA for unrecognised types Project: GnuTLS Submitted by: None Submitted on: Sun 06 Jul 2014 19:39:05 UTC Category: Extra library Priority: 5 - Normal Severity: 6 - Security Status: None Privacy: Public Assigned to: None Originator Email: bugs.gnutls.simon at arlott.org Open/Closed: Open Discussion Lock: Any Operating System: None _______________________________________________________ Details: Both verify_ca() and verify_ee() abort DANE processing with DANE_E_UNKNOWN_DANE_DATA for unrecognised types. The correct response is to ignore that TLSA record. If a new TLSA type is introduced then DANE checking will return an error and be ignored by clients. Instead, the clients may have been able to verify the certificate with another TLSA record or they should have rejected it when there are no more recognised records. These functions should return 0 and set *verify |= DANE_VERIFY_UNKNOWN_DANE_INFO. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Jul 6 22:56:03 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sun, 06 Jul 2014 20:56:03 +0000 Subject: [gnutls-devel] [sr #108592] Fix OCSP configure option In-Reply-To: <20140604-113912.sv707.4493@savannah.gnu.org> References: <20140603-113039.sv95437.52653@savannah.gnu.org> <20140604-082416.sv95437.75556@savannah.gnu.org> <20140604-113912.sv707.4493@savannah.gnu.org> Message-ID: <20140706-235602.sv707.64568@savannah.gnu.org> Update of sr #108592 (project gnutls): Category: None => Core library Status: None => Done Assigned to: None => nmav Open/Closed: Open => Closed _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Jul 6 23:02:22 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sun, 06 Jul 2014 21:02:22 +0000 Subject: [gnutls-devel] [sr #108610] dane_verify_crt_raw() does not check chain_size In-Reply-To: <20140706-192659.sv0.21639@savannah.gnu.org> References: <20140706-192659.sv0.21639@savannah.gnu.org> Message-ID: <20140707-000222.sv707.3702@savannah.gnu.org> Update of sr #108610 (project gnutls): Status: None => Done Open/Closed: Open => Closed _______________________________________________________ Follow-up Comment #1: I've committed a check in the repository. Thank you for reporting that. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Jul 6 23:05:04 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sun, 06 Jul 2014 21:05:04 +0000 Subject: [gnutls-devel] [sr #108611] verify_ca() bypasses DANE checking if there are fewer than 2 certificates In-Reply-To: <20140706-193407.sv0.89922@savannah.gnu.org> References: <20140706-193407.sv0.89922@savannah.gnu.org> Message-ID: <20140707-000504.sv707.63200@savannah.gnu.org> Follow-up Comment #1, sr #108611 (project gnutls): I'm not sure what would be the proper behavior. What do you think would be better than returning an invalid request? _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Jul 6 23:11:46 2014 From: INVALID.NOREPLY at gnu.org (Simon Arlott) Date: Sun, 06 Jul 2014 21:11:46 +0000 Subject: [gnutls-devel] [sr #108550] It is impractical to call dane_verify_session_crt() from the gnutls_certificate_set_verify_function() In-Reply-To: <20140706-151703.sv707.17886@savannah.gnu.org> References: <20140419-152442.sv0.8040@savannah.gnu.org> <20140419-161906.sv0.73978@savannah.gnu.org> <20140428-123927.sv707.14646@savannah.gnu.org> <20140629-191005.sv0.52744@savannah.gnu.org> <20140702-145158.sv707.53124@savannah.gnu.org> <20140705-210755.sv0.73310@savannah.gnu.org> <20140706-151703.sv707.17886@savannah.gnu.org> Message-ID: <20140706-211145.sv95894.82631@savannah.gnu.org> Follow-up Comment #7, sr #108550 (project gnutls): I'll implement a copy of https://github.com/lp0/weechat/commit/6d69397b4fa3c947e1cc80b1b454a666232b1d1a#diff-8053959401d6693d38be5b1272ef40d7R158 directly in libdane/dane.c (I've added the number of entries as a return value because it simplifies duplicating the data if you don't have to iterate first to find this out). It's a bit inconvenient having to obtain and provide the certificate chain manually when the non-raw session version of the function does this automatically: https://github.com/lp0/weechat/commit/e9d033abd9669315b73e3f8b707a592964ae932c#diff-e5707b6a1e5cfc1f92761719c83b3782R3748 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Jul 6 23:13:14 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sun, 06 Jul 2014 21:13:14 +0000 Subject: [gnutls-devel] [sr #108612] Both verify_ca() and verify_ee() abort DANE processing with DANE_E_UNKNOWN_DANE_DATA for unrecognised types In-Reply-To: <20140706-193905.sv0.41002@savannah.gnu.org> References: <20140706-193905.sv0.41002@savannah.gnu.org> Message-ID: <20140707-001314.sv707.39125@savannah.gnu.org> Update of sr #108612 (project gnutls): Category: Extra library => DANE library Status: None => Ready For Test Assigned to: None => nmav _______________________________________________________ Follow-up Comment #1: I've added a check that skips those entries. I don't think that an UNKNOWN_DANE_INFO verify flag is needed. Having it may cause similar failures at the application layer, and wouldn't provide any significant information that the application can act on. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From hammi_mohamed_tahar at hotmail.fr Mon Jul 7 00:47:21 2014 From: hammi_mohamed_tahar at hotmail.fr (hammi_mohamed_tahar at hotmail.fr) Date: Mon, 7 Jul 2014 00:47:21 +0200 Subject: [gnutls-devel] gnutls handling error Message-ID: Hello, First of all, thank you for your answer, As OS, I have Ubuntu 14.04 Desktop 64 bits. For GNUTLS installation I followed these steps : 1- Install the prequisites: sudo apt-get install build-essential nettle-dev libgmp-dev 2- Download the GnuTLS source files: wget ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.23.tar.xz 3- Extract the files: unxz gnutls-3.1.23.tar.xz && tar -xvf gnutls-3.1.23.tar 4- Change into the build directory: cd gnutls-3.1.23 5- Compile and install: ./configure && make && make install 6- Add a symlink to your libgnutls.so.28 file so gnutls-cli can tell us what version we are running: ln -s /usr/local/lib/libgnutls.so.28 /usr/lib/libgnutls.so.28 After, to create my extension, I followed this tutorial (http://gnutls.org/manual/html_node/TLS-Extension-Handling.html), for compilation I did these commands: 1- ./configure --enable-myExtension : [..............] version: 3.1.23 shared 49:3:21 Host/Target system: x86_64-unknown-linux-gnu Build system: x86_64-unknown-linux-gnu Install prefix: /usr/local Compiler: gcc -std=gnu99 CFlags: -g -O2 Library types: Shared=yes, Static=yes configure: External hardware support: /dev/crypto: no Hardware accel: x86-64 PKCS#11 support: yes TPM support: no configure: Optional features: (note that included applications might not compile properly if features are disabled) DTLS-SRTP support: yes OCSP support: yes OpenPGP support: yes SRP support: yes PSK support: yes DHE support: yes ECDHE support: yes RSA-EXPORT support: yes Anon auth support: yes Heartbeat support: yes configure: Optional applications : crywrap app: yes local libopts: no local libtasn1: no configure: Optional libraries: Guile wrappers: no C++ library: yes DANE library: no OpenSSL compat: yes configure: System files: Trust store pkcs: Trust store file: /etc/ssl/certs/ca-certificates.crt Blacklist file: CRL file: DNSSEC root key file: /etc/unbound/root.key 2- make ./../gnutls_datum.h:26:24: error: unknown type name 'gnutls_datum_t' int _gnutls_set_datum (gnutls_datum_t * dat, const void *data, ^ ./../gnutls_datum.h:27:26: error: unknown type name 'size_t' size_t data_size); ^ [........] /gnutls_int.h:726:3: error: unknown type name 'gnutls_buffer_st' .... gnutls_int.h:782:3: error: unknown type name 'gnutls_buffer_st' ..... myExtension.c 15:11 : error: unknown type name 'opaque' const opaque * data, [..............etc] Finaly, for the other extensions, for exemple when I execute this commande: gnutls-cli --verbose --port 443www.ietf.org --heartbeat, With Wireshark, I can see the add of the new extension. Nb: Even when I dont touch the source code of gnutls and when I juste modifie the gnutls_int.h file for exemple : GNUTLS_EXTENSION_SIGNATURE_ALGORITHMS = 99, /*instead of 13*/ and after executing with ./configure, make, sudo make install, In wireshark the Type of the extension did not change and still equal to 000d that it means 13 in decimal. Think you. Mohamed Tahar HAMMI Le 05/07/2014 12:27, Nikos Mavrogiannopoulos a ?crit : > On Fri, 2014-07-04 at 12:40 +0200,hammi_mohamed_tahar at hotmail.fr wrote: >> Hello, >> I'm trying to create a new TLS extension with Gnutls, so i've install >> "gnutls-3.3.4" with all their dependencies, when i make "make check" >> i've got no error and all is well. After i've followed this tutorial >> (http://gnutls.org/manual/html_node/TLS-Extension-Handling.html) to make >> the necessary modifications, but when i compile the new code with "make" >> commande after done "./configure --enable-myExtension" i got some errors >> messages, for exemple: >> .... >> /gnutls_int.h:726:3: error: unknown type name 'gnutls_buffer_st' >> .... >> gnutls_int.h:782:3: error: unknown type name 'gnutls_buffer_st' >> ..... >> myExtension.c 15:11 : error: unknown type name 'opaque' >> const opaque * data, > How did you try to compile it? These will be defined if you have a > normal gnutls built. Check how the other extensions are defined/used, > and if there is something missing from the documentation let us know. > > regards, > Nikos > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Jul 7 10:51:31 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 7 Jul 2014 10:51:31 +0200 Subject: [gnutls-devel] gnutls handling error In-Reply-To: References: Message-ID: On Mon, Jul 7, 2014 at 12:47 AM, hammi_mohamed_tahar at hotmail.fr wrote: > Hello, > First of all, thank you for your answer, [...] > 5- Compile and install: ./configure && make && make install > 6- Add a symlink to your libgnutls.so.28 file so gnutls-cli can tell us what > version we are > running: ln -s /usr/local/lib/libgnutls.so.28 /usr/lib/libgnutls.so.28 > After, to create my extension, I followed this tutorial > (http://gnutls.org/manual/html_node/TLS-Extension-Handling.html), for > compilation I did these commands: You miss to describe the important part. What did you add in Makefile.am? Did you run autoreconf after modifying hooks.m4? regards, Nikos From hammi_mohamed_tahar at hotmail.fr Mon Jul 7 11:09:59 2014 From: hammi_mohamed_tahar at hotmail.fr (hammi_mohamed_tahar at hotmail.fr) Date: Mon, 7 Jul 2014 11:09:59 +0200 Subject: [gnutls-devel] gnutls handling error In-Reply-To: References: Message-ID: Mr Nikos, I used the last version (gnutls-3.3.4) and gnutls-3.1.23, In the ext/Mikefile.am I added these lines : if ENABLE_MYEXTENSION libgnutls_ext_la_SOURCES += myextension.c myextension.h endif But I did not run the autoreconf after modifying hooks.m4, please if this step is crutial tell me what are the arguments that I must add to this commande. Thank you. Mohamed Tahar HAMMI Le 07/07/2014 10:51, Nikos Mavrogiannopoulos a ?crit : > On Mon, Jul 7, 2014 at 12:47 AM, hammi_mohamed_tahar at hotmail.fr > wrote: >> Hello, >> First of all, thank you for your answer, > [...] >> 5- Compile and install: ./configure && make && make install >> 6- Add a symlink to your libgnutls.so.28 file so gnutls-cli can tell us what >> version we are >> running: ln -s /usr/local/lib/libgnutls.so.28 /usr/lib/libgnutls.so.28 >> After, to create my extension, I followed this tutorial >> (http://gnutls.org/manual/html_node/TLS-Extension-Handling.html), for >> compilation I did these commands: > You miss to describe the important part. What did you add in > Makefile.am? Did you run autoreconf after modifying hooks.m4? > > regards, > Nikos From hammi_mohamed_tahar at hotmail.fr Mon Jul 7 15:52:14 2014 From: hammi_mohamed_tahar at hotmail.fr (hammi_mohamed_tahar at hotmail.fr) Date: Mon, 7 Jul 2014 15:52:14 +0200 Subject: [gnutls-devel] gnutls handling error In-Reply-To: References: Message-ID: Mr Nikos, I redid the steps of " http://gnutls.org/manual/html_node/TLS-Extension-Handling.html" until just before the step " /Add API functions to enable/disable the extension /", and I ran the commande "autoreconf" just after the modification of the "hooks.m4", then I made : ./configure --enable-myextention make --> this time I have no more errors make check -->(I had no error) sudo make install But when I try to see the display of my new extension, I can not find it. For exemple when I Write : gnutls-cli --verbose --port 443 www.ietf.org I get : ################## Wireshark ##################################### Transmission Control Protocol, Src Port: 50917 (50917), Dst Port: https (443), Seq: 1, Ack: 1, Len: 275 Secure Sockets Layer TLSv1.2 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: SSL 3.0 (0x0300) Length: 270 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 266 Version: TLS 1.2 (0x0303) Random Session ID Length: 0 Cipher Suites Length: 132 Cipher Suites (66 suites) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 93 Extension: status_request Extension: server_name Extension: renegotiation_info Extension: SessionTicket TLS Extension: elliptic_curves Extension: ec_point_formats Extension: signature_algorithms ##################################################################### At first time I juste want to see the name of my extension added to the list, what I must do ? Thank you. Mohamed Tahar HAMMI Le 07/07/2014 10:51, Nikos Mavrogiannopoulos a ?crit : > On Mon, Jul 7, 2014 at 12:47 AM, hammi_mohamed_tahar at hotmail.fr > wrote: >> Hello, >> First of all, thank you for your answer, > [...] >> 5- Compile and install: ./configure && make && make install >> 6- Add a symlink to your libgnutls.so.28 file so gnutls-cli can tell us what >> version we are >> running: ln -s /usr/local/lib/libgnutls.so.28 /usr/lib/libgnutls.so.28 >> After, to create my extension, I followed this tutorial >> (http://gnutls.org/manual/html_node/TLS-Extension-Handling.html), for >> compilation I did these commands: > You miss to describe the important part. What did you add in > Makefile.am? Did you run autoreconf after modifying hooks.m4? > > regards, > Nikos -------------- next part -------------- An HTML attachment was scrubbed... URL: From ametzler at bebt.de Mon Jul 7 19:41:19 2014 From: ametzler at bebt.de (Andreas Metzler) Date: Mon, 7 Jul 2014 19:41:19 +0200 Subject: [gnutls-devel] Expected timeline for GnuTLS 3.3 to be declared stable In-Reply-To: <1404666991.13119.29.camel@nomad.lan> References: <20140706162952.GC1249@downhill.g.la> <1404666991.13119.29.camel@nomad.lan> Message-ID: <20140707174119.GB12160@downhill.g.la> On 2014-07-06 Nikos Mavrogiannopoulos wrote: > On Sun, 2014-07-06 at 18:29 +0200, Andreas Metzler wrote: [...] > Hello Andreas, > The plan is to make it stable as soon as possible. No new features that > require significant changes will be included, and my plan is to have it > replace 3.2 by end of summer. Great, I will switch Debian unstable when it is opportune. > > (It is probably a little bit early for asking this, since currently we > > are trying to move to 3.2 from 2.12.) > There shouldn't be any issue with the move to 3.3 from 3.2. > Out of curiosity, what is the major obstacle from abolishing 2.12? Don't > programs compile out of the box with 3.2? Many do but some important ones (OpenLDAP, fixed in upstream git) did not. The most frequent issues are more uglyness than real breakage and related to swiching of crypto backends: * If gnutls is available and you need gcrypt you need to build-depend on and search for it. It is not always there anymore. * Configuring gcrypt (quick random, thread handlers) only on the assumption that it is used by gnutls is pointless. Drop the dependency. * Calculating a MD5 hash is not be done best by invoking gcrypt, use the GnuTLS crypt API and avoid the additional external dependency. It is alse a bit of an organizational problem. Due to the license issues and the timing of the last Debian release we needed to have both gnutls versions in Debian for a very long time. - If that was not the case a quick hard cut might have been used instead. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From hammi_mohamed_tahar at hotmail.fr Tue Jul 8 15:57:05 2014 From: hammi_mohamed_tahar at hotmail.fr (hammi_mohamed_tahar at hotmail.fr) Date: Tue, 8 Jul 2014 15:57:05 +0200 Subject: [gnutls-devel] gnutls handling error In-Reply-To: References: Message-ID: Mr Nikos, I verified the _gnutls_gen_extensions(), and I think that all is well, maybe I did not activate my extension, or I must add a parametter like (--enable-myextension) when I use gnutls-cli ?? this is what I added to hooks.m4 ################################################################# ac_enable_myextension=yes AC_MSG_CHECKING([whether to disable myextension support]) AC_ARG_ENABLE(myextension, AS_HELP_STRING([--disable-myextension], [disable myextension support]), ac_enable_myextension=no) if test x$ac_enable_myextension != xno; then AC_MSG_RESULT(no) AC_DEFINE([ENABLE_MYEXTENSION], 1, [enable myextension]) else ac_full=0 AC_MSG_RESULT(yes) fi AM_CONDITIONAL(ENABLE_MYEXTENSION, test "$ac_enable_myextension" != "no") ################################################################# Nb: I have not the files "myextension.lo" nor "myextension.o" like the others extensions ?? Regards, Mohamed Tahar HAMMI Le 08/07/2014 15:02, Nikos Mavrogiannopoulos a ?crit : > On Mon, Jul 7, 2014 at 3:52 PM, hammi_mohamed_tahar at hotmail.fr > wrote: >> Mr Nikos, >> I redid the steps of " >> http://gnutls.org/manual/html_node/TLS-Extension-Handling.html " until just >> before the step " Add API functions to enable/disable the extension ", and I >> ran the commande "autoreconf" just after the modification of the "hooks.m4", >> then I made : > [...] >> But when I try to see the display of my new extension, I can not find it. >> For exemple when I Write : gnutls-cli --verbose --port 443 www.ietf.org > I assume that you registered you extension, so my guess would be to > see _gnutls_gen_extensions() and why it is or is not sent. > > regards, > Nikos From hammi_mohamed_tahar at hotmail.fr Wed Jul 9 11:24:17 2014 From: hammi_mohamed_tahar at hotmail.fr (hammi_mohamed_tahar at hotmail.fr) Date: Wed, 9 Jul 2014 11:24:17 +0200 Subject: [gnutls-devel] gnutls handling error In-Reply-To: References: Message-ID: Mr Nikos, I think I understood the reason why I have not the "myextension.lo" and the "myextension.o", and the reason why I can not see my extension with Wireshark, it's all just because my extension was not taken into account in the "hooks.m4": AS_HELP_STRING([--disable-myextension], [disable the MYEXTENSION support]), ac_enable_myextension=no) when I changed the value "no" into a "yes" (and done: autoreconf, ./ configure --enable-myextension, make.), I had exactly the same errors I got the first time: . /.. / gnutls_datum.h: 26:24: error: unknown type name 'gnutls_datum_t' _gnutls_set_datum int (* gnutls_datum_t dat, const void * data, ^ . /.. / gnutls_datum.h: 27:26: error: unknown type name 'size_t' DATA_SIZE size_t); ^ [........] / gnutls_int.h: 726:3: error: unknown type name 'gnutls_buffer_st' .... gnutls_int.h: 782:3: error: unknown type name 'gnutls_buffer_st' ..... myExtension.c 3:11 p.m.: error: unknown type name 'opaque' const opaque * data, [.............. etc] Please, if you can find the problem I would be very grateful. thank you, Mohamed Tahar HAMMI Le 08/07/2014 15:02, Nikos Mavrogiannopoulos a ?crit : > On Mon, Jul 7, 2014 at 3:52 PM, hammi_mohamed_tahar at hotmail.fr > wrote: >> Mr Nikos, >> I redid the steps of " >> http://gnutls.org/manual/html_node/TLS-Extension-Handling.html " until just >> before the step " Add API functions to enable/disable the extension ", and I >> ran the commande "autoreconf" just after the modification of the "hooks.m4", >> then I made : > [...] >> But when I try to see the display of my new extension, I can not find it. >> For exemple when I Write : gnutls-cli --verbose --port 443 www.ietf.org > I assume that you registered you extension, so my guess would be to > see _gnutls_gen_extensions() and why it is or is not sent. > > regards, > Nikos From INVALID.NOREPLY at gnu.org Wed Jul 9 23:22:17 2014 From: INVALID.NOREPLY at gnu.org (Simon Arlott) Date: Wed, 09 Jul 2014 21:22:17 +0000 Subject: [gnutls-devel] [sr #108550] It is impractical to call dane_verify_session_crt() from the gnutls_certificate_set_verify_function() In-Reply-To: <20140706-211145.sv95894.82631@savannah.gnu.org> References: <20140419-152442.sv0.8040@savannah.gnu.org> <20140419-161906.sv0.73978@savannah.gnu.org> <20140428-123927.sv707.14646@savannah.gnu.org> <20140629-191005.sv0.52744@savannah.gnu.org> <20140702-145158.sv707.53124@savannah.gnu.org> <20140705-210755.sv0.73310@savannah.gnu.org> <20140706-151703.sv707.17886@savannah.gnu.org> <20140706-211145.sv95894.82631@savannah.gnu.org> Message-ID: <20140709-212217.sv95894.16457@savannah.gnu.org> Follow-up Comment #8, sr #108550 (project gnutls): This code allocates an unnecessary extra NULL entry for dane_data_len to avoid trying to malloc 0 bytes if q->data_entries is 0. (file #31693) _______________________________________________________ Additional Item Attachment: File name: dane-108550.patch Size:4 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Jul 10 12:35:01 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Thu, 10 Jul 2014 10:35:01 +0000 Subject: [gnutls-devel] [sr #108550] It is impractical to call dane_verify_session_crt() from the gnutls_certificate_set_verify_function() In-Reply-To: <20140709-212217.sv95894.16457@savannah.gnu.org> References: <20140419-152442.sv0.8040@savannah.gnu.org> <20140419-161906.sv0.73978@savannah.gnu.org> <20140428-123927.sv707.14646@savannah.gnu.org> <20140629-191005.sv0.52744@savannah.gnu.org> <20140702-145158.sv707.53124@savannah.gnu.org> <20140705-210755.sv0.73310@savannah.gnu.org> <20140706-151703.sv707.17886@savannah.gnu.org> <20140706-211145.sv95894.82631@savannah.gnu.org> <20140709-212217.sv95894.16457@savannah.gnu.org> Message-ID: <20140710-133501.sv707.80685@savannah.gnu.org> Update of sr #108550 (project gnutls): Category: Core library => DANE library _______________________________________________________ Follow-up Comment #9: Thank you. It looks reasonable. Would you like to send the DCO to the list (or at bugs at gnutls.org) and submit a git diff with the sign-off tag? http://www.gnutls.org/devel.html _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Jul 10 23:14:35 2014 From: INVALID.NOREPLY at gnu.org (Simon Arlott) Date: Thu, 10 Jul 2014 21:14:35 +0000 Subject: [gnutls-devel] [sr #108550] It is impractical to call dane_verify_session_crt() from the gnutls_certificate_set_verify_function() In-Reply-To: <20140710-133501.sv707.80685@savannah.gnu.org> References: <20140419-152442.sv0.8040@savannah.gnu.org> <20140419-161906.sv0.73978@savannah.gnu.org> <20140428-123927.sv707.14646@savannah.gnu.org> <20140629-191005.sv0.52744@savannah.gnu.org> <20140702-145158.sv707.53124@savannah.gnu.org> <20140705-210755.sv0.73310@savannah.gnu.org> <20140706-151703.sv707.17886@savannah.gnu.org> <20140706-211145.sv95894.82631@savannah.gnu.org> <20140709-212217.sv95894.16457@savannah.gnu.org> <20140710-133501.sv707.80685@savannah.gnu.org> Message-ID: <20140710-211435.sv95894.25261@savannah.gnu.org> Additional Item Attachment, sr #108550 (project gnutls): File name: 0001-libdane-add-function-dane_query_to_raw_tlsa.patch Size:4 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From simon at arlott.org Thu Jul 10 23:14:27 2014 From: simon at arlott.org (Simon Arlott) Date: Thu, 10 Jul 2014 22:14:27 +0100 Subject: [gnutls-devel] DCO Message-ID: <53BF0233.6080309@simon.arlott.org.uk> Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. -- Simon Arlott -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2387 bytes Desc: S/MIME Cryptographic Signature URL: From saghul at gmail.com Fri Jul 11 16:09:35 2014 From: saghul at gmail.com (=?UTF-8?B?U2HDumwgSWJhcnJhIENvcnJldGfDqQ==?=) Date: Fri, 11 Jul 2014 16:09:35 +0200 Subject: [gnutls-devel] python-gnutls updated for GnuTLS 3, please update webpage Message-ID: <53BFF01F.1060805@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, We recently updated and released python-gnutls 2.0, which only works with GnuTLS 3 now. Could you please update the main GnuTLS website and remove the "(outdated)" text? Thanks a lot! - -- Sa?l Ibarra Corretg? bettercallsaghul.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJTv/AfAAoJEEEOVVOum8BZ/SQP/jmLKC2OwSxV664g1BTZIS7r JCCbR1UKUZVFU3IB5HBHA4gcbqUERzRFSeu0UGqeEK6IZMiK7MV6UygNDzzfTKyA SMbEKjbhynX1IX+2w1Kn6RmyDljsaQYE4Z1IEybsgLsaeY9Y/KNTmnq4N69T0YaO QqYt3vNobioMwL2LCX6fVr9XNrPRudH2ovxjnHEfEG7R1dg+HOLu3EZ2D3OXSXUJ jMZBBVaQEb1rHDJe923l/6VTJ/klEUF1jkSYGPjS+dkzLHFXdWHyj0adwWevmc56 giG6s9SUKruf9OCaQe/xXvbLCpg1vRsvchTQ0RLjSh8SpDiqVv74oNiS54F3DTzE fn8h0SS6bW+4HJpXYjzCuNrnwcEn5ikq8MxsaWVdzMV0Nb/iA2sq33tgVBGTRYl+ Vs6mp4EUIk+obhnmjwkKIOj3We6gAgZ5D1HmPYpcyl6maY5n+OIzFFyG8+p+6nwj wpRIo5hFfcddLKUmpAekFRHYhNo5PjHvBIw4wArY4CSAUqIipO9jXRBSS9sAGhhF 1iACgK7/AGgmHlfP5r+PXoIZjy3chT+6sTAoXC5viMKEa2kRBgn3aNjh4iZ59CVj cojMIl8+o+upv1cOW4Rxzsq52uRdidXiGjSCiWwSUFI2hB/z0pY7ohXDCYA0EBBJ iBsfDJd7uFm+Q5LjavCx =khXb -----END PGP SIGNATURE----- From INVALID.NOREPLY at gnu.org Fri Jul 11 17:49:09 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Fri, 11 Jul 2014 15:49:09 +0000 Subject: [gnutls-devel] [sr #108550] It is impractical to call dane_verify_session_crt() from the gnutls_certificate_set_verify_function() In-Reply-To: <20140710-211435.sv95894.25261@savannah.gnu.org> References: <20140419-152442.sv0.8040@savannah.gnu.org> <20140419-161906.sv0.73978@savannah.gnu.org> <20140428-123927.sv707.14646@savannah.gnu.org> <20140629-191005.sv0.52744@savannah.gnu.org> <20140702-145158.sv707.53124@savannah.gnu.org> <20140705-210755.sv0.73310@savannah.gnu.org> <20140706-151703.sv707.17886@savannah.gnu.org> <20140706-211145.sv95894.82631@savannah.gnu.org> <20140709-212217.sv95894.16457@savannah.gnu.org> <20140710-133501.sv707.80685@savannah.gnu.org> <20140710-211435.sv95894.25261@savannah.gnu.org> Message-ID: <20140711-184909.sv707.92524@savannah.gnu.org> Follow-up Comment #10, sr #108550 (project gnutls): It is now applied. This function also allows easier testing of dane_raw_tlsa(). I'll try to add a test case for both of these as soon as I'm back. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Fri Jul 11 19:17:42 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 11 Jul 2014 19:17:42 +0200 Subject: [gnutls-devel] python-gnutls updated for GnuTLS 3, please update webpage In-Reply-To: <53BFF01F.1060805@gmail.com> References: <53BFF01F.1060805@gmail.com> Message-ID: On Fri, Jul 11, 2014 at 4:09 PM, Sa?l Ibarra Corretg? wrote: > Hi, > We recently updated and released python-gnutls 2.0, which only works > with GnuTLS 3 now. Could you please update the main GnuTLS website and > remove the "(outdated)" text? Hello, I've removed the outdated text; the update may take some hours to take effect. May I suggest using on the examples the system trust functions? (e.g., http://gnutls.org/manual/gnutls.html#gnutls_005fcertificate_005fset_005fx509_005fsystem_005ftrust) That way python programs will also use the system trust rather than setting individually the ca file. regards, Nikos From saghul at gmail.com Sat Jul 12 19:26:52 2014 From: saghul at gmail.com (=?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?=) Date: Sat, 12 Jul 2014 19:26:52 +0200 Subject: [gnutls-devel] python-gnutls updated for GnuTLS 3, please update webpage In-Reply-To: References: <53BFF01F.1060805@gmail.com> Message-ID: <53C16FDC.60704@gmail.com> On 11/07/14 19:17, Nikos Mavrogiannopoulos wrote: > On Fri, Jul 11, 2014 at 4:09 PM, Sa?l Ibarra Corretg? wrote: >> Hi, >> We recently updated and released python-gnutls 2.0, which only works >> with GnuTLS 3 now. Could you please update the main GnuTLS website and >> remove the "(outdated)" text? > > Hello, > I've removed the outdated text; the update may take some hours to > take effect. May I suggest using on the examples the system trust > functions? (e.g., > http://gnutls.org/manual/gnutls.html#gnutls_005fcertificate_005fset_005fx509_005fsystem_005ftrust) > > That way python programs will also use the system trust rather than > setting individually the ca file. > Thanks Nikos! That was quick! I'll look into that. Regards, -- Sa?l Ibarra Corretg? http://bettercallsaghul.com From dan at coneharvesters.com Sun Jul 13 01:26:44 2014 From: dan at coneharvesters.com (Dan Fandrich) Date: Sun, 13 Jul 2014 01:26:44 +0200 Subject: [gnutls-devel] err_pos not set on error in gnutls_priority_init Message-ID: <20140712232644.GA10148@coneharvesters.com> The documentation for gnutls_priority_init states: @err_pos: In case of an error this will have the position in the string the error occured Leaving the issue of the spelling error in "occurred", there is a code path in which an error is returned without this argument being set. If gnutls_calloc returns NULL, then GNUTLS_E_MEMORY_ERROR is returned and err_pos is NOT touched. The code fragment setting *err_pos should be moved the calloc call to fix this. >>> Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 308 bytes Desc: not available URL: From INVALID.NOREPLY at gnu.org Mon Jul 14 08:24:19 2014 From: INVALID.NOREPLY at gnu.org (Ryan Schmidt) Date: Mon, 14 Jul 2014 06:24:19 +0000 Subject: [gnutls-devel] [sr #108614] Reinstate support for C89 Message-ID: <20140714-062418.sv64386.1640@savannah.gnu.org> URL: Summary: Reinstate support for C89 Project: GnuTLS Submitted by: ryandesign Submitted on: Mon 14 Jul 2014 06:24:18 AM 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: Hello, I'm with the MacPorts package management system, which recently updated its gnutls package from version 3.1.x to 3.3.5. We've found that now, software that uses gnutls cannot be compiled in c89 mode because of errors like this: /opt/local/include/gnutls/gnutls.h:172: error: comma at end of enumerator list /opt/local/include/gnutls/gnutls.h:186: error: comma at end of enumerator list /opt/local/include/gnutls/gnutls.h:244: error: comma at end of enumerator list /opt/local/include/gnutls/gnutls.h:295: error: comma at end of enumerator list /opt/local/include/gnutls/gnutls.h:394: error: comma at end of enumerator list /opt/local/include/gnutls/gnutls.h:434: error: comma at end of enumerator list /opt/local/include/gnutls/gnutls.h:485: error: comma at end of enumerator list /opt/local/include/gnutls/gnutls.h:599: error: comma at end of enumerator list /opt/local/include/gnutls/gnutls.h:618: error: comma at end of enumerator list /opt/local/include/gnutls/gnutls.h:668: error: comma at end of enumerator list /opt/local/include/gnutls/gnutls.h:688: error: comma at end of enumerator list /opt/local/include/gnutls/gnutls.h:722: error: comma at end of enumerator list /opt/local/include/gnutls/gnutls.h:1598: error: comma at end of enumerator list /opt/local/include/gnutls/gnutls.h:1937: error: comma at end of enumerator list /opt/local/include/gnutls/gnutls.h:2085: error: comma at end of enumerator list For more info, see: https://trac.macports.org/ticket/44323 These problems are not seen in c99 mode, where a comma at the end of an enumerator list is legal. c99 mode is used by default by clang, which is included in the developer tools on Mac OS X v10.6 and later. However, c89 is used by default by the old versions of gcc included in the developer tools on Mac OS X v10.6 and earlier, and that's also the default compiler there. One could say "well, just build in c99 mode", but I feel that's an onerous requirement to place on every software package that uses gnutls. Therefore, to better support earlier Mac OS X versions, I propose you remove the commas at the end of your enumerator lists. I made this patch to do this, and it seems to work: https://trac.macports.org/attachment/ticket/44323/patch-c89.diff _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Jul 14 08:40:46 2014 From: INVALID.NOREPLY at gnu.org (Ryan Schmidt) Date: Mon, 14 Jul 2014 06:40:46 +0000 Subject: [gnutls-devel] [sr #108615] Regenerating documentation fails when sed is BSD sed Message-ID: <20140714-064046.sv64386.31705@savannah.gnu.org> URL: Summary: Regenerating documentation fails when sed is BSD sed Project: GnuTLS Submitted by: ryandesign Submitted on: Mon 14 Jul 2014 06:40:45 AM 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: I found that gnutls 3.3.5 fails to build on OS X, and presumably other BSD-derived systems like FreeBSD and OpenBSD whose "sed" program is BSD sed instead of GNU sed, if I make a change to the sources that causes the documentation to be regenerated, such as patching gnutls.h.in which I was doing to resolve issue #108614. The error I encountered was: sed -i 's/\@anchor{.*//g' functions/* sed: 1: "functions/dane_cert_typ ...": invalid command code f make[4]: *** [stamp_functions] Error 1 The doc Makefile uses GNU-specific sed features, such as assuming that the argument to the "-i" flag is optional. (In BSD sed, it is required.) I do actually have GNU sed installed as well, but under the name "gsed" (as provided by the MacPorts "gsed" port). However, although your configure script correctly finds this gsed, your Makefile does not make use of the $SED variable which would have expanded to that program, but instead just uses the program name "sed". Ideally, your complete build system, including the documentation regeneration, should support both BSD sed and GNU sed. Either stick with just the capabilities that both flavors provide (e.g. always use an argument to "-i", since GNU sed should be happy with that as well), or detect which flavor of BSD is present and change your invocations accordingly at build time. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Tue Jul 22 13:21:17 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 22 Jul 2014 13:21:17 +0200 Subject: [gnutls-devel] err_pos not set on error in gnutls_priority_init In-Reply-To: <20140712232644.GA10148@coneharvesters.com> References: <20140712232644.GA10148@coneharvesters.com> Message-ID: On Sun, Jul 13, 2014 at 1:26 AM, Dan Fandrich wrote: > The documentation for gnutls_priority_init states: > @err_pos: In case of an error this will have the position in the string the error occured > which an error is returned without this argument being set. If gnutls_calloc > returns NULL, then GNUTLS_E_MEMORY_ERROR is returned and err_pos is NOT > touched. The code fragment setting *err_pos should be moved the calloc call to > fix this. Thank you for reporting that. I've updated that to always set a valid err_pos. However, it should be noted that err_pos makes sense if this function returns GNUTLS_E_INVALID_REQUEST, which indicates a parsing error. regards, Nikos From nmav at gnutls.org Wed Jul 23 09:31:37 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 23 Jul 2014 09:31:37 +0200 Subject: [gnutls-devel] gnutls 3.2.16 Message-ID: <1406100697.22361.0.camel@nomad.lan> Hello, I've just released gnutls 3.2.16. This is a bugfix release on the current stable branch. * Version 3.2.16 (released 2014-07-23) ** libgnutls: Do not call the post client hello callback twice when resuming using session tickets. ** libgnutls: When the decoding of a printable DN element fails, then treat it as unknown and print its hex value rather than failing. That works around an issue in a TURKTRST root certificate which improperly encodes the X520countryName element. ** libgnutls: IP addresses are printed using inet_ntop() when available. ** libgnutls: gnutls_x509_crt_check_hostname will also check IP addresses and match documented behavior. Reported by David Woodhouse. ** libgnutls: Fixed PKCS #11 ECDSA key generation. ** p11tool: use GNUTLS_SO_PIN to read the security officer's PIN if set. ** p11tool: will not implicitly enable so-login for certain types of objects. That avoids issues with tokens that require different login types. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.16.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.16.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.16.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.16.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 Wed Jul 23 09:33:08 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 23 Jul 2014 09:33:08 +0200 Subject: [gnutls-devel] gnutls 3.3.6 Message-ID: <1406100788.22361.2.camel@nomad.lan> Hello, I've just released gnutls 3.3.6. This release adds new features, and fixes bugs on the next-stable branch. * Version 3.3.6 (released 2014-07-23) ** libgnutls: Use inet_ntop to print IP addresses when available ** libgnutls: gnutls_x509_crt_check_hostname and friends will also check IP addresses, and match documented behavior. Reported by David Woodhouse. ** libgnutls: DSA key generation in FIPS140-2 mode doesn't allow 1024 bit parameters. ** libgnutls: fixed issue in gnutls_pkcs11_reinit() which prevented tokens being usable after a reinitialization. ** libgnutls: fixed PKCS #11 private key operations after a fork. ** libgnutls: fixed PKCS #11 ECDSA key generation. ** libgnutls: The GNUTLS_CPUID_OVERRIDE environment variable can be used to explicitly enable/disable the use of certain CPU capabilities. Note that CPU detection cannot be overriden, i.e., VIA options cannot be enabled on an Intel CPU. The currently available options are: 0x1: Disable all run-time detected optimizations 0x2: Enable AES-NI 0x4: Enable SSSE3 0x8: Enable PCLMUL 0x100000: Enable VIA padlock 0x200000: Enable VIA PHE 0x400000: Enable VIA PHE SHA512 ** libdane: added dane_query_to_raw_tlsa(); patch by Simon Arlott. ** p11tool: use GNUTLS_SO_PIN to read the security officer's PIN if set. ** p11tool: ask for label when one isn't provided. ** p11tool: added --batch parameter to disable any interactivity. ** p11tool: will not implicitly enable so-login for certain types of objects. That avoids issues with tokens that require different login types. ** certtool/p11tool: Added the --curve parameter which allows to explicitly specify the curve to use. ** API and ABI modifications: gnutls_certificate_set_x509_trust_dir: Added gnutls_x509_trust_list_add_trust_dir: Added Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.6.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.6.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.6.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.6.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 INVALID.NOREPLY at gnu.org Sun Jul 27 14:21:09 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sun, 27 Jul 2014 12:21:09 +0000 Subject: [gnutls-devel] [sr #108614] Reinstate support for C89 In-Reply-To: <20140714-062418.sv64386.1640@savannah.gnu.org> References: <20140714-062418.sv64386.1640@savannah.gnu.org> Message-ID: <20140727-152108.sv707.62584@savannah.gnu.org> Follow-up Comment #1, sr #108614 (project gnutls): Hello, I could apply the patch if you attach it in a text format (the link you sent is in html format). Nevertheless, C99 is already 15 years old and I'll not spent much resources in keeping the code C89-compliant, except maybe for headers, as your patch does. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Jul 27 14:27:57 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sun, 27 Jul 2014 12:27:57 +0000 Subject: [gnutls-devel] [sr #108615] Regenerating documentation fails when sed is BSD sed In-Reply-To: <20140714-064046.sv64386.31705@savannah.gnu.org> References: <20140714-064046.sv64386.31705@savannah.gnu.org> Message-ID: <20140727-152757.sv707.24675@savannah.gnu.org> Update of sr #108615 (project gnutls): Status: None => Done Assigned to: None => nmav Operating System: None => Mac OS _______________________________________________________ Follow-up Comment #1: Hello, I've done the replacement of sed with $(SED) in makefile.am, but I'm not sure whether that this change would be sufficient to build documentation in any system without the gnu tools. Would it make sense to use "--disable-doc" and ship only the included documentation? _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Jul 27 14:34:18 2014 From: INVALID.NOREPLY at gnu.org (Ryan Schmidt) Date: Sun, 27 Jul 2014 12:34:18 +0000 Subject: [gnutls-devel] [sr #108615] Regenerating documentation fails when sed is BSD sed In-Reply-To: <20140727-152757.sv707.24675@savannah.gnu.org> References: <20140714-064046.sv64386.31705@savannah.gnu.org> <20140727-152757.sv707.24675@savannah.gnu.org> Message-ID: <20140727-123418.sv64386.82513@savannah.gnu.org> Follow-up Comment #2, sr #108615 (project gnutls): Right, using $(SED) will ensure the sed that configure found gets used, but that won't fix the build failure if configure found a BSD sed. Disabling documentation building is one idea, but is it really that hard to support BSD sed as well? For example, as I mentioned, always supply an argument to the -i flag: -i '' would be the portable equivalent to the GNU-specific -i you're currently using. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Jul 27 14:35:13 2014 From: INVALID.NOREPLY at gnu.org (Ryan Schmidt) Date: Sun, 27 Jul 2014 12:35:13 +0000 Subject: [gnutls-devel] [sr #108614] Reinstate support for C89 In-Reply-To: <20140727-152108.sv707.62584@savannah.gnu.org> References: <20140714-062418.sv64386.1640@savannah.gnu.org> <20140727-152108.sv707.62584@savannah.gnu.org> Message-ID: <20140727-123513.sv64386.57035@savannah.gnu.org> Follow-up Comment #2, sr #108614 (project gnutls): The text version is available via the link "Original Format" at the bottom of the page, or directly at: https://trac.macports.org/raw-attachment/ticket/44323/patch-c89.diff _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Jul 27 14:39:23 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sun, 27 Jul 2014 12:39:23 +0000 Subject: [gnutls-devel] [sr #108615] Regenerating documentation fails when sed is BSD sed In-Reply-To: <20140727-123418.sv64386.82513@savannah.gnu.org> References: <20140714-064046.sv64386.31705@savannah.gnu.org> <20140727-152757.sv707.24675@savannah.gnu.org> <20140727-123418.sv64386.82513@savannah.gnu.org> Message-ID: <20140727-153923.sv707.17910@savannah.gnu.org> Follow-up Comment #3, sr #108615 (project gnutls): All uses of -i have filenames as argument. Do you mean rearranging the arguments so that the filenames come after -i? Would that address that issue? _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Jul 27 15:20:51 2014 From: INVALID.NOREPLY at gnu.org (Ryan Schmidt) Date: Sun, 27 Jul 2014 13:20:51 +0000 Subject: [gnutls-devel] [sr #108615] Regenerating documentation fails when sed is BSD sed In-Reply-To: <20140727-153923.sv707.17910@savannah.gnu.org> References: <20140714-064046.sv64386.31705@savannah.gnu.org> <20140727-152757.sv707.24675@savannah.gnu.org> <20140727-123418.sv64386.82513@savannah.gnu.org> <20140727-153923.sv707.17910@savannah.gnu.org> Message-ID: <20140727-132051.sv64386.61232@savannah.gnu.org> Follow-up Comment #4, sr #108615 (project gnutls): The argument to the -i flag is the suffix to use on the backup file. In GNU sed the argument is optional, and if not specified, no backup is made. In BSD sed the argument is mandatory, and if you don't want a backup, specify the empty string. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Sun Jul 27 15:21:11 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 27 Jul 2014 15:21:11 +0200 Subject: [gnutls-devel] RFC for gnutls 3.4 plan Message-ID: <1406467271.6968.12.camel@nomad.lan> Hello, My plan for gnutls 3.4 is listed below. I'd appreciate any comments/recommendations, as well as additions to the list especially if you volunteer to implement it. New Features: - Chacha cipher DTLS lacks a fast stream cipher, and TLS only specifies the broken RC4. My experiments with salsa20 (the predecessor of chacha) showed that there are indeed speed improvements and it would be nice to take advantage of them. - Chacha cipher + poly1305 MAC An AEAD combination of chacha with the poly1305 authenticator for performance in software implementations. A former variant of it is already being used by google's servers for communication between them and chrome. http://tools.ietf.org/html/draft-mavrogiannopoulos-chacha-tls-02 - Support for alternative to NIST elliptic curves (e.g., brainpool or curve25519). There is a lot of hype around the curves defined by NIST and although there are many exaggerations, having alternatives is a good thing. (I personally prefer brainpool but features depends mainly on what nettle will support) http://tools.ietf.org/html/draft-josefsson-tls-curve25519-05 http://tools.ietf.org/html/rfc7027 - Privilege separation for private key operations: During the development of openconnect vpn server, I've realized the need for separating private key operations for typical SSL operations. That resulted to a special security module that handles the private key operations of a less privileged worker process. That could be generalized so that more applications can use it. The advantage of such a design is that a bug on the TLS/ASN.1 parsing code would not leak the server's private key (thus counter heartbleed type of attacks). That part would be restricted to UNIX/POSIX systems so it may be released as a different library. - Support for Encrypt-then-authenticate mode: http://tools.ietf.org/html/draft-ietf-tls-encrypt-then-mac-02 That is becoming less and less relevant as GCM is becoming mainstream. - OCB mode (not decided on that as it seems quite of thankless work) OCB is very simple authenticated-encryption mode which performs much better than GCM in generic-purpose CPUs (e.g., without a special instruction for carry-less multiplication), and CCM (always). Its license to use is now quite liberal: http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm That requires both an internet draft to be written and its implementation in nettle. House keeping: - nettle 3.0 Unfortunately nettle 3.0 breaks the API and we need to convert to it in order to use the new features of it. That probably has to be combined with the chacha-poly1305 AEAD cipher inclusion. - Drop the unbound dependency in libdane That dependency requires a dependency either on openssl or nss and both are unacceptable. My current plan is to convert libdane to a non-validating dnssec library that depends on a validating server running on localhost - e.g., unbound or dnsmasq. Such library currently does not exist, but I've made a patch for c-ares at: https://github.com/bagder/c-ares/pull/16 regards, Nikos From INVALID.NOREPLY at gnu.org Sun Jul 27 15:23:48 2014 From: INVALID.NOREPLY at gnu.org (Ryan Schmidt) Date: Sun, 27 Jul 2014 13:23:48 +0000 Subject: [gnutls-devel] [sr #108615] Regenerating documentation fails when sed is BSD sed In-Reply-To: <20140727-132051.sv64386.61232@savannah.gnu.org> References: <20140714-064046.sv64386.31705@savannah.gnu.org> <20140727-152757.sv707.24675@savannah.gnu.org> <20140727-123418.sv64386.82513@savannah.gnu.org> <20140727-153923.sv707.17910@savannah.gnu.org> <20140727-132051.sv64386.61232@savannah.gnu.org> Message-ID: <20140727-132348.sv64386.18748@savannah.gnu.org> Follow-up Comment #5, sr #108615 (project gnutls): Doing some testing, I see that's not going to work. GNU sed requires no space between -i and the argument, while BSD sed requires a space if it's the empty string. A portable solution that does work with both seds is to just specify a backup suffix, e.g. "-i.bak" works. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Jul 30 15:14:03 2014 From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen) Date: Wed, 30 Jul 2014 13:14:03 +0000 Subject: [gnutls-devel] [sr #108623] gnutls for Windows port. Message-ID: <20140730-131401.sv79827.20795@savannah.gnu.org> URL: Summary: gnutls for Windows port. Project: GnuTLS Submitted by: cybear Submitted on: Wed 30 Jul 2014 01:14:01 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: The declaration of the gnutls memory function casuses problems. It is all the memory function but I will try and describe the problem with gnutls_free. gnutls_free is declared as follows: typedef void (*gnutls_free_function) (void *); extern gnutls_free_function gnutls_free; when cross-compiled and made to a windows .lib file _fnutls_free is not found in the library because the declaration misses a __declspec(dllimport). typedef void (*gnutls_free_function) (void *); extern __declspec(dllimport) gnutls_free_function gnutls_free; this is one solution but since the headers is platform independant right now, a better solution could be to convert the gnutls_free to a real function and have a placeholder for the gnutls_free_function_pointer that it could call. void gnutls_free(void *p) { (*gnutls_free_function_pointer)(p); } all the function calls in the gnutls library is ok since for functions the __declspec(dllimport) is implicit. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Jul 31 12:20:08 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Thu, 31 Jul 2014 10:20:08 +0000 Subject: [gnutls-devel] [sr #108623] gnutls for Windows port. In-Reply-To: <20140730-131401.sv79827.20795@savannah.gnu.org> References: <20140730-131401.sv79827.20795@savannah.gnu.org> Message-ID: <20140731-132008.sv707.28574@savannah.gnu.org> Follow-up Comment #1, sr #108623 (project gnutls): Unfortunately changing the symbol to a function would require an ABI bump. Would a patch like the following address your issue? https://gitorious.org/gnutls/gnutls/commit/8e4df216fee26e346a46817d4af64d85a21e40f6 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From BHC at insight.dk Thu Jul 31 16:33:23 2014 From: BHC at insight.dk (=?utf-8?B?QmrDuHJuIEguIENocmlzdGVuc2Vu?=) Date: Thu, 31 Jul 2014 14:33:23 +0000 Subject: [gnutls-devel] [sr #108623] gnutls for Windows port. In-Reply-To: <20140731-132008.sv707.28574@savannah.gnu.org> References: <20140730-131401.sv79827.20795@savannah.gnu.org> <20140731-132008.sv707.28574@savannah.gnu.org> Message-ID: Hello Nikos, Yes that would be equally good, I was not sure that you wanted to introduce platform dependencies into the header files. But with that change I am a happy bunny! Thanks for the quick response. /bhc -----Original Message----- From: Nikos Mavrogiannopoulos [mailto:INVALID.NOREPLY at gnu.org] Sent: 31. juli 2014 12:20 To: Nikos Mavrogiannopoulos; Bj?rn H. Christensen; bugs at gnutls.org Subject: [sr #108623] gnutls for Windows port. Follow-up Comment #1, sr #108623 (project gnutls): Unfortunately changing the symbol to a function would require an ABI bump. Would a patch like the following address your issue? https://gitorious.org/gnutls/gnutls/commit/8e4df216fee26e346a46817d4af64d85a21e40f6 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/