From lfinsto at gwdg.de Wed Aug 4 10:30:52 2010 From: lfinsto at gwdg.de (lfinsto at gwdg.de) Date: Wed, 4 Aug 2010 10:30:52 +0200 Subject: master branch --- build problems In-Reply-To: <1130a5387b787686d67649113caa3641.squirrel@mailbox.gwdg.de> References: <909753d2b8f354ee101f273d94eb900a.squirrel@mailbox.gwdg.de> <2ff6947a7fcd4d99174e3c160f72e2e1.squirrel@mailbox.gwdg.de> <87fwz13w75.fsf@mocca.josefsson.org> <1130a5387b787686d67649113caa3641.squirrel@mailbox.gwdg.de> Message-ID: <7b47983efd820d7bc9135f03a8497483.squirrel@mailbox.gwdg.de> On Fri, July 30, 2010 4:21 pm, lfinsto at gwdg.de wrote: > > On Fri, July 30, 2010 4:01 pm, Simon Josefsson wrote: >>> 2. configure must be called after `make bootstrap' because the latter >>> doesn't accept options. >> >> It does, you may supply them as 'make ADDFLAGS=--with-foo' or similar. >> Check at the top of cfg.mk for variable names and how they are used. > > Okay, thanks. make ADDFLAGS="--disable-valgrind-tests --with-libgcrypt-prefix=/home/lfinsto/libgcrypt-1.4.6 --prefix=/home/lfinsto/gnutls_dev/gnutls_master" bootstrap This works, except that it doesn't fix this error: init.c:36: error: 'GCRY_THREAD_OPTION_VERSION' undeclared here (not in a function) make[4]: *** [init.lo] Error 1 make[4]: Leaving directory `/home/lfinsto/gnutls_dev/gnutls_master/lib/gcrypt' As before: ln -s /home/lfinsto/libgcrypt-1.4.6/include/gcrypt.h /home/lfinsto/gnutls_dev/gnutls_master/lib/gcrypt/gcrypt.h New errors: Making all in reference make[4]: Entering directory `/home/lfinsto/gnutls_dev/gnutls_master/doc/reference' gtk-doc: Scanning header files gtk-doc: Rebuilding template files ERROR: ck_flags_t has multiple definitions: ./gnutls-decl.txt:1963 ERROR: ck_notification_t has multiple definitions: ./gnutls-decl.txt:1967 ERROR: ck_slot_id_t has multiple definitions: ./gnutls-decl.txt:1975 ERROR: ck_session_handle_t has multiple definitions: ./gnutls-decl.txt:2075 ERROR: ck_user_type_t has multiple definitions: ./gnutls-decl.txt:2083 ERROR: ck_state_t has multiple definitions: ./gnutls-decl.txt:2099 ERROR: ck_object_handle_t has multiple definitions: ./gnutls-decl.txt:2131 ERROR: ck_object_class_t has multiple definitions: ./gnutls-decl.txt:2135 ERROR: ck_hw_feature_type_t has multiple definitions: ./gnutls-decl.txt:2175 ERROR: ck_key_type_t has multiple definitions: ./gnutls-decl.txt:2195 ERROR: ck_certificate_type_t has multiple definitions: ./gnutls-decl.txt:2303 ERROR: ck_attribute_type_t has multiple definitions: ./gnutls-decl.txt:2323 ERROR: ck_mechanism_type_t has multiple definitions: ./gnutls-decl.txt:2667 ERROR: ck_rv_t has multiple definitions: ./gnutls-decl.txt:3527 ERROR: ck_notify_t has multiple definitions: ./gnutls-decl.txt:3533 ERROR: ck_function_list has multiple definitions: ./gnutls-decl.txt:3537 ERROR: ck_createmutex_t has multiple definitions: ./gnutls-decl.txt:3546 ERROR: ck_destroymutex_t has multiple definitions: ./gnutls-decl.txt:3551 ERROR: ck_lockmutex_t has multiple definitions: ./gnutls-decl.txt:3556 ERROR: ck_unlockmutex_t has multiple definitions: ./gnutls-decl.txt:3561 ###Can't parse args for function gcry_cipher_algo_name: int algorithm) _GCRY_GCC_ATTR_PURE;int gcry_cipher_map_name (const char *name) _GCRY_GCC_ATTR_PURE;int gcry_cipher_mode_from_oid (const char *string) _GCRY_GCC_ATTR_PURE;gcry_error_t gcry_cipher_encrypt (gcry_cipher_hd_t h,void *out, size_t outsize,const void *in, size_t inlen ###Can't parse args for function gcry_pk_algo_name: int algorithm) _GCRY_GCC_ATTR_PURE;int gcry_pk_map_name (const char* name) _GCRY_GCC_ATTR_PURE;unsigned int gcry_pk_get_nbits (gcry_sexp_t key) _GCRY_GCC_ATTR_PURE;unsigned char *gcry_pk_get_keygrip (gcry_sexp_t key, unsigned char *array ###Can't parse args for function gcry_md_algo_name: int algo) _GCRY_GCC_ATTR_PURE;int gcry_md_map_name (const char* name) _GCRY_GCC_ATTR_PURE;gcry_error_t gcry_md_setkey (gcry_md_hd_t hd, const void *key, size_t keylen Enum declaration 'typedef enum gcry_md_algos gcry_md_algo_t; typedef struct gcry_ac_emsa_pkcs_v1_5 { gcry_md_algo_t md; size_t em_n; } gcry_ac_emsa_pkcs_v1_5_t; ' does not begin with 'typedef enum {' or 'enum XXX {' make[4]: *** [tmpl-build.stamp] Error 9 make[4]: Leaving directory `/home/lfinsto/gnutls_dev/gnutls_master/doc/reference' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/lfinsto/gnutls_dev/gnutls_master/doc' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/lfinsto/gnutls_dev/gnutls_master/doc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/lfinsto/gnutls_dev/gnutls_master' make: *** [all] Error 2 I don't know what this is about. Does anyone have any hints? > >> >>> 3. Files installed by libtoolize are not readable by the user (?!). >> >> This seems weird, and could be a problem with your libtool installation. >> Maybe you can debug it? > > I'll try. The permissions are correct in the directory from which libtoolize copies them. I haven't found anything obvious that would explain the problem. I think I'll have to write to the bug-libtool mailing list. Laurence ------------------------------------------------------------- Laurence Finston Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH Am Fassberg 11 37077 Goettingen Telefon: +49 551 201-1882 E-Mail: lfinsto at gwdg.de From nmav at gnutls.org Wed Aug 4 18:43:49 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 4 Aug 2010 19:43:49 +0300 Subject: Example for /doc/examples/ using Flex and Bison In-Reply-To: References: Message-ID: On Fri, Jul 30, 2010 at 5:24 PM, wrote: > Hello, > This may or not be of interest to you, but I thought I'd send it in case > it is. > The application I've written for my job uses a server and client that > communicate using two scanner/parser pairs, one for each peer. ?They are > written using Flex and GNU Bison. ?It is slightly tricky getting this to > work and the actual application is already fairly complicated, so I wanted > to make a simple example, while it's fresh in my mind. ?I think it would > be most useful if it was included in the GNUTLS package, where people > would find it. Hi Laurence, I'm on holidays and haven't checked the code, but my question would be why would this be good as an example? The examples included in gnutls have to be pretty simple, so developers can understand the usage of the underlying gnutls functions. For example in most of the examples we hide out the TCP/IP functions, for simplicity. Having a parser as an example would be confusing to people who don't know bison/flex and I don't know what the benefit would be to people who know how to use them. (this written without having seen the actual code) regards, Nikos From hilberg at kernelconcepts.de Thu Aug 5 12:32:59 2010 From: hilberg at kernelconcepts.de (Christian Hilberg) Date: Thu, 5 Aug 2010 12:32:59 +0200 Subject: gnutls 2.11.0 released In-Reply-To: <4C488421.5000605@gnutls.org> References: <4C488421.5000605@gnutls.org> Message-ID: <201008051233.07006.hilberg@kernelconcepts.de> Hi everyone. Nice to see a GnuTLS release (though dev version) which has PKCS#11 support: On Thursday 22 Juli 2010 Nikos Mavrogiannopoulos wrote: > [...] > This is major update release that includes features such as PKCS #11 > support for cryptographic objects, support for local system thread > locks, new message buffering layer, support for nettle library and more. > [...] > * Version 2.11.0 (released 2010-07-22) > [...] > ** libgnutls: Added PKCS #11 support and an API to access objects in > gnutls/pkcs11.h. Currently certificates and public keys can be > imported from tokens, and operations can be performed on private keys. > [...more pkcs #11 additions...] I'm interested in getting to know whether you see this version of GnuTLS fit for accessing client certificates residing in a TPM module (token). We have a setup with openCryptoki and Trousers and we can access the TPM token via openCryptoki's pkcsslotd using the NSS library. Is the same possible with the current GnuTLS development release as well? NB: Since some parts of the software we're working with currently use NSS, we are most probably unable to switch to a different software stack (different from openCryptoki and Trousers, that is). Will this be a problem or GnuTLS make use of the same software stack? Will we be able to use NSS and GnuTLS at the same time for accessing the same token? Best regards, all input on the issue will be happily accepted. Christian -- kernel concepts GbR Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 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 hilberg at kernelconcepts.de Thu Aug 5 11:25:22 2010 From: hilberg at kernelconcepts.de (Christian Hilberg) Date: Thu, 5 Aug 2010 11:25:22 +0200 Subject: Broken Links on http://www.gnu.org/software/gnutls/lists.html Message-ID: <201008051125.29194.hilberg@kernelconcepts.de> Hi, I just found via http://www.gnu.org/software/gnutls/lists.html that the following links are broken (error: not found): http://mail.gnu.org/mailman/listinfo/help-gnutls http://mail.gnu.org/mailman/listinfo/gnutls-devel The following link (on that same page) works, however: http://lists.gnu.org/mailman/listinfo/gnutls-commit (I'm getting the mailman list info page there, as expected). Best regards, Christian -- kernel concepts GbR Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 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 lfinsto at gwdg.de Thu Aug 5 09:12:17 2010 From: lfinsto at gwdg.de (lfinsto at gwdg.de) Date: Thu, 5 Aug 2010 09:12:17 +0200 Subject: Example for /doc/examples/ using Flex and Bison In-Reply-To: References: Message-ID: <6b588e0a975cd1fdf21874bfcf68e0d2.squirrel@mailbox.gwdg.de> On Wed, August 4, 2010 6:43 pm, Nikos Mavrogiannopoulos wrote: > On Fri, Jul 30, 2010 at 5:24 PM, wrote: >> Hello, >> This may or not be of interest to you, but I thought I'd send it in case >> it is. >> The application I've written for my job uses a server and client that >> communicate using two scanner/parser pairs, one for each peer. ??They >> are >> written using Flex and GNU Bison. ??It is slightly tricky getting this >> to >> work and the actual application is already fairly complicated, so I >> wanted >> to make a simple example, while it's fresh in my mind. ??I think it >> would >> be most useful if it was included in the GNUTLS package, where people >> would find it. > > Hi Laurence, > I'm on holidays and haven't checked the code, but my question would > be why would this be good as an example? The examples included in > gnutls have to be pretty simple, so developers can understand the > usage of the underlying gnutls functions. For example in most of the > examples we hide out the TCP/IP functions, for simplicity. Having a > parser as an example would be confusing to people who don't know > bison/flex and I don't know what the benefit would be to people who > know how to use them. (this written without having seen the actual > code) It's up to you and Simon, of course. My idea is that it would be a simple, realistic example that shows how communication between a server and client could be implemented. The existing examples are good for demonstrating how to use GNUTLS, but (unless I've missed something) don't address the issue of how a server and client are supposed to communicate with each other on a higher level, i.e., how to implement a "protocol". It seems to me that using Flex and Bison would be one of the most practical ways of implementing this communication. >From the Bison mailing list, I know that it's not clear to many people how to generate a reentrant parser, pass a parameter to yylex and yyparse, use multiple parsers in a single project, etc. Having gotten these sorts of things to work, it seems to me that it would be useful to have a simple example of it somewhere. It was just an idea and it's not a problem for me if you and/or Simon don't think it would be worth pursuing. Laurence > > regards, > Nikos > ------------------------------------------------------------- Laurence Finston Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH Am Fassberg 11 37077 Goettingen Telefon: +49 551 201-1882 E-Mail: lfinsto at gwdg.de From nmav at gnutls.org Thu Aug 5 21:09:30 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 5 Aug 2010 21:09:30 +0200 Subject: gnutls 2.11.0 released In-Reply-To: <201008051233.07006.hilberg@kernelconcepts.de> References: <4C488421.5000605@gnutls.org> <201008051233.07006.hilberg@kernelconcepts.de> Message-ID: On Thu, Aug 5, 2010 at 12:32 PM, Christian Hilberg >> [...] >> This is major update release that includes features such as PKCS #11 >> support for cryptographic objects, support for local system thread >> locks, new message buffering layer, support for nettle library and more. >> [...] >> * Version 2.11.0 (released 2010-07-22) >> [...] >> ** libgnutls: Added PKCS #11 support and an API to access objects in >> gnutls/pkcs11.h. Currently certificates and public keys can be >> imported from tokens, and operations can be performed on private keys. >> [...more pkcs #11 additions...] > > I'm interested in getting to know whether you see this version of GnuTLS fit > for accessing client certificates residing in a TPM module (token). > > We have a setup with openCryptoki and Trousers and we can access the TPM token > via openCryptoki's pkcsslotd using the NSS library. Is the same possible with > the current GnuTLS development release as well? I've never tried the pkcsslotd but if it provides a pkcs11 module, then it should work. Check the gnutls.pdf from the development for more details on pkcs11. The certtool program will provide a quick test on whether the pkcs11 library can be used. regards, Nikos From hilberg at kernelconcepts.de Fri Aug 6 09:34:36 2010 From: hilberg at kernelconcepts.de (Christian Hilberg) Date: Fri, 6 Aug 2010 09:34:36 +0200 Subject: gnutls 2.11.0 released In-Reply-To: References: <4C488421.5000605@gnutls.org> <201008051233.07006.hilberg@kernelconcepts.de> Message-ID: <201008060934.44638.hilberg@kernelconcepts.de> Hi Nikos, tanks for the hints. On Thursday 05 August 2010 Nikos Mavrogiannopoulos wrote: > On Thu, Aug 5, 2010 at 12:32 PM, Christian Hilberg > > >> [...] > >> This is major update release that includes features such as PKCS #11 > >> support for cryptographic objects, support for local system thread > >> locks, new message buffering layer, support for nettle library and more. > >> [...] > >> * Version 2.11.0 (released 2010-07-22) > >> [...] > >> ** libgnutls: Added PKCS #11 support and an API to access objects in > >> gnutls/pkcs11.h. Currently certificates and public keys can be > >> imported from tokens, and operations can be performed on private keys. > >> [...more pkcs #11 additions...] > > > > I'm interested in getting to know whether you see this version of GnuTLS > > fit for accessing client certificates residing in a TPM module (token). > > > > We have a setup with openCryptoki and Trousers and we can access the TPM > > token via openCryptoki's pkcsslotd using the NSS library. Is the same > > possible with the current GnuTLS development release as well? > > I've never tried the pkcsslotd but if it provides a pkcs11 module, > then it should work. Check the gnutls.pdf from the development for > more details on pkcs11. The certtool program will provide a quick test > on whether the pkcs11 library can be used. pkcsslotd has a PKCS #11 module, which is what NSS uses to talk to the daemon. We wil give it a try and report back. However, libsoup (which is the HPPT client lib we are evaluating) cannot handle client certificates, so GnuTLS' capabilities might not help us much here (unless GnuTLS would handle client certs automatically, if the server asks for one). Thanks and best regards, Christian -- kernel concepts GbR Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 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 INVALID.NOREPLY at gnu.org Fri Aug 6 22:49:33 2010 From: INVALID.NOREPLY at gnu.org (anonymous) Date: Fri, 06 Aug 2010 20:49:33 +0000 Subject: [sr #107449] selftest sh-script fails on non-bash Message-ID: <20100806-204933.sv0.95708@savannah.gnu.org> URL: Summary: selftest sh-script fails on non-bash Project: GnuTLS Submitted by: None Submitted on: Fri 06 Aug 2010 08:49:33 PM UTC Category: None Priority: 5 - Normal Severity: 2 - Minor Status: None Privacy: Public Assigned to: None Originator Email: m.drochner at fz-juelich.de Open/Closed: Open Discussion Lock: Any Operating System: *BSD _______________________________________________________ Details: tests/openpgp-certs/testselfsigs sets "set -e" but later does: unset RETCODE This happens to work with bash because "unset" doesn't give an error there if the variable wasn't defined before. A regular/Posix sh gives a non-zero return code here, stopping the script in its tracks due to the "-e". See http://www.opengroup.org/onlinepubs/000095399/utilities/unset.html for reference. The wording is somewhat poor because it says "Unsetting a variable or function that was not previously set shall not be considered an error and does not cause the shell to abort". It is not about aborting in the common case but about the exit code; the aborting would only due to the "-e". Anyway, the sh and ksh implementations I found give a non-zero return code in this situation. Replacing the offending line with unset RETCODE || true fixes the issue. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From tzz at lifelogs.com Sun Aug 8 06:20:29 2010 From: tzz at lifelogs.com (Ted Zlatanov) Date: Sat, 07 Aug 2010 23:20:29 -0500 Subject: need help adding GnuTLS support to Emacs Message-ID: <87bp9dhh0y.fsf@lifelogs.com> I started with http://josefsson.org/securemacs/emacs-21-ssl-4.patch ending with the attached patch (against the latest Bazaar update of Emacs). It's pretty hard for me to know if my changes are sensible because my GnuTLS knowledge is very limited. So far I have the configure.in and Makefile.in changes working (I had to directly add '-I/usr/include/gnutls' on my Ubuntu system because pkg-config didn't have the correct cflags). I use PKG_CHECK_MODULES and ask for GnuTLS 2.2.4 or newer (assuming the earliest version on the FTP site as of today is acceptable). The process.c changes are definitely wrong because the following functions are missing: process.c:7141: warning: implicit declaration of function ?gnutls_x509pki_set_client_key_file? process.c:7174: warning: implicit declaration of function ?gnutls_x509pki_set_client_trust_file? process.c:7233: warning: implicit declaration of function ?gnutls_anon_set_client_dh_params? process.c:7271: warning: implicit declaration of function ?gnutls_crd_allocate_client_credentials? and they may be incorrect in these places: process.c:7348: warning: passing argument 2 of ?gnutls_transport_set_ptr? makes pointer from integer without a cast /usr/include/gnutls/gnutls.h:894: note: expected ?gnutls_transport_ptr_t? but argument is of type ?int? process.c:7381: warning: passing argument 2 of ?gnutls_transport_set_ptr? makes pointer from integer without a cast /usr/include/gnutls/gnutls.h:894: note: expected ?gnutls_transport_ptr_t? but argument is of type ?int? I changed many of the type names in the patch according to my understanding of gnutls.h. It's very possible I made mistakes along the way. I would appreciate it if someone experienced with GnuTLS took the time to review the patch. At this point the changes are all in the source code and should not involve touching the Emacs internals. I think, outside of the problems noted above, that I followed the original patch closely, but it's been many years since it was written so there may be overarching design issues with it as well. Thanks for your help Ted -------------- next part -------------- A non-text attachment was scrubbed... Name: tls.patch Type: text/x-diff Size: 24812 bytes Desc: not available URL: From nmav at gnutls.org Sun Aug 8 23:28:37 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 9 Aug 2010 00:28:37 +0300 Subject: [2.10.1] segfault at gnutls_record.c:58 In-Reply-To: References: Message-ID: A bug report is only helpful if it can be reproduced. A segfault can be anything related to memory corruption that could occur by any unrelated code. Please specify a way to reproduce it. On Sat, Aug 7, 2010 at 10:05 PM, Yclept Nemo wrote: > More information, not very helpful I'm afraid: > http://pastebin.com/qJMm2XyY > basically > gdb > set logging on > attach ... > directory ... > b gnutls_record.c:59 > c > ... > c 10 > ... > while 1==1 >> step >> end > > _______________________________________________ > Help-gnutls mailing list > Help-gnutls at gnu.org > http://lists.gnu.org/mailman/listinfo/help-gnutls > From ametzler at downhill.at.eu.org Mon Aug 9 08:51:27 2010 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Mon, 9 Aug 2010 08:51:27 +0200 Subject: need help adding GnuTLS support to Emacs In-Reply-To: <87bp9dhh0y.fsf@lifelogs.com> References: <87bp9dhh0y.fsf@lifelogs.com> Message-ID: <20100809065126.GA2684@seumegasse.bebt.de> On 2010-08-08 Ted Zlatanov wrote: [...] > === modified file 'configure.in' > --- configure.in 2010-08-06 11:28:59 +0000 > +++ configure.in 2010-08-08 03:17:07 +0000 > @@ -169,6 +169,7 @@ > OPTION_DEFAULT_ON([dbus],[don't compile with D-Bus support]) > OPTION_DEFAULT_ON([gconf],[don't compile with GConf support]) > OPTION_DEFAULT_ON([selinux],[don't compile with SELinux support]) > +OPTION_DEFAULT_ON([gnutls],[don't use -lgnutls for SSL/TLS support]) > ## For the times when you want to build Emacs but don't have > ## a suitable makeinfo, and can live without the manuals. > @@ -1986,6 +1987,14 @@ > fi > AC_SUBST(LIBSELINUX_LIBS) > +HAVE_GNUTLS=no > +if test "x$no_libgnutls" = x ; then > + PKG_CHECK_MODULES([LIBGNUTLS], [gnutls >= 2.2.4]) > + # the following is necessary because on my Ubuntu 10.04 system, "pkg-config --cflags gnutls" doesn't return /usr/include/gnutls as it should > + LIBGNUTLS_CFLAGS=-I/usr/include/gnutls [...] I am pretty sure this wrong. You should simply use "#include " instead of "#include ". That is what gnutls/doc/examples/* is doing. cu andreas -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash" From orbisvicis at gmail.com Sat Aug 7 20:18:24 2010 From: orbisvicis at gmail.com (Yclept Nemo) Date: Sat, 7 Aug 2010 14:18:24 -0400 Subject: [2.10.1] segfault at gnutls_record.c:58 Message-ID: Hi, Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb744f710 (LWP 23279)] gnutls_protocol_get_version (session=0x8ba9b00) at gnutls_record.c:58 58 gnutls_record.c: No such file or directory. in gnutls_record.c (gdb) bt #0 gnutls_protocol_get_version (session=0x8ba9b00) at gnutls_record.c:58 #1 0x08074b0b in ap_run_fixups () #2 0x08089f90 in ap_process_request () #3 0x080872ab in ?? () #4 0x08080b29 in ap_run_process_connection () #5 0x0808e3c9 in ?? () #6 0x0808e707 in ?? () #7 0x0808e7c4 in ?? () #8 0x0808f24b in ap_mpm_run () #9 0x08066dd5 in main () (gdb) Does this directly concern GnuTLS? I'm using it in tandem with mod_gnutls 0.5.7/apache. I wish I could get more in-depth backtrace, but every time I step into gnutls_protocol_get_version gdb reports a broken pipe. From the apache errorfile: [Sat Aug 07 13:57:00 2010] [error] [client 74.105.42.220] GnuTLS: Handshake Failed (-8) 'A record packet with illegal version was received.' [Sat Aug 07 13:57:00 2010] [error] [client 74.105.42.220] GnuTLS: Handshake Failed (-8) 'A record packet with illegal version was received.' [Sat Aug 07 13:57:00 2010] [error] [client 74.105.42.220] GnuTLS: Handshake Failed (-8) 'A record packet with illegal version was received.' [Sat Aug 07 13:57:01 2010] [error] [client 74.105.42.220] GnuTLS: Handshake Failed (-8) 'A record packet with illegal version was received.' [Sat Aug 07 13:57:01 2010] [error] [client 74.105.42.220] GnuTLS: Handshake Failed (-8) 'A record packet with illegal version was received.' [Sat Aug 07 13:57:01 2010] [notice] child pid 22594 exit signal Segmentation fault (11) I'm assuming this is pertinent, since older versions had the same error minus the segfault. If I set a breakpoint at gnutls_record.c:59, it enters into gnutls_protocol_get_version a few times before crashing. Sincerely, From orbisvicis at gmail.com Sat Aug 7 21:05:56 2010 From: orbisvicis at gmail.com (Yclept Nemo) Date: Sat, 7 Aug 2010 15:05:56 -0400 Subject: [2.10.1] segfault at gnutls_record.c:58 In-Reply-To: References: Message-ID: More information, not very helpful I'm afraid: http://pastebin.com/qJMm2XyY basically gdb set logging on attach ... directory ... b gnutls_record.c:59 c ... c 10 ... while 1==1 > step > end From bradh at frogmouth.net Tue Aug 10 08:30:44 2010 From: bradh at frogmouth.net (Brad Hards) Date: Tue, 10 Aug 2010 16:30:44 +1000 Subject: RFC - support for subjectUniqueID and issuerUniqueID Message-ID: <201008101630.44915.bradh@frogmouth.net> Hi, During investigation into some windows protocols, we've found that windows servers create certificates that make use of the subjectUniqueID and issuerUniqueID fields. They seem to contain GUID values. The attached patch (which I'm looking for feedback on, not to be applied at this stage) allows fetching / display of those fields. I have a second patch for setting / writing those fields, but I haven't tested it yet. A sample certificate is also attached. I recognise that they aren't normally used (and are deprecated), but for interop purposes, I'd like to be able to access them if necessary. Thoughts and comments? Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-support-for-issuerUniqueID-and-subjectUniqueID.patch Type: text/x-patch Size: 4817 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: cert Type: application/octet-stream Size: 772 bytes Desc: not available URL: From simon at josefsson.org Tue Aug 10 09:43:41 2010 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 10 Aug 2010 09:43:41 +0200 Subject: Broken Links on http://www.gnu.org/software/gnutls/lists.html In-Reply-To: <201008051125.29194.hilberg@kernelconcepts.de> (Christian Hilberg's message of "Thu, 5 Aug 2010 11:25:22 +0200") References: <201008051125.29194.hilberg@kernelconcepts.de> Message-ID: <87d3tq52vm.fsf@mocca.josefsson.org> Christian Hilberg writes: > Hi, > > I just found via > > http://www.gnu.org/software/gnutls/lists.html > > that the following links are broken (error: not found): > > http://mail.gnu.org/mailman/listinfo/help-gnutls > http://mail.gnu.org/mailman/listinfo/gnutls-devel > > The following link (on that same page) works, however: > > http://lists.gnu.org/mailman/listinfo/gnutls-commit Thank you! Should be fixed now. /Simon From hilberg at kernelconcepts.de Tue Aug 10 14:25:02 2010 From: hilberg at kernelconcepts.de (Christian Hilberg) Date: Tue, 10 Aug 2010 14:25:02 +0200 Subject: Broken Links on http://www.gnu.org/software/gnutls/lists.html In-Reply-To: <87d3tq52vm.fsf@mocca.josefsson.org> References: <201008051125.29194.hilberg@kernelconcepts.de> <87d3tq52vm.fsf@mocca.josefsson.org> Message-ID: <201008101425.09490.hilberg@kernelconcepts.de> Hi, On Tuesday 10 August 2010 Simon Josefsson wrote: > Christian Hilberg writes: > > Hi, > > I just found via > > http://www.gnu.org/software/gnutls/lists.html > > that the following links are broken (error: not found): > > http://mail.gnu.org/mailman/listinfo/help-gnutls > > http://mail.gnu.org/mailman/listinfo/gnutls-devel > [...] > Thank you! Should be fixed now. Looks good from here. Thanks! (Bye)^2, Christian -- kernel concepts GbR Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 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 simon at josefsson.org Wed Aug 11 13:31:58 2010 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 11 Aug 2010 13:31:58 +0200 Subject: RFC - support for subjectUniqueID and issuerUniqueID In-Reply-To: <201008101630.44915.bradh@frogmouth.net> (Brad Hards's message of "Tue, 10 Aug 2010 16:30:44 +1000") References: <201008101630.44915.bradh@frogmouth.net> Message-ID: <87y6cdz8pd.fsf@mocca.josefsson.org> Brad Hards writes: > Hi, > > During investigation into some windows protocols, we've found that windows > servers create certificates that make use of the subjectUniqueID and > issuerUniqueID fields. They seem to contain GUID values. > > The attached patch (which I'm looking for feedback on, not to be applied at > this stage) allows fetching / display of those fields. I have a second patch > for setting / writing those fields, but I haven't tested it yet. A sample > certificate is also attached. > > I recognise that they aren't normally used (and are deprecated), but for > interop purposes, I'd like to be able to access them if necessary. > > Thoughts and comments? Generally, I think we should have an API to extract arbitrary extensions instead of adding new APIs for each and every strange extension. I think we already have these APIs though? I don't see any extensions in your certificate though? So I'm not sure exactly what fields you are talking about. /Simon jas at mocca:~$ dumpasn1 cert 0 768: SEQUENCE { 4 492: SEQUENCE { 8 3: [0] { 10 1: INTEGER 2 : } 13 16: INTEGER BD 76 DF 42 47 0A 00 8D 47 3E 74 3F A1 DC 8B BD : Error: Integer has a negative value. 31 9: SEQUENCE { 33 5: OBJECT IDENTIFIER sha-1WithRSAEncryption (1 3 14 3 2 29) 40 0: NULL : } 42 45: SEQUENCE { 44 43: SET { 46 41: SEQUENCE { 48 3: OBJECT IDENTIFIER commonName (2 5 4 3) 53 34: PrintableString 'w.2.k.8.r.2...m.a.t.w.s...n.e.t...' : Error: PrintableString contains illegal character(s). : } : } : } 89 30: SEQUENCE { 91 13: UTCTime 28/04/2010 11:41:54 GMT 106 13: UTCTime 28/04/2011 11:41:54 GMT : } 121 45: SEQUENCE { 123 43: SET { 125 41: SEQUENCE { 127 3: OBJECT IDENTIFIER commonName (2 5 4 3) 132 34: PrintableString 'w.2.k.8.r.2...m.a.t.w.s...n.e.t...' : Error: PrintableString contains illegal character(s). : } : } : } 168 290: SEQUENCE { 172 13: SEQUENCE { 174 9: OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1) 185 0: NULL : } 187 271: BIT STRING, encapsulates { 192 266: SEQUENCE { 196 257: INTEGER : 00 AA D7 32 26 D7 FC 69 57 4A 55 08 2B 97 C1 5B : 90 FD E8 F5 F7 9E 7D 34 CE E9 BB 38 A0 9F EC 84 : 86 3E 47 2E 71 D7 C3 BF 89 F3 80 B5 77 80 D3 B0 : 56 6B 9C F4 D3 42 2B 26 01 5C 42 EF F6 51 5A AA : 55 6B 30 D3 2C DC DE 36 4D DD F3 5F 59 BA 57 D8 : 39 0F 5B D3 E1 34 39 22 AA 71 10 59 7A EC 9F 1A : F5 A9 40 D6 7B 32 5F 19 85 C0 FD A6 6C 32 58 DC : 7C 07 42 36 D0 57 78 63 60 92 1D 1F 9D BD CC D7 : [ Another 129 bytes skipped ] 457 3: INTEGER 65537 : } : } : } 462 17: [1] 00 BD 8B DC A1 3F 74 3E 47 8D 00 0A 47 42 DF 76 BD 481 17: [2] 00 BD 8B DC A1 3F 74 3E 47 8D 00 0A 47 42 DF 76 BD : } 500 9: SEQUENCE { 502 5: OBJECT IDENTIFIER sha-1WithRSAEncryption (1 3 14 3 2 29) 509 0: NULL : } 511 257: BIT STRING : A7 B0 66 75 14 7E 7D B5 31 EC B2 EB 90 80 95 25 : 59 0F E4 15 86 2D 9D D7 35 E9 22 74 E7 85 36 19 : 4F 27 5C 17 63 7B 2A FE 59 E9 76 77 D0 C9 40 78 : 7C 31 62 1E 87 1B C1 19 EF 6F 15 E6 CE 74 84 6D : D6 3B 57 D9 A9 13 F6 7D 84 E7 8F C6 01 5F CF C4 : 95 C9 DE 97 17 43 12 70 27 F9 C4 D7 E1 05 BB 63 : 87 5F DC 20 BD D1 DE D6 2D 9F 3F 5D 0A 27 40 11 : 5F 5D 54 A7 28 F9 03 2E 84 8D 48 60 A1 71 A3 46 : [ Another 128 bytes skipped ] : } 0 warnings, 3 errors. jas at mocca:~$ From bradh at frogmouth.net Wed Aug 11 13:56:25 2010 From: bradh at frogmouth.net (Brad Hards) Date: Wed, 11 Aug 2010 21:56:25 +1000 Subject: RFC - support for subjectUniqueID and issuerUniqueID In-Reply-To: <87y6cdz8pd.fsf@mocca.josefsson.org> References: <201008101630.44915.bradh@frogmouth.net> <87y6cdz8pd.fsf@mocca.josefsson.org> Message-ID: <201008112156.26724.bradh@frogmouth.net> On Wednesday, August 11, 2010 09:31:58 pm Simon Josefsson wrote: > Generally, I think we should have an API to extract arbitrary extensions > instead of adding new APIs for each and every strange extension. I > think we already have these APIs though? I agree. > I don't see any extensions in your certificate though? So I'm not sure > exactly what fields you are talking about. These fields aren't an extension. From RFC 3280 (or 5280): TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3 extensions [3] EXPLICIT Extensions OPTIONAL -- If present, version MUST be v3 } > jas at mocca:~$ dumpasn1 cert > 13 16: INTEGER BD 76 DF 42 47 0A 00 8D 47 3E 74 3F A1 DC 8B BD This is one of them (I can't tell which, since they're the same for this cert). UniqueIdentifier is a BIT STRING. Brad From simon at josefsson.org Wed Aug 11 14:01:47 2010 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 11 Aug 2010 14:01:47 +0200 Subject: RFC - support for subjectUniqueID and issuerUniqueID In-Reply-To: <201008112156.26724.bradh@frogmouth.net> (Brad Hards's message of "Wed, 11 Aug 2010 21:56:25 +1000") References: <201008101630.44915.bradh@frogmouth.net> <87y6cdz8pd.fsf@mocca.josefsson.org> <201008112156.26724.bradh@frogmouth.net> Message-ID: <87zkwtxsr8.fsf@mocca.josefsson.org> Brad Hards writes: > On Wednesday, August 11, 2010 09:31:58 pm Simon Josefsson wrote: >> Generally, I think we should have an API to extract arbitrary extensions >> instead of adding new APIs for each and every strange extension. I >> think we already have these APIs though? > I agree. > >> I don't see any extensions in your certificate though? So I'm not sure >> exactly what fields you are talking about. > These fields aren't an extension. From RFC 3280 (or 5280): > TBSCertificate ::= SEQUENCE { > version [0] EXPLICIT Version DEFAULT v1, > serialNumber CertificateSerialNumber, > signature AlgorithmIdentifier, > issuer Name, > validity Validity, > subject Name, > subjectPublicKeyInfo SubjectPublicKeyInfo, > issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, > -- If present, version MUST be v2 or v3 > subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, > -- If present, version MUST be v2 or v3 > extensions [3] EXPLICIT Extensions OPTIONAL > -- If present, version MUST be v3 > } > >> jas at mocca:~$ dumpasn1 cert >> 13 16: INTEGER BD 76 DF 42 47 0A 00 8D 47 3E 74 3F A1 DC 8B BD > This is one of them (I can't tell which, since they're the same for this > cert). UniqueIdentifier is a BIT STRING. Ah, thanks. Then I believe we should have native APIs for it, since the fields are so tied in with the core format. /Simon From sjoerd.simons at collabora.co.uk Wed Aug 11 15:49:08 2010 From: sjoerd.simons at collabora.co.uk (Sjoerd Simons) Date: Wed, 11 Aug 2010 14:49:08 +0100 Subject: [patch] Fix various bugs when using the gnutls async API Message-ID: <1281534548.12716.38.camel@night> Hi, Our XMPP library (wocky) uses gnutls in a quite heavily async way, which unfortunately seems to have triggered some bugs in the lastest versions :/. Some patches for git HEAD attached, which seems to fix things nicely for me. Some extra comments for some of the patches: * 0002-Check-whether-the-error-is-fatal-in-more-cases.patch I don't know the code well enough, but i'm not sure why the handshake hash buffers are cleared on non-fatal errors in some cases. I went for the more conservative approach here and just change that around when it caused things to break for me... * 0003-Remember-the-amount-of-user-data-we-re-sending-out.patch I guess It could be argued that this information should be stored inside the record_send_buffer instead of in the session internal struct directly. I'm happy to change the patch around to do just that :) -- Sjoerd Simons Collabora Ltd. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-state-for-flushing-the-handshake-buffer.patch Type: text/x-patch Size: 2096 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Check-whether-the-error-is-fatal-in-more-cases.patch Type: text/x-patch Size: 2862 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Remember-the-amount-of-user-data-we-re-sending-out.patch Type: text/x-patch Size: 2004 bytes Desc: not available URL: From tzz at lifelogs.com Fri Aug 13 00:52:08 2010 From: tzz at lifelogs.com (Ted Zlatanov) Date: Thu, 12 Aug 2010 17:52:08 -0500 Subject: need help adding GnuTLS support to Emacs References: <87bp9dhh0y.fsf@lifelogs.com> <20100809065126.GA2684@seumegasse.bebt.de> Message-ID: <871va3h2av.fsf@lifelogs.com> On Mon, 9 Aug 2010 08:51:27 +0200 Andreas Metzler wrote: AM> I am pretty sure this wrong. You should simply use "#include AM> " instead of "#include ". That is what AM> gnutls/doc/examples/* is doing. Thanks for your advice. Attached is a revised version of the patch, rebased against today's Emacs. I would appreciate it if you or anyone else could answer my other questions regarding the design issues and what are the specific client functions I should be using. Thanks Ted -------------- next part -------------- A non-text attachment was scrubbed... Name: tls.patch Type: text/x-diff Size: 24375 bytes Desc: not available URL: From orbisvicis at gmail.com Fri Aug 13 08:23:52 2010 From: orbisvicis at gmail.com (Yclept Nemo) Date: Fri, 13 Aug 2010 02:23:52 -0400 Subject: [2.10.1] segfault at gnutls_record.c:58 In-Reply-To: References: Message-ID: meh, how gmail handles mailing list replies is troubling. To the correct recipients: On Fri, Aug 13, 2010 at 2:21 AM, Yclept Nemo wrote: > It is with: > mod_gnutls-0.5.7 or mod_gnutls-0.5.5 > GnuTLSPriorities > NONE:+CAMELLIA-256-CBC:+AES-256-CBC:+DHE-RSA:+SHA1:+COMP-NULL:+COMP-DEFLATE:+VERS-TLS1.1:+VERS-SSL3.0 > gnutls-2.10.1 > httpd: Server version: Apache/2.2.8 (Ubuntu) > firefox 3.6.8 > > There is no segfault if "GnuTLSPriorities SECURE256" or if I downgrade > to an older version of gnutls (can't quite remember which release, but > probably 2.9.3or9). I can't really comment on usage of > mod_gnutls-0.5.7 because I experience another bug that also affects > versions >0.5.5 http://issues.outoforder.cc/view.php?id=106 > From simon at josefsson.org Sat Aug 14 01:53:02 2010 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 14 Aug 2010 01:53:02 +0200 Subject: need help adding GnuTLS support to Emacs In-Reply-To: <871va3h2av.fsf@lifelogs.com> (Ted Zlatanov's message of "Thu, 12 Aug 2010 17:52:08 -0500") References: <87bp9dhh0y.fsf@lifelogs.com> <20100809065126.GA2684@seumegasse.bebt.de> <871va3h2av.fsf@lifelogs.com> Message-ID: <87ocd6ul29.fsf@mocca.josefsson.org> Ted Zlatanov writes: > On Mon, 9 Aug 2010 08:51:27 +0200 Andreas Metzler wrote: > > AM> I am pretty sure this wrong. You should simply use "#include > AM> " instead of "#include ". That is what > AM> gnutls/doc/examples/* is doing. > > Thanks for your advice. Attached is a revised version of the patch, > rebased against today's Emacs. Nice work! It reminds me of the fun I had with similar ideas some time ago... see http://josefsson.org/securemacs/ > +DEFUN ("gnutls-global-init", Fgnutls_global_init, Do you really want to expose this function to elisp? It is thread-unsafe. It makes more sense if Emacs initialized the GnuTLS library on startup instead. > +DEFUN ("gnutls-protocol-set-priority", Fgnutls_protocol_set_priority, ... > +DEFUN ("gnutls-cipher-set-priority", Fgnutls_cipher_set_priority, ... > +DEFUN ("gnutls-compression-set-priority", Fgnutls_compression_set_priority, ... Don't expose these deprecated APIs, instead just expose a gnutls-set-priority interface that takes a priority string. It should be possible to specify all protocol/cipher/compression/MAC/etc variants using one simple string. Thanks, /Simon From carlo.bramix at libero.it Fri Aug 13 19:53:47 2010 From: carlo.bramix at libero.it (carlo.bramix at libero.it) Date: Fri, 13 Aug 2010 19:53:47 +0200 (CEST) Subject: GnuTls: Fixed compilation of gnutlsxx Message-ID: <12207214.1437921281722027161.JavaMail.root@wmail50> Hello, I tried to compile GnuTls in Mingw+Msys and I got an error because gnutls/gnutls.h was not found with gnutlsxx.c After a quick check I discovered that there was a mistake into lib/Makefile.am because there was a wrong hardcoded path to includes into libgnutlsxx_la_CPPFLAGS. I guess the compilation had been possible with some luck if there was already a gnutls/gnutls.h installed into the global path. Otherwise, into an empty enviroment like mine, the compilation always aborted. Attached patch fixes the problem. I hope you will find this very little fix useful and it could be possible to commit it without the need of subscribing to bugzilla. Greetings from Italy. Sincerely, Carlo Bramini. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gnutls.txt URL: From simon at josefsson.org Sat Aug 14 12:51:53 2010 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 14 Aug 2010 12:51:53 +0200 Subject: GnuTls: Fixed compilation of gnutlsxx In-Reply-To: <12207214.1437921281722027161.JavaMail.root@wmail50> (carlo's message of "Fri, 13 Aug 2010 19:53:47 +0200 (CEST)") References: <12207214.1437921281722027161.JavaMail.root@wmail50> Message-ID: <87ocd5tqk6.fsf@mocca.josefsson.org> "carlo.bramix at libero.it" writes: > Hello, > I tried to compile GnuTls in Mingw+Msys and I got an error because > gnutls/gnutls.h was not found with gnutlsxx.c > After a quick check I discovered that there was a mistake into lib/Makefile.am > because there was a wrong hardcoded path to includes into > libgnutlsxx_la_CPPFLAGS. > I guess the compilation had been possible with some luck if there was already > a gnutls/gnutls.h installed into the global path. Otherwise, into an empty > enviroment like mine, the compilation always aborted. > Attached patch fixes the problem. > I hope you will find this very little fix useful and it could be possible to > commit it without the need of subscribing to bugzilla. Hi. Thanks, I have pushed a similar fix to the gnutls-2.8 branch. It was already solved on the master branch. /Simon > Carlo Bramini. > diff -r -u gnutls-2.8.6-old//lib/Makefile.am gnutls-2.8.6-new//lib/Makefile.am > --- gnutls-2.8.6-old//lib/Makefile.am 2009-06-02 19:07:14 +0000 > +++ gnutls-2.8.6-new//lib/Makefile.am 2010-08-13 14:10:08 +0000 > @@ -138,7 +138,7 @@ > # C++ library > > if ENABLE_CXX > -libgnutlsxx_la_CPPFLAGS = -I$(top_srcdir)/includes -I../includes > +libgnutlsxx_la_CPPFLAGS = -I$(top_srcdir)/includes -I$(builddir)/includes > > AM_CXXFLAGS = -I$(top_srcdir)/includes/ > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > http://lists.gnu.org/mailman/listinfo/gnutls-devel From tzz at lifelogs.com Tue Aug 17 16:36:10 2010 From: tzz at lifelogs.com (Ted Zlatanov) Date: Tue, 17 Aug 2010 09:36:10 -0500 Subject: need help adding GnuTLS support to Emacs References: <87bp9dhh0y.fsf@lifelogs.com> <20100809065126.GA2684@seumegasse.bebt.de> <871va3h2av.fsf@lifelogs.com> <87ocd6ul29.fsf@mocca.josefsson.org> Message-ID: <874oeti9wl.fsf@lifelogs.com> On Sat, 14 Aug 2010 01:53:02 +0200 Simon Josefsson wrote: SJ> Ted Zlatanov writes: >> Thanks for your advice. Attached is a revised version of the patch, >> rebased against today's Emacs. SJ> Nice work! SJ> It reminds me of the fun I had with similar ideas some time ago... see SJ> http://josefsson.org/securemacs/ Simon, this *is* your patch! :) >> +DEFUN ("gnutls-global-init", Fgnutls_global_init, SJ> Do you really want to expose this function to elisp? It is SJ> thread-unsafe. It makes more sense if Emacs initialized the GnuTLS SJ> library on startup instead. Chong Yidong had the same question on the emacs-devel mailing list. I was trying to keep your original patch mostly intact but I guess it can be done better. I'll also put it all into gnutls.c instead of sending out patches to process.c. I'll probably look at implementing a seamless "open stream" operation with all the options bundled in, instead of the "initialize, build, open" sequence that's familiar on the C side. >> +DEFUN ("gnutls-protocol-set-priority", Fgnutls_protocol_set_priority, >> +DEFUN ("gnutls-cipher-set-priority", Fgnutls_cipher_set_priority, >> +DEFUN ("gnutls-compression-set-priority", Fgnutls_compression_set_priority, SJ> Don't expose these deprecated APIs, instead just expose a SJ> gnutls-set-priority interface that takes a priority string. It should SJ> be possible to specify all protocol/cipher/compression/MAC/etc variants SJ> using one simple string. I need to read up on GnuTLS. Is there a particular example in the source that is best adapted to the Emacs use case (embedded, exposed through a secondary API, should handle as many options and errors as possible, could be a server or a client)? Yidong also had concerns about all the defconst's in the patch. If we can use strings to specify options, that makes it much easier (although the Emacs Lisp side may still need work to assemble those options correctly). Thanks for writing back, I appreciate yours and everyone else's help with this. My C is very rusty so expect slow progress. Ted From nmav at gnutls.org Tue Aug 17 17:55:48 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 17 Aug 2010 17:55:48 +0200 Subject: [patch] Fix various bugs when using the gnutls async API In-Reply-To: <1281534548.12716.38.camel@night> References: <1281534548.12716.38.camel@night> Message-ID: <4C6AB104.6070205@gnutls.org> On 08/11/2010 03:49 PM, Sjoerd Simons wrote: > Hi, > > Our XMPP library (wocky) uses gnutls in a quite heavily async way, which > unfortunately seems to have triggered some bugs in the lastest > versions :/. Some patches for git HEAD attached, which seems to fix > things nicely for me. > > Some extra comments for some of the patches: > * 0003-Remember-the-amount-of-user-data-we-re-sending-out.patch > I guess It could be argued that this information should be stored > inside the record_send_buffer instead of in the session internal > struct directly. I'm happy to change the patch around to do just > that :) Hello Sjoerd, Thanks for the patches. I've applied 1 and 2. But on 3 I cannot get what was the issue that mandated the change. Why you need the user length instead of the byte length? I am also wondering why the test program mini-egain that forces the pull function to return eagain now and then, it didn't trigger the errors you see. How do you trigger those issues? best regards, Nikos From sjoerd.simons at collabora.co.uk Tue Aug 17 18:26:38 2010 From: sjoerd.simons at collabora.co.uk (Sjoerd Simons) Date: Tue, 17 Aug 2010 17:26:38 +0100 Subject: [patch] Fix various bugs when using the gnutls async API In-Reply-To: <4C6AB104.6070205@gnutls.org> References: <1281534548.12716.38.camel@night> <4C6AB104.6070205@gnutls.org> Message-ID: <1282062398.26227.38.camel@night> On Tue, 2010-08-17 at 17:55 +0200, Nikos Mavrogiannopoulos wrote: > On 08/11/2010 03:49 PM, Sjoerd Simons wrote: > > Hi, > > > > Our XMPP library (wocky) uses gnutls in a quite heavily async way, which > > unfortunately seems to have triggered some bugs in the lastest > > versions :/. Some patches for git HEAD attached, which seems to fix > > things nicely for me. > > > > Some extra comments for some of the patches: > > * 0003-Remember-the-amount-of-user-data-we-re-sending-out.patch > > I guess It could be argued that this information should be stored > > inside the record_send_buffer instead of in the session internal > > struct directly. I'm happy to change the patch around to do just > > that :) > > Hello Sjoerd, > Thanks for the patches. I've applied 1 and 2. Thanks > But on 3 I cannot get what was the issue that mandated the change. Why you need the user > length instead of the byte length? gnutls_record_send is documented to return the number of bytes send (by the user!), so the failure case is currently like this: gnutls_record_send () => -EAGAIN gnutls_record_send () => byte_length Where byte_lenght is what at that point is still left in the record_send_buffer, it's not related to the data the user was sending. > I am also wondering why the test program mini-egain that forces the pull > function to return eagain now and then, it didn't trigger the errors you > see. How do you trigger those issues? I guess pure luck in the case of running mini-egain ? In our case every pull and push will first return EAGAIN and only on the second call succeed, so it will stress all the code-patch related to EAGAIN. -- Sjoerd Simons Collabora Ltd. From nmav at gnutls.org Tue Aug 17 20:02:41 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 17 Aug 2010 20:02:41 +0200 Subject: [patch] Fix various bugs when using the gnutls async API In-Reply-To: <1282062398.26227.38.camel@night> References: <1281534548.12716.38.camel@night> <4C6AB104.6070205@gnutls.org> <1282062398.26227.38.camel@night> Message-ID: <4C6ACEC1.9090401@gnutls.org> On 08/17/2010 06:26 PM, Sjoerd Simons wrote: > gnutls_record_send is documented to return the number of bytes send (by > the user!), so the failure case is currently like this: > > gnutls_record_send () => -EAGAIN > gnutls_record_send () => byte_length > > Where byte_lenght is what at that point is still left in the > record_send_buffer, it's not related to the data the user was sending. Applied. >> I am also wondering why the test program mini-egain that forces the pull >> function to return eagain now and then, it didn't trigger the errors you >> see. How do you trigger those issues? > I guess pure luck in the case of running mini-egain ? In our case every > pull and push will first return EAGAIN and only on the second call > succeed, so it will stress all the code-patch related to EAGAIN. Something is missing in mini-eagain and cannot detect the issues you found, even with a change like you say. I cannot figure it out so I'm postponing to a less busy moment. Thanks again, Nikos From nmav at gnutls.org Tue Aug 17 20:22:50 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 17 Aug 2010 20:22:50 +0200 Subject: RFC - support for subjectUniqueID and issuerUniqueID In-Reply-To: <201008101630.44915.bradh@frogmouth.net> References: <201008101630.44915.bradh@frogmouth.net> Message-ID: <4C6AD37A.1090609@gnutls.org> On 08/10/2010 08:30 AM, Brad Hards wrote: > Hi, > > During investigation into some windows protocols, we've found that windows > servers create certificates that make use of the subjectUniqueID and > issuerUniqueID fields. They seem to contain GUID values. > > The attached patch (which I'm looking for feedback on, not to be applied at > this stage) allows fetching / display of those fields. I have a second patch > for setting / writing those fields, but I haven't tested it yet. A sample > certificate is also attached. > I recognise that they aren't normally used (and are deprecated), but for > interop purposes, I'd like to be able to access them if necessary. > Thoughts and comments? They look useful and anyway they should be added for completeness. As of the implementation, I'd prefer a version that doesn't return an allocated string but rather something that writes a user buffer such as gnutls_x509_crt_get_dn() does. If you have such a version we could add it. Thanks, Nikos From bradh at frogmouth.net Tue Aug 17 23:46:13 2010 From: bradh at frogmouth.net (Brad Hards) Date: Wed, 18 Aug 2010 07:46:13 +1000 Subject: RFC - support for subjectUniqueID and issuerUniqueID In-Reply-To: <4C6AD37A.1090609@gnutls.org> References: <201008101630.44915.bradh@frogmouth.net> <4C6AD37A.1090609@gnutls.org> Message-ID: <201008180746.13347.bradh@frogmouth.net> On Wednesday, August 18, 2010 04:22:50 am you wrote: > They look useful and anyway they should be added for completeness. As of > the implementation, I'd prefer a version that doesn't return an > allocated string but rather something that writes a user buffer such as > gnutls_x509_crt_get_dn() does. If you have such a version we could add it. OK. I don't like this approach, because you always have to do the call twice (once to get the length, and again to actually get any data), but will comply to get the feature added. I'll try to get this (and the reverse to allow writing of these fields) implemented today. Brad From bradh at frogmouth.net Wed Aug 18 01:14:45 2010 From: bradh at frogmouth.net (Brad Hards) Date: Wed, 18 Aug 2010 09:14:45 +1000 Subject: minor build breakage Message-ID: <201008180914.45343.bradh@frogmouth.net> http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=2a539ad961affeffee32cb6148f421c8e66ab693 appears to have broken the (developer) build, since oldstate is now an unused variable in lib/gnutls_handshake.c in _gnutls_sendshake_final(). -int oldstate = STATE; (around line 2770) will correct the issue. Thanks Brad From nmav at gnutls.org Wed Aug 18 18:35:38 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 18 Aug 2010 18:35:38 +0200 Subject: minor build breakage In-Reply-To: <201008180914.45343.bradh@frogmouth.net> References: <201008180914.45343.bradh@frogmouth.net> Message-ID: <4C6C0BDA.6060007@gnutls.org> On 08/18/2010 01:14 AM, Brad Hards wrote: > http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=2a539ad961affeffee32cb6148f421c8e66ab693 > appears to have broken the (developer) build, since oldstate is now an unused > variable in lib/gnutls_handshake.c in _gnutls_sendshake_final(). > -int oldstate = STATE; > (around line 2770) will correct the issue. Thanks. Committed. From orbisvicis at gmail.com Wed Aug 18 21:50:02 2010 From: orbisvicis at gmail.com (Yclept Nemo) Date: Wed, 18 Aug 2010 15:50:02 -0400 Subject: [2.10.1] segfault at gnutls_record.c:58 In-Reply-To: References: <4C6AC260.10902@gnutls.org> Message-ID: Hi, Since the patch attached (patch3.txt) only applies cleanly against the latest mod_gnutls, I'm now using 0.5.7 and haven't tested 0.5.5. From a limited 1/2-hour of testing I can report the patch solves the bug reported at http://issues.outoforder.cc/view.php?id=106, so everything looks good on that front. One note: I'm using apache2-mpm-prefork 2.2.8-1ubuntu0.11 so the additional issues tinlans is reporting might very well be thread-safety problems. While the patch also resolves the segfaults I reported when using a customized GnuTLSPriorities list, it seems to break any communication with the browser: GnuTLS: Handshake Failed (-8) 'A record packet with illegal version was received.' Invalid method in request \x10 "\x10" 501 521 "-" "-" (GnuTLSPriorities NONE:+CAMELLIA-256-CBC:+AES-256-CBC:+DHE-RSA:+SHA1:+COMP-NULL:+COMP-DEFLATE:+VERS-TLS1.1:+VERS-SSL3.0) Also, I'm not sure if this is related to changes from the patch, but firefox (same version as above) is telling me: ": server does not support RFC 5746, see CVE-2009-3555" thanks, One question, does 0.5.8 incorporate patch3.txt? From agl at golang.org Wed Aug 18 21:20:56 2010 From: agl at golang.org (Adam Langley) Date: Wed, 18 Aug 2010 15:20:56 -0400 Subject: certtool generating invalid RSA private keys? Message-ID: A user reported that they couldn't load an RSA private key, generated by certtool, with the Go[1] libraries. This is almost certainly an issue with Go, but I must admit that the private does look odd: $ certtool --generate-privkey --bits 128 > key.pem $ openssl asn1parse < key.pem 0:d=0 hl=2 l= 98 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :00 5:d=1 hl=2 l= 17 prim: INTEGER :CB5DA5AE9BCB2E0AA7DF77D525598DF1 24:d=1 hl=2 l= 3 prim: INTEGER :010001 29:d=1 hl=2 l= 16 prim: INTEGER :2B47B158914072FA21292CE371B28377 47:d=1 hl=2 l= 9 prim: INTEGER :D317519B689CE7AB 58:d=1 hl=2 l= 9 prim: INTEGER :F6A195E47387D4D3 69:d=1 hl=2 l= 8 prim: INTEGER :2E7E8D60009BC6BF 79:d=1 hl=2 l= 9 prim: INTEGER :9A9424528F66AF29 90:d=1 hl=2 l= 8 prim: INTEGER :662DDEAC721A7443 If we calculate de mod (p-1)(q-1): (0x010001 * 0x2B47B158914072FA21292CE371B28377) % ((0xD317519B689CE7AB - 1) * (0xF6A195E47387D4D3 - 1)) It does not equal one. This is the check which the Go libraries are failing. However, based on my understanding of RSA, it should, should it not? [1] http://golang.org Cheers AGL From orbisvicis at gmail.com Wed Aug 18 23:52:56 2010 From: orbisvicis at gmail.com (Yclept Nemo) Date: Wed, 18 Aug 2010 17:52:56 -0400 Subject: [2.10.1] segfault at gnutls_record.c:58 In-Reply-To: References: <4C6AC260.10902@gnutls.org> Message-ID: Eh, nevermind the last bit, I learned to add ":%SAFE_RENEGOTIATION". From agl at golang.org Thu Aug 19 03:56:30 2010 From: agl at golang.org (Adam Langley) Date: Wed, 18 Aug 2010 21:56:30 -0400 Subject: certtool generating invalid RSA private keys? In-Reply-To: References: Message-ID: On Wed, Aug 18, 2010 at 3:20 PM, Adam Langley wrote: > A user reported that they couldn't load an RSA private key, generated > by certtool, with the Go[1] libraries. This is almost certainly an > issue with Go, but I must admit that the private does look odd: Please ignore me. http://tools.ietf.org/html/rfc3447#section-3.2 explains all. AGL From bradh at frogmouth.net Fri Aug 20 02:18:19 2010 From: bradh at frogmouth.net (Brad Hards) Date: Fri, 20 Aug 2010 10:18:19 +1000 Subject: [patch] Subject Unique ID / Issuer Unique ID - first part Message-ID: <201008201018.20018.bradh@frogmouth.net> As identified in a previous mail, I've added support for accessing / displaying the subjectUniqueID and issuerUniqueID fields within an X.509 certificate. This is provided (along with a test case) in the attached patch. I've started work on writing these fields too, but that isn't finished yet. Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: uniqueid-read-2010-08-20.patch Type: text/x-patch Size: 14458 bytes Desc: not available URL: From nmav at gnutls.org Fri Aug 20 19:41:10 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 20 Aug 2010 19:41:10 +0200 Subject: [patch] Subject Unique ID / Issuer Unique ID - first part In-Reply-To: <201008201018.20018.bradh@frogmouth.net> References: <201008201018.20018.bradh@frogmouth.net> Message-ID: <4C6EBE36.2080404@gnutls.org> On 08/20/2010 02:18 AM, Brad Hards wrote: > As identified in a previous mail, I've added support for accessing / displaying > the subjectUniqueID and issuerUniqueID fields within an X.509 certificate. This > is provided (along with a test case) in the attached patch. > I've started work on writing these fields too, but that isn't finished yet. Hi thanks, I've applied it (with some modifications to prevent a memory leak). regards, Nikos From simon at josefsson.org Sat Aug 21 19:37:26 2010 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 21 Aug 2010 19:37:26 +0200 Subject: need help adding GnuTLS support to Emacs In-Reply-To: <874oeti9wl.fsf@lifelogs.com> (Ted Zlatanov's message of "Tue, 17 Aug 2010 09:36:10 -0500") References: <87bp9dhh0y.fsf@lifelogs.com> <20100809065126.GA2684@seumegasse.bebt.de> <871va3h2av.fsf@lifelogs.com> <87ocd6ul29.fsf@mocca.josefsson.org> <874oeti9wl.fsf@lifelogs.com> Message-ID: <87iq33sw89.fsf@mocca.josefsson.org> Ted Zlatanov writes: > On Sat, 14 Aug 2010 01:53:02 +0200 Simon Josefsson wrote: > > SJ> Ted Zlatanov writes: >>> Thanks for your advice. Attached is a revised version of the patch, >>> rebased against today's Emacs. > > SJ> Nice work! > > SJ> It reminds me of the fun I had with similar ideas some time ago... see > SJ> http://josefsson.org/securemacs/ > > Simon, this *is* your patch! :) That would explain why I recognized it. :-) >>> +DEFUN ("gnutls-global-init", Fgnutls_global_init, > > SJ> Do you really want to expose this function to elisp? It is > SJ> thread-unsafe. It makes more sense if Emacs initialized the GnuTLS > SJ> library on startup instead. > > Chong Yidong had the same question on the emacs-devel mailing list. I > was trying to keep your original patch mostly intact but I guess it can > be done better. I'll also put it all into gnutls.c instead of sending > out patches to process.c. I'll probably look at implementing a seamless > "open stream" operation with all the options bundled in, instead of the > "initialize, build, open" sequence that's familiar on the C side. Sounds good. >>> +DEFUN ("gnutls-protocol-set-priority", Fgnutls_protocol_set_priority, >>> +DEFUN ("gnutls-cipher-set-priority", Fgnutls_cipher_set_priority, >>> +DEFUN ("gnutls-compression-set-priority", Fgnutls_compression_set_priority, > > SJ> Don't expose these deprecated APIs, instead just expose a > SJ> gnutls-set-priority interface that takes a priority string. It should > SJ> be possible to specify all protocol/cipher/compression/MAC/etc variants > SJ> using one simple string. > > I need to read up on GnuTLS. Is there a particular example in the > source that is best adapted to the Emacs use case (embedded, exposed > through a secondary API, should handle as many options and errors as > possible, could be a server or a client)? Those APIs are deprecated and not needed any more. They were complicated to use, especially from non-C language bindings. Just remove all of them from C. What you need to provide is a elisp function that takes a session and a string and calls gnutls_priority_set_direct: http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html#gnutls-priority-set-direct For string format see: http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html#gnutls-priority-init Simple example code is here: http://git.savannah.gnu.org/cgit/gnutls.git/tree/doc/examples/ex-client1.c Calling this via elisp should be simple, I think. > Yidong also had concerns about all the defconst's in the patch. If we > can use strings to specify options, that makes it much easier (although > the Emacs Lisp side may still need work to assemble those options > correctly). With the above interface instead, just remove all the defconst's. The string is something that should come from the elisp application, and doesn't have to be provided by the gnutls.el file. That's the beauty of it. /Simon From INVALID.NOREPLY at gnu.org Wed Aug 25 14:44:31 2010 From: INVALID.NOREPLY at gnu.org (=?UTF-8?B?QmrDuHJu?= Christensen) Date: Wed, 25 Aug 2010 12:44:31 +0000 Subject: [sr #107464] Secure Connections on AIX using non blocking socket Message-ID: <20100825-124430.sv79827.98910@savannah.gnu.org> URL: Summary: Secure Connections on AIX using non blocking socket Project: GnuTLS Submitted by: cybear Submitted on: Wed Aug 25 12:44:30 2010 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: *BSD _______________________________________________________ Details: I have a tool that uses GNUTLS and are ported between different platforms Windows, Linux and AIX. The tool are working on Windows and Linux but causing problems on AIX. The behaviour is failing handshake. And from the log file I can see: READ: -1 returned from b, errno=0 gerrno=0 Comming from line 310 of gnutls_buffers.c and followed by an assertion in line 329 of gnutls_buffers.c >From inspecting the code it looks like recv is returning -1 but not setting the errno. I am uncertain what could cause recv to return result like this. I am using non-blocking sockets and recv are called with the MSG_PEEK option. I have made the changes below to make the GNUTLS library complete the Handshake. I am changing the err from 0 to EAGAIN err=err==0?EAGAIN:err; // HACK by BHC All of the _gnutls_read function below from version (2.10.1) /* This function is like read. But it does not return -1 on error. * It does return gnutls_errno instead. * * Flags are only used if the default recv() function is being used. */ static ssize_t _gnutls_read (gnutls_session_t session, void *iptr, size_t sizeOfPtr, int flags) { size_t left; ssize_t i = 0; char *ptr = iptr; unsigned j, x, sum = 0; gnutls_transport_ptr_t fd = session->internals.transport_recv_ptr; session->internals.direction = 0; left = sizeOfPtr; while (left > 0) { session->internals.errnum = 0; if (session->internals._gnutls_pull_func == NULL) { i = recv (GNUTLS_POINTER_TO_INT (fd), &ptr[sizeOfPtr - left], left, flags); _gnutls_read_log ("BHC: %d returned from %p, errno=%d gerrno=%d\n", (int) i, fd, errno, session->internals.errnum); #if HAVE_WINSOCK2_H if (i < 0) { int tmperr = WSAGetLastError (); switch (tmperr) { case WSAEWOULDBLOCK: session->internals.errnum = EAGAIN; break; case WSAEINTR: session->internals.errnum = EINTR; break; default: session->internals.errnum = EIO; break; } WSASetLastError (tmperr); } #endif } else i = session->internals._gnutls_pull_func (fd, &ptr[sizeOfPtr - left], left); if (i < 0) { int err = session->internals.errnum ? session->internals.errnum : errno; _gnutls_read_log ("READ: %d returned from %p, errno=%d gerrno=%d\n", (int) i, fd, errno, session->internals.errnum); err=err==0?EAGAIN:err; // HACK by BHC if (err == EAGAIN || err == EINTR) { if (sizeOfPtr - left > 0) { _gnutls_read_log ("READ: returning %d bytes from %p\n", (int) (sizeOfPtr - left), fd); goto finish; } if (err == EAGAIN) return GNUTLS_E_AGAIN; return GNUTLS_E_INTERRUPTED; } else { gnutls_assert (); return GNUTLS_E_PULL_ERROR; } } else { _gnutls_read_log ("READ: Got %d bytes from %p\n", (int) i, fd); if (i == 0) break; /* EOF */ } left -= i; } finish: if (_gnutls_log_level >= 7) { char line[128]; char tmp[16]; _gnutls_read_log ("READ: read %d bytes from %p\n", (int) (sizeOfPtr - left), fd); for (x = 0; x < ((sizeOfPtr - left) / 16) + 1; x++) { line[0] = 0; sprintf (tmp, "%.4x - ", x); _gnutls_str_cat (line, sizeof (line), tmp); for (j = 0; j < 16; j++) { if (sum < (sizeOfPtr - left)) { sprintf (tmp, "%.2x ", ((unsigned char *) ptr)[sum++]); _gnutls_str_cat (line, sizeof (line), tmp); } } _gnutls_read_log ("%s\n", line); } } return (sizeOfPtr - left); } _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Aug 25 16:14:44 2010 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Wed, 25 Aug 2010 14:14:44 +0000 Subject: [sr #107464] Secure Connections on AIX using non blocking socket In-Reply-To: <20100825-124430.sv79827.98910@savannah.gnu.org> References: <20100825-124430.sv79827.98910@savannah.gnu.org> Message-ID: <20100825-171444.sv707.51438@savannah.gnu.org> Follow-up Comment #1, sr #107464 (project gnutls): If you instead call gnutls_transport_set_lowat() with a value of zero, would it solve your problem? It might be that AIX does not support the MSG_PEEK value to recv(). _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From joe at x2a.org Fri Aug 27 04:09:54 2010 From: joe at x2a.org (Jonathan Bastien-Filiatrault) Date: Thu, 26 Aug 2010 22:09:54 -0400 Subject: [PULL][PATCH] Small buffering fixes, start of recv side cleanup Message-ID: <4C771E72.3030204@x2a.org> Greetings, I have started work again on DTLS. This needs preparation on the read side in order to be able to receive datagrams in whole chunks at once. The first 5 commits include fixes and documentation for every function. The last 3 are the actual changes on the read side. The diffstat would be negative if the documentation was not added. The following changes since commit ed3ae748ba6ee8b82e590f6d51d4b8473430c6de: prevent a memory leak in the unique_id functions. (2010-08-20 19:41:34 +0200) are available in the git repository at: git://github.com/jothan/gnutls.git recv-mbuffers Jonathan Bastien-Filiatrault (8): mbuffers: Document the internal mbuffer API. mbuffers: Make _mbuffer_remove_bytes return a meaningful error code. mbuffers: fix wrong size calculation. mbuffers: Add mbuffer_linearize. Parenthesize size calculations. mbuffers: make _gnutls_io_read_buffered use mbuffers. mbuffers: Add _mbuffer_xfree operation. Fully mbufferize _gnutls_read and _gnutls_read_buffered. lib/gnutls_buffers.c | 124 +++++++++++++++++++++------------------------- lib/gnutls_buffers.h | 5 +- lib/gnutls_int.h | 6 +- lib/gnutls_mbuffers.c | 131 ++++++++++++++++++++++++++++++++++++++++++++++++- lib/gnutls_mbuffers.h | 18 ++++++- lib/gnutls_record.c | 30 ++++++++--- lib/gnutls_state.c | 16 +----- 7 files changed, 231 insertions(+), 99 deletions(-) Happy hacking, Jonathan From bradh at frogmouth.net Sat Aug 28 04:28:36 2010 From: bradh at frogmouth.net (Brad Hards) Date: Sat, 28 Aug 2010 12:28:36 +1000 Subject: [patch] Show which option is the default for command line tools. Message-ID: <201008281228.36674.bradh@frogmouth.net> Show which option is the default for command line tools. We use "y/N" is most places - this just adapts two places that use "Y/N" to match the behavior of read_yesno(). - - - src/certtool.c | 2 +- src/pkcs11.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Show-which-option-is-the-default-for-command-line-to.patch Type: text/x-patch Size: 1320 bytes Desc: not available URL: From bhc at insight.dk Thu Aug 26 11:17:32 2010 From: bhc at insight.dk (=?UTF-8?B?QmrDuHJuIENocmlzdGVuc2Vu?=) Date: Thu, 26 Aug 2010 11:17:32 +0200 Subject: [sr #107464] Secure Connections on AIX using non blocking socket Message-ID: <83D596805E41464EB382DFEEB6232D5487DEF1@shelob.Insight.local> I have tried to remove the hack I have put into the _gnutls_read and added gnutls_transport_set_lowat() to zero. That does not solve the problem, recv still return -1 with no errno set and that still causes _gnutls_read to assert. I can not set in which context it would be ok to return -1 from recv and not set the errno. /bhc -----Original Message----- From: Nikos Mavrogiannopoulos [mailto:INVALID.NOREPLY at gnu.org] Sent: 25. august 2010 16:15 To: Nikos Mavrogiannopoulos; Bj?rn Christensen; gnutls-devel at gnu.org Subject: [sr #107464] Secure Connections on AIX using non blocking socket Follow-up Comment #1, sr #107464 (project gnutls): If you instead call gnutls_transport_set_lowat() with a value of zero, would it solve your problem? It might be that AIX does not support the MSG_PEEK value to recv(). _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From bhc at insight.dk Thu Aug 26 11:47:32 2010 From: bhc at insight.dk (=?UTF-8?B?QmrDuHJuIENocmlzdGVuc2Vu?=) Date: Thu, 26 Aug 2010 11:47:32 +0200 Subject: [sr #107464] Secure Connections on AIX using non blocking socket Message-ID: <83D596805E41464EB382DFEEB6232D5487DEF2@shelob.Insight.local> Hello Nikos! The code in _gnutls_read fires a gnutls_assert if recv return -1 and the errno is different from EAGAIN and EINTR. _gnutls_read function returns GNUTLS_E_PULL_ERROR. I think the assertion leads to the HandShake being terminated. In the _gnutls_read when recv returns -1 and no errno it is treated as a fatal error assert and GNUTLS_E_PULL_ERROR. Mayby is would be enough to not return the GNUTLS_E_PULL_ERROR if the errno is zero? /bhc -----Original Message----- From: n.mavrogiannopoulos at gmail.com [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos Sent: 26. august 2010 11:38 To: Bj?rn Christensen Cc: gnutls-devel at gnu.org Subject: Re: [sr #107464] Secure Connections on AIX using non blocking socket 2010/8/26 Bj?rn Christensen : > I have tried to remove the hack I have put into the _gnutls_read and added gnutls_transport_set_lowat() to zero. > That does not solve the problem, recv still return -1 with no errno set and that still causes _gnutls_read to assert. > I can not set in which context it would be ok to return -1 from recv and not set the errno. A call might return -1 and no errno, but this should be treated as fatal error and not as EINTR or EAGAIN. That's why we cannot add such a hack to main code. You'd better keep the hack then and file a bug report on AIX. regards, Nikos From nmav at gnu.org Thu Aug 26 11:37:35 2010 From: nmav at gnu.org (Nikos Mavrogiannopoulos) Date: Thu, 26 Aug 2010 11:37:35 +0200 Subject: [sr #107464] Secure Connections on AIX using non blocking socket In-Reply-To: <83D596805E41464EB382DFEEB6232D5487DEF1@shelob.Insight.local> References: <83D596805E41464EB382DFEEB6232D5487DEF1@shelob.Insight.local> Message-ID: 2010/8/26 Bj?rn Christensen : > I have tried to remove the hack I have put into the _gnutls_read and added gnutls_transport_set_lowat() to zero. > That does not solve the problem, recv still return -1 with no errno set and that still causes _gnutls_read to assert. > I can not set in which context it would be ok to return -1 from recv and not set the errno. A call might return -1 and no errno, but this should be treated as fatal error and not as EINTR or EAGAIN. That's why we cannot add such a hack to main code. You'd better keep the hack then and file a bug report on AIX. regards, Nikos From nmav at gnu.org Thu Aug 26 11:52:33 2010 From: nmav at gnu.org (Nikos Mavrogiannopoulos) Date: Thu, 26 Aug 2010 11:52:33 +0200 Subject: [sr #107464] Secure Connections on AIX using non blocking socket In-Reply-To: <83D596805E41464EB382DFEEB6232D5487DEF2@shelob.Insight.local> References: <83D596805E41464EB382DFEEB6232D5487DEF2@shelob.Insight.local> Message-ID: 2010/8/26 Bj?rn Christensen : > Hello Nikos! > > The code in _gnutls_read fires a gnutls_assert if ?recv return -1 and the errno is different from EAGAIN and EINTR. _gnutls_read function returns GNUTLS_E_PULL_ERROR. > I think the assertion leads to the HandShake being terminated. > In the _gnutls_read when recv returns -1 and no errno it is treated as a fatal error assert and GNUTLS_E_PULL_ERROR. > Mayby is would be enough to not return the GNUTLS_E_PULL_ERROR if the errno is zero? This doesn't sound correct. It will break systems where recv() returns -1 for a fatal error without errno. regards, Nikos From bhc at insight.dk Thu Aug 26 13:31:52 2010 From: bhc at insight.dk (=?UTF-8?B?QmrDuHJuIENocmlzdGVuc2Vu?=) Date: Thu, 26 Aug 2010 13:31:52 +0200 Subject: [sr #107464] Secure Connections on AIX using non blocking socket Message-ID: <83D596805E41464EB382DFEEB6232D5487DEF6@shelob.Insight.local> Hello Nikos From www.opengroup.org Upon successful completion, recv() shall return the length of the message in bytes. If no messages are available to be received and the peer has performed an orderly shutdown, recv() shall return 0. Otherwise, -1 shall be returned and errno set to indicate the error This means that the AIX have a problem. The specification says that errno should be set when returning -1 from recv. This means that the error can not be fatal. What happens if I let _gnutls_read return 0 in this case?? Returning GNUTLS_E_AGAIN makes the handshake complete /bhc -----Original Message----- From: n.mavrogiannopoulos at gmail.com [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos Sent: 26. august 2010 11:53 To: Bj?rn Christensen Cc: gnutls-devel at gnu.org Subject: Re: [sr #107464] Secure Connections on AIX using non blocking socket 2010/8/26 Bj?rn Christensen : > Hello Nikos! > > The code in _gnutls_read fires a gnutls_assert if ?recv return -1 and the errno is different from EAGAIN and EINTR. _gnutls_read function returns GNUTLS_E_PULL_ERROR. > I think the assertion leads to the HandShake being terminated. > In the _gnutls_read when recv returns -1 and no errno it is treated as a fatal error assert and GNUTLS_E_PULL_ERROR. > Mayby is would be enough to not return the GNUTLS_E_PULL_ERROR if the errno is zero? This doesn't sound correct. It will break systems where recv() returns -1 for a fatal error without errno. regards, Nikos From nmav at gnutls.org Sun Aug 29 20:31:54 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 29 Aug 2010 20:31:54 +0200 Subject: [PULL][PATCH] Small buffering fixes, start of recv side cleanup In-Reply-To: <4C771E72.3030204@x2a.org> References: <4C771E72.3030204@x2a.org> Message-ID: <4C7AA79A.4070404@gnutls.org> On 08/27/2010 04:09 AM, Jonathan Bastien-Filiatrault wrote: > Greetings, > > I have started work again on DTLS. This needs preparation on the read > side in order to be able to receive datagrams in whole chunks at once. > > The first 5 commits include fixes and documentation for every function. > The last 3 are the actual changes on the read side. The diffstat would > be negative if the documentation was not added. Hi and thank you! My question would be how would you move on. That is what would be your next (planned) moves in adding DTLS? regards, Nikos From nmav at gnutls.org Sun Aug 29 20:59:28 2010 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 29 Aug 2010 20:59:28 +0200 Subject: [patch] Show which option is the default for command line tools. In-Reply-To: <201008281228.36674.bradh@frogmouth.net> References: <201008281228.36674.bradh@frogmouth.net> Message-ID: <4C7AAE10.3030301@gnutls.org> On 08/28/2010 04:28 AM, Brad Hards wrote: > Show which option is the default for command line tools. > > We use "y/N" is most places - this just adapts two places that use "Y/N" > to match the behavior of read_yesno(). Applied. Thanks.