From oronzo10010 at yahoo.com Wed Aug 1 11:10:31 2012 From: oronzo10010 at yahoo.com (sneeboo) Date: Wed, 1 Aug 2012 02:10:31 -0700 (PDT) Subject: gnutls_certificate_verify_peers2 failing with GNUTLS_E_INVALID_REQUEST Message-ID: <34239744.post@talk.nabble.com> Hello, as a complete novice in gnutls (and in security in general) I am doing some development using libmicrohttpd with the purpose of developing a webserver that works with client certificates for user authorization purposes. I am starting my work by cloning the example in the libmicrohttpd tutorial. This code uses gnutls_certificate_verify_peers2 () to obtain the certificate of the connection in order to proceed with the required validations. The problem is that gnutls_certificate_verify_peers2() fails with GNUTLS_E_INVALID_REQUEST. Is there anyone that might give me a pointer of what could be the reason? the only sensible parameter that this function accepts as input is the tls session that in libmicrohttpd code is obtained with a call as follows MHD_get_connection_info (connection, MHD_CONNECTION_INFO_GNUTLS_SESSION) The other parameter of gnutls_certificate_verify_peers2 is an ouput one and should give no problem thanks -- View this message in context: http://old.nabble.com/gnutls_certificate_verify_peers2-failing-with-GNUTLS_E_INVALID_REQUEST-tp34239744p34239744.html Sent from the GnuPG - Gnutls - Dev mailing list archive at Nabble.com. From nmav at gnutls.org Thu Aug 2 01:05:19 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 02 Aug 2012 01:05:19 +0200 Subject: buffer\datum questions In-Reply-To: <5011AFFB.7040803@gmail.com> References: <5011AFFB.7040803@gmail.com> Message-ID: <5019B62F.4060808@gnutls.org> On 07/26/2012 11:00 PM, Olya wrote: > Hello. > > I've been struggling with data buffering - seems like what I've guessed from source > code is not entirely true: buffer content is not what I've put in there, segfaults etc. > > Could you help me to figure out how to use gnutls_str properly? > Code snippets would be most awesome. (Yepp, I'm aware that it's used throughout > GnuTLS - but thousands of lines of undocumented code is hardly a good illustration :) > I'll try to add some documentation to gnutls_str.c once I figure out how stuff in > there actually works. > 1) I've got gnutls_buffer_st with some content and void * data of size len - how do I > replace the buffer content? Who\when does memory allocation\free? Hello Olga, The idea of gnutls_buffer_st is that you have a variable length buffer that resizes automatically once you append data to it. It requires to initially use _gnutls_buffer_init() to set the structure to some sensible defaults (set everything to zero values) and you deallocate by using _gnutls_buffer_clear(). You append data by using _gnutls_buffer_append_data() - and you must always check the error code since memory allocation may occur, and you can access the data appended by using the structure's data and length fields. > 2) I'd like to get hex representation of buffer content to char * (for printing) - > how do I do that? There is _gnutls_bin2hex() that given your buffer's data and length fields it would save the hex output in the array you specified. > 3) What's the difference between datum and buffer - when I should use one? The datum is a structure that provides two fields, data, and size. If that's all you need then use a datum. The buffer allows to append to it (possibly formatted for TLS) data, and to read data (pop) from it in an efficient way. > 4) What's with memory management? Is it completely automated? When and why do I need > _gnutls_buffer_resize()? If you use the gnutls_buffer*() functions it is automated. If however you need to add some data in some other fashion that isn't covered by the current functions the resize can be used. If the length of your buffer is X and the you do a resize of X+N, then it makes sure that there are N bytes available at the position buffer->data[buffer->length]. If you use this option you should increase buffer->length manually once you store the data there. > 5) What does various _prefix() functions do? They are used to store the TLS variable length fields. That is they prepend the size of the buffer before the data. The prefix size is the number of bits used for the length (8,16,24,32). regards, Nikos From nmav at gnutls.org Thu Aug 2 01:17:28 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 02 Aug 2012 01:17:28 +0200 Subject: segfault in gnutls-cli -d 65535 post.craigslist.org In-Reply-To: <878ve0x74n.fsf@pip.fifthhorseman.net> References: <878ve0x74n.fsf@pip.fifthhorseman.net> Message-ID: <5019B908.5000404@gnutls.org> On 07/31/2012 05:50 PM, Daniel Kahn Gillmor wrote: > In attempting to replicate Todd T. Fries' report, i found a segmentation > fault in gnutls-cli when asking for out-of-range debugging (> 9999): Thanks. It looks like an issue in the libopts used. I'll try to check if there is a newer version that fixes this issue. regards, Nikos From nmav at gnutls.org Thu Aug 2 01:23:19 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 02 Aug 2012 01:23:19 +0200 Subject: [PATCH] Respect certtool --hash when signing request and CRL In-Reply-To: <1343312324-16993-1-git-send-email-petr.pisar@atlas.cz> References: <1343312324-16993-1-git-send-email-petr.pisar@atlas.cz> Message-ID: <5019BA67.5000409@gnutls.org> On 07/26/2012 04:18 PM, Petr P?sa? wrote: > The certtool hard-codes the digest algorithm despite '--hash' option exists. > This patch allows user to choose the algorithm when signing certificate > request or certificate revocation list. > --- > src/certtool.c | 37 ++++++++++++++++++++++++------------- > 1 files changed, 24 insertions(+), 13 deletions(-) Thank you. Applied! From INVALID.NOREPLY at gnu.org Thu Aug 2 01:28:21 2012 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Wed, 01 Aug 2012 23:28:21 +0000 Subject: [sr #108094] unresolved symbols in windows because wincrypt.h is not included In-Reply-To: <20120725-194109.sv88767.22707@savannah.gnu.org> References: <20120725-194109.sv88767.22707@savannah.gnu.org> Message-ID: <20120802-022821.sv707.66501@savannah.gnu.org> Update of sr #108094 (project gnutls): Status: None => Need Info Assigned to: None => nmav _______________________________________________________ Follow-up Comment #1: Hello, Which version of gnutls is that and which compiler? gnutls_x509.c already includes wincrypt.h and crypto-api.c doesn't seem to call any windows API function. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Thu Aug 2 01:33:02 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 02 Aug 2012 01:33:02 +0200 Subject: 'gnutls-cli -d 9999 --insecure -p 443 post.craigslist.org' fails with 3.0.20 In-Reply-To: <20120730171851.GA30437@fries.net> References: <20120730171851.GA30437@fries.net> Message-ID: <5019BCAE.3040104@gnutls.org> On 07/30/2012 07:18 PM, Todd T. Fries wrote: > |<2>| p11: loaded provider 'gnome-keyring-module' with 0 slots > |<2>| ASSERT: pkcs11.c:459 > Processed 152 CA certificate(s). > Resolving 'post.craigslist.org'... > Connecting to '208.82.238.151:443'... > |<4>| REC[0x73118]: Allocating epoch #0 > |<1>| Note that the security level of the Diffie-Hellman key exchange has been lowered to 512 bits and this may allow decryption of the session data > *** Fatal error: The TLS connection was non-properly terminated. Hello, Thanks for the report. It seems there are several broken servers out there (the server is closing the connection for some reason). You can avoid them by using one of priority strings listed at: http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html regards, Nikos From nmav at gnutls.org Thu Aug 2 01:36:20 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 02 Aug 2012 01:36:20 +0200 Subject: gnutls_certificate_verify_peers2 failing with GNUTLS_E_INVALID_REQUEST In-Reply-To: <34239744.post@talk.nabble.com> References: <34239744.post@talk.nabble.com> Message-ID: <5019BD74.9040503@gnutls.org> On 08/01/2012 11:10 AM, sneeboo wrote: > > Hello, as a complete novice in gnutls (and in security in general) I am > doing some development using libmicrohttpd with the purpose of developing a > webserver that works with client certificates for user authorization > purposes. > > I am starting my work by cloning the example in the libmicrohttpd tutorial. > This code uses gnutls_certificate_verify_peers2 () to obtain the certificate > of the connection in order to proceed with the required validations. > > The problem is that gnutls_certificate_verify_peers2() fails with > GNUTLS_E_INVALID_REQUEST. Is there anyone that might give me a pointer of > what could be the reason? the only sensible parameter that this function > accepts as input is the tls session that in libmicrohttpd code is obtained > with a call as follows You must have a gnutls session established before calling the certificate_verify_peers2(). To pinpoint the issue you can try the debugging functions listed in: http://www.gnu.org/software/gnutls/manual/html_node/Debugging-and-auditing.html#Debugging-and-auditing regards, Nikos From todd at fries.net Thu Aug 2 06:01:51 2012 From: todd at fries.net (todd at fries.net) Date: Wed, 1 Aug 2012 23:01:51 -0500 Subject: 'gnutls-cli -d 9999 --insecure -p 443 post.craigslist.org' fails with 3.0.20 In-Reply-To: <5019BCAE.3040104@gnutls.org> References: <20120730171851.GA30437@fries.net> <5019BCAE.3040104@gnutls.org> Message-ID: <20120802040151.GA6276@fries.net> Great suggestion, except for applications that use glib-networking there is no way to set the priority beyond the defaults. We're working on glib-networking folks, but is there any consideration to permit random applications to over-ride the defaults? Thanks, Penned by Nikos Mavrogiannopoulos on 20120801 18:33.02, we have: | On 07/30/2012 07:18 PM, Todd T. Fries wrote: | | > |<2>| p11: loaded provider 'gnome-keyring-module' with 0 slots | > |<2>| ASSERT: pkcs11.c:459 | > Processed 152 CA certificate(s). | > Resolving 'post.craigslist.org'... | > Connecting to '208.82.238.151:443'... | > |<4>| REC[0x73118]: Allocating epoch #0 | > |<1>| Note that the security level of the Diffie-Hellman key exchange has been lowered to 512 bits and this may allow decryption of the session data | | > *** Fatal error: The TLS connection was non-properly terminated. | | Hello, | Thanks for the report. It seems there are several broken servers out | there (the server is closing the connection for some reason). You can | avoid them by using one of priority strings listed at: | http://www.gnu.org/software/gnutls/manual/html_node/Interoperability.html | | regards, | Nikos -- Todd Fries .. todd at fries.net _____________________________________________ | \ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC \ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX) | 2525 NW Expy #525, Oklahoma City, OK 73112 \ sip:freedaemon at ekiga.net | "..in support of free software solutions." \ sip:4052279094 at ekiga.net \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt From olyasib12 at gmail.com Thu Aug 2 06:02:01 2012 From: olyasib12 at gmail.com (Olya) Date: Thu, 02 Aug 2012 11:02:01 +0700 Subject: buffer\datum questions In-Reply-To: <5019B62F.4060808@gnutls.org> References: <5011AFFB.7040803@gmail.com> <5019B62F.4060808@gnutls.org> Message-ID: <5019FBB9.5050401@gmail.com> 02.08.2012 06:05, Nikos Mavrogiannopoulos ?????: > There is _gnutls_bin2hex() that given your buffer's data and length > fields it would save the hex output in the array you specified. Do I have to allocate that char * array or _gnutls_bin2hex() will take care of that? >> 5) What does various _prefix() functions do? > > > They are used to store the TLS variable length fields. That is they > prepend the size of the buffer before the data. The prefix size is the > number of bits used for the length (8,16,24,32). What's the meaning of check in _gnutls_buffer_pop_prefix (gnutls_buffer_st * buf, size_t * data_size, int check) ? And few more related questions: 1) Why _gnutls_buffer_replace_data( gnutls_buffer_st * buf, gnutls_datum_t * data) uses datum while _append() uses data & size? 2) Do I have to pre-allocate memory for the datum, copy my data to datum, call _replace() and deallocate datum? Could you give simple example of _replace() usage? 3) When should I use _gnutls_buffer_reset() ? Thank you for detailed explanations - it's too good to leave it be in my inbox :-) Should I add them to doc/cha-internals.texi or there's more appropriate place for that? best regards, Olga. From nmav at gnutls.org Thu Aug 2 09:37:14 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 2 Aug 2012 09:37:14 +0200 Subject: buffer\datum questions In-Reply-To: <5019FBB9.5050401@gmail.com> References: <5011AFFB.7040803@gmail.com> <5019B62F.4060808@gnutls.org> <5019FBB9.5050401@gmail.com> Message-ID: On Thu, Aug 2, 2012 at 6:02 AM, Olya wrote: >> There is _gnutls_bin2hex() that given your buffer's data and length >> fields it would save the hex output in the array you specified. > Do I have to allocate that char * array or _gnutls_bin2hex() will take care of that? You need to take care of allocation. Typically functions that return allocated data they do it inside a gnutls_datum_t (and should be explicit about it). >>> 5) What does various _prefix() functions do? >> They are used to store the TLS variable length fields. That is they >> prepend the size of the buffer before the data. The prefix size is the >> number of bits used for the length (8,16,24,32). > What's the meaning of check in > _gnutls_buffer_pop_prefix (gnutls_buffer_st * buf, size_t * data_size, int check) ? It reads a 32-bit integer from the buffer and checks whether the remaining data length are less than that. > And few more related questions: > 1) Why _gnutls_buffer_replace_data( gnutls_buffer_st * buf, gnutls_datum_t * data) > uses datum while _append() uses data & size? It could have been that most of calls to replace_data() were using datums. No particular reason. > 2) Do I have to pre-allocate memory for the datum, copy my data to datum, call > _replace() and deallocate datum? Could you give simple example of _replace() usage? The replace, will copy the datum you provide (already allocated) to the buffer. > 3) When should I use _gnutls_buffer_reset() ? If you want to re-use a buffer. I.e. you appended some data, sent it to the peer, and want to use a new buffer. Instead of initializing a new one you reset that one. > Thank you for detailed explanations - it's too good to leave it be in my inbox :-) > Should I add them to doc/cha-internals.texi or there's more appropriate place for that? I think the best is to add inline comments like: http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob;f=lib/gnutls_cert.c;h=01636cc35326a7931fbb3083c116bc71411da461;hb=HEAD#l140 That way once the function is updated it is easy to modify its description. regards, Nikos From nmav at gnutls.org Thu Aug 2 09:41:03 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 2 Aug 2012 09:41:03 +0200 Subject: 'gnutls-cli -d 9999 --insecure -p 443 post.craigslist.org' fails with 3.0.20 In-Reply-To: <20120802040151.GA6276@fries.net> References: <20120730171851.GA30437@fries.net> <5019BCAE.3040104@gnutls.org> <20120802040151.GA6276@fries.net> Message-ID: On Thu, Aug 2, 2012 at 6:01 AM, wrote: > Great suggestion, except for applications that use glib-networking there > is no way to set the priority beyond the defaults. There has to be a way, if not to set a priority, a way to set a compatibility mode that would use one of these priorities. If there is a single way to start a session you'll have the issues you see with broken servers, or if the compatibility strings are used by default you'll have a low security level. > We're working on glib-networking folks, but is there any consideration > to permit random applications to over-ride the defaults? Setting a priority string is the only way. regards, Nikos From olyasib12 at gmail.com Thu Aug 2 09:54:34 2012 From: olyasib12 at gmail.com (Olya) Date: Thu, 02 Aug 2012 14:54:34 +0700 Subject: buffer\datum questions In-Reply-To: References: <5011AFFB.7040803@gmail.com> <5019B62F.4060808@gnutls.org> <5019FBB9.5050401@gmail.com> Message-ID: <501A323A.2020406@gmail.com> 02.08.2012 14:37, Nikos Mavrogiannopoulos ?????: >> _gnutls_buffer_pop_prefix (gnutls_buffer_st * buf, size_t * data_size, int check) ? > > It reads a 32-bit integer from the buffer and checks whether the > remaining data length are less than that. So how exactly "int check" is used - boolean indicator whether to perform remainder length check or not? Or it's the length value against which the remainder will be checked? Are there similar functions for 16 bits? 8 bits? etc. >> 2) Do I have to pre-allocate memory for the datum, copy my data to datum, call >> _replace() and deallocate datum? Could you give simple example of _replace() usage? > > The replace, will copy the datum you provide (already allocated) to the buffer. So the expected call sequence is: _gnutls_set_datum (&dat, data, data_size); _gnutls_buffer_replace_data (&buffer, &dat); _gnutls_free_datum (&dat); When I'm trying to do that I got segfault on _free_datum() due to double-free. Could you provide proper example? >> 3) When should I use _gnutls_buffer_reset() ? > > If you want to re-use a buffer. I.e. you appended some data, sent it > to the peer, and want to use a new buffer. Instead of initializing a > new one you reset that one. So instead of _replace_data() I can call _reset() and _append()? cheers, Olga. From nmav at gnutls.org Thu Aug 2 10:10:11 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 2 Aug 2012 10:10:11 +0200 Subject: buffer\datum questions In-Reply-To: <501A323A.2020406@gmail.com> References: <5011AFFB.7040803@gmail.com> <5019B62F.4060808@gnutls.org> <5019FBB9.5050401@gmail.com> <501A323A.2020406@gmail.com> Message-ID: On Thu, Aug 2, 2012 at 9:54 AM, Olya wrote: >>> _gnutls_buffer_pop_prefix (gnutls_buffer_st * buf, size_t * data_size, int check) ? >> It reads a 32-bit integer from the buffer and checks whether the >> remaining data length are less than that. > So how exactly "int check" is used - boolean indicator whether to perform remainder > length check or not? Just a boolean. > Or it's the length value against which the remainder will be checked? > Are there similar functions for 16 bits? 8 bits? etc. No. But we can make this more general if you need it. >>> 2) Do I have to pre-allocate memory for the datum, copy my data to datum, call >>> _replace() and deallocate datum? Could you give simple example of _replace() usage? >> The replace, will copy the datum you provide (already allocated) to the buffer. > So the expected call sequence is: > _gnutls_set_datum (&dat, data, data_size); Use set_datum() only if you want to copy(duplicate) the data you have into the datum. Otherwise just assign the values (datum->data, datum->size) to the needed one. > _gnutls_buffer_replace_data (&buffer, &dat); > _gnutls_free_datum (&dat); No need to call free_datum(). buffer_replace() takes the array you provided and it will be deinitialized when you clear the buffer. >> If you want to re-use a buffer. I.e. you appended some data, sent it >> to the peer, and want to use a new buffer. Instead of initializing a >> new one you reset that one. > So instead of _replace_data() I can call _reset() and _append()? replace_data() doesn't do any data copy. So if the data size is large it may be more efficient. regards, Nikos From olyasib12 at gmail.com Thu Aug 2 11:20:49 2012 From: olyasib12 at gmail.com (Olya) Date: Thu, 02 Aug 2012 16:20:49 +0700 Subject: buffer\datum questions In-Reply-To: References: <5011AFFB.7040803@gmail.com> <5019B62F.4060808@gnutls.org> <5019FBB9.5050401@gmail.com> <501A323A.2020406@gmail.com> Message-ID: <501A4671.2050600@gmail.com> 02.08.2012 15:10, Nikos Mavrogiannopoulos ?????: >> Or it's the length value against which the remainder will be checked? >> Are there similar functions for 16 bits? 8 bits? etc. > > No. But we can make this more general if you need it. That would be great. How about: _gnutls_buffer_pop_prefix (gnutls_buffer_st * buf, size_t * data_size, int check, uint8_t pfx_len = 32); Or should we use "bool check" to make it more obvious? >>>> 2) Do I have to pre-allocate memory for the datum, copy my data to datum, call >>>> _replace() and deallocate datum? Could you give simple example of _replace() usage? >>> The replace, will copy the datum you provide (already allocated) to the buffer. >> So the expected call sequence is: >> _gnutls_set_datum (&dat, data, data_size); > > Use set_datum() only if you want to copy(duplicate) the data you have > into the datum. Otherwise just assign the values (datum->data, > datum->size) to the needed one. If I'm trying to use datum->data I've got to drop const qualifier from "const void * data" parameter. Right now I'm not sure if I should copy data or not. thanks, Olga. From nmav at gnutls.org Thu Aug 2 16:22:02 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 2 Aug 2012 16:22:02 +0200 Subject: buffer\datum questions In-Reply-To: <501A4671.2050600@gmail.com> References: <5011AFFB.7040803@gmail.com> <5019B62F.4060808@gnutls.org> <5019FBB9.5050401@gmail.com> <501A323A.2020406@gmail.com> <501A4671.2050600@gmail.com> Message-ID: On Thu, Aug 2, 2012 at 11:20 AM, Olya wrote: > 02.08.2012 15:10, Nikos Mavrogiannopoulos ?????: >>> Or it's the length value against which the remainder will be checked? >>> Are there similar functions for 16 bits? 8 bits? etc. >> No. But we can make this more general if you need it. > That would be great. How about: > _gnutls_buffer_pop_prefix (gnutls_buffer_st * buf, size_t * data_size, int check, > uint8_t pfx_len = 32); Looks good. However use I'd use the integer type for length. > Or should we use "bool check" to make it more obvious? Although we use many C99 features already the boolean type isn't one of them. Let's keep int. >> Use set_datum() only if you want to copy(duplicate) the data you have >> into the datum. Otherwise just assign the values (datum->data, >> datum->size) to the needed one. > If I'm trying to use datum->data I've got to drop const qualifier from "const void * > data" parameter. Right now I'm not sure if I should copy data or not. No problem to you use casts for that. Just make sure that the callee doesn't modify that data. regards, Nikos From INVALID.NOREPLY at gnu.org Fri Aug 3 20:07:01 2012 From: INVALID.NOREPLY at gnu.org (Steve Trotman) Date: Fri, 03 Aug 2012 18:07:01 +0000 Subject: [sr #108094] unresolved symbols in windows because wincrypt.h is not included In-Reply-To: <20120802-022821.sv707.66501@savannah.gnu.org> References: <20120725-194109.sv88767.22707@savannah.gnu.org> <20120802-022821.sv707.66501@savannah.gnu.org> Message-ID: <20120803-180701.sv88767.58070@savannah.gnu.org> Follow-up Comment #2, sr #108094 (project gnutls): Gnutls 3.0.20 GCC 4.6.2 under MSYS/Mingw32 offending functions below: CC gnutls_x509.lo gnutls_x509.c: In function 'set_x509_system_trust_file': gnutls_x509.c:1595:1: error: unknown type name 'HCERTSTORE' gnutls_x509.c:1595:1: warning: implicit declaration of function 'CertOpenSystemStore' [-Wimplicit-function-declaration] gnutls_x509.c:1596:1: error: unknown type name 'CERT_CONTEXT' gnutls_x509.c:1597:1: error: unknown type name 'CRL_CONTEXT' gnutls_x509.c:1608:17: warning: comparison between pointer and integer [enabled by default] gnutls_x509.c:1610:7: warning: implicit declaration of function 'CertEnumCertificatesInStore' [-Wimplicit-function-decla ration] gnutls_x509.c:1610:12: warning: assignment makes pointer from integer without a cast [enabled by default] gnutls_x509.c:1611:7: warning: implicit declaration of function 'CertEnumCRLsInStore' [-Wimplicit-function-declaration] gnutls_x509.c:1611:11: warning: assignment makes pointer from integer without a cast [enabled by default] gnutls_x509.c:1615:19: error: request for member 'dwCertEncodingType' in something not a structure or union gnutls_x509.c:1615:43: error: 'X509_ASN_ENCODING' undeclared (first use in this function) gnutls_x509.c:1615:43: note: each undeclared identifier is reported only once for each function it appears in gnutls_x509.c:1617:31: error: request for member 'pbCertEncoded' in something not a structure or union gnutls_x509.c:1618:31: error: request for member 'cbCertEncoded' in something not a structure or union gnutls_x509.c:1622:16: warning: assignment makes pointer from integer without a cast [enabled by default] gnutls_x509.c:1627:18: error: request for member 'dwCertEncodingType' in something not a structure or union gnutls_x509.c:1629:30: error: request for member 'pbCrlEncoded' in something not a structure or union gnutls_x509.c:1630:30: error: request for member 'cbCrlEncoded' in something not a structure or union gnutls_x509.c:1634:15: warning: assignment makes pointer from integer without a cast [enabled by default] gnutls_x509.c:1636:7: warning: implicit declaration of function 'CertCloseStore' [-Wimplicit-function-declaration] make[3]: *** [gnutls_x509.lo] Error 1 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Fri Aug 3 20:36:08 2012 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Fri, 03 Aug 2012 18:36:08 +0000 Subject: [sr #108094] unresolved symbols in windows because wincrypt.h is not included In-Reply-To: <20120803-180701.sv88767.58070@savannah.gnu.org> References: <20120725-194109.sv88767.22707@savannah.gnu.org> <20120802-022821.sv707.66501@savannah.gnu.org> <20120803-180701.sv88767.58070@savannah.gnu.org> Message-ID: <20120803-213607.sv707.93682@savannah.gnu.org> Follow-up Comment #3, sr #108094 (project gnutls): This is a mingw32 bug. You can use mingw64 to compile gnutls. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From ametzler at downhill.at.eu.org Sat Aug 4 13:45:08 2012 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sat, 4 Aug 2012 13:45:08 +0200 Subject: segfault in gnutls-cli -d 65535 post.craigslist.org In-Reply-To: <5019B908.5000404@gnutls.org> References: <878ve0x74n.fsf@pip.fifthhorseman.net> <5019B908.5000404@gnutls.org> Message-ID: <20120804114508.GA2634@downhill.g.la> On 2012-08-02 Nikos Mavrogiannopoulos wrote: > On 07/31/2012 05:50 PM, Daniel Kahn Gillmor wrote: > > In attempting to replicate Todd T. Fries' report, i found a segmentation > > fault in gnutls-cli when asking for out-of-range debugging (> 9999): > Thanks. It looks like an issue in the libopts used. I'll try to check if > there is a newer version that fixes this issue. libopts 5.16 does not segfault. gnutls-cli error: debug option value 65535 is out of range. It must be in the range: 0 to 9999 Usage: gnutls-cli [options] hostname gnutls-cli --help for usage instructions. 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 nmav at gnutls.org Sat Aug 4 21:14:33 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 04 Aug 2012 21:14:33 +0200 Subject: gnutls 3.0.22 Message-ID: <501D7499.2020507@gnutls.org> Hello, I've just released gnutls 3.0.22. This is a bug-fix release on the current stable branch. * Version 3.0.22 (released 2012-08-04) ** libgnutls: gnutls_certificate_set_x509_system_trust() is now supported on OpenBSD. ** libgnutls: When verifying a certificate chain make sure it is chain. If the chain is wronly interrupted at some point then truncate it, and only try to verify the correct part. Patch by David Woodhouse ** libgnutls: Restored the behavior of gnutls_x509_privkey_import_pkcs8() which now may (again) accept a NULL password. ** certtool: Allow the user to choose the hash algorithm when signing certificate request or certificate revocation list. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.22.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.22.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.22.tar.xz Here are the LZIP compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.22.tar.lz http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.22.tar.lz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.22.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.22.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.22.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.22.tar.xz.sig ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.0.22.tar.lz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.0.22.tar.lz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.0.22.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 Sun Aug 5 12:38:40 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 05 Aug 2012 12:38:40 +0200 Subject: gnutls 3.1.0 pre-release Message-ID: <501E4D30.6090901@gnutls.org> Hello, One of the next few weeks I plan to release gnutls 3.1.0. This includes quite some changes comparing to 3.0.x, the most prominent being: * Dependence on nettle for RSA PKCS #1 1.5 operations. * Support for TPM keys (if trousers is available). The former means that we save quite some code by not reimplementing this stuff in gnutls. The TPM support means that you can use your TPM chip to secure your private key similarly to a smart-card. Keys are referred to by using a (for now custom) URL-like format that looks like: tpmkey:uuid=58ad734b-bde6-45c7-89d8-756a55ad1891;storage=user tpmkey:file=/path/to/tpmkey.pem I've put some pre-release versions at alpha.gnu.org. Please try them and feel free to report any issues you encounter or any other comments. ftp://alpha.gnu.org/gnu/gnutls/gnutls-3.1.0pre0.tar.lz ftp://alpha.gnu.org/gnu/gnutls/gnutls-3.1.0pre0.tar.xz ftp://alpha.gnu.org/gnu/gnutls/gnutls-3.1.0pre0.tar.lz.sig ftp://alpha.gnu.org/gnu/gnutls/gnutls-3.1.0pre0.tar.xz.sig A more detailed changelog follows. * Version 3.1.0pre0 (released 2012-08-05) ** libgnutls: Added direct support for TPM as a cryptographic module in gnutls/tpm.h. ** libgnutls: requires libnettle 2.5. ** libgnutls: Use the PKCS #1 1.5 encoding provided by nettle (2.5) for encryption and signatures. ** libgnutls: Added GNUTLS_CERT_SIGNATURE_FAILURE to differentiate between generic errors and signature verification errors in the verification functions. ** libgnutls: Added gnutls_pkcs12_simple_parse() as a helper function to simplify parsing in most PKCS #12 use cases. ** libgnutls: gnutls_certificate_set_x509_simple_pkcs12_file() adds the whole certificate chain (if any) to the credentials structure, instead of only the end-user certificate. ** libgnutls: Key import functions such as gnutls_pkcs12_simple_parse() and gnutls_x509_privkey_import_pkcs8(), return consistently GNUTLS_E_DECRYPTION_FAILED if the input structure is encrypted but no password was provided. ** libgnutlsxx: Added session::set_transport_vec_push_function. Patch by Alexandre Bique. ** tpmtool: Added. It is a tool to generate private keys in the TPM. ** gnutls-cli: --benchmark-tls was split to --benchmark-tls-kx and --benchmark-tls-ciphers ** certtool: generated PKCS #12 structures may hold more than one private key. Patch by Lucas Fisher. ** certtool: Added option --null-password to generate/decrypt keys that use a NULL password (in schemas that distinguish between NULL an empty passwords). ** minitasn1: Upgraded to libtasn1 version 2.13. ** API and ABI modifications: GNUTLS_CERT_SIGNATURE_FAILURE: Added GNUTLS_CAMELLIA_192_CBC: Added GNUTLS_PKCS_NULL_PASSWORD: Added gnutls_url_is_supported: Added gnutls_pkcs11_obj_list_import_url2: Added gnutls_pkcs11_obj_set_pin_function: Added gnutls_pkcs11_privkey_set_pin_function: Added gnutls_pkcs11_get_pin_function: Added gnutls_privkey_import_tpm_raw: Added gnutls_privkey_import_tpm_url: Added gnutls_privkey_import_pkcs11_url: Added gnutls_privkey_import_openpgp_raw: Added gnutls_privkey_import_x509_raw: Added gnutls_privkey_import_ext2: Added gnutls_privkey_import_url: Added gnutls_privkey_set_pin_function: Added gnutls_tpm_privkey_generate: Added gnutls_tpm_key_list_deinit: Added gnutls_tpm_key_list_get_url: Added gnutls_tpm_get_registered: Added gnutls_tpm_privkey_delete: Added gnutls_pubkey_import_tpm_raw: Added gnutls_pubkey_import_tpm_url: Added gnutls_pubkey_import_url: Added gnutls_pubkey_verify_hash2: Added gnutls_pubkey_set_pin_function: Added gnutls_x509_privkey_import2: Added gnutls_x509_privkey_import_openssl: Added gnutls_x509_crt_set_pin_function: Added gnutls_load_file: Added gnutls_pkcs12_simple_parse: Added gnutls_certificate_set_x509_system_trust: Added gnutls_certificate_set_pin_function: Added gnutls_x509_trust_list_add_system_trust: Added gnutls_x509_trust_list_add_trust_file: Added gnutls_x509_trust_list_add_trust_mem: Added gnutls_pk_to_sign: Added gnutls_pubkey_verify_hash: Deprecated (use gnutls_pubkey_verify_hash2) gnutls_pubkey_verify_data: Deprecated (use gnutls_pubkey_verify_data2) regards, Nikos From INVALID.NOREPLY at gnu.org Mon Aug 6 21:13:41 2012 From: INVALID.NOREPLY at gnu.org (LRN) Date: Mon, 06 Aug 2012 19:13:41 +0000 Subject: [sr #108094] unresolved symbols in windows because wincrypt.h is not included In-Reply-To: <20120803-213607.sv707.93682@savannah.gnu.org> References: <20120725-194109.sv88767.22707@savannah.gnu.org> <20120802-022821.sv707.66501@savannah.gnu.org> <20120803-180701.sv88767.58070@savannah.gnu.org> <20120803-213607.sv707.93682@savannah.gnu.org> Message-ID: <20120806-191340.sv74148.48442@savannah.gnu.org> Follow-up Comment #4, sr #108094 (project gnutls): This was fixed in 3.0.21 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nyjkkyjn at gmail.com Fri Aug 10 17:53:55 2012 From: nyjkkyjn at gmail.com (nyjkkyjn at gmail.com) Date: Fri, 10 Aug 2012 17:53:55 +0200 Subject: Problem compiling gnutls Message-ID: <50252E93.5010405@gmail.com> I'm trying to compile gnutls 3.0.22 through mingw-w64 toolchain on cygwin.. The configuration step seems to be OK, but when I execute "make" while processing ex-cxx.cpp in doc/examples I get this error: /usr/x86_64-w64-mingw32/sys-root/mingw/include/stdio.h:328:5: error: previous declaration of 'int asprintf(char**, const char*, ...)' with 'C++' linkage ../../gl/stdio.h:1425:1: error: conflicts with new declaration with 'C' linkage /usr/x86_64-w64-mingw32/sys-root/mingw/include/stdio.h:339:5: error: previous declaration of 'int vasprintf(char**, const char*, char*)' with 'C++' linkage ../../gl/stdio.h:1446:1: error: conflicts with new declaration with 'C' linkage Is it a problem with the toolchain or else? Is there a workaround? Thanks, anyway.. I hope someone could help me.. From vincent.torri at gmail.com Sat Aug 11 07:42:22 2012 From: vincent.torri at gmail.com (Vincent Torri) Date: Sat, 11 Aug 2012 07:42:22 +0200 Subject: Problem compiling gnutls In-Reply-To: <50252E93.5010405@gmail.com> References: <50252E93.5010405@gmail.com> Message-ID: On Fri, Aug 10, 2012 at 5:53 PM, nyjkkyjn at gmail.com wrote: > I'm trying to compile gnutls 3.0.22 through mingw-w64 toolchain on > cygwin.. The configuration step seems to be OK, but when I execute > "make" while processing ex-cxx.cpp in doc/examples I get this error: > /usr/x86_64-w64-mingw32/sys-root/mingw/include/stdio.h:328:5: > error: previous declaration of 'int > asprintf(char**, const char*, ...)' with 'C++' linkage > ../../gl/stdio.h:1425:1: error: conflicts with new declaration > with 'C' linkage > /usr/x86_64-w64-mingw32/sys-root/mingw/include/stdio.h:339:5: > error: previous declaration of 'int > vasprintf(char**, const char*, char*)' with 'C++' linkage > ../../gl/stdio.h:1446:1: error: conflicts with new declaration > with 'C' linkage > Is it a problem with the toolchain or else? Is there a workaround? > Thanks, anyway.. I hope someone could help me.. the correct fix is to check if these functions are available in configure.ac and declare/define them conditionally in the cpp file Vincent Torri From scottm at aero.org Mon Aug 13 23:10:06 2012 From: scottm at aero.org (B. Scott Michel) Date: Mon, 13 Aug 2012 14:10:06 -0700 Subject: Problem compiling gnutls In-Reply-To: References: <50252E93.5010405@gmail.com> Message-ID: <50296D2E.4070007@aero.org> On 8/10/2012 10:42 PM, Vincent Torri wrote: > the correct fix is to check if these functions are available in > configure.ac and declare/define them conditionally in the cpp file Amazingly insightful answer. I can successfully compile 3.0.17 using the mingw-64 compiler without issues. I haven't tried 3.0.22 yet. I do all of my work under MSys. I try to avoid cygwin; see below. configure (and configure.ac) look for vasprintf. The scripts do not look for asprintf, specifically. Two reasons why you might have problems: a) cygwin: The mingw-64 toolchain may be picking up a header from cygwin. This header's declarations for asprintf and vasprintf differ from what gnutls' replacement thinks it should be. b) You didn't specify "--host=x86_64-w64-mingw32" as an argument to configure. Both (a) and (b) are related -- if you didn't give "--host" to configure, then it is possible for toolchains to pick up headers they're not supposed to find. You might also need to unset your settings for CC and CFLAGS as well. Hope this helps you get a little farther. -scooter From sven at gegg.us Tue Aug 14 11:39:37 2012 From: sven at gegg.us (Sven Geggus) Date: Tue, 14 Aug 2012 11:39:37 +0200 Subject: hangs with active p11-kit modules Message-ID: <20120814093935.GA21090@geggus.net> Hello, I encounter strange hangs on various pieces of software (cups, mutt, ...) linked against gnutls (2.12.x) with an active pkcs11 smartcard module. This module is not used by these applications, they are just linked against gnutls. This goes this far that building gnutls with an active pkcs11 module takes ages because of very long delays in various gnutls self-tests and after some very long delay in almost every single test the build fails with the following messages: make[4]: Entering directory `/home/geg/tmp/gnutls26-2.12.20/tests/safe-renegotiation' Self test `./srn0' finished with 0 errors ==22313== 4 bytes in 1 blocks are definitely lost in loss record 2 of 33 ==22313== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==22313== by 0x55EF881: strdup (strdup.c:43) ==22313== by 0x536717B: p11_kit_registered_module_to_name (in /usr/lib/libp11-kit.so.0.0.0) ==22313== by 0x4E76D04: gnutls_pkcs11_init (pkcs11.c:462) ==22313== by 0x4E5D23A: gnutls_global_init (gnutls_global.c:252) ==22313== by 0x4012CA: doit (srn0.c:102) ==22313== by 0x4018E4: main (utils.c:149) ==22313== ==22313== 252,824 (8,232 direct, 244,592 indirect) bytes in 1 blocks are definitely lost in loss record 33 of 33 ==22313== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==22313== by 0x68BA49B: ??? ==22313== by 0x68BC248: ??? ==22313== by 0x68BC483: ??? ==22313== by 0x68B9FE4: ??? ==22313== by 0x685D550: ??? ==22313== by 0x6874C1F: ??? ==22313== by 0x68A4C5D: ??? ==22313== by 0x5366AD4: ??? (in /usr/lib/libp11-kit.so.0.0.0) ==22313== by 0x536785B: ??? (in /usr/lib/libp11-kit.so.0.0.0) ==22313== by 0x5367E8B: p11_kit_initialize_registered (in /usr/lib/libp11-kit.so.0.0.0) ==22313== by 0x4E76CCD: gnutls_pkcs11_init (pkcs11.c:448) ==22313== FAIL: srn0 Self test `./srn1' finished with 0 errors ==22328== 4 bytes in 1 blocks are definitely lost in loss record 2 of 33 ==22328== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==22328== by 0x55EF881: strdup (strdup.c:43) ==22328== by 0x536717B: p11_kit_registered_module_to_name (in /usr/lib/libp11-kit.so.0.0.0) ==22328== by 0x4E76D04: gnutls_pkcs11_init (pkcs11.c:462) ==22328== by 0x4E5D23A: gnutls_global_init (gnutls_global.c:252) ==22328== by 0x40121A: doit (srn1.c:101) ==22328== by 0x4016F4: main (utils.c:149) ==22328== ==22328== 252,824 (8,232 direct, 244,592 indirect) bytes in 1 blocks are definitely lost in loss record 33 of 33 ==22328== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==22328== by 0x68BA49B: ??? ==22328== by 0x68BC248: ??? ==22328== by 0x68BC483: ??? ==22328== by 0x68B9FE4: ??? ==22328== by 0x685D550: ??? ==22328== by 0x6874C1F: ??? ==22328== by 0x68A4C5D: ??? ==22328== by 0x5366AD4: ??? (in /usr/lib/libp11-kit.so.0.0.0) ==22328== by 0x536785B: ??? (in /usr/lib/libp11-kit.so.0.0.0) ==22328== by 0x5367E8B: p11_kit_initialize_registered (in /usr/lib/libp11-kit.so.0.0.0) ==22328== by 0x4E76CCD: gnutls_pkcs11_init (pkcs11.c:448) ==22328== FAIL: srn1 Self test `./srn2' finished with 0 errors ==22343== 4 bytes in 1 blocks are definitely lost in loss record 2 of 33 ==22343== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==22343== by 0x55EF881: strdup (strdup.c:43) ==22343== by 0x536717B: p11_kit_registered_module_to_name (in /usr/lib/libp11-kit.so.0.0.0) ==22343== by 0x4E76D04: gnutls_pkcs11_init (pkcs11.c:462) ==22343== by 0x4E5D23A: gnutls_global_init (gnutls_global.c:252) ==22343== by 0x4012CC: doit (srn2.c:99) ==22343== by 0x401B54: main (utils.c:149) ==22343== ==22343== 252,824 (8,232 direct, 244,592 indirect) bytes in 1 blocks are definitely lost in loss record 33 of 33 ==22343== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==22343== by 0x68BA49B: ??? ==22343== by 0x68BC248: ??? ==22343== by 0x68BC483: ??? ==22343== by 0x68B9FE4: ??? ==22343== by 0x685D550: ??? ==22343== by 0x6874C1F: ??? ==22343== by 0x68A4C5D: ??? ==22343== by 0x5366AD4: ??? (in /usr/lib/libp11-kit.so.0.0.0) ==22343== by 0x536785B: ??? (in /usr/lib/libp11-kit.so.0.0.0) ==22343== by 0x5367E8B: p11_kit_initialize_registered (in /usr/lib/libp11-kit.so.0.0.0) ==22343== by 0x4E76CCD: gnutls_pkcs11_init (pkcs11.c:448) ==22343== FAIL: srn2 Self test `./srn3' finished with 0 errors ==22358== 4 bytes in 1 blocks are definitely lost in loss record 2 of 33 ==22358== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==22358== by 0x55EF881: strdup (strdup.c:43) ==22358== by 0x536717B: p11_kit_registered_module_to_name (in /usr/lib/libp11-kit.so.0.0.0) ==22358== by 0x4E76D04: gnutls_pkcs11_init (pkcs11.c:462) ==22358== by 0x4E5D23A: gnutls_global_init (gnutls_global.c:252) ==22358== by 0x40121A: doit (srn3.c:101) ==22358== by 0x4016E4: main (utils.c:149) ==22358== ==22358== 252,824 (8,232 direct, 244,592 indirect) bytes in 1 blocks are definitely lost in loss record 33 of 33 ==22358== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==22358== by 0x68BA49B: ??? ==22358== by 0x68BC248: ??? ==22358== by 0x68BC483: ??? ==22358== by 0x68B9FE4: ??? ==22358== by 0x685D550: ??? ==22358== by 0x6874C1F: ??? ==22358== by 0x68A4C5D: ??? ==22358== by 0x5366AD4: ??? (in /usr/lib/libp11-kit.so.0.0.0) ==22358== by 0x536785B: ??? (in /usr/lib/libp11-kit.so.0.0.0) ==22358== by 0x5367E8B: p11_kit_initialize_registered (in /usr/lib/libp11-kit.so.0.0.0) ==22358== by 0x4E76CCD: gnutls_pkcs11_init (pkcs11.c:448) ==22358== FAIL: srn3 Self test `./srn4' finished with 0 errors ==22373== 4 bytes in 1 blocks are definitely lost in loss record 2 of 33 ==22373== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==22373== by 0x55EF881: strdup (strdup.c:43) ==22373== by 0x536717B: p11_kit_registered_module_to_name (in /usr/lib/libp11-kit.so.0.0.0) ==22373== by 0x4E76D04: gnutls_pkcs11_init (pkcs11.c:462) ==22373== by 0x4E5D23A: gnutls_global_init (gnutls_global.c:252) ==22373== by 0x4012CA: doit (srn4.c:101) ==22373== by 0x4018F4: main (utils.c:149) ==22373== ==22373== 252,824 (8,232 direct, 244,592 indirect) bytes in 1 blocks are definitely lost in loss record 33 of 33 ==22373== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==22373== by 0x68BA49B: ??? ==22373== by 0x68BC248: ??? ==22373== by 0x68BC483: ??? ==22373== by 0x68B9FE4: ??? ==22373== by 0x685D550: ??? ==22373== by 0x6874C1F: ??? ==22373== by 0x68A4C5D: ??? ==22373== by 0x5366AD4: ??? (in /usr/lib/libp11-kit.so.0.0.0) ==22373== by 0x536785B: ??? (in /usr/lib/libp11-kit.so.0.0.0) ==22373== by 0x5367E8B: p11_kit_initialize_registered (in /usr/lib/libp11-kit.so.0.0.0) ==22373== by 0x4E76CCD: gnutls_pkcs11_init (pkcs11.c:448) ==22373== FAIL: srn4 Self test `./srn5' finished with 0 errors ==22388== 4 bytes in 1 blocks are definitely lost in loss record 2 of 33 ==22388== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==22388== by 0x55EF881: strdup (strdup.c:43) ==22388== by 0x536717B: p11_kit_registered_module_to_name (in /usr/lib/libp11-kit.so.0.0.0) ==22388== by 0x4E76D04: gnutls_pkcs11_init (pkcs11.c:462) ==22388== by 0x4E5D23A: gnutls_global_init (gnutls_global.c:252) ==22388== by 0x4012CA: doit (srn5.c:102) ==22388== by 0x4018E4: main (utils.c:149) ==22388== ==22388== 252,824 (8,232 direct, 244,592 indirect) bytes in 1 blocks are definitely lost in loss record 33 of 33 ==22388== at 0x4C244E8: malloc (vg_replace_malloc.c:236) ==22388== by 0x68BA49B: ??? ==22388== by 0x68BC248: ??? ==22388== by 0x68BC483: ??? ==22388== by 0x68B9FE4: ??? ==22388== by 0x685D550: ??? ==22388== by 0x6874C1F: ??? ==22388== by 0x68A4C5D: ??? ==22388== by 0x5366AD4: ??? (in /usr/lib/libp11-kit.so.0.0.0) ==22388== by 0x536785B: ??? (in /usr/lib/libp11-kit.so.0.0.0) ==22388== by 0x5367E8B: p11_kit_initialize_registered (in /usr/lib/libp11-kit.so.0.0.0) ==22388== by 0x4E76CCD: gnutls_pkcs11_init (pkcs11.c:448) ==22388== FAIL: srn5 =================================== 6 of 6 tests failed Please report to bug-gnutls at gnu.org =================================== make[4]: *** [check-TESTS] Error 1 make[4]: Leaving directory `/home/geg/tmp/gnutls26-2.12.20/tests/safe-renegotiation' make[3]: *** [check-am] Error 2 make[3]: Leaving directory `/home/geg/tmp/gnutls26-2.12.20/tests/safe-renegotiation' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/home/geg/tmp/gnutls26-2.12.20/tests' make[1]: *** [check-recursive] Fehler 1 make[1]: Leaving directory `/home/geg/tmp/gnutls26-2.12.20' make: *** [debian/stamp-makefile-check] Fehler 2 Regards Sven P.S.: I am running p11-kit 0.13 from debian -- "Those who do not understand Unix are condemned to reinvent it, poorly" (Henry Spencer) /me is giggls at ircnet, http://sven.gegg.us/ on the Web From nmav at gnutls.org Tue Aug 14 14:53:00 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 14 Aug 2012 14:53:00 +0200 Subject: hangs with active p11-kit modules In-Reply-To: <20120814093935.GA21090@geggus.net> References: <20120814093935.GA21090@geggus.net> Message-ID: On Tue, Aug 14, 2012 at 11:39 AM, Sven Geggus wrote: > Hello, > I encounter strange hangs on various pieces of software (cups, mutt, ...) > linked against gnutls (2.12.x) with an active pkcs11 smartcard module. This > module is not used by these applications, they are just linked against > gnutls. GnuTLS uses any active PKCS #11 modules. In any applications that use gnutls you may provide a pkcs11 url and access your keys and certificates stored in smart cards or tokens as it would have been in a file. > This goes this far that building gnutls with an active pkcs11 module takes > ages because of very long delays in various gnutls self-tests and after some > very long delay in almost every single test the build fails with the following messages: That is because several pkcs11 modules have memory leaks and delays on initialization. gnutls 3.0.22 isn't so strict on the test suite to avoid those errors. regards, Nikos From INVALID.NOREPLY at gnu.org Tue Aug 14 15:08:33 2012 From: INVALID.NOREPLY at gnu.org (Alexandre Chataignon) Date: Tue, 14 Aug 2012 13:08:33 +0000 Subject: [sr #108090] Unable to decode PKCS12 with NULL password since 3.0.20 In-Reply-To: <20120726-081403.sv88698.37017@savannah.gnu.org> References: <20120718-165700.sv88698.84726@savannah.gnu.org> <20120719-231510.sv707.61446@savannah.gnu.org> <20120719-213235.sv88698.80504@savannah.gnu.org> <20120720-010933.sv707.70079@savannah.gnu.org> <20120719-222439.sv88698.53332@savannah.gnu.org> <20120720-072625.sv0.3763@savannah.gnu.org> <20120726-081403.sv88698.37017@savannah.gnu.org> Message-ID: <20120814-130833.sv88698.11249@savannah.gnu.org> Follow-up Comment #6, sr #108090 (project gnutls): I have attached the file since July 26, have you stated on the problem ? _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Aug 14 15:12:03 2012 From: INVALID.NOREPLY at gnu.org (Alexandre Chataignon) Date: Tue, 14 Aug 2012 13:12:03 +0000 Subject: [sr #108090] Unable to decode PKCS12 with NULL password since 3.0.20 In-Reply-To: <20120814-130833.sv88698.11249@savannah.gnu.org> References: <20120718-165700.sv88698.84726@savannah.gnu.org> <20120719-231510.sv707.61446@savannah.gnu.org> <20120719-213235.sv88698.80504@savannah.gnu.org> <20120720-010933.sv707.70079@savannah.gnu.org> <20120719-222439.sv88698.53332@savannah.gnu.org> <20120720-072625.sv0.3763@savannah.gnu.org> <20120726-081403.sv88698.37017@savannah.gnu.org> <20120814-130833.sv88698.11249@savannah.gnu.org> Message-ID: <20120814-131203.sv88698.23454@savannah.gnu.org> Follow-up Comment #7, sr #108090 (project gnutls): Sorry, didn't see it was included in 3.0.22, thank you very much _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Tue Aug 14 15:47:30 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 14 Aug 2012 15:47:30 +0200 Subject: hangs with active p11-kit modules In-Reply-To: <20120814133658.GA26428@geggus.net> References: <20120814093935.GA21090@geggus.net> <20120814133658.GA26428@geggus.net> Message-ID: On Tue, Aug 14, 2012 at 3:36 PM, Sven Geggus wrote: >> In any applications that use gnutls you may provide a pkcs11 url and >> access your keys and certificates stored in smart cards or tokens as it >> would have been in a file. > Fine in principle, but what is causing these annoing delays? Your pkcs11 module. You can disable it if you don't use it. regards, Nikos From nmav at gnutls.org Tue Aug 14 18:11:56 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 14 Aug 2012 18:11:56 +0200 Subject: hangs with active p11-kit modules In-Reply-To: <20120814141236.GA27063@geggus.net> References: <20120814093935.GA21090@geggus.net> <20120814133658.GA26428@geggus.net> <20120814141236.GA27063@geggus.net> Message-ID: On Tue, Aug 14, 2012 at 4:12 PM, Sven Geggus wrote: >> Your pkcs11 module. You can disable it if you don't use it. > I really do not want to disable it as I need it for VPN. > What would probably be needed then is some kind of application blacklist or > whitelist in p11-kit - right? Yes (as you say in your next e-mail). > It simply does not make sence for any application to query a smartcard which > has not even been unlocked as this will never succeed. There is no such notion as an unlocked smart card. A key may be protected by PIN in the smart card but it is not mandatory. Nevertheless, the gnutls initialization only initializes the pkcs11 driver, which reports the number of slots available etc, it doesn't access any smart card. I wouldn't expect a long delay on that, unless there is some issue in the driver you're using. > I still do not completely undestand why stuff like "lpq" and "mutt" query > the pkcs11-module at all. Well it would be nice if mutt could handle S/MIME > encrypted emails using pkcs11, but it doesn't. As I told you any application using gnutls may accept pkcs11 URLs in addition to files to specify private keys (e.g. your key to login to your smtp server). For that to work any pkcs11 module/driver has to be initialized when gnutls starts. If a pin is required, then this can be read from a file (using the pin-source directive), or the user may be prompted for a password using a callback. About lpq, I have no idea why it uses gnutls. regards, Nikos From nmav at gnutls.org Tue Aug 14 20:31:11 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 14 Aug 2012 20:31:11 +0200 Subject: Problem compiling gnutls In-Reply-To: <50296D2E.4070007@aero.org> References: <50252E93.5010405@gmail.com> <50296D2E.4070007@aero.org> Message-ID: <502A996F.5090303@gnutls.org> On 08/13/2012 11:10 PM, B. Scott Michel wrote: > On 8/10/2012 10:42 PM, Vincent Torri wrote: >> the correct fix is to check if these functions are available in >> configure.ac and declare/define them conditionally in the cpp file > > Amazingly insightful answer. > > I can successfully compile 3.0.17 using the mingw-64 compiler without > issues. I haven't tried 3.0.22 yet. I do all of my work under MSys. I > try to avoid cygwin; see below. > > configure (and configure.ac) look for vasprintf. The scripts do not look > for asprintf, specifically. Two reasons why you might have problems: Is there anything gnutls could check to avoid this issue? Any suggested patch? regards, Nikos From sven at gegg.us Tue Aug 14 15:36:58 2012 From: sven at gegg.us (Sven Geggus) Date: Tue, 14 Aug 2012 15:36:58 +0200 Subject: hangs with active p11-kit modules In-Reply-To: References: <20120814093935.GA21090@geggus.net> Message-ID: <20120814133658.GA26428@geggus.net> Nikos Mavrogiannopoulos schrieb am Dienstag, den 14. August um 14:53 Uhr: > GnuTLS uses any active PKCS #11 modules. Most Smartcards can not be used without a password. It is really annoying whenn "lpq" returns just minutes after actually doing something. > In any applications that use gnutls you may provide a pkcs11 url and > access your keys and certificates stored in smart cards or tokens as it > would have been in a file. Fine in principle, but what is causing these annoing delays? Sven -- "If you don't make lower-resolution mapping data publicly available, there will be people with their cars and GPS devices, driving around with their laptops" (Tim Berners-Lee) /me is giggls at ircnet, http://sven.gegg.us/ on the Web From sven at gegg.us Tue Aug 14 16:12:36 2012 From: sven at gegg.us (Sven Geggus) Date: Tue, 14 Aug 2012 16:12:36 +0200 Subject: hangs with active p11-kit modules In-Reply-To: References: <20120814093935.GA21090@geggus.net> <20120814133658.GA26428@geggus.net> Message-ID: <20120814141236.GA27063@geggus.net> Nikos Mavrogiannopoulos schrieb am Dienstag, den 14. August um 15:47 Uhr: > Your pkcs11 module. You can disable it if you don't use it. I really do not want to disable it as I need it for VPN. What would probably be needed then is some kind of application blacklist or whitelist in p11-kit - right? It simply does not make sence for any application to query a smartcard which has not even been unlocked as this will never succeed. I still do not completely undestand why stuff like "lpq" and "mutt" query the pkcs11-module at all. Well it would be nice if mutt could handle S/MIME encrypted emails using pkcs11, but it doesn't. Sven -- Unix is simple and coherent, but it takes a genius ? or at any rate a programmer ? to understand and appreciate the simplicity (Dennis M. Ritchie) /me is giggls at ircnet, http://sven.gegg.us/ on the Web From sven at gegg.us Tue Aug 14 16:21:30 2012 From: sven at gegg.us (Sven Geggus) Date: Tue, 14 Aug 2012 16:21:30 +0200 Subject: hangs with active p11-kit modules In-Reply-To: <20120814141236.GA27063@geggus.net> References: <20120814093935.GA21090@geggus.net> <20120814133658.GA26428@geggus.net> <20120814141236.GA27063@geggus.net> Message-ID: <20120814142130.GA27487@geggus.net> Sven Geggus schrieb am Dienstag, den 14. August um 16:12 Uhr: > What would probably be needed then is some kind of application blacklist or > whitelist in p11-kit - right? Ahh YFTR: Reading p11kit documentation I found there already is both of them. http://p11-glue.freedesktop.org/doc/p11-kit/config-module.html enable-in and/or disable-in is exactly what I need. Regards Sven -- Kernel panic: I have no root and I want to scream (Linux Kernel Error Message) /me is giggls at ircnet, http://sven.gegg.us/ on the Web From sven at gegg.us Tue Aug 14 21:18:49 2012 From: sven at gegg.us (Sven Geggus) Date: Tue, 14 Aug 2012 21:18:49 +0200 Subject: hangs with active p11-kit modules In-Reply-To: References: <20120814093935.GA21090@geggus.net> <20120814133658.GA26428@geggus.net> <20120814141236.GA27063@geggus.net> Message-ID: <20120814191848.GA2985@geggus.net> Nikos Mavrogiannopoulos schrieb am Dienstag, den 14. August um 18:11 Uhr: > About lpq, I have no idea why it uses gnutls. I'm quite certain, that this is because cups uses https for (at least) some communication. Regards Sven -- "and on the third day he rebooted into Linux-1.3.84" (Linus Torvalds, Easter Kernel Release 1996) /me is giggls at ircnet, http://sven.gegg.us/ on the Web From stefw at gnome.org Tue Aug 14 22:25:05 2012 From: stefw at gnome.org (Stef Walter) Date: Tue, 14 Aug 2012 22:25:05 +0200 Subject: hangs with active p11-kit modules In-Reply-To: References: <20120814093935.GA21090@geggus.net> <20120814133658.GA26428@geggus.net> <20120814141236.GA27063@geggus.net> Message-ID: <502AB421.9080809@gnome.org> On 08/14/2012 06:11 PM, Nikos Mavrogiannopoulos wrote: > There is no such notion as an unlocked smart card. A key may be > protected by PIN in the smart card but it is not mandatory. > Nevertheless, the gnutls initialization only initializes the pkcs11 > driver, which reports the number of slots available etc, it doesn't > access any smart card. I wouldn't expect a long delay on that, unless > there is some issue in the driver you're using. The opensc driver when used with a Feitan token has this issue. C_Initialize takes forever. :( But I agree it's a problem with the module. Stef From nmav at gnutls.org Tue Aug 14 22:33:00 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 14 Aug 2012 22:33:00 +0200 Subject: hangs with active p11-kit modules In-Reply-To: <502AB421.9080809@gnome.org> References: <20120814093935.GA21090@geggus.net> <20120814133658.GA26428@geggus.net> <20120814141236.GA27063@geggus.net> <502AB421.9080809@gnome.org> Message-ID: <502AB5FC.9000401@gnutls.org> On 08/14/2012 10:25 PM, Stef Walter wrote: > On 08/14/2012 06:11 PM, Nikos Mavrogiannopoulos wrote: >> There is no such notion as an unlocked smart card. A key may be >> protected by PIN in the smart card but it is not mandatory. >> Nevertheless, the gnutls initialization only initializes the pkcs11 >> driver, which reports the number of slots available etc, it doesn't >> access any smart card. I wouldn't expect a long delay on that, unless >> there is some issue in the driver you're using. > > The opensc driver when used with a Feitan token has this issue. > C_Initialize takes forever. :( In that case Sven, could you report this delay to opensc or the pkcs11 module you're using? regards, Nikos From sven at gegg.us Tue Aug 14 22:47:00 2012 From: sven at gegg.us (Sven Geggus) Date: Tue, 14 Aug 2012 22:47:00 +0200 Subject: hangs with active p11-kit modules In-Reply-To: <502AB5FC.9000401@gnutls.org> References: <20120814093935.GA21090@geggus.net> <20120814133658.GA26428@geggus.net> <20120814141236.GA27063@geggus.net> <502AB421.9080809@gnome.org> <502AB5FC.9000401@gnutls.org> Message-ID: <20120814204658.GA4200@geggus.net> Nikos Mavrogiannopoulos schrieb am Dienstag, den 14. August um 22:33 Uhr: > In that case Sven, could you report this delay to opensc or the pkcs11 > module you're using? Unfortunately in my case we are talking about "quality" proprietary Software here :-( Sven -- If you can spend five minutes on the Internet and do not run Linux, you're a genius. (Dirk Hohndel) /me is giggls at ircnet, http://sven.gegg.us/ on the Web From scottm at aero.org Tue Aug 14 23:06:27 2012 From: scottm at aero.org (B. Scott Michel) Date: Tue, 14 Aug 2012 14:06:27 -0700 Subject: Problem compiling gnutls In-Reply-To: <502A996F.5090303@gnutls.org> References: <50252E93.5010405@gmail.com> <50296D2E.4070007@aero.org> <502A996F.5090303@gnutls.org> Message-ID: <502ABDD3.8030901@aero.org> On 8/14/2012 11:31 AM, Nikos Mavrogiannopoulos wrote: > I can successfully compile 3.0.17 using the mingw-64 compiler without > issues. I haven't tried 3.0.22 yet. I do all of my work under MSys. I > try to avoid cygwin; see below. > > configure (and configure.ac) look for vasprintf. The scripts do not look > for asprintf, specifically. Two reasons why you might have problems: > Is there anything gnutls could check to avoid this issue? Any suggested > patch? MinGW (32 and 64 bit) have an "alternative" stdio that's closer to GNU, but only if __USE_MINGW_ANSI_STDIO is defined. Otherwise, it should use the MSVCRT stdio, which has no asprintf() or vasprintf(). In the MinGW-W64 headers (mingw-w64-headers/crt/stdio.h), the declarations for asprintf() and vasprintf() are "#if 0"-ed out. The note reads: /* Disabled due issue of definition in POSIX way in libmingwex, which could cause troubles on scenarios venure expects those function in MS formatter style. So simplest way for now, disable it. */ So, I'm not sure why the user encountered the compile error, other than a clash with cygwin. -scooter From scottm at aero.org Wed Aug 15 01:27:24 2012 From: scottm at aero.org (B. Scott Michel) Date: Tue, 14 Aug 2012 16:27:24 -0700 Subject: Problem compiling gnutls In-Reply-To: <502A996F.5090303@gnutls.org> References: <50252E93.5010405@gmail.com> <50296D2E.4070007@aero.org> <502A996F.5090303@gnutls.org> Message-ID: <502ADEDC.7030806@aero.org> On 8/14/2012 11:31 AM, Nikos Mavrogiannopoulos wrote: > Is there anything gnutls could check to avoid this issue? Any suggested > patch? > > regards, > Nikos > I just did a test compile using 3.0.22 and mingw-w64's latest from subversion. The compile problem I've run into is a linker error (libopt depends on gettext -- patch forthcoming in the next day or two.) To be fair, though, I am tracking mingw-w64's current subversion repo and I compile both mingw-w64 runtime and gcc. Consequently, there may actually be an issue with the original poster's version of mingw-w64 currently installed in cygwin. -scooter From nmav at gnutls.org Wed Aug 15 22:50:47 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 15 Aug 2012 22:50:47 +0200 Subject: gnutls 3.1.0 Message-ID: <502C0BA7.7090302@gnutls.org> Hello, I've just released gnutls 3.1.0. This is release is a major feature update on gnutls 3.0.x, but is fully binary and source compatible with it. The main addition are support for the TPM module to store cryptographic keys, and simplified functions to access encrypted structures. * Version 3.1.0 (released 2012-08-15) ** libgnutls: Added direct support for TPM as a cryptographic module in gnutls/tpm.h. TPM keys can be used in functions accepting files using URLs of the following types: tpmkey:file=/path/to/file tpmkey:uuid=7f468c16-cb7f-11e1-824d-b3a4f4b20343;storage=user ** libgnutls: Priority string level keywords can be combined. For example the string "SECURE256:+SUITEB128" is now allowed. ** libgnutls: requires libnettle 2.5. ** libgnutls: Use the PKCS #1 1.5 encoding provided by nettle (2.5) for encryption and signatures. ** libgnutls: Added GNUTLS_CERT_SIGNATURE_FAILURE to differentiate between generic errors and signature verification errors in the verification functions. ** libgnutls: Added gnutls_pkcs12_simple_parse() as a helper function to simplify parsing in most PKCS #12 use cases. ** libgnutls: gnutls_certificate_set_x509_simple_pkcs12_file() adds the whole certificate chain (if any) to the credentials structure, instead of only the end-user certificate. ** libgnutls: Key import functions such as gnutls_pkcs12_simple_parse() and gnutls_x509_privkey_import_pkcs8(), return consistently GNUTLS_E_DECRYPTION_FAILED if the input structure is encrypted but no password was provided. ** libgnutls: Added gnutls_handshake_set_timeout() a function that allows to set the maximum time spent in a handshake. ** libgnutlsxx: Added session::set_transport_vec_push_function. Patch by Alexandre Bique. ** tpmtool: Added. It is a tool to generate private keys in the TPM. ** gnutls-cli: --benchmark-tls was split to --benchmark-tls-kx and --benchmark-tls-ciphers ** certtool: generated PKCS #12 structures may hold more than one private key. Patch by Lucas Fisher. ** certtool: Added option --null-password to generate/decrypt keys that use a NULL password (in schemas that distinguish between NULL an empty passwords). ** minitasn1: Upgraded to libtasn1 version 2.13. ** API and ABI modifications: GNUTLS_CERT_SIGNATURE_FAILURE: Added GNUTLS_CAMELLIA_192_CBC: Added GNUTLS_PKCS_NULL_PASSWORD: Added gnutls_url_is_supported: Added gnutls_pkcs11_obj_list_import_url2: Added gnutls_pkcs11_obj_set_pin_function: Added gnutls_pkcs11_privkey_set_pin_function: Added gnutls_pkcs11_get_pin_function: Added gnutls_privkey_import_tpm_raw: Added gnutls_privkey_import_tpm_url: Added gnutls_privkey_import_pkcs11_url: Added gnutls_privkey_import_openpgp_raw: Added gnutls_privkey_import_x509_raw: Added gnutls_privkey_import_ext2: Added gnutls_privkey_import_url: Added gnutls_privkey_set_pin_function: Added gnutls_tpm_privkey_generate: Added gnutls_tpm_key_list_deinit: Added gnutls_tpm_key_list_get_url: Added gnutls_tpm_get_registered: Added gnutls_tpm_privkey_delete: Added gnutls_pubkey_import_tpm_raw: Added gnutls_pubkey_import_tpm_url: Added gnutls_pubkey_import_url: Added gnutls_pubkey_verify_hash2: Added gnutls_pubkey_set_pin_function: Added gnutls_x509_privkey_import2: Added gnutls_x509_privkey_import_openssl: Added gnutls_x509_crt_set_pin_function: Added gnutls_load_file: Added gnutls_pkcs12_simple_parse: Added gnutls_certificate_set_x509_system_trust: Added gnutls_certificate_set_pin_function: Added gnutls_x509_trust_list_add_system_trust: Added gnutls_x509_trust_list_add_trust_file: Added gnutls_x509_trust_list_add_trust_mem: Added gnutls_pk_to_sign: Added gnutls_handshake_set_timeout: Added gnutls_pubkey_verify_hash: Deprecated (use gnutls_pubkey_verify_hash2) gnutls_pubkey_verify_data: Deprecated (use gnutls_pubkey_verify_data2) Getting the Software ==================== GnuTLS may be downloaded from one of the GNU mirror sites or directly >From . The list of GNU mirrors can be found at and a list of GnuTLS mirrors can be found at . Here are the XZ compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.0.tar.xz http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.0.tar.xz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.1.0.tar.xz Here are the LZIP compressed sources: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.0.tar.lz http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.0.tar.lz ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.1.0.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.0.tar.xz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.0.tar.xz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.1.0.tar.xz.sig ftp://ftp.gnu.org/gnu/gnutls/gnutls-3.1.0.tar.lz.sig http://ftp.gnu.org/gnu/gnutls/gnutls-3.1.0.tar.lz.sig ftp://ftp.gnutls.org/pub/gnutls/gnutls-3.1.0.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 dbreiser at gmail.com Thu Aug 16 07:37:03 2012 From: dbreiser at gmail.com (David Reiser) Date: Thu, 16 Aug 2012 01:37:03 -0400 Subject: gnutls 3.1.0 build issues Message-ID: <8621F9FE-027C-40AD-8815-DE7F83C04A18@gmail.com> Trying to build 3.1.0 in OS X using clang 4.0 from Apple's Xcode 4.4.1, configure gives me: checking for tss library... no configure: WARNING: *** *** trousers was not found. TPM support will be disabled. *** Neither the announcement nor the the docs that I can find mention a dependency on trousers. That probably should be corrected. Since TPM support is disabled, I then see compiling stop with: CC gnutls_supplemental.lo system.c:442:10: error: use of undeclared identifier 'r' return r; ^ 1 error generated. because r is declared after gnutls determines that it is going to return GNUTLS_E_UNIMPLEMENTED_FEATURE; but clang is being ornery about the final 'return r;' Dave -- David Reiser dbreiser at gmail.com From n.mavrogiannopoulos at gmail.com Thu Aug 16 10:28:33 2012 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Thu, 16 Aug 2012 10:28:33 +0200 Subject: gnutls 3.1.0 build issues In-Reply-To: <8621F9FE-027C-40AD-8815-DE7F83C04A18@gmail.com> References: <8621F9FE-027C-40AD-8815-DE7F83C04A18@gmail.com> Message-ID: <502CAF31.5020604@gmail.com> On 08/16/2012 07:37 AM, David Reiser wrote: > Trying to build 3.1.0 in OS X using clang 4.0 from Apple's Xcode 4.4.1, configure gives me: > > checking for tss library... no > configure: WARNING: > *** > *** trousers was not found. TPM support will be disabled. > *** > Neither the announcement nor the the docs that I can find mention a dependency on trousers. That probably should be corrected. Yes, a dependency on trousers is required when compiling with TPM support. > Since TPM support is disabled, I then see compiling stop with: > CC gnutls_supplemental.lo > system.c:442:10: error: use of undeclared identifier 'r' > return r; > 1 error generated. > because r is declared after gnutls determines that it is going to > return GNUTLS_E_UNIMPLEMENTED_FEATURE; > but clang is being ornery about the final 'return r;' Thanks. I've committed a fix. regards, Nikos From mabrand at mabrand.nl Thu Aug 16 11:41:33 2012 From: mabrand at mabrand.nl (Mark Brand) Date: Thu, 16 Aug 2012 11:41:33 +0200 Subject: [PATCH] fix case of include file Message-ID: <502CC04D.5030308@mabrand.nl> The case matters when cross-building on unix for windows. regard, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fix-case-of-include-file.patch Type: text/x-patch Size: 458 bytes Desc: not available URL: From nmav at gnutls.org Thu Aug 16 19:03:17 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 16 Aug 2012 19:03:17 +0200 Subject: [PATCH] fix case of include file In-Reply-To: <502CC04D.5030308@mabrand.nl> References: <502CC04D.5030308@mabrand.nl> Message-ID: <502D27D5.9080308@gnutls.org> On 08/16/2012 11:41 AM, Mark Brand wrote: > The case matters when cross-building on unix for windows. Thank you. Applied. regards, Nikos From INVALID.NOREPLY at gnu.org Thu Aug 23 03:40:17 2012 From: INVALID.NOREPLY at gnu.org (Brad Smith) Date: Thu, 23 Aug 2012 01:40:17 +0000 Subject: [sr #108119] Fix for gnutls' pkg-config file with static linking Message-ID: <20120823-014017.sv67648.96215@savannah.gnu.org> URL: Summary: Fix for gnutls' pkg-config file with static linking Project: GnuTLS Submitted by: brad0 Submitted on: Thu 23 Aug 2012 01:40:17 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: The current pkg-config file for gnutls is missing -lpthread for the static linking scenario. The attached patch adds -lpthread to Libs.private. _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Thu 23 Aug 2012 01:40:17 AM GMT Name: patch-lib_gnutls_pc_in Size: 455B By: brad0 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From ametzler at downhill.at.eu.org Sun Aug 26 18:34:53 2012 From: ametzler at downhill.at.eu.org (Andreas Metzler) Date: Sun, 26 Aug 2012 18:34:53 +0200 Subject: gnutls 3.1.0 spurious test-suite failure Message-ID: <20120826163453.GA2689@downhill.g.la> Hello, I have uploade 3.1.0 to Debian/experimental today, just to check buildability. About half of the builds failed with a testsuite failure like this one: ------------------------------ PASS: mini-emsgsize-dtls Child died with status 1 Self test `./mini-handshake-timeout' finished with 1 errors FAIL: mini-handshake-timeout PASS: ocsp ------------------------------ I do not see the error locally (tried on amd64) comparing a successful awith a failed buildlog was not enlightening either (I looked at armhf and armel.) Any ideas? cu andreas https://buildd.debian.org/status/package.php?p=gnutls28&suite=experimental From n.mavrogiannopoulos at gmail.com Mon Aug 27 18:22:03 2012 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Mon, 27 Aug 2012 18:22:03 +0200 Subject: gnutls 3.1.0 spurious test-suite failure In-Reply-To: <20120826163453.GA2689@downhill.g.la> References: <20120826163453.GA2689@downhill.g.la> Message-ID: <503B9EAB.9010601@gmail.com> On 08/26/2012 06:34 PM, Andreas Metzler wrote: > Hello, > > I have uploade 3.1.0 to Debian/experimental today, just to check > buildability. About half of the builds failed with a testsuite failure > like this one: > ------------------------------ > PASS: mini-emsgsize-dtls > Child died with status 1 > Self test `./mini-handshake-timeout' finished with 1 errors > FAIL: mini-handshake-timeout Interesting. This is a timeout test. Could you run the test with the "-v" option on one of the machines that fail? regards, Nikos From tim.ruehsen at gmx.de Tue Aug 28 12:23:23 2012 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Tue, 28 Aug 2012 12:23:23 +0200 Subject: Loading credentials in verify callback just as needed ? Message-ID: <201208281223.23642.tim.ruehsen@gmx.de> Hi, maybe you can help me or point me to the right direction. My problem: GnuTLS initialization - as used in tools like wget - loads ALL .pem files from e.g. /etc/ssl/certs/. This takes 'ages' on slow computers (there are hundreds of certificates). I can't believe that all these certs are needed to handshake one single HTTPS connection. I am looking for a way to just load the needed certs (very likely with the verification callback function). The current code is mainly taken from the GnuTLS example client code. It's initialization looks like gnutls_global_init(); gnutls_certificate_allocate_credentials(&credentials); gnutls_certificate_set_verify_function(credentials,_verify_certificate_callback); * now loading all files in ca_directory by calling gnutls_certificate_set_x509_trust_file(credentials, fname, GNUTLS_X509_FMT_PEM); While handshaking _verify_certificate_callback is called and contains: gnutls_certificate_verify_peers2() * do some checks... gnutls_certificate_get_peers() gnutls_x509_crt_import() * do more checks To reduce startup load, my idea is leaving away gnutls_certificate_set_x509_trust_file() while initialization and call it right before gnutls_certificate_verify_peers2() while handshaking. But how do I know which files to load right here. There must be some way to find that out which files/certs are needed. As far as I know, OpenSSL is doing something similar using some kind of hashes (c_rehash). Does anyone can help ? FYI, here is a valgrind summary of mget1.14 downloading https://www.google.de using GnuTLS 3.0.22 (up-to-date Debian SID) == HEAP SUMMARY: == total heap usage: 1,808,439 allocs, 1,626,939 frees, 168,972,716 bytes allocated same with using OpenSSL == HEAP SUMMARY: == total heap usage: 5,170 allocs, 1,503 frees, 418,739 bytes allocated and one for http://www.google.de == HEAP SUMMARY: == total heap usage: 454 allocs, 416 frees, 118,981 bytes allocated Cachegrinding wget/GnuTLS shows a 97% impact lies in gnutls_certificate_set_x509_trust_file(). Now you know, why I want to avoid calling it too often. Regards, Tim Ruehsen From nmav at gnutls.org Wed Aug 29 13:30:15 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 29 Aug 2012 13:30:15 +0200 Subject: Loading credentials in verify callback just as needed ? In-Reply-To: <201208281223.23642.tim.ruehsen@gmx.de> References: <201208281223.23642.tim.ruehsen@gmx.de> Message-ID: On Tue, Aug 28, 2012 at 12:23 PM, Tim Ruehsen wrote: > Hi, maybe you can help me or point me to the right direction. > > My problem: > GnuTLS initialization - as used in tools like wget - loads ALL .pem files from > e.g. /etc/ssl/certs/. This takes 'ages' on slow computers (there are hundreds > of certificates). > I can't believe that all these certs are needed to handshake one single HTTPS > connection. In the current Internet trust situation most probably you need all of those. > I am looking for a way to just load the needed certs (very likely with the > verification callback function). > The current code is mainly taken from the GnuTLS example client code. > It's initialization looks like > gnutls_global_init(); > gnutls_certificate_allocate_credentials(&credentials); > gnutls_certificate_set_verify_function(credentials,_verify_certificate_callback); > * now loading all files in ca_directory by calling > gnutls_certificate_set_x509_trust_file(credentials, fname, > GNUTLS_X509_FMT_PEM); You may also use gnutls_certificate_set_x509_system_trust() for this purpose. > To reduce startup load, my idea is leaving away > gnutls_certificate_set_x509_trust_file() > while initialization and call it right before > gnutls_certificate_verify_peers2() > while handshaking. I'm surprised that this function takes long for you. How many certificates do you have an which version of gnutls is that? > But how do I know which files to load right here. > There must be some way to find that out which files/certs are needed. > As far as I know, OpenSSL is doing something similar using some kind of hashes > (c_rehash). > Does anyone can help ? GnuTLS doesn't have something similar to that, like loading the CA file on demand. You could of course simulate that functionality by using the certificate's authority key identifier, or the issuer's name. What I'd do if loading time was an issue, is to delegate verification to a special process that has the CAs loaded already. regards, Nikos From olyasib12 at gmail.com Wed Aug 29 22:10:51 2012 From: olyasib12 at gmail.com (Olya) Date: Wed, 29 Aug 2012 22:10:51 +0200 Subject: [PATCH] Heratbeat support implemented during GSoC Message-ID: <503E774B.3040603@gmail.com> Hello. Attached are the patches resulted from my GSoC project this summer. And few small corrections discovered afterwards :) Those patches add rfc 6520 (heartbeat) extension support. They were tested against openssl for compatibility. However no "real world" testing was done e. g. no dedicated programs, just slight modification of existing echo client\server. So testing, corrections, suggestions are more than welcomed. Please review and merge if possible. -- best regards, Olga. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-Conflicts.patch Type: text/x-patch Size: 2207 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fix-indentation.patch Type: text/x-patch Size: 18202 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Remove-useless-check.patch Type: text/x-patch Size: 888 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Add-Heartbeat-extension-support.patch Type: text/x-patch Size: 63345 bytes Desc: not available URL: From itumaykin at gmail.com Thu Aug 30 10:41:42 2012 From: itumaykin at gmail.com (Ilya Tumaykin) Date: Thu, 30 Aug 2012 12:41:42 +0400 Subject: [PATCH] wMNAF-based multiplication Message-ID: <2107604.LUmpacYJdC@ion> Hello everyone. Introducing a patch with wMNAF-based ECC scalar point multiplication. Together with cache-aware and timing resistant versions. Part of GSoC 2012. Also added several functions for low-level ECC point operations like negate_point, isneutral and a faster add_point called add_point_ng. Switched everywhere to newer functions and added proper handling of neutral point in existing add_point and dbl_point functions. Overall speedup in integrated gnutls benchmark is about 8-18% measured in trans./sec. The best results are achieved with the greatest number of bits available (521 bits). For correctness tests, benchmarks and more please see git://bonespirit.dyndns.org/ellcurves.git -- Best regards. Tumaykin Ilya. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-wMNAF-based-multiplication.patch Type: text/x-patch Size: 63218 bytes Desc: not available URL: From nmav at gnutls.org Thu Aug 30 22:29:24 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 30 Aug 2012 22:29:24 +0200 Subject: [PATCH] wMNAF-based multiplication In-Reply-To: <2107604.LUmpacYJdC@ion> References: <2107604.LUmpacYJdC@ion> Message-ID: <503FCD24.3080606@gnutls.org> On 08/30/2012 10:41 AM, Ilya Tumaykin wrote: > Hello everyone. > > Introducing a patch with wMNAF-based ECC scalar point multiplication. > Together with cache-aware and timing resistant versions. Part of GSoC 2012. > > Also added several functions for low-level ECC point operations like > negate_point, isneutral and a faster add_point called add_point_ng. > > Switched everywhere to newer functions and added proper handling > of neutral point in existing add_point and dbl_point functions. > > Overall speedup in integrated gnutls benchmark is about 8-18% > measured in trans./sec. The best results are achieved with the > greatest number of bits available (521 bits). Thank you Ilya, I've applied it in master. I only needed a small fix to avoid an issue during deinitialization. The code seems to be pretty much ready for inclusion in 3.1.x. I'll pass it once more and add it. regards, Nikos From nmav at gnutls.org Thu Aug 30 22:35:24 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 30 Aug 2012 22:35:24 +0200 Subject: [PATCH] Heratbeat support implemented during GSoC In-Reply-To: <503E774B.3040603@gmail.com> References: <503E774B.3040603@gmail.com> Message-ID: <503FCE8C.1040700@gnutls.org> On 08/29/2012 10:10 PM, Olya wrote: > Hello. > > Attached are the patches resulted from my GSoC project this summer. And few small > corrections discovered afterwards :) > > Those patches add rfc 6520 (heartbeat) extension support. They were tested against > openssl for compatibility. However no "real world" testing was done e. g. no > dedicated programs, just slight modification of existing echo client\server. So > testing, corrections, suggestions are more than welcomed. Thank you Olga, I've just applied it to master. I'll give it a final refinement and after that I think it could be added in the 3.1.x branch. regards, Nikos From tim.ruehsen at gmx.de Thu Aug 30 13:07:08 2012 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Thu, 30 Aug 2012 13:07:08 +0200 Subject: Loading credentials in verify callback just as needed ? In-Reply-To: References: <201208281223.23642.tim.ruehsen@gmx.de> Message-ID: <201208301307.08469.tim.ruehsen@gmx.de> Am Wednesday 29 August 2012 schrieb Nikos Mavrogiannopoulos: > On Tue, Aug 28, 2012 at 12:23 PM, Tim Ruehsen wrote: > > Hi, maybe you can help me or point me to the right direction. > > > > My problem: > > GnuTLS initialization - as used in tools like wget - loads ALL .pem files > > from e.g. /etc/ssl/certs/. This takes 'ages' on slow computers (there > > are hundreds of certificates). > > I can't believe that all these certs are needed to handshake one single > > HTTPS connection. > > In the current Internet trust situation most probably you need all of > those. > > > I am looking for a way to just load the needed certs (very likely with > > the verification callback function). > > The current code is mainly taken from the GnuTLS example client code. > > It's initialization looks like > > gnutls_global_init(); > > gnutls_certificate_allocate_credentials(&credentials); > > gnutls_certificate_set_verify_function(credentials,_verify_certificate_ca > > llback); > > > > * now loading all files in ca_directory by calling > > > > gnutls_certificate_set_x509_trust_file(credentials, fname, > > GNUTLS_X509_FMT_PEM); > > You may also use gnutls_certificate_set_x509_system_trust() for this > purpose. > > > To reduce startup load, my idea is leaving away > > > > gnutls_certificate_set_x509_trust_file() > > > > while initialization and call it right before > > > > gnutls_certificate_verify_peers2() > > > > while handshaking. > > I'm surprised that this function takes long for you. How many > certificates do you have an which version of gnutls is that? There are 150 certs at the moment. GnuTLS 3.0.22 uses ~1.8 millions of malloc()s to read these files in. OpenSSL just ~5.000. On my rather old AMD 2000+ it takes ~1s to load these. Using valgrind for development (wget1.14), it takes around 30-40s. See some output at the end of my inital post (i meant to write Wget1.14 there, not mget1.14). > > But how do I know which files to load right here. > > There must be some way to find that out which files/certs are needed. > > As far as I know, OpenSSL is doing something similar using some kind of > > hashes (c_rehash). > > Does anyone can help ? > > GnuTLS doesn't have something similar to that, like loading the CA > file on demand. > You could of course simulate that functionality by using the > certificate's authority key identifier, or the issuer's name. Here is exactly the point, where you could help me. I would like to do that. But when the verification callback function is called (set by gnutls_certificate_set_verify_function()), information about the key id or issuer seem not to be available. The function is being called somewhere while handshaking. After handshaking at least some info seems to be available: Here is some output from the *_get_name() functions after handshake. At the beginning of the verfify callback function, these fields are empty. Key Exchange: ECDHE-RSA Certificate info [0]: Certificate is valid since: Thu Jan 1 00:59:59 1970 Certificate expires: Thu Jan 1 00:59:59 1970 Certificate fingerprint: 83c997fda1c6a2b8d60ade7de771cc66 Certificate public key: UNKNOWN Certificate version: #1 DN: Certificate Issuer's DN: Certificate info [1]: Certificate is valid since: Thu Jan 1 00:59:59 1970 Certificate expires: Thu Jan 1 00:59:59 1970 Certificate fingerprint: 33a0ea980e3d6e261d772d82df66007d Certificate public key: UNKNOWN Certificate version: #1 DN: Certificate Issuer's DN: Ephemeral ECDH using curve SECP256R1 Protocol: TLS1.2 Certificate Type: X.509 Compression: NULL Cipher: AES-128-CBC MAC: SHA1 Which of these informations can be used for my purpose. > What I'd do if loading time was an issue, is to delegate verification to a > special process that has the CAs loaded already. Wget is in most cases a short time runner. Starting/Stopping a process/thread to load the CA files would even increase the impact on CPU load. > regards, > Nikos Regards, Tim From nmav at gnutls.org Thu Aug 30 22:55:56 2012 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 30 Aug 2012 22:55:56 +0200 Subject: Loading credentials in verify callback just as needed ? In-Reply-To: <201208301307.08469.tim.ruehsen@gmx.de> References: <201208281223.23642.tim.ruehsen@gmx.de> <201208301307.08469.tim.ruehsen@gmx.de> Message-ID: <503FD35C.7030305@gnutls.org> On 08/30/2012 01:07 PM, Tim Ruehsen wrote: >> I'm surprised that this function takes long for you. How many >> certificates do you have an which version of gnutls is that? > There are 150 certs at the moment. > GnuTLS 3.0.22 uses ~1.8 millions of malloc()s to read these files in. > OpenSSL just ~5.000. Ouch. It's the libtasn1's operation that uses quite excessively malloc to parse the X.509 structures and create a tree, but 1.8 million for 150 certificates seems too much. Most probably an optimization there would eliminate the issue you see. > On my rather old AMD 2000+ it takes ~1s to load these. > Using valgrind for development (wget1.14), it takes around 30-40s. > See some output at the end of my inital post (i meant to write Wget1.14 there, > not mget1.14). Ouch. >> GnuTLS doesn't have something similar to that, like loading the CA >> file on demand. >> You could of course simulate that functionality by using the >> certificate's authority key identifier, or the issuer's name. > Here is exactly the point, where you could help me. > I would like to do that. > But when the verification callback function is called (set by > gnutls_certificate_set_verify_function()), information about the key id or > issuer seem not to be available. You can obtain the peer's certificate. gnutls_certificate_get_peers() convert it to a gnutls_x509_crt_t and then read the key id or issuer. regards, Nikos From ml at smtp.fakessh.eu Fri Aug 31 00:24:59 2012 From: ml at smtp.fakessh.eu (ml) Date: Fri, 31 Aug 2012 00:24:59 +0200 Subject: small point of detail Message-ID: <1346365499.28169.6.camel@localhost> hello all gurus I just go a small part of the code and I wonder one thing that is a small point of detail *_entry = gnutls_calloc (1, sizeof (SRP_PWD_ENTRY)); if (*_entry == NULL) { gnutls_assert (); return GNUTLS_E_MEMORY_ERROR; } entry = *_entry; i do not understand this line *_entry is allocated of the same size ? please answer me -- http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC2626742 gpg --keyserver pgp.mit.edu --recv-key C2626742 http://about.me/fakessh http://urlshort.eu fakessh @ http://gplus.to/sshfake http://gplus.to/sshswilting http://gplus.to/john.swilting https://lists.fakessh.eu/mailman/ This list is moderated by me, but all applications will be accepted provided they receive a note of presentation -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ml at smtp.fakessh.eu Fri Aug 31 00:29:45 2012 From: ml at smtp.fakessh.eu (ml) Date: Fri, 31 Aug 2012 00:29:45 +0200 Subject: small point of detail In-Reply-To: <1346365499.28169.6.camel@localhost> References: <1346365499.28169.6.camel@localhost> Message-ID: <1346365785.28169.9.camel@localhost> this feature is a point of detail to the file auth_srp_passwd.c line 266 gnutls 2 last release Le vendredi 31 ao?t 2012 ? 00:24 +0200, ml a ?crit : > hello all gurus > I just go a small part of the code and I wonder one thing that is a > small point of detail > > *_entry = gnutls_calloc (1, sizeof (SRP_PWD_ENTRY)); > if (*_entry == NULL) > { > gnutls_assert (); > return GNUTLS_E_MEMORY_ERROR; > } > entry = *_entry; > > i do not understand this line > *_entry is allocated of the same size ? > > please answer me > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > https://lists.gnu.org/mailman/listinfo/gnutls-devel -- http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC2626742 gpg --keyserver pgp.mit.edu --recv-key C2626742 http://about.me/fakessh http://urlshort.eu fakessh @ http://gplus.to/sshfake http://gplus.to/sshswilting http://gplus.to/john.swilting https://lists.fakessh.eu/mailman/ This list is moderated by me, but all applications will be accepted provided they receive a note of presentation -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From tim.ruehsen at gmx.de Fri Aug 31 17:45:17 2012 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Fri, 31 Aug 2012 17:45:17 +0200 Subject: Loading credentials in verify callback just as needed ? In-Reply-To: <503FD35C.7030305@gnutls.org> References: <201208281223.23642.tim.ruehsen@gmx.de> <201208301307.08469.tim.ruehsen@gmx.de> <503FD35C.7030305@gnutls.org> Message-ID: <201208311745.17824.tim.ruehsen@gmx.de> Am Thursday 30 August 2012 schrieb Nikos Mavrogiannopoulos: > > There are 150 certs at the moment. > > GnuTLS 3.0.22 uses ~1.8 millions of malloc()s to read these files in. > > OpenSSL just ~5.000. > > Ouch. It's the libtasn1's operation that uses quite excessively malloc > to parse the X.509 structures and create a tree, but 1.8 million for 150 > certificates seems too much. Most probably an optimization there would > eliminate the issue you see. > > > On my rather old AMD 2000+ it takes ~1s to load these. > > Using valgrind for development (wget1.14), it takes around 30-40s. > > See some output at the end of my inital post (i meant to write Wget1.14 > > there, not mget1.14). > > Ouch. Yes, ouch ;-) I took a look at libtasn1, and yes, the best thing would be a partial rewrite. Unlikely someone is doing that... a quicker way to speed up would be the use of memory pools in libtasn1. If there is some potential within the GnuTLS sources, I can't say. > >> GnuTLS doesn't have something similar to that, like loading the CA > >> file on demand. > >> You could of course simulate that functionality by using the > >> certificate's authority key identifier, or the issuer's name. > > > > Here is exactly the point, where you could help me. > > I would like to do that. > > But when the verification callback function is called (set by > > gnutls_certificate_set_verify_function()), information about the key id > > or issuer seem not to be available. > > You can obtain the peer's certificate. gnutls_certificate_get_peers() > convert it to a gnutls_x509_crt_t and then read the key id or issuer. Sorry, Nikos, for being my "rubber duck" ;-) I found the problem some minutes ago while writing this email. I used gnutls_x509_crt_import(cert, &cert_list[it], GNUTLS_X509_FMT_PEM) instead of gnutls_x509_crt_import(cert, &cert_list[it], GNUTLS_X509_FMT_DER) Now I am getting issuer and DN etc. I let you know if and when the 'lazy loading' works and how it performs. But still: optimizing libtasn1 is an issue... Tim R?hsen From scottm at aero.org Fri Aug 31 17:51:08 2012 From: scottm at aero.org (B. Scott Michel) Date: Fri, 31 Aug 2012 08:51:08 -0700 Subject: Loading credentials in verify callback just as needed ? In-Reply-To: <201208311745.17824.tim.ruehsen@gmx.de> References: <201208281223.23642.tim.ruehsen@gmx.de> <201208301307.08469.tim.ruehsen@gmx.de> <503FD35C.7030305@gnutls.org> <201208311745.17824.tim.ruehsen@gmx.de> Message-ID: <5040DD6C.6060105@aero.org> On 8/31/2012 8:45 AM, Tim Ruehsen wrote: > Am Thursday 30 August 2012 schrieb Nikos Mavrogiannopoulos: >>> There are 150 certs at the moment. >>> GnuTLS 3.0.22 uses ~1.8 millions of malloc()s to read these files in. >>> OpenSSL just ~5.000. >> Ouch. It's the libtasn1's operation that uses quite excessively malloc >> to parse the X.509 structures and create a tree, but 1.8 million for 150 >> certificates seems too much. Most probably an optimization there would >> eliminate the issue you see. >> >>> On my rather old AMD 2000+ it takes ~1s to load these. >>> Using valgrind for development (wget1.14), it takes around 30-40s. >>> See some output at the end of my inital post (i meant to write Wget1.14 >>> there, not mget1.14). >> Ouch. > Yes, ouch ;-) > > I took a look at libtasn1, and yes, the best thing would be a partial rewrite. > Unlikely someone is doing that... a quicker way to speed up would be the use > of memory pools in libtasn1. I'd hesitate before writing my own memory manager (essentially what you're proposing with memory pools). There's a good chunk of literature that demonstrates that customized memory management is inefficient. It's also a good indication that there's a different problem that needs to be addressed. If you're using Linux, malloc() is already managing pools of memory, as is almost every other malloc() implementation since around 1990. 2 million malloc() calls probably needs to be fixed first. If that can't be fixed, look at the algorithm and fix it. But think long and hard before writing your own memory manager. -scooter From scottm at aero.org Fri Aug 31 17:55:02 2012 From: scottm at aero.org (B. Scott Michel) Date: Fri, 31 Aug 2012 08:55:02 -0700 Subject: [WARNING: SPOOFED E-MAIL--Non-Aerospace Sender] Re: Loading credentials in verify callback just as needed ? In-Reply-To: <5040DD6C.6060105@aero.org> References: <201208281223.23642.tim.ruehsen@gmx.de> <201208301307.08469.tim.ruehsen@gmx.de> <503FD35C.7030305@gnutls.org> <201208311745.17824.tim.ruehsen@gmx.de> <5040DD6C.6060105@aero.org> Message-ID: <5040DE56.6090608@aero.org> On 8/31/2012 8:51 AM, B. Scott Michel wrote: > I'd hesitate before writing my own memory manager (essentially what > you're proposing with memory pools). There's a good chunk of literature > that demonstrates that customized memory management is inefficient. It's > also a good indication that there's a different problem that needs to be > addressed. If you're using Linux, malloc() is already managing pools of > memory, as is almost every other malloc() implementation since around 1990. > > 2 million malloc() calls probably needs to be fixed first. If that can't > be fixed, look at the algorithm and fix it. But think long and hard > before writing your own memory manager. > > > -scooter > For the academically inclined, Emery Berger's dissertation research is what you want to go look at: *OOPSLA 2002: Reconsidering Custom Memory Allocation * with Ben Zorn & Kathryn McKinley We show that a good general-purpose allocator is better (faster and more space-efficient) than all styles of custom allocators except regions, but these have serious problems. We introduce *reaps* (regions + heaps), which combine the flexibility and space efficiency of heaps with the performance of regions. Talk (PowerPoint) . *OOPSLA 2005: Quantifying the Performance of Garbage Collection vs. Explicit Memory Management * with Matthew Hertz. This paper provides empirical answers to an age-old question: is garbage collection faster/slower/the same speed as malloc/free? We introduce oracular memory management, an approach that lets us measure unaltered Java programs as if they used malloc and free. The result: a good GC can match the performance of a good allocator, but it takes 5X more space. If physical memory is tight, however, conventional garbage collectors suffer an order-of-magnitude performance penalty. Talk: PowerPoint , PDF . -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottm at aero.org Fri Aug 31 23:41:29 2012 From: scottm at aero.org (B. Scott Michel) Date: Fri, 31 Aug 2012 14:41:29 -0700 Subject: small point of detail In-Reply-To: <1346365785.28169.9.camel@localhost> References: <1346365499.28169.6.camel@localhost> <1346365785.28169.9.camel@localhost> Message-ID: <50412F89.2070302@aero.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 _entry is a pointer to a pointer to a SRP_PWD_ENTRY. calloc() and friends return a void pointer, which means that the code has to dereference _entry in order to assign it the value from calloc(). calloc() allocates a 1 element sized array, where each element is the size of a SRP_PWD_ENTRY. And, the resulting memory is filled with zeroes. The "entry = *_entry" statement just makes entry point to the same thing as *_entry, which is the memory just allocated by calloc(). entry is just used a shorthand for (*_entry) in the subsequent code. Otherwise, you'd have to write (*_entry)-> to manipulate the SRP_PWD_ENTRY structure. Hope this helps you understand the code better. - -scooter On 8/30/2012 3:29 PM, ml wrote: > this feature is a point of detail to the file > auth_srp_passwd.c > line 266 > gnutls 2 last release > > > Le vendredi 31 ao?t 2012 ? 00:24 +0200, ml a ?crit : >> hello all gurus >> I just go a small part of the code and I wonder one thing that is a >> small point of detail >> >> *_entry = gnutls_calloc (1, sizeof (SRP_PWD_ENTRY)); >> if (*_entry == NULL) >> { >> gnutls_assert (); >> return GNUTLS_E_MEMORY_ERROR; >> } >> entry = *_entry; >> >> i do not understand this line >> *_entry is allocated of the same size ? >> >> please answer me >> _______________________________________________ >> Gnutls-devel mailing list >> Gnutls-devel at gnu.org >> https://lists.gnu.org/mailman/listinfo/gnutls-devel > > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at gnu.org > https://lists.gnu.org/mailman/listinfo/gnutls-devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBAgAGBQJQQS+JAAoJEHOWfvkM4ss/hEMIALjD+XWiSM6lzdyfdxl7fWH2 Mq6maxmooUki4zHz02qdZVe7rE6VRgdgX6gF2WZ4vMBkVXSMe/ng7HETuXllyXna HoQNRhWgICQNLx94JNbCYRI8ArBvygxkJP8PtP48IX3TyYnSq0QA7UEx7Qy0TM+e rcstaw5ACKx0WCSVn6quL46zKCwrmuH/iRov4+lLyq7fQYm2Vp0qR0sGg/wtByKB hXLF+RQJ3aH+X9mDRwqFFBxz8nsulfPqbvryT/qyBpr0M1iAeHlt9TDiR3gOkOXq jXpppaPsdBJM0mGkHcibiq+Q5JPOH0hDtPereLLaYgIuXwWrNmyV+pgOlvnzUGc= =ZC8y -----END PGP SIGNATURE----- -------------- next part -------------- An HTML attachment was scrubbed... URL: