From dkg at fifthhorseman.net Fri Nov 1 01:15:30 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 31 Oct 2013 20:15:30 -0400 Subject: [gnutls-devel] [PATCH] Correct audit log: gnutls_dh_set_prime_bits(s, 0) falls back to security level Message-ID: <1383264930-9953-1-git-send-email-dkg@fifthhorseman.net> Currently, when invoking gnutls_dh_set_prime_bits(s, 0), the audit log claims "Note that the security level of the Diffie-Hellman key exchange has been lowered to 0 bits and this may allow decryption of the session data". This is incorrect, since setting dh_prime_bits to 0 actually makes GnuTLS rely on the default security level requested. This patch corrects the audit log. --- lib/gnutls_ui.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/gnutls_ui.c b/lib/gnutls_ui.c index 26335c8..eb855ab 100644 --- a/lib/gnutls_ui.c +++ b/lib/gnutls_ui.c @@ -102,7 +102,8 @@ int gnutls_random_art (gnutls_random_art_t type, void gnutls_dh_set_prime_bits (gnutls_session_t session, unsigned int bits) { - if (bits <= 512) _gnutls_audit_log(session, "Note that the security level of the Diffie-Hellman key exchange has been lowered to %u bits and this may allow decryption of the session data\n", bits); + if (bits == 0) _gnutls_audit_log(session, "Ignoring request to set required bits for Diffie-Hellman key exchange to 0; using security level from the priority string to determine DH bit requirement\n"); + else if (bits <= 512) _gnutls_audit_log(session, "Note that the security level of the Diffie-Hellman key exchange has been lowered to %u bits and this may allow decryption of the session data\n", bits); session->internals.priorities.dh_prime_bits = bits; } -- 1.8.4.rc3 From dkg at fifthhorseman.net Fri Nov 1 01:15:53 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 31 Oct 2013 20:15:53 -0400 Subject: [gnutls-devel] tests invoke gnutls_dh_set_prime_bits on servers Message-ID: <5272F2B9.2060307@fifthhorseman.net> the docs for gnutls_dh_set_prime_bits say "The function has no effect in server side." but src/benchmark-tls.c and several files matching tests/*.c all invoke something like: gnutls_dh_set_prime_bits (server, 1024); this seems like a possible bug, unless that gnutls_session_t server is somehow elsewhere being used as a client. should those invocations be removed? --dkg From nmav at gnutls.org Fri Nov 1 20:42:54 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 01 Nov 2013 20:42:54 +0100 Subject: [gnutls-devel] GnuTLS 3.2.6 fails to build with --disable-dtls-alpn-support In-Reply-To: <52727967.9050409@cyber.ee> References: <52727967.9050409@cyber.ee> Message-ID: <5274043E.50403@gnutls.org> On 10/31/2013 04:38 PM, Jaak Ristioja wrote: > Hi! > > It appears there are some #ifdef ENABLE_ALPN missing from common.c > around this piece of code (error on line 580): > > rc = gnutls_alpn_get_selected_protocol (session, &p); > if (rc == 0) > printf ("- Application protocol: %.*s\n", p.size, p.data); Thanks. Should be fixed in master. regards, Nikos From dkg at fifthhorseman.net Fri Nov 1 21:57:07 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 1 Nov 2013 16:57:07 -0400 Subject: [gnutls-devel] [PATCH] fix DHE parameter output for gnutls-cli-debug --verbose Message-ID: <1383339427-10852-1-git-send-email-dkg@fifthhorseman.net> gnutls_handshake() was failing during test_dhe_group, with an error of GNUTLS_E_NO_PRIORITIES_WERE_SET. Adding this call fixes the handshake so that DHE group details can be printed when requested. --- src/tests.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/tests.c b/src/tests.c index 43d1c78..4aeaa0f 100644 --- a/src/tests.c +++ b/src/tests.c @@ -265,6 +265,7 @@ test_dhe_group (gnutls_session_t session) sprintf (prio_str, INIT_STR ALL_CIPHERS ":" ALL_COMP ":" ALL_CERTTYPES ":%s:" ALL_MACS ":+DHE-RSA:+DHE-DSS:%s", protocol_str, rest); + _gnutls_priority_set_direct (session, prio_str); gnutls_credentials_set (session, GNUTLS_CRD_CERTIFICATE, xcred); -- 1.8.4.rc3 From nmav at gnutls.org Sat Nov 2 08:38:21 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 02 Nov 2013 08:38:21 +0100 Subject: [gnutls-devel] [PATCH] Correct audit log: gnutls_dh_set_prime_bits(s, 0) falls back to security level In-Reply-To: <1383264930-9953-1-git-send-email-dkg@fifthhorseman.net> References: <1383264930-9953-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <5274ABED.9030905@gnutls.org> On 11/01/2013 01:15 AM, Daniel Kahn Gillmor wrote: > Currently, when invoking gnutls_dh_set_prime_bits(s, 0), the audit log > claims "Note that the security level of the Diffie-Hellman key > exchange has been lowered to 0 bits and this may allow decryption of > the session data". This is incorrect, since setting dh_prime_bits to > 0 actually makes GnuTLS rely on the default security level requested. Nice catch, but this isn't a documented option. I think it would be better if it would print nothing when setting it to zero. regards, Nikos From nmav at gnutls.org Sat Nov 2 08:42:02 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 02 Nov 2013 08:42:02 +0100 Subject: [gnutls-devel] tests invoke gnutls_dh_set_prime_bits on servers In-Reply-To: <5272F2B9.2060307@fifthhorseman.net> References: <5272F2B9.2060307@fifthhorseman.net> Message-ID: <5274ACCA.3010807@gnutls.org> On 11/01/2013 01:15 AM, Daniel Kahn Gillmor wrote: > the docs for gnutls_dh_set_prime_bits say "The function has no effect in > server side." > > but src/benchmark-tls.c and several files matching tests/*.c all invoke > something like: > > gnutls_dh_set_prime_bits (server, 1024); > > this seems like a possible bug, unless that gnutls_session_t server is > somehow elsewhere being used as a client. should those invocations be > removed? Thanks, I've now removed them. It looks like a copy & paste error. regards, Nikos From nmav at gnutls.org Sat Nov 2 08:43:48 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 02 Nov 2013 08:43:48 +0100 Subject: [gnutls-devel] [PATCH] fix DHE parameter output for gnutls-cli-debug --verbose In-Reply-To: <1383339427-10852-1-git-send-email-dkg@fifthhorseman.net> References: <1383339427-10852-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <5274AD34.702@gnutls.org> On 11/01/2013 09:57 PM, Daniel Kahn Gillmor wrote: > gnutls_handshake() was failing during test_dhe_group, with an error of > GNUTLS_E_NO_PRIORITIES_WERE_SET. Adding this call fixes the handshake > so that DHE group details can be printed when requested. Applied! From dkg at fifthhorseman.net Mon Nov 4 07:43:56 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 4 Nov 2013 01:43:56 -0500 Subject: [gnutls-devel] [PATCH] argument descriptions should not end in a dot Message-ID: <1383547436-4905-1-git-send-email-dkg@fifthhorseman.net> When the descrip value for an argument ends in a dot, the rendered documentation places two dots (for example "specify a password file.." in srptool(1)). Most of the descriptions are declared properly (without a trailing dot), but this patch should clean up the rest. After this commit, any auto-generated documentation that is committed to git will probably will also need to be refreshed (or removed from git entirely and generated from the definitions during build, which might be cleaner). --- src/args-std.def | 2 +- src/certtool-args.def | 16 ++++++++-------- src/cli-args.def | 4 ++-- src/danetool-args.def | 22 +++++++++++----------- src/psk-args.def | 2 +- src/srptool-args.def | 6 +++--- 6 files changed, 26 insertions(+), 26 deletions(-) diff --git a/src/args-std.def b/src/args-std.def index 10cedda..3997e18 100644 --- a/src/args-std.def +++ b/src/args-std.def @@ -24,7 +24,7 @@ flag = { value = d; arg-type = number; arg-range = "0 -> 9999"; - descrip = "Enable debugging."; + descrip = "Enable debugging"; doc = "Specifies the debug level."; }; diff --git a/src/certtool-args.def b/src/certtool-args.def index c99da89..767bd14 100644 --- a/src/certtool-args.def +++ b/src/certtool-args.def @@ -64,33 +64,33 @@ flag = { flag = { name = verify-chain; value = e; - descrip = "Verify a PEM encoded certificate chain."; + descrip = "Verify a PEM encoded certificate chain"; doc = "The last certificate in the chain must be a self signed one."; }; flag = { name = verify; - descrip = "Verify a PEM encoded certificate chain using a trusted list."; + descrip = "Verify a PEM encoded certificate chain using a trusted list"; doc = "The trusted certificate list must be loaded with --load-ca-certificate."; flags-must = load-ca-certificate; }; flag = { name = verify-crl; - descrip = "Verify a CRL using a trusted list."; + descrip = "Verify a CRL using a trusted list"; doc = "The trusted certificate list must be loaded with --load-ca-certificate."; flags-must = load-ca-certificate; }; flag = { name = generate-dh-params; - descrip = "Generate PKCS #3 encoded Diffie-Hellman parameters."; + descrip = "Generate PKCS #3 encoded Diffie-Hellman parameters"; doc = ""; }; flag = { name = get-dh-params; - descrip = "Get the included PKCS #3 encoded Diffie-Hellman parameters."; + descrip = "Get the included PKCS #3 encoded Diffie-Hellman parameters"; doc = "Returns stored DH parameters in GnuTLS. Those parameters are used in the SRP protocol. The parameters returned by fresh generation are more efficient since GnuTLS 3.0.9."; }; @@ -303,13 +303,13 @@ flag = { flag = { name = hash; arg-type = string; - descrip = "Hash algorithm to use for signing."; + descrip = "Hash algorithm to use for signing"; doc = "Available hash functions are SHA1, RMD160, SHA256, SHA384, SHA512."; }; flag = { name = inder; - descrip = "Use DER format for input certificates and private keys."; + descrip = "Use DER format for input certificates and private keys"; disabled; disable = "no"; doc = "The input files will be assumed to be in DER or RAW format. @@ -346,7 +346,7 @@ flag = { name = sec-param; arg-type = string; arg-name = "Security parameter"; - descrip = "Specify the security level [low, legacy, normal, high, ultra]."; + descrip = "Specify the security level [low, legacy, normal, high, ultra]"; doc = "This is alternative to the bits option."; }; diff --git a/src/cli-args.def b/src/cli-args.def index 957ed9f..7b920ac 100644 --- a/src/cli-args.def +++ b/src/cli-args.def @@ -32,7 +32,7 @@ available via DNSSEC."; flag = { name = local-dns; - descrip = "Use the local DNS server for DNSSEC resolving."; + descrip = "Use the local DNS server for DNSSEC resolving"; disabled; disable = "no"; doc = "This option will use the local DNS server for DNSSEC. @@ -72,7 +72,7 @@ flag = { flag = { name = starttls; value = s; - descrip = "Connect, establish a plain session and start TLS."; + descrip = "Connect, establish a plain session and start TLS"; doc = "The TLS session will be initiated when EOF or a SIGALRM is received."; }; diff --git a/src/danetool-args.def b/src/danetool-args.def index b22fd41..33baf9d 100644 --- a/src/danetool-args.def +++ b/src/danetool-args.def @@ -35,38 +35,38 @@ flag = { flag = { name = hash; arg-type = string; - descrip = "Hash algorithm to use for signing."; + descrip = "Hash algorithm to use for signing"; doc = "Available hash functions are SHA1, RMD160, SHA256, SHA384, SHA512."; }; flag = { name = check; arg-type = string; - descrip = "Check a host's DANE TLSA entry."; + descrip = "Check a host's DANE TLSA entry"; doc = "Obtains the DANE TLSA entry from the given hostname and prints information. Note that the actual certificate of the host has to be provided using --load-certificate."; }; flag = { name = check-ee; - descrip = "Check only the end-entity's certificate."; + descrip = "Check only the end-entity's certificate"; doc = "Checks the end-entity's certificate only. Trust anchors or CAs are not considered."; }; flag = { name = check-ca; - descrip = "Check only the CA's certificate."; + descrip = "Check only the CA's certificate"; doc = "Checks the trust anchor's and CA's certificate only. End-entities are not considered."; }; flag = { name = insecure; - descrip = "Do not verify any DNSSEC signature."; + descrip = "Do not verify any DNSSEC signature"; doc = "Ignores any DNSSEC signature verification results."; }; flag = { name = local-dns; - descrip = "Use the local DNS server for DNSSEC resolving."; + descrip = "Use the local DNS server for DNSSEC resolving"; disabled; disable = "no"; doc = "This option will use the local DNS server for DNSSEC. @@ -75,7 +75,7 @@ This is disabled by default due to many servers not allowing DNSSEC."; flag = { name = inder; - descrip = "Use DER format for input certificates and private keys."; + descrip = "Use DER format for input certificates and private keys"; disabled; disable = "no"; doc = "The input files will be assumed to be in DER or RAW format. @@ -114,20 +114,20 @@ flag = { flag = { name = port; arg-type = number; - descrip = "Specify the port number for the DANE data."; + descrip = "Specify the port number for the DANE data"; default-value = 443; doc = ""; }; flag = { name = ca; - descrip = "Whether the provided certificate or public key is a Certificate Authority."; + descrip = "Whether the provided certificate or public key is a Certificate Authority"; doc = "Marks the DANE RR as a CA certificate if specified."; }; flag = { name = x509; - descrip = "Use the hash of the X.509 certificate, rather than the public key."; + descrip = "Use the hash of the X.509 certificate, rather than the public key"; doc = "This option forces the generated record to contain the hash of the full X.509 certificate. By default only the hash of the public key is used."; }; @@ -138,7 +138,7 @@ flag = { flag = { name = domain; - descrip = "The provided certificate or public key is issued by the local domain."; + descrip = "The provided certificate or public key is issued by the local domain"; enabled; disable = "no"; doc = "DANE distinguishes certificates and public keys offered via the DNSSEC to trusted and local entities. This flag indicates that this is a domain-issued certificate, meaning that there could be no CA involved."; diff --git a/src/psk-args.def b/src/psk-args.def index d19ae26..819acdb 100644 --- a/src/psk-args.def +++ b/src/psk-args.def @@ -30,7 +30,7 @@ flag = { name = passwd; value = p; arg-type = string; - descrip = "specify a password file."; + descrip = "specify a password file"; doc = ""; }; diff --git a/src/srptool-args.def b/src/srptool-args.def index cb78e3b..c6fdd71 100644 --- a/src/srptool-args.def +++ b/src/srptool-args.def @@ -20,7 +20,7 @@ flag = { value = i; arg-type = number; arg-default = 1; - descrip = "specify the index of the group parameters in tpasswd.conf to use."; + descrip = "specify the index of the group parameters in tpasswd.conf to use"; doc = ""; }; @@ -36,7 +36,7 @@ flag = { name = passwd; value = p; arg-type = string; - descrip = "specify a password file."; + descrip = "specify a password file"; doc = ""; }; @@ -44,7 +44,7 @@ flag = { name = salt; value = s; arg-type = number; - descrip = "specify salt size."; + descrip = "specify salt size"; doc = ""; }; -- 1.8.4.rc3 From dkg at fifthhorseman.net Tue Nov 5 04:57:20 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 04 Nov 2013 22:57:20 -0500 Subject: [gnutls-devel] priority string DHE parameter acceptance Message-ID: <87bo1zzejj.fsf@alice.fifthhorseman.net> I'm having some difficulty following the logic behind the way the GnuTLS priority strings set what the minimum number of bits are required for the group used for DHE key exchange. I notice that if i set up a server using 1024-bit DHE, i get a different response from these two priority strings: SECURE256:+VERS-TLS-ALL:+DHE-RSA:+MAC-ALL:+COMP-NULL NONE:+SECURE256:+VERS-TLS-ALL:+DHE-RSA:+MAC-ALL:+COMP-NULL Using the former priority string, connections complete, but using the latter priority string makes gnutls-cli refuse the connection at 1024-bit DHE. If the DHE group is larger (2048 bits), both strings allow connections to complete. My understanding of the priority string mechanism suggests that the two strings should have the same behavior. What am i missing? I'm using gnutls 3.2.5-1 on debian. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 965 bytes Desc: not available URL: From nmav at gnutls.org Tue Nov 5 21:13:16 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 05 Nov 2013 21:13:16 +0100 Subject: [gnutls-devel] [PATCH] argument descriptions should not end in a dot In-Reply-To: <1383547436-4905-1-git-send-email-dkg@fifthhorseman.net> References: <1383547436-4905-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <5279515C.2090600@gnutls.org> On 11/04/2013 07:43 AM, Daniel Kahn Gillmor wrote: > When the descrip value for an argument ends in a dot, the rendered > documentation places two dots (for example "specify a password file.." > in srptool(1)). > > Most of the descriptions are declared properly (without a trailing > dot), but this patch should clean up the rest. > > After this commit, any auto-generated documentation that is committed > to git will probably will also need to be refreshed (or removed from > git entirely and generated from the definitions during build, which > might be cleaner). Applied. Thanks. From n.mavrogiannopoulos at gmail.com Tue Nov 5 21:39:08 2013 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Tue, 05 Nov 2013 21:39:08 +0100 Subject: [gnutls-devel] priority string DHE parameter acceptance In-Reply-To: <87bo1zzejj.fsf@alice.fifthhorseman.net> References: <87bo1zzejj.fsf@alice.fifthhorseman.net> Message-ID: <5279576C.9070001@gmail.com> On 11/05/2013 04:57 AM, Daniel Kahn Gillmor wrote: > I'm having some difficulty following the logic behind the way the GnuTLS > priority strings set what the minimum number of bits are required for > the group used for DHE key exchange. > > I notice that if i set up a server using 1024-bit DHE, i get a different > response from these two priority strings: > > SECURE256:+VERS-TLS-ALL:+DHE-RSA:+MAC-ALL:+COMP-NULL > > NONE:+SECURE256:+VERS-TLS-ALL:+DHE-RSA:+MAC-ALL:+COMP-NULL > > Using the former priority string, connections complete, but using the > latter priority string makes gnutls-cli refuse the connection at > 1024-bit DHE. If the DHE group is larger (2048 bits), both strings > allow connections to complete. > > My understanding of the priority string mechanism suggests that the two > strings should have the same behavior. What am i missing? Nothing, that doesn't make sense. It's a bug. I've figure it out, but it seems a test case is needed there to avoid such issues. regards, Nikos -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 551 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Nov 8 00:20:40 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 7 Nov 2013 18:20:40 -0500 Subject: [gnutls-devel] [PATCH 2/2] enable --outder for certtool --dh-info In-Reply-To: <1383866440-25558-1-git-send-email-dkg@fifthhorseman.net> References: <1383866440-25558-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1383866440-25558-2-git-send-email-dkg@fifthhorseman.net> "certool --dh-info --outder" produces PEM-encoded output without this patch. --- src/certtool-args.def | 2 +- src/certtool-common.c | 14 +++++++++++--- src/certtool-common.h | 1 + src/certtool.c | 1 + 4 files changed, 14 insertions(+), 4 deletions(-) diff --git a/src/certtool-args.def b/src/certtool-args.def index 30cfb7d..36f0629 100644 --- a/src/certtool-args.def +++ b/src/certtool-args.def @@ -324,7 +324,7 @@ flag = { flag = { name = outder; - descrip = "Use DER format for output certificates and private keys"; + descrip = "Use DER format for output certificates, private keys, and DH parameters"; disabled; disable = "no"; doc = "The output will be in DER or RAW format."; diff --git a/src/certtool-common.c b/src/certtool-common.c index e51a6c8..2b0c4c7 100644 --- a/src/certtool-common.c +++ b/src/certtool-common.c @@ -912,18 +912,26 @@ void dh_info (FILE* infile, FILE* outfile, common_info_st * ci) exit (1); } - print_dh_info (outfile, &p, &g, q_bits, ci->cprint); + if (ci->outcert_format == GNUTLS_X509_FMT_PEM) + print_dh_info (outfile, &p, &g, q_bits, ci->cprint); if (!ci->cprint) { /* generate a PKCS#3 structure */ size_t len = buffer_size; - ret = gnutls_dh_params_export_pkcs3 (dh_params, GNUTLS_X509_FMT_PEM, + ret = gnutls_dh_params_export_pkcs3 (dh_params, ci->outcert_format, buffer, &len); if (ret == 0) { - fprintf (outfile, "\n%s", buffer); + if (ci->outcert_format == GNUTLS_X509_FMT_PEM) + { + fprintf (outfile, "\n%s", buffer); + } + else + { + fwrite (buffer, 1, len, outfile); + } } else { diff --git a/src/certtool-common.h b/src/certtool-common.h index 556a3cc..35d1c2f 100644 --- a/src/certtool-common.h +++ b/src/certtool-common.h @@ -39,6 +39,7 @@ typedef struct common_info const char *pubkey; int pkcs8; int incert_format; + int outcert_format; const char *cert; const char *request; diff --git a/src/certtool.c b/src/certtool.c index 4dc6dea..1e0aab2 100644 --- a/src/certtool.c +++ b/src/certtool.c @@ -1147,6 +1147,7 @@ cmd_parser (int argc, char **argv) cinfo.pkcs8 = HAVE_OPT(PKCS8); cinfo.incert_format = incert_format; + cinfo.outcert_format = outcert_format; if (HAVE_OPT(LOAD_CERTIFICATE)) cinfo.cert = OPT_ARG(LOAD_CERTIFICATE); -- 1.8.4.rc3 From dkg at fifthhorseman.net Fri Nov 8 00:20:39 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 7 Nov 2013 18:20:39 -0500 Subject: [gnutls-devel] [PATCH 1/2] enable --inder for certtool --dh-info Message-ID: <1383866440-25558-1-git-send-email-dkg@fifthhorseman.net> certtool --dh-info is unable to read DER-encoded DH parameters without this patch. --- src/certtool-args.def | 2 +- src/certtool-common.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/certtool-args.def b/src/certtool-args.def index 767bd14..30cfb7d 100644 --- a/src/certtool-args.def +++ b/src/certtool-args.def @@ -309,7 +309,7 @@ flag = { flag = { name = inder; - descrip = "Use DER format for input certificates and private keys"; + descrip = "Use DER format for input certificates, private keys, and DH parameters "; disabled; disable = "no"; doc = "The input files will be assumed to be in DER or RAW format. diff --git a/src/certtool-common.c b/src/certtool-common.c index 1799250..e51a6c8 100644 --- a/src/certtool-common.c +++ b/src/certtool-common.c @@ -897,7 +897,7 @@ void dh_info (FILE* infile, FILE* outfile, common_info_st * ci) params.size = size; ret = - gnutls_dh_params_import_pkcs3 (dh_params, ¶ms, GNUTLS_X509_FMT_PEM); + gnutls_dh_params_import_pkcs3 (dh_params, ¶ms, ci->incert_format); if (ret < 0) { fprintf (stderr, "Error parsing dh params: %s\n", gnutls_strerror (ret)); -- 1.8.4.rc3 From nmav at gnutls.org Fri Nov 8 14:50:34 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 8 Nov 2013 14:50:34 +0100 Subject: [gnutls-devel] [PATCH 2/2] enable --outder for certtool --dh-info In-Reply-To: <1383866440-25558-2-git-send-email-dkg@fifthhorseman.net> References: <1383866440-25558-1-git-send-email-dkg@fifthhorseman.net> <1383866440-25558-2-git-send-email-dkg@fifthhorseman.net> Message-ID: On Fri, Nov 8, 2013 at 12:20 AM, Daniel Kahn Gillmor wrote: > "certool --dh-info --outder" produces PEM-encoded output without this > patch. Thank you. Both were applied. regards, Nikos From ametzler at bebt.de Sun Nov 10 08:22:17 2013 From: ametzler at bebt.de (Andreas Metzler) Date: Sun, 10 Nov 2013 08:22:17 +0100 Subject: [gnutls-devel] gnutls28 3.2.6 - race condition in mini-handshake-timeout.c Message-ID: <20131110072217.GB3269@downhill.g.la> Good morning, there is a race condition in mini-handshake-timeout.c which causes spurious build failures. The issue appeared on the Debian build-daemons . It was diagnosed by Petr Salinger and Steven Chamberlain, Petr in specific narrowd it down: quote ------------------------------ | It also failed on mips, in the same test - mini-handshake-timeout.c | | It receives SIGPIPE during | gnutls_bye(session, GNUTLS_SHUT_RDWR); | | There is a race window, which can be enlarged as shown bellow. | After that it fails also under linux-i386 -> not kfreebsd specific. | | Petr | | --- tests/mini-handshake-timeout.c | +++ tests/mini-handshake-timeout.c | @@ -181,7 +181,10 @@ | while (ret < 0 && gnutls_error_is_fatal(ret) == 0); | | if (ret == 0) | + { | + sleep(1); | gnutls_bye(session, GNUTLS_SHUT_RDWR); | + } | } | | gnutls_deinit (session); unquote ---------------------------- See and . 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 Sun Nov 10 10:24:34 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 10 Nov 2013 10:24:34 +0100 Subject: [gnutls-devel] gnutls28 3.2.6 - race condition in mini-handshake-timeout.c In-Reply-To: <20131110072217.GB3269@downhill.g.la> References: <20131110072217.GB3269@downhill.g.la> Message-ID: <1384075474.25799.0.camel@aspire.lan> On Sun, 2013-11-10 at 08:22 +0100, Andreas Metzler wrote: > Good morning, > > there is a race condition in mini-handshake-timeout.c which causes > spurious build failures. The issue appeared on the Debian > build-daemons > . > > It was diagnosed by Petr Salinger and Steven Chamberlain, Petr in > specific narrowd it down: Thanks. I've added a signal(SIGPIPE, SIG_IGN), and that should solve the issue. regards, Nikos From nmav at gnutls.org Sat Nov 16 11:04:27 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 16 Nov 2013 11:04:27 +0100 Subject: [gnutls-devel] certtool endless loop in expiration_days In-Reply-To: <20131115180335.35948134@chromobil.localdomain> References: <20131115180335.35948134@chromobil.localdomain> Message-ID: <1384596267.24545.2.camel@aspire.lan> On Fri, 2013-11-15 at 18:03 +0100, Stefan B?hler wrote: > Hi, > > expiration_days = 36500 > > in a certtool template config leads to an endless loop as it overflows > and tries again forever. > > a) it should fail with an error instead of looping; also signed integer > overflow is undefined: check it manually before instead of checking > the result. (days * 24 * 60 * 60 is where the overflow happens, as days > is only an integer) > > b) it should really support large expiration values; ideally it should > also support the "no well-defined expiration date" 99991231235959Z > somehow. Thanks. Both should be fixed now. That reminds me that there is no way to set the activation time as well. Anyway some other time. regards, Nikos From code at funwithsoftware.org Wed Nov 20 06:05:54 2013 From: code at funwithsoftware.org (Patrick Pelletier) Date: Tue, 19 Nov 2013 21:05:54 -0800 Subject: [gnutls-devel] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: <528BBD84.60700@amacapital.net> References: <52874576.9000708@gmx.net> <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> Message-ID: <528C4332.9060806@funwithsoftware.org> On 11/19/13, 11:35 AM, Andy Lutomirski wrote: > - Support multiple clients in the same process linked against the same > library without causing those clients to interfere with each other > (hello, GnuTLS). What's the issue that GnuTLS has with this? I'm more familiar with the issue OpenSSL has, namely that it requires threading callbacks to be set, so each client in the same process is going to be stomping on the same set of global callbacks. I'd thought GnuTLS was better about global state, but maybe there's something I've missed. Also, I thought Botan wasn't good on this point either, since it requires a LibraryInitializer object to be created, and (I thought) it doesn't support more than one LibraryInitializer existing at once. --Patrick From nmav at gnutls.org Thu Nov 21 23:12:10 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 21 Nov 2013 23:12:10 +0100 Subject: [gnutls-devel] error in \gnutls-3.2.6-w32\bin\gnutls-cli.exe In-Reply-To: <39BD387677639F4B8B0C9363669EC24806477B30@SINPEX01CL01.citrite.net> References: <39BD387677639F4B8B0C9363669EC24806477B30@SINPEX01CL01.citrite.net> Message-ID: <1385071930.716.1.camel@aspire.lan> On Thu, 2013-11-21 at 11:02 +0000, Sajeev S wrote: > D:\GNUTLS\gnutls-3.2.6-w32\bin>gnutls-cli.exe 10.102.57.54 -p 443 > --insecure --priority "NORMAL:%COMPAT > Processed 135 CA certificate(s). > Processed 1 client X.509 certificates... It seems there is an issue with the socket functions. Thanks for pointing that out. It will be fixed on the next release. regards, Nikos From nmav at gnutls.org Fri Nov 22 22:35:37 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 22 Nov 2013 22:35:37 +0100 Subject: [gnutls-devel] gnutls 3.2.3-1 breaks irssi/xmpp In-Reply-To: <20131122131226.GB27819@setan> References: <20131122131226.GB27819@setan> Message-ID: <1385156137.5383.2.camel@aspire.lan> On Fri, 2013-11-22 at 14:12 +0100, Frank Zschockelt wrote: > Hi Nikos, > > I'm not subscribed to the mailinglist, which is why i can't reply properly to > those two threads: > > [gnutls-devel] gnutls 3.2.3-1 breaks irssi/xmpp > http://lists.gnutls.org/pipermail/gnutls-devel/2013-August/006407.html > [gnutls-devel] mcabber GnuTLS related problem > http://lists.gnutls.org/pipermail/gnutls-devel/2013-August/006405.html > I'm one of the authors of mcabber, and found a way to reproduce the issue with > gnutls-cli. I'm using archlinux with gnutls 3.2.6: Thank you for pinpointing the issue. There was an issue with compressed record handling in 3.2. I have committed a fix which will be included in the next release. A work-around is to disable compression in gnutls 3.2. regards, Nikos From nmav at gnutls.org Sat Nov 23 11:16:03 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 23 Nov 2013 11:16:03 +0100 Subject: [gnutls-devel] gnutls 3.1.17 Message-ID: <1385201763.32052.2.camel@aspire.lan> Hello, I've just released gnutls 3.1.17. This release prioritizes the GCM ciphersuites over CBC, enables TPM support and fixes few other bugs on the current stable branch. * Version 3.1.17 (released 2013-11-23) ** libgnutls: Support for TPM via trousers is now enabled by default. ** libgnutls: GCM mode is prioritized over CBC in all of the default priority strings. ** libgnutls: Added support for ISO OID for RSA-SHA1 signatures. ** libgnutls: When traversing PKCS #11 tokens looking for an object, avoid looking in unrelated to the object tokens. ** libgnutls: Fixed bug in gnutls_x509_crt_set_dn() at DN parsing. ** libgnutls: gnutls_x509_crt_set_expiration_time() will set the no well defined expiration date when (time_t)-1 is specified as date. ** libgnutls: Backported memory leak fix when a handshake is terminated by an EOF. ** libgnutls: Forbid all compression methods in DTLS. ** gnutls-serv: Fixed issue with IPv6 address in UDP mode. ** certtool: When exporting an encrypted PEM private key do not output the key parameters. ** certtool: Expiration days template option allows for a -1 value which will set to the no well defined expiration date (RFC5280), and no longer chokes on integer overflows. Suggested by Stefan Buehler. ** tools: The environment variable GNUTLS_PIN can be used to read any PIN requested from tokens. ** tools: The installed version of libopts is used if the autogen tool is present. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.17.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.17.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.17.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.1/gnutls-3.1.17.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 Sat Nov 23 16:23:32 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 23 Nov 2013 16:23:32 +0100 Subject: [gnutls-devel] gnutls 3.2.7 Message-ID: <1385220212.14918.3.camel@aspire.lan> Hello, I've just released gnutls 3.2.7. This release adds new features and fixes bugs on the next stable branch. Note that this will be the last release of 3.2.7 with (major) new features added. If there are no serious bugs reported on this branch for a while, it will be marked as stable. * Version 3.2.7 (released 2013-11-23) ** libgnutls: gnutls_cipher_get_iv_size() now returns the correct IV size in GCM ciphers (previously it returned the implicit IV used in TLS). ** libgnutls: gnutls_certificate_set_x509_key_file() et al when provided with a PKCS #11 URL pointing to a certificate, will attempt to load the whole chain. ** libgnutls: When traversing PKCS #11 tokens looking for an object, avoid looking in unrelated to the object tokens. ** libgnutls: Added an experimental %DUMBFW option in priority strings. This avoids a black hole behavior in some firewalls by sending a large client hello. See http://www.ietf.org/mail-archive/web/tls/current/msg10423.html ** libgnutls: The GNUTLS_DEBUG_LEVEL variable if set to a log level number will force output of debug messages to stderr. ** libgnutls: Fixed the setting of the ciphersuite when gnutls_premaster_set() is used with another protocol than the GNUTLS_DTLS0_9 protocol. ** libgnutls: gnutls_x509_crt_set_expiration_time() will set the no well defined expiration date when (time_t)-1 is specified as date. ** libgnutls: Session tickets are encrypted using AES-GCM. ** libgnutls: Corrected issue in record decompression. Issue pinpointed by Frank Zschockel. ** libgnutls: Forbid all compression methods in DTLS. ** gnutls-serv: Fixed issue with IPv6 address in UDP mode. ** certtool: When exporting an encrypted PEM private key do not output the key parameters. ** certtool: Expiration days template option allows for a -1 value which will set to the no well defined expiration date (RFC5280), and no longer chokes on integer overflows. Suggested by Stefan Buehler. ** certtool: Added new template options: 'activation_date', and 'expiration_date'. ** tools: The environment variable GNUTLS_PIN can be used to read any PIN requested from tokens. ** tools: The installed version of libopts is used if the autogen tool is present. ** API and ABI modifications: gnutls_pkcs11_obj_export3: Added gnutls_pkcs11_get_raw_issuer: Added gnutls_est_record_overhead_size: Exported Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.7.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.7.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.7.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.7.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From dkg at fifthhorseman.net Wed Nov 27 09:12:42 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 27 Nov 2013 03:12:42 -0500 Subject: [gnutls-devel] [Andy Lutomirski] Re: [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) Message-ID: <877gbu6z5x.fsf@alice.fifthhorseman.net> hey gnutls and p11-kit folks-- this message came up on the IETF TLS WG list, as a particular complaint about the relationship between gnutls and pkcs11 making it more difficult to use gnutls than it should be. I'm not sure if there is anything concrete to address here (or if there is, if it would be doable without API or ABI breakage), but i just wanted to make sure that the developers are aware that the concern has been aired publicly. If the concern can be addressed and fixed, that would be great. If you think the concern raised is a misconception, or if there is a particular way to avoid the implied risks with forking or multithreading, i would be happy to relay any relevant clarifications to the TLS WG. --dkg -------------- next part -------------- An embedded message was scrubbed... From: Andy Lutomirski Subject: Re: [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) Date: Tue, 19 Nov 2013 22:24:03 -0800 Size: 3179 URL: From nmav at gnutls.org Wed Nov 27 09:28:07 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 27 Nov 2013 09:28:07 +0100 Subject: [gnutls-devel] [Andy Lutomirski] Re: [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: <877gbu6z5x.fsf@alice.fifthhorseman.net> References: <877gbu6z5x.fsf@alice.fifthhorseman.net> Message-ID: On Wed, Nov 27, 2013 at 9:12 AM, Daniel Kahn Gillmor wrote: > hey gnutls and p11-kit folks-- > this message came up on the IETF TLS WG list, as a particular complaint > about the relationship between gnutls and pkcs11 making it more > difficult to use gnutls than it should be. > > I'm not sure if there is anything concrete to address here (or if there > is, if it would be doable without API or ABI breakage), but i just > wanted to make sure that the developers are aware that the concern has > been aired publicly. If the concern can be addressed and fixed, that > would be great. > > If you think the concern raised is a misconception, or if there is a > particular way to avoid the implied risks with forking or > multithreading, i would be happy to relay any relevant clarifications to > the TLS WG. Hello, I didn't bother to reply as I didn't understand what was his point. As far as I understood he claimed that he could not call gnutls_global_init() simultaneously on all the threads of his process. As this is documented I didn't understand what he really thought it was bug. At best he could make a feature request. One of the things gnutls_global_init() does is to setup the mutex locks, so obviously it cannot be called by many threads at once. (btw. I'm working on a different design for global_init in 3.3, but I'll bring that up on a different thread later). regards, Nikos From dkg at fifthhorseman.net Wed Nov 27 15:21:40 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 27 Nov 2013 09:21:40 -0500 Subject: [gnutls-devel] [Andy Lutomirski] Re: [TLS] multiple clients in one process In-Reply-To: <5295FDB3.4060306@thewalter.net> References: <877gbu6z5x.fsf@alice.fifthhorseman.net> <5295FDB3.4060306@thewalter.net> Message-ID: <5295FFF4.8020002@fifthhorseman.net> On 11/27/2013 09:12 AM, Stef Walter wrote: > p11-kit solves the concurrency issue, with multiple callers of gnutls in > the same process. Although it's still possible for someone to use a > fragile PKCS#11 module directly with gnutls, that's not the default > behavior. > > Secondly, I'm working actively in the PKCS#11 OASIS TC (even though such > work can be tedious), to solve the inate PKCS#11 issues with multiple > callers in a process. Progress has been made, and it's looking likely > that we'll have fixed this in a future version of the PKCS#11 standard > itself. > > But until then: p11-kit does aim to fix this exact case. If there is a > specific issue, or corner case that we've missed, I would love to hear > details. thanks for this, Stef. Do you want me to relay this sentiment to the TLS WG so that the implementation and goals are clear to people who look at that archive? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From luto at amacapital.net Wed Nov 20 07:24:03 2013 From: luto at amacapital.net (Andy Lutomirski) Date: Tue, 19 Nov 2013 22:24:03 -0800 Subject: [gnutls-devel] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: <528C4332.9060806@funwithsoftware.org> References: <52874576.9000708@gmx.net> <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> Message-ID: On Tue, Nov 19, 2013 at 9:05 PM, Patrick Pelletier wrote: > On 11/19/13, 11:35 AM, Andy Lutomirski wrote: > >> - Support multiple clients in the same process linked against the same >> library without causing those clients to interfere with each other >> (hello, GnuTLS). > > > What's the issue that GnuTLS has with this? I'm more familiar with the > issue OpenSSL has, namely that it requires threading callbacks to be set, so > each client in the same process is going to be stomping on the same set of > global callbacks. I'd thought GnuTLS was better about global state, but > maybe there's something I've missed. > GnuTLS has gnutls_pkcs11_init, which is rather impolite -- it manipulates global state, and it sometimes causes things to malfunction after forking. gnutls_global_init is documented as being unsafe if called from multiple threads, which seems silly. (As an even more off-topic aside, how is there nothing better than pkcs11 for interfacing with abstract keys?) > Also, I thought Botan wasn't good on this point either, since it requires a > LibraryInitializer object to be created, and (I thought) it doesn't support > more than one LibraryInitializer existing at once. No clue -- I've never used it. --Andy -- Andy Lutomirski AMA Capital Management, LLC From sajeev.s at citrix.com Fri Nov 22 04:29:39 2013 From: sajeev.s at citrix.com (Sajeev S) Date: Fri, 22 Nov 2013 03:29:39 +0000 Subject: [gnutls-devel] error in \gnutls-3.2.6-w32\bin\gnutls-cli.exe In-Reply-To: <1385071930.716.1.camel@aspire.lan> References: <39BD387677639F4B8B0C9363669EC24806477B30@SINPEX01CL01.citrite.net> <1385071930.716.1.camel@aspire.lan> Message-ID: <39BD387677639F4B8B0C9363669EC248064780E3@SINPEX01CL01.citrite.net> This is on windows platform........same release on Linux works fine. Regards, Sajeev -----Original Message----- From: Nikos Mavrogiannopoulos [mailto:n.mavrogiannopoulos at gmail.com] On Behalf Of Nikos Mavrogiannopoulos Sent: Friday, November 22, 2013 3:42 AM To: Sajeev S Cc: bugs at gnutls.org Subject: Re: error in \gnutls-3.2.6-w32\bin\gnutls-cli.exe On Thu, 2013-11-21 at 11:02 +0000, Sajeev S wrote: > D:\GNUTLS\gnutls-3.2.6-w32\bin>gnutls-cli.exe 10.102.57.54 -p 443 > --insecure --priority "NORMAL:%COMPAT Processed 135 CA certificate(s). > Processed 1 client X.509 certificates... It seems there is an issue with the socket functions. Thanks for pointing that out. It will be fixed on the next release. regards, Nikos From ben at nx3d.org Sun Nov 24 01:00:10 2013 From: ben at nx3d.org (Ben de Graaff) Date: Sun, 24 Nov 2013 01:00:10 +0100 Subject: [gnutls-devel] Memory leak in print_aia in lib/x509/output.c Message-ID: <5291418A.80609@nx3d.org> The print_aia function in lib/x509/output.c (called via e.g. gnutls_x509_crt_print) calls gnutls_x509_crt_get_authority_info_access but never frees the data if this call is successful. This results in a memory leak. Bug requires authority info access to be present, and exists in version 3.2.6 and latest git. Attached is sample code that triggers the memory leak. Compile with e.g.: gcc memleak.c -o memleak -std=c99 -Werror -Wall -Wextra -pedantic -lgnutls && valgrind --leak-check=full ./memleak -------------- next part -------------- A non-text attachment was scrubbed... Name: memleak.c Type: text/x-csrc Size: 1244 bytes Desc: not available URL: From n-roeser at gmx.net Mon Nov 25 21:14:37 2013 From: n-roeser at gmx.net (Nico R.) Date: Mon, 25 Nov 2013 21:14:37 +0100 Subject: [gnutls-devel] Latest version of GnuTLS API Reference Manual Message-ID: <5293AFAD.5020708@gmx.net> Hello! The GnuTLS Reference Manual on gnutls.org[0] tells users to go to gnu.org[1] for the latest version, but [1] talks about GnuTLS 3.1.5 whereas [0] is about GnuTLS 3.2.7. [0] http://gnutls.org/reference/ [1] https://www.gnu.org/software/gnutls/reference/ -- Nico -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: From stef at thewalter.net Wed Nov 27 15:12:03 2013 From: stef at thewalter.net (Stef Walter) Date: Wed, 27 Nov 2013 15:12:03 +0100 Subject: [gnutls-devel] [Andy Lutomirski] Re: [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: <877gbu6z5x.fsf@alice.fifthhorseman.net> References: <877gbu6z5x.fsf@alice.fifthhorseman.net> Message-ID: <5295FDB3.4060306@thewalter.net> p11-kit solves the concurrency issue, with multiple callers of gnutls in the same process. Although it's still possible for someone to use a fragile PKCS#11 module directly with gnutls, that's not the default behavior. Secondly, I'm working actively in the PKCS#11 OASIS TC (even though such work can be tedious), to solve the inate PKCS#11 issues with multiple callers in a process. Progress has been made, and it's looking likely that we'll have fixed this in a future version of the PKCS#11 standard itself. But until then: p11-kit does aim to fix this exact case. If there is a specific issue, or corner case that we've missed, I would love to hear details. And no, PKCS#11 is not beautiful, but working-around some of it's inadequacies (while also fixing them for real in the TC) has been preferable to rewriting the Linux world + all the drivers to use something else. All the best, Stef On 27.11.2013 09:12, Daniel Kahn Gillmor wrote: > hey gnutls and p11-kit folks-- > > this message came up on the IETF TLS WG list, as a particular complaint > about the relationship between gnutls and pkcs11 making it more > difficult to use gnutls than it should be. > > I'm not sure if there is anything concrete to address here (or if there > is, if it would be doable without API or ABI breakage), but i just > wanted to make sure that the developers are aware that the concern has > been aired publicly. If the concern can be addressed and fixed, that > would be great. > > If you think the concern raised is a misconception, or if there is a > particular way to avoid the implied risks with forking or > multithreading, i would be happy to relay any relevant clarifications to > the TLS WG. > > --dkg -- stef at thewalter.net http://stef.thewalter.net From stef at thewalter.net Wed Nov 27 15:23:43 2013 From: stef at thewalter.net (Stef Walter) Date: Wed, 27 Nov 2013 15:23:43 +0100 Subject: [gnutls-devel] [Andy Lutomirski] Re: [TLS] multiple clients in one process In-Reply-To: <5295FFF4.8020002@fifthhorseman.net> References: <877gbu6z5x.fsf@alice.fifthhorseman.net> <5295FDB3.4060306@thewalter.net> <5295FFF4.8020002@fifthhorseman.net> Message-ID: <5296006F.9050908@thewalter.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27.11.2013 15:21, Daniel Kahn Gillmor wrote: > On 11/27/2013 09:12 AM, Stef Walter wrote: >> p11-kit solves the concurrency issue, with multiple callers of >> gnutls in the same process. Although it's still possible for >> someone to use a fragile PKCS#11 module directly with gnutls, >> that's not the default behavior. >> >> Secondly, I'm working actively in the PKCS#11 OASIS TC (even >> though such work can be tedious), to solve the inate PKCS#11 >> issues with multiple callers in a process. Progress has been >> made, and it's looking likely that we'll have fixed this in a >> future version of the PKCS#11 standard itself. >> >> But until then: p11-kit does aim to fix this exact case. If there >> is a specific issue, or corner case that we've missed, I would >> love to hear details. > > thanks for this, Stef. Do you want me to relay this sentiment to > the TLS WG so that the implementation and goals are clear to people > who look at that archive? Sure, that would be great. Thanks, Stef - -- stef at thewalter.net http://stef.thewalter.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKWAG4ACgkQe/sRCNknZa+z9wCg5++bipHJhNJVBRJVc1w8dj9t 8cAAnR1Dl/J6c1CC8aQ5xDbXvInn+Ys1 =S1Zv -----END PGP SIGNATURE----- From luto at amacapital.net Thu Nov 28 00:58:27 2013 From: luto at amacapital.net (Andy Lutomirski) Date: Wed, 27 Nov 2013 15:58:27 -0800 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: <20131127235451.GW21240@localhost> References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <20131127235451.GW21240@localhost> Message-ID: [stripped tls at ietf.org] On Wed, Nov 27, 2013 at 3:54 PM, Nico Williams wrote: > > All of this is off-topic for this list. I'll post a reply anyways, and > I apologize to the list. > > On Tue, Nov 19, 2013 at 10:24:03PM -0800, Andy Lutomirski wrote: >> [...]. gnutls_global_init is documented as being >> unsafe if called from multiple threads, which seems silly. > > Initialization is not thread-safe in OpenSSL either. This is a terrible > thing. It *can* be made thread-safe, so there's no excuse for it not > being thread-safe. > >> GnuTLS has gnutls_pkcs11_init, which is rather impolite -- it >> manipulates global state, and it sometimes causes things to >> malfunction after forking. [...] > > PKCS#11 is by definition fork-unsafe (see the PKCS#11 docs). > > Any API dealing with "tokens" (in the PKCS#11 sense) is bound to be > fork-unsafe for at least open sessions/objects on tokens that require > authentication (PIN). That's because any library using file descriptors > where offset is not a relevant concept will necessarily be fork-unsafe > by default. And: any stateful cryptography library (e.g., an > implementation of TLS) will tend to be fork-unsafe (imagine a process > trying to use a TLS connection on both sides of a fork()!). I agree with all of this, except that I don't think that GnuTLS has any business even trying to use PKCS11 unless something explicitly requests it. I've had all kinds of problems with libvmime causing GnuTLS to start interfacing with some mysterious GNOME PKCS11 token, when I don't want any of the above. It breaks fork for no good reason. (I'm not even trying to do crypto in the child -- I just want to avoid getting all kinds of random errors.) > > Of course, that's all rather POSIX-specific, but the problem is inherent > to any fork()-like interface. Use posix_spawn() or similar, then you > won't have to worry about fork-safety at all. Long ago I used to think > fork+exec superior to spawn since spawn was easy to implement in terms > of fork+exec, but in truth fork() is a dangerous and difficult-to-use > interface -- the only safe things to do on the child side of fork() are: > async-signal-safe things, culminating in _exit() or exec*() ASAP. Except that glibc's posix_spawn is screwed up wrt atfork. There are some bugs open about it. > >> (As an even more off-topic aside, how is there nothing better than >> pkcs11 for interfacing with abstract keys?) > > Not really, not portably, not to my knowledge :( Something better is > badly needed, yes. > > In particular we need: a) decent APIs for software crypto (even if it > uses specialized HW under the covers), b) decent APIs for talking to > smartcards (tokens), including softtokens, c) decent APIs for > cryptographic protocols, d) decent APIs for PKIX naming, ... > > Nico > -- -- Andy Lutomirski AMA Capital Management, LLC From luto at amacapital.net Thu Nov 28 01:18:39 2013 From: luto at amacapital.net (Andy Lutomirski) Date: Wed, 27 Nov 2013 16:18:39 -0800 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <20131127235451.GW21240@localhost> Message-ID: On Wed, Nov 27, 2013 at 4:16 PM, Nico Williams wrote: > On Wed, Nov 27, 2013 at 5:58 PM, Andy Lutomirski wrote: >> [stripped tls at ietf.org] >> >> On Wed, Nov 27, 2013 at 3:54 PM, Nico Williams wrote: >>> >>> All of this is off-topic for this list. I'll post a reply anyways, and >>> I apologize to the list. >>> >>> On Tue, Nov 19, 2013 at 10:24:03PM -0800, Andy Lutomirski wrote: >>>> [...]. gnutls_global_init is documented as being >>>> unsafe if called from multiple threads, which seems silly. >>> >>> Initialization is not thread-safe in OpenSSL either. This is a terrible >>> thing. It *can* be made thread-safe, so there's no excuse for it not >>> being thread-safe. >>> >>>> GnuTLS has gnutls_pkcs11_init, which is rather impolite -- it >>>> manipulates global state, and it sometimes causes things to >>>> malfunction after forking. [...] >>> >>> PKCS#11 is by definition fork-unsafe (see the PKCS#11 docs). >>> >>> Any API dealing with "tokens" (in the PKCS#11 sense) is bound to be >>> fork-unsafe for at least open sessions/objects on tokens that require >>> authentication (PIN). That's because any library using file descriptors >>> where offset is not a relevant concept will necessarily be fork-unsafe >>> by default. And: any stateful cryptography library (e.g., an >>> implementation of TLS) will tend to be fork-unsafe (imagine a process >>> trying to use a TLS connection on both sides of a fork()!). >> >> I agree with all of this, except that I don't think that GnuTLS has >> any business even trying to use PKCS11 unless something explicitly >> requests it. I've had all kinds of problems with libvmime causing >> GnuTLS to start interfacing with some mysterious GNOME PKCS11 token, >> when I don't want any of the above. It breaks fork for no good >> reason. (I'm not even trying to do crypto in the child -- I just want >> to avoid getting all kinds of random errors.) > > The thing to do is to arrange to re-initialize on the child-side of > fork(). I don't mean lock-everything in a pre-fork() atfork handler, > then unlock everything in the parent and child handlers -- that's not > safe. I mean: reset all global state in the PKCS#11 implementation on > the child-side of fork() in a child atfork handler -- yes, this means > leaking memory (and its contents), but hopefully the child will > immediately _exit() or exec*(). Also, O_CLOEXEC should be safely set > on all file descriptors used by the PKCS#11 implementation. The thing to do for whom? I think that GnuTLS should stay far away from anything PKCS11 by default until something actually requests a key from a PKCS11 token. Again, I'm not trying to use PKCS11. > >>> Of course, that's all rather POSIX-specific, but the problem is inherent >>> to any fork()-like interface. Use posix_spawn() or similar, then you >>> won't have to worry about fork-safety at all. Long ago I used to think >>> fork+exec superior to spawn since spawn was easy to implement in terms >>> of fork+exec, but in truth fork() is a dangerous and difficult-to-use >>> interface -- the only safe things to do on the child side of fork() are: >>> async-signal-safe things, culminating in _exit() or exec*() ASAP. >> >> Except that glibc's posix_spawn is screwed up wrt atfork. There are >> some bugs open about it. > > That's because it needs a real vfork() (or at least to tell fork() not > to run atfork handlers when called from posix_spawn()). It has a real vfork. It just opts not to use it. --Andy From nico at cryptonector.com Thu Nov 28 01:16:03 2013 From: nico at cryptonector.com (Nico Williams) Date: Wed, 27 Nov 2013 18:16:03 -0600 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <20131127235451.GW21240@localhost> Message-ID: On Wed, Nov 27, 2013 at 5:58 PM, Andy Lutomirski wrote: > [stripped tls at ietf.org] > > On Wed, Nov 27, 2013 at 3:54 PM, Nico Williams wrote: >> >> All of this is off-topic for this list. I'll post a reply anyways, and >> I apologize to the list. >> >> On Tue, Nov 19, 2013 at 10:24:03PM -0800, Andy Lutomirski wrote: >>> [...]. gnutls_global_init is documented as being >>> unsafe if called from multiple threads, which seems silly. >> >> Initialization is not thread-safe in OpenSSL either. This is a terrible >> thing. It *can* be made thread-safe, so there's no excuse for it not >> being thread-safe. >> >>> GnuTLS has gnutls_pkcs11_init, which is rather impolite -- it >>> manipulates global state, and it sometimes causes things to >>> malfunction after forking. [...] >> >> PKCS#11 is by definition fork-unsafe (see the PKCS#11 docs). >> >> Any API dealing with "tokens" (in the PKCS#11 sense) is bound to be >> fork-unsafe for at least open sessions/objects on tokens that require >> authentication (PIN). That's because any library using file descriptors >> where offset is not a relevant concept will necessarily be fork-unsafe >> by default. And: any stateful cryptography library (e.g., an >> implementation of TLS) will tend to be fork-unsafe (imagine a process >> trying to use a TLS connection on both sides of a fork()!). > > I agree with all of this, except that I don't think that GnuTLS has > any business even trying to use PKCS11 unless something explicitly > requests it. I've had all kinds of problems with libvmime causing > GnuTLS to start interfacing with some mysterious GNOME PKCS11 token, > when I don't want any of the above. It breaks fork for no good > reason. (I'm not even trying to do crypto in the child -- I just want > to avoid getting all kinds of random errors.) The thing to do is to arrange to re-initialize on the child-side of fork(). I don't mean lock-everything in a pre-fork() atfork handler, then unlock everything in the parent and child handlers -- that's not safe. I mean: reset all global state in the PKCS#11 implementation on the child-side of fork() in a child atfork handler -- yes, this means leaking memory (and its contents), but hopefully the child will immediately _exit() or exec*(). Also, O_CLOEXEC should be safely set on all file descriptors used by the PKCS#11 implementation. >> Of course, that's all rather POSIX-specific, but the problem is inherent >> to any fork()-like interface. Use posix_spawn() or similar, then you >> won't have to worry about fork-safety at all. Long ago I used to think >> fork+exec superior to spawn since spawn was easy to implement in terms >> of fork+exec, but in truth fork() is a dangerous and difficult-to-use >> interface -- the only safe things to do on the child side of fork() are: >> async-signal-safe things, culminating in _exit() or exec*() ASAP. > > Except that glibc's posix_spawn is screwed up wrt atfork. There are > some bugs open about it. That's because it needs a real vfork() (or at least to tell fork() not to run atfork handlers when called from posix_spawn()). Anyways, it should be possible to write atfork handlers that don't screw up a posix_spawn() user. If one really does use only async-signal-safe code in the atfork handlers, then that's really not that hard. But of course, you've no idea what atfork handlers have been set... Nico -- From nico at cryptonector.com Thu Nov 28 00:54:54 2013 From: nico at cryptonector.com (Nico Williams) Date: Wed, 27 Nov 2013 17:54:54 -0600 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> Message-ID: <20131127235451.GW21240@localhost> All of this is off-topic for this list. I'll post a reply anyways, and I apologize to the list. On Tue, Nov 19, 2013 at 10:24:03PM -0800, Andy Lutomirski wrote: > [...]. gnutls_global_init is documented as being > unsafe if called from multiple threads, which seems silly. Initialization is not thread-safe in OpenSSL either. This is a terrible thing. It *can* be made thread-safe, so there's no excuse for it not being thread-safe. > GnuTLS has gnutls_pkcs11_init, which is rather impolite -- it > manipulates global state, and it sometimes causes things to > malfunction after forking. [...] PKCS#11 is by definition fork-unsafe (see the PKCS#11 docs). Any API dealing with "tokens" (in the PKCS#11 sense) is bound to be fork-unsafe for at least open sessions/objects on tokens that require authentication (PIN). That's because any library using file descriptors where offset is not a relevant concept will necessarily be fork-unsafe by default. And: any stateful cryptography library (e.g., an implementation of TLS) will tend to be fork-unsafe (imagine a process trying to use a TLS connection on both sides of a fork()!). Of course, that's all rather POSIX-specific, but the problem is inherent to any fork()-like interface. Use posix_spawn() or similar, then you won't have to worry about fork-safety at all. Long ago I used to think fork+exec superior to spawn since spawn was easy to implement in terms of fork+exec, but in truth fork() is a dangerous and difficult-to-use interface -- the only safe things to do on the child side of fork() are: async-signal-safe things, culminating in _exit() or exec*() ASAP. > (As an even more off-topic aside, how is there nothing better than > pkcs11 for interfacing with abstract keys?) Not really, not portably, not to my knowledge :( Something better is badly needed, yes. In particular we need: a) decent APIs for software crypto (even if it uses specialized HW under the covers), b) decent APIs for talking to smartcards (tokens), including softtokens, c) decent APIs for cryptographic protocols, d) decent APIs for PKIX naming, ... Nico -- From phobos at panopticism.net Thu Nov 28 02:22:24 2013 From: phobos at panopticism.net (/dev/ph0b0s) Date: Wed, 27 Nov 2013 20:22:24 -0500 Subject: [gnutls-devel] Broken link on www.gnutls.org Message-ID: <20131128012224.GA12985@phobos.panopticism.net> A broken hyperlink exists on http://www.gnutls.org/index.html. Under the "Features" heading, the text "Trusted Platform Module (TPM)" in the second to last bullet point is a hyperlink to: http://www.gnutls.org/manual/html_node/Trusted-platform-module.html#Trusted-platform-module The correct target is: http://www.gnutls.org/manual/html_node/Trusted-Platform-Module.html#Trusted-Platform-Module (Note the differences in case of the words "Platform" and "Module".) Thanks. From nmav at redhat.com Thu Nov 28 10:10:30 2013 From: nmav at redhat.com (Nikos Mavrogiannopoulos) Date: Thu, 28 Nov 2013 10:10:30 +0100 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: <20131127235451.GW21240@localhost> References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <20131127235451.GW21240@localhost> Message-ID: <1385629830.23418.8.camel@dhcp-2-127.brq.redhat.com> On Wed, 2013-11-27 at 17:54 -0600, Nico Williams wrote: > All of this is off-topic for this list. I'll post a reply anyways, and > I apologize to the list. > > On Tue, Nov 19, 2013 at 10:24:03PM -0800, Andy Lutomirski wrote: > > [...]. gnutls_global_init is documented as being > > unsafe if called from multiple threads, which seems silly. > Initialization is not thread-safe in OpenSSL either. This is a terrible > thing. It *can* be made thread-safe, so there's no excuse for it not > being thread-safe. Hello, I don't understand why this is an issue since it is documented. If a function (like a global initialization function) is supposed to create the mutexes for the rest of the library functions it cannot be expected to be thread safe; at least in a portable way since static initialization of mutexes is not a portable thing. Nevertheless, even if you really need to call a global initialization function in every thread you create (I really don't see why), you can simply call it in a locked mutex. > > GnuTLS has gnutls_pkcs11_init, which is rather impolite -- it > > manipulates global state, and it sometimes causes things to > > malfunction after forking. [...] > PKCS#11 is by definition fork-unsafe (see the PKCS#11 docs). It requires some reinitialization on every fork. Again if that is documented it can be made to work. I agree, it is a PITA to handle though. regards, Nikos From nmav at gnutls.org Thu Nov 28 11:42:01 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 28 Nov 2013 11:42:01 +0100 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <20131127235451.GW21240@localhost> Message-ID: On Thu, Nov 28, 2013 at 12:58 AM, Andy Lutomirski wrote: >> PKCS#11 is by definition fork-unsafe (see the PKCS#11 docs). >> >> Any API dealing with "tokens" (in the PKCS#11 sense) is bound to be >> fork-unsafe for at least open sessions/objects on tokens that require >> authentication (PIN). That's because any library using file descriptors >> where offset is not a relevant concept will necessarily be fork-unsafe >> by default. And: any stateful cryptography library (e.g., an >> implementation of TLS) will tend to be fork-unsafe (imagine a process >> trying to use a TLS connection on both sides of a fork()!). > > I agree with all of this, except that I don't think that GnuTLS has > any business even trying to use PKCS11 unless something explicitly > requests it. I've had all kinds of problems with libvmime causing > GnuTLS to start interfacing with some mysterious GNOME PKCS11 token, > when I don't want any of the above. Well, I presume you don't know how gnutls works and I suggest that you read our online manual. We need PKCS #11 initialization because every gnutls function that accepts a key file may be provided with a PKCS #11 URL (or even a TPM key) and will work the way it is expected. You can of course disable PKCS #11 support if you don't need it, but as smart cards are getting wirespread, I prefer to have that enabled by default for all applications using gnutls. Otherwise we would have some gnutls applications that work with smart cards, and others that don't, just because someone forgot to explicitly enable smart card support. > It breaks fork for no good > reason. (I'm not even trying to do crypto in the child -- I just want > to avoid getting all kinds of random errors.) What do you mean it breaks fork? So far we had no issues with gnutls and fork (and I use it on several projects like that). There could be a bug, but I cannot find anything you reported on that. regards, Nikos From nmav at gnutls.org Thu Nov 28 17:30:48 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 28 Nov 2013 17:30:48 +0100 Subject: [gnutls-devel] Memory leak in print_aia in lib/x509/output.c In-Reply-To: <5291418A.80609@nx3d.org> References: <5291418A.80609@nx3d.org> Message-ID: On Sun, Nov 24, 2013 at 1:00 AM, Ben de Graaff wrote: > The print_aia function in lib/x509/output.c (called via e.g. > gnutls_x509_crt_print) calls gnutls_x509_crt_get_authority_info_access > but never frees the data if this call is successful. This results in a > memory leak. > Bug requires authority info access to be present, and exists in version > 3.2.6 and latest git. Hello Ben, Thank you for reporting that. I've committed a fix in the master branch. regards, Nikos From nmav at gnutls.org Thu Nov 28 17:45:13 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 28 Nov 2013 17:45:13 +0100 Subject: [gnutls-devel] Latest version of GnuTLS API Reference Manual In-Reply-To: <5293AFAD.5020708@gmx.net> References: <5293AFAD.5020708@gmx.net> Message-ID: On Mon, Nov 25, 2013 at 9:14 PM, Nico R. wrote: > Hello! > The GnuTLS Reference Manual on gnutls.org[0] tells users to go to > gnu.org[1] for the latest version, but [1] talks about GnuTLS 3.1.5 > whereas [0] is about GnuTLS 3.2.7. Thank you for reporting that. I'll try to update it as soon. regards, Nikos From nmav at gnutls.org Thu Nov 28 18:36:20 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 28 Nov 2013 18:36:20 +0100 Subject: [gnutls-devel] Broken link on www.gnutls.org In-Reply-To: <20131128012224.GA12985@phobos.panopticism.net> References: <20131128012224.GA12985@phobos.panopticism.net> Message-ID: <1385660180.1971.0.camel@aspire.lan> On Wed, 2013-11-27 at 20:22 -0500, /dev/ph0b0s wrote: > A broken hyperlink exists on http://www.gnutls.org/index.html. > > Under the "Features" heading, the text "Trusted Platform Module (TPM)" > in the second to last bullet point is a hyperlink to: > > http://www.gnutls.org/manual/html_node/Trusted-platform-module.html#Trusted-platform-module > > The correct target is: > > http://www.gnutls.org/manual/html_node/Trusted-Platform-Module.html#Trusted-Platform-Module > > (Note the differences in case of the words "Platform" and "Module".) Thank you, I've just updated. regards, Nikos From ametzler at bebt.de Thu Nov 28 19:13:48 2013 From: ametzler at bebt.de (Andreas Metzler) Date: Thu, 28 Nov 2013 19:13:48 +0100 Subject: [gnutls-devel] gnutls 3.2.7 FTBFS on kfreebsd - undefined reference to `rpl_strerror' Message-ID: <20131128181348.GA3193@downhill.g.la> Hello, gnutls 3.2.7 fails to build on kfreebsd where 3.2.6 worked: --------------- /bin/bash ../../libtool --tag=CC --mode=link gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -Wl,-z,relro -o crywrap crywrap.o ../../lib/libgnutls.la -lidn libtool: link: gcc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -Wl,-z -Wl,relro -o .libs/crywrap crywrap.o ../../lib/.libs/libgnutls.so -L/usr/lib/x86_64-kfreebsd-gnu -lz -lrt -lp11-kit -ltasn1 -lnettle -lhogweed -lgmp -lidn ../../lib/.libs/libgnutls.so: undefined reference to `rpl_strerror' collect2: error: ld returned 1 exit status make[6]: *** [crywrap] Error 1 make[6]: Leaving directory `/home/ametzler/GNUTLS/gnutls28-3.2.7/src/crywrap' make[5]: *** [all-recursive] Error 1 --------------- src/gl/string.h shows that @REPLACE_STRERROR@ ended up as 1 although ./configure seemed to be happy: -------------- grep strerror ../buildlog* checking for strerror_r... yes checking for __xpg_strerror_r... yes checking whether gai_strerror is declared without a macro... yes checking whether strerror_r is declared without a macro... yes checking whether strerror(0) succeeds... yes checking whether strerror_r is declared... (cached) yes checking whether gai_strerror is declared... (cached) yes checking whether gai_strerrorA is declared... no checking for gai_strerror with POSIX signature... yes checking whether gai_strerror is declared without a macro... (cached) yes checking whether perror matches strerror... yes checking whether strerror_r is declared... (cached) yes checking for strerror_r... (cached) yes checking whether strerror_r returns char *... yes checking for strerror... yes [...] -------------- Any ideas? cu Andreas https://buildd.debian.org/status/package.php?p=gnutls28&suite=experimental -- `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 Thu Nov 28 19:34:18 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 28 Nov 2013 19:34:18 +0100 Subject: [gnutls-devel] gnutls 3.2.7 FTBFS on kfreebsd - undefined reference to `rpl_strerror' In-Reply-To: <20131128181348.GA3193@downhill.g.la> References: <20131128181348.GA3193@downhill.g.la> Message-ID: <1385663658.22993.2.camel@aspire.lan> On Thu, 2013-11-28 at 19:13 +0100, Andreas Metzler wrote: > Hello, > > gnutls 3.2.7 fails to build on kfreebsd where 3.2.6 worked: > [...] > -------------- > > Any ideas? Hello, I've noticed that too, unfortunately after the release. It seems there is an issue in gnulib which replaces strerror with rpl_strerror even if I didn't use the gnulib strerror module. I've solved that by adding strerror in libgnutls' gnulib. A quick and dirty fix would be to remove the strerror() calls in lib/nettle/egd.c. regards, Nikos From jaak.ristioja at cyber.ee Fri Nov 29 15:11:56 2013 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Fri, 29 Nov 2013 16:11:56 +0200 Subject: [gnutls-devel] gnutls 3.2.7 FTBFS on kfreebsd - undefined reference to `rpl_strerror' In-Reply-To: <1385663658.22993.2.camel@aspire.lan> References: <20131128181348.GA3193@downhill.g.la> <1385663658.22993.2.camel@aspire.lan> Message-ID: <5298A0AC.6000307@cyber.ee> I also get undefined references to rpl_strerror when building GnuTLS or linking against it, on Debian stable (Wheezy), CentOS 6.4 and on some OS X machine. Best regards, Jaak On 28.11.2013 20:34, Nikos Mavrogiannopoulos wrote: > On Thu, 2013-11-28 at 19:13 +0100, Andreas Metzler wrote: >> Hello, >> >> gnutls 3.2.7 fails to build on kfreebsd where 3.2.6 worked: >> [...] >> -------------- >> >> Any ideas? > > Hello, > I've noticed that too, unfortunately after the release. It seems there > is an issue in gnulib which replaces strerror with rpl_strerror even if > I didn't use the gnulib strerror module. I've solved that by adding > strerror in libgnutls' gnulib. A quick and dirty fix would be to remove > the strerror() calls in lib/nettle/egd.c. > > regards, > Nikos > > > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-devel > From wiz at NetBSD.org Fri Nov 29 18:11:44 2013 From: wiz at NetBSD.org (Thomas Klausner) Date: Fri, 29 Nov 2013 18:11:44 +0100 Subject: [gnutls-devel] portability problem in gnutls-3.2.7: rpl_strerror missing Message-ID: <20131129171144.GU469@danbala.tuwien.ac.at> Hi! gnutls decides to replace NetBSD's strerror() with its own; I guess because this configure test fails: checking whether strerror(0) succeeds... no strerror(0) on NetBSD is: "Undefined error: 0" I don't see how that is a problem, can someone explain please? However, it later fails to link: CCLD gnutls-cli-debug ../lib/.libs/libgnutls.so: undefined reference to `rpl_strerror' clang: error: linker command failed with exit code 1 (use -v to see invocation) Where is this function supposed to be defined? grep -r rpl_strerror doesn't give me a hint: gnutls-3.2.7/src/gl/string.in.h:# define strerror rpl_strerror gnutls-3.2.7/src/gl/string.in.h:# define strerror_r rpl_strerror_r gnutls-3.2.7/src/gl/string.h:# define strerror rpl_strerror gnutls-3.2.7/src/gl/string.h:# define strerror_r rpl_strerror_r gnutls-3.2.7/gl/string.in.h:# define strerror rpl_strerror gnutls-3.2.7/gl/string.in.h:# define strerror_r rpl_strerror_r gnutls-3.2.7/gl/string.h:# define strerror rpl_strerror gnutls-3.2.7/gl/string.h:# define strerror_r rpl_strerror_r Ideas? Thanks, Thomas From ametzler at bebt.de Fri Nov 29 19:03:20 2013 From: ametzler at bebt.de (Andreas Metzler) Date: Fri, 29 Nov 2013 19:03:20 +0100 Subject: [gnutls-devel] portability problem in gnutls-3.2.7: rpl_strerror missing In-Reply-To: <20131129171144.GU469@danbala.tuwien.ac.at> References: <20131129171144.GU469@danbala.tuwien.ac.at> Message-ID: <20131129180320.GA3426@downhill.g.la> On 2013-11-29 Thomas Klausner wrote: > gnutls decides to replace NetBSD's strerror() with its own; I guess > because this configure test fails: > checking whether strerror(0) succeeds... no > strerror(0) on NetBSD is: "Undefined error: 0" > I don't see how that is a problem, can someone explain please? > However, it later fails to link: > CCLD gnutls-cli-debug > ../lib/.libs/libgnutls.so: undefined reference to `rpl_strerror' > clang: error: linker command failed with exit code 1 (use -v to see invocation) [...] > Ideas? http://lists.gnupg.org/pipermail/gnutls-devel/2013-November/006588.html 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 wiz at NetBSD.org Fri Nov 29 23:14:22 2013 From: wiz at NetBSD.org (Thomas Klausner) Date: Fri, 29 Nov 2013 23:14:22 +0100 Subject: [gnutls-devel] portability problem in gnutls-3.2.7: rpl_strerror missing In-Reply-To: <20131129180320.GA3426@downhill.g.la> References: <20131129171144.GU469@danbala.tuwien.ac.at> <20131129180320.GA3426@downhill.g.la> Message-ID: <20131129221422.GE17540@danbala.tuwien.ac.at> On Fri, Nov 29, 2013 at 07:03:20PM +0100, Andreas Metzler wrote: > http://lists.gnupg.org/pipermail/gnutls-devel/2013-November/006588.html Thanks. I tried what the post suggests, but still get: ../lib/.libs/libgnutls.so: undefined reference to `rpl_strerror' clang: error: linker command failed with exit code 1 (use -v to see invocation) ../lib/.libs/libgnutls.so: undefined reference to `rpl_strerror' clang: error: linker command failed with exit code 1 (use -v to see invocation) Makefile:1832: recipe for target 'srptool' failed gmake[4]: *** [srptool] Error 1 gmake[4]: *** Waiting for unfinished jobs.... Makefile:1828: recipe for target 'psktool' failed gmake[4]: *** [psktool] Error 1 I'll attach the patch I've used. Thomas -------------- next part -------------- $NetBSD$ http://lists.gnupg.org/pipermail/gnutls-devel/2013-November/006588.html --- lib/nettle/egd.c.orig 2013-11-10 17:59:14.000000000 +0000 +++ lib/nettle/egd.c @@ -155,12 +155,10 @@ int _rndegd_connect_socket(void) fd = socket(LOCAL_SOCKET_TYPE, SOCK_STREAM, 0); if (fd == -1) { - _gnutls_debug_log("can't create unix domain socket: %s\n", - strerror(errno)); + _gnutls_debug_log("can't create unix domain socket\n"); return -1; } else if (connect(fd, (struct sockaddr *) &addr, addr_len) == -1) { - _gnutls_debug_log("can't connect to EGD socket `%s': %s\n", - name, strerror(errno)); + _gnutls_debug_log("can't connect to EGD socket `%s'\n", name); close(fd); fd = -1; } @@ -202,13 +200,11 @@ int _rndegd_read(int *fd, void *_output, buffer[1] = nbytes; if (do_write(*fd, buffer, 2) == -1) - _gnutls_debug_log("can't write to the EGD: %s\n", - strerror(errno)); + _gnutls_debug_log("can't write to the EGD\n"); n = do_read(*fd, buffer, 1); if (n == -1) { - _gnutls_debug_log("read error on EGD: %s\n", - strerror(errno)); + _gnutls_debug_log("read error on EGD\n"); do_restart = 1; goto restart; } @@ -217,8 +213,7 @@ int _rndegd_read(int *fd, void *_output, if (n) { n = do_read(*fd, buffer, n); if (n == -1) { - _gnutls_debug_log("read error on EGD: %s\n", - strerror(errno)); + _gnutls_debug_log("read error on EGD\n"); do_restart = 1; goto restart; } @@ -240,12 +235,10 @@ int _rndegd_read(int *fd, void *_output, buffer[0] = 2; /* blocking */ buffer[1] = nbytes; if (do_write(*fd, buffer, 2) == -1) - _gnutls_debug_log("can't write to the EGD: %s\n", - strerror(errno)); + _gnutls_debug_log("can't write to the EGD\n"); n = do_read(*fd, buffer, nbytes); if (n == -1) { - _gnutls_debug_log("read error on EGD: %s\n", - strerror(errno)); + _gnutls_debug_log("read error on EGD\n"); do_restart = 1; goto restart; } From nmav at gnutls.org Fri Nov 29 23:45:41 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 29 Nov 2013 23:45:41 +0100 Subject: [gnutls-devel] portability problem in gnutls-3.2.7: rpl_strerror missing In-Reply-To: <20131129221422.GE17540@danbala.tuwien.ac.at> References: <20131129171144.GU469@danbala.tuwien.ac.at> <20131129180320.GA3426@downhill.g.la> <20131129221422.GE17540@danbala.tuwien.ac.at> Message-ID: <1385765141.5937.0.camel@aspire.lan> On Fri, 2013-11-29 at 23:14 +0100, Thomas Klausner wrote: > On Fri, Nov 29, 2013 at 07:03:20PM +0100, Andreas Metzler wrote: > > http://lists.gnupg.org/pipermail/gnutls-devel/2013-November/006588.html > > Thanks. > > I tried what the post suggests, but still get: > ../lib/.libs/libgnutls.so: undefined reference to `rpl_strerror' > clang: error: linker command failed with exit code 1 (use -v to see invocation) > ../lib/.libs/libgnutls.so: undefined reference to `rpl_strerror' > clang: error: linker command failed with exit code 1 (use -v to see invocation) > Makefile:1832: recipe for target 'srptool' failed > gmake[4]: *** [srptool] Error 1 Indeed. I missed nettle/rnd.c. It also calls strerror(). Apart from those two I don't see it in any other files. regards, Nikos From wiz at NetBSD.org Fri Nov 29 23:54:42 2013 From: wiz at NetBSD.org (Thomas Klausner) Date: Fri, 29 Nov 2013 23:54:42 +0100 Subject: [gnutls-devel] portability problem in gnutls-3.2.7: rpl_strerror missing In-Reply-To: <1385765141.5937.0.camel@aspire.lan> References: <20131129171144.GU469@danbala.tuwien.ac.at> <20131129180320.GA3426@downhill.g.la> <20131129221422.GE17540@danbala.tuwien.ac.at> <1385765141.5937.0.camel@aspire.lan> Message-ID: <20131129225442.GI25304@danbala.tuwien.ac.at> On Fri, Nov 29, 2013 at 11:45:41PM +0100, Nikos Mavrogiannopoulos wrote: > On Fri, 2013-11-29 at 23:14 +0100, Thomas Klausner wrote: > > On Fri, Nov 29, 2013 at 07:03:20PM +0100, Andreas Metzler wrote: > > > http://lists.gnupg.org/pipermail/gnutls-devel/2013-November/006588.html > > > > Thanks. > > > > I tried what the post suggests, but still get: > > ../lib/.libs/libgnutls.so: undefined reference to `rpl_strerror' > > clang: error: linker command failed with exit code 1 (use -v to see invocation) > > ../lib/.libs/libgnutls.so: undefined reference to `rpl_strerror' > > clang: error: linker command failed with exit code 1 (use -v to see invocation) > > Makefile:1832: recipe for target 'srptool' failed > > gmake[4]: *** [srptool] Error 1 > > Indeed. I missed nettle/rnd.c. It also calls strerror(). Apart from > those two I don't see it in any other files. Thanks. Using the attached two patches gnutls compiles for me again. Btw, please fix the test(1) '==' usage in configure.ac -- only bash test(1) supports that, everywhere else it's just '='. (patch attached) Thanks, Thomas -------------- next part -------------- $NetBSD$ http://lists.gnupg.org/pipermail/gnutls-devel/2013-November/006588.html --- lib/nettle/egd.c.orig 2013-11-10 17:59:14.000000000 +0000 +++ lib/nettle/egd.c @@ -155,12 +155,10 @@ int _rndegd_connect_socket(void) fd = socket(LOCAL_SOCKET_TYPE, SOCK_STREAM, 0); if (fd == -1) { - _gnutls_debug_log("can't create unix domain socket: %s\n", - strerror(errno)); + _gnutls_debug_log("can't create unix domain socket\n"); return -1; } else if (connect(fd, (struct sockaddr *) &addr, addr_len) == -1) { - _gnutls_debug_log("can't connect to EGD socket `%s': %s\n", - name, strerror(errno)); + _gnutls_debug_log("can't connect to EGD socket `%s'\n", name); close(fd); fd = -1; } @@ -202,13 +200,11 @@ int _rndegd_read(int *fd, void *_output, buffer[1] = nbytes; if (do_write(*fd, buffer, 2) == -1) - _gnutls_debug_log("can't write to the EGD: %s\n", - strerror(errno)); + _gnutls_debug_log("can't write to the EGD\n"); n = do_read(*fd, buffer, 1); if (n == -1) { - _gnutls_debug_log("read error on EGD: %s\n", - strerror(errno)); + _gnutls_debug_log("read error on EGD\n"); do_restart = 1; goto restart; } @@ -217,8 +213,7 @@ int _rndegd_read(int *fd, void *_output, if (n) { n = do_read(*fd, buffer, n); if (n == -1) { - _gnutls_debug_log("read error on EGD: %s\n", - strerror(errno)); + _gnutls_debug_log("read error on EGD\n"); do_restart = 1; goto restart; } @@ -240,12 +235,10 @@ int _rndegd_read(int *fd, void *_output, buffer[0] = 2; /* blocking */ buffer[1] = nbytes; if (do_write(*fd, buffer, 2) == -1) - _gnutls_debug_log("can't write to the EGD: %s\n", - strerror(errno)); + _gnutls_debug_log("can't write to the EGD\n"); n = do_read(*fd, buffer, nbytes); if (n == -1) { - _gnutls_debug_log("read error on EGD: %s\n", - strerror(errno)); + _gnutls_debug_log("read error on EGD\n"); do_restart = 1; goto restart; } -------------- next part -------------- $NetBSD$ http://lists.gnupg.org/pipermail/gnutls-devel/2013-November/006588.html --- lib/nettle/rnd.c.orig 2013-11-10 17:59:14.000000000 +0000 +++ lib/nettle/rnd.c @@ -90,8 +90,7 @@ static int do_trivia_source(int init) memcpy(&event.now, ¤t_time, sizeof(event.now)); #ifdef HAVE_GETRUSAGE if (getrusage(RUSAGE_SELF, &event.rusage) < 0) { - _gnutls_debug_log("getrusage failed: %s\n", - strerror(errno)); + _gnutls_debug_log("getrusage failed\n"); abort(); } #endif @@ -244,8 +243,7 @@ static int do_device_source_urandom(int if (res <= 0) { if (res < 0) { _gnutls_debug_log - ("Failed to read /dev/urandom: %s\n", - strerror(errno)); + ("Failed to read /dev/urandom\n"); } else { _gnutls_debug_log ("Failed to read /dev/urandom: end of file\n"); -------------- next part -------------- $NetBSD$ --- configure.ac.orig 2013-11-23 10:04:09.000000000 +0000 +++ configure.ac @@ -347,7 +347,7 @@ fi AM_CONDITIONAL(ENABLE_TROUSERS, test "$with_tpm" != "no") LIBOPTS_CHECK([src/libopts]) -if test "$NEED_LIBOPTS_DIR" == "true";then +if test "$NEED_LIBOPTS_DIR" = "true";then dnl delete libopts-generated files for i in ${srcdir}/src/*-args.c.bak ${srcdir}/src/*-args.h.bak; do nam=`echo $i|sed 's/.bak//g'` From luto at amacapital.net Sat Nov 30 00:35:43 2013 From: luto at amacapital.net (Andy Lutomirski) Date: Fri, 29 Nov 2013 15:35:43 -0800 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: <1385629830.23418.8.camel@dhcp-2-127.brq.redhat.com> References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <20131127235451.GW21240@localhost> <1385629830.23418.8.camel@dhcp-2-127.brq.redhat.com> Message-ID: On Thu, Nov 28, 2013 at 1:10 AM, Nikos Mavrogiannopoulos wrote: > On Wed, 2013-11-27 at 17:54 -0600, Nico Williams wrote: >> All of this is off-topic for this list. I'll post a reply anyways, and >> I apologize to the list. >> >> On Tue, Nov 19, 2013 at 10:24:03PM -0800, Andy Lutomirski wrote: >> > [...]. gnutls_global_init is documented as being >> > unsafe if called from multiple threads, which seems silly. >> Initialization is not thread-safe in OpenSSL either. This is a terrible >> thing. It *can* be made thread-safe, so there's no excuse for it not >> being thread-safe. > Hello, > I don't understand why this is an issue since it is documented. If a > function (like a global initialization function) is supposed to create > the mutexes for the rest of the library functions it cannot be expected > to be thread safe; at least in a portable way since static > initialization of mutexes is not a portable thing. > > Nevertheless, even if you really need to call a global initialization > function in every thread you create (I really don't see why), you can > simply call it in a locked mutex. No, I can't. I occasionally use libraries, and those libraries in turn use GnuTLS. Requiring those libraries to force their users to synchronize their initialization of GnuTLS sucks. If GnuTLS really must use global state in a manner that isn't transparent to its users, it should get the synchronization right. Any self-respecting pthreads implementation should implement PTHREAD_MUTEX_INITIALIZER in such a way that it constant-initializes its data, making it completely safe. An even better solution would be to use pthread_once. --Andy From luto at amacapital.net Sat Nov 30 00:46:13 2013 From: luto at amacapital.net (Andy Lutomirski) Date: Fri, 29 Nov 2013 15:46:13 -0800 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: <1385768592.5937.29.camel@aspire.lan> References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <20131127235451.GW21240@localhost> <1385629830.23418.8.camel@dhcp-2-127.brq.redhat.com> <1385768592.5937.29.camel@aspire.lan> Message-ID: On Fri, Nov 29, 2013 at 3:43 PM, Nikos Mavrogiannopoulos wrote: > On Fri, 2013-11-29 at 15:35 -0800, Andy Lutomirski wrote: > > [This is clearly off-topic for the TLS working group so it was striken > out] > >> >> Initialization is not thread-safe in OpenSSL either. This is a terrible >> >> thing. It *can* be made thread-safe, so there's no excuse for it not >> >> being thread-safe. >> > Hello, >> > I don't understand why this is an issue since it is documented. If a >> > function (like a global initialization function) is supposed to create >> > the mutexes for the rest of the library functions it cannot be expected >> > to be thread safe; at least in a portable way since static >> > initialization of mutexes is not a portable thing. >> > >> > Nevertheless, even if you really need to call a global initialization >> > function in every thread you create (I really don't see why), you can >> > simply call it in a locked mutex. >> >> No, I can't. I occasionally use libraries, and those libraries in >> turn use GnuTLS. Requiring those libraries to force their users to >> synchronize their initialization of GnuTLS sucks. > > I don't quite understand by what you mean by synchronize. They don't > need to synchronize, they just need to initialize the library at an > early state. > >> Any self-respecting pthreads implementation should implement >> PTHREAD_MUTEX_INITIALIZER in such a way that it constant-initializes >> its data, making it completely safe. An even better solution would be >> to use pthread_once. > > Unfortuntely that only works with pthreads. What about systems that > don't have static initializers for locks? Unfortunately we need a > consistent API for all the supported systems. Windows has an InitOnceInitialize, etc mechanism (on Vista and higher). In any case, getting this right on pthreads systems would be a major improvement over getting it wrong everywhere. --Andy From nmav at gnutls.org Sat Nov 30 00:43:12 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 30 Nov 2013 00:43:12 +0100 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <20131127235451.GW21240@localhost> <1385629830.23418.8.camel@dhcp-2-127.brq.redhat.com> Message-ID: <1385768592.5937.29.camel@aspire.lan> On Fri, 2013-11-29 at 15:35 -0800, Andy Lutomirski wrote: [This is clearly off-topic for the TLS working group so it was striken out] > >> Initialization is not thread-safe in OpenSSL either. This is a terrible > >> thing. It *can* be made thread-safe, so there's no excuse for it not > >> being thread-safe. > > Hello, > > I don't understand why this is an issue since it is documented. If a > > function (like a global initialization function) is supposed to create > > the mutexes for the rest of the library functions it cannot be expected > > to be thread safe; at least in a portable way since static > > initialization of mutexes is not a portable thing. > > > > Nevertheless, even if you really need to call a global initialization > > function in every thread you create (I really don't see why), you can > > simply call it in a locked mutex. > > No, I can't. I occasionally use libraries, and those libraries in > turn use GnuTLS. Requiring those libraries to force their users to > synchronize their initialization of GnuTLS sucks. I don't quite understand by what you mean by synchronize. They don't need to synchronize, they just need to initialize the library at an early state. > Any self-respecting pthreads implementation should implement > PTHREAD_MUTEX_INITIALIZER in such a way that it constant-initializes > its data, making it completely safe. An even better solution would be > to use pthread_once. Unfortuntely that only works with pthreads. What about systems that don't have static initializers for locks? Unfortunately we need a consistent API for all the supported systems. regards, Nikos From nico at cryptonector.com Sat Nov 30 00:51:06 2013 From: nico at cryptonector.com (Nico Williams) Date: Fri, 29 Nov 2013 17:51:06 -0600 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <20131127235451.GW21240@localhost> <1385629830.23418.8.camel@dhcp-2-127.brq.redhat.com> <1385768592.5937.29.camel@aspire.lan> Message-ID: See the thread_safety branch of my github clone of OpenSSL for how to use InitOnceInitialize() and pthread_once(). OpenSSL has exactly this same problem: it wants to be initialized *once*, but its callers can be buried in libraries, many layers below the [threaded] application. Worse, OpenSSL's initialization is inherently thread-unsafe (for dynlock callbacks). WARNING: My OpenSSL patches aren't complete / tested. Nico -- From luto at amacapital.net Sat Nov 30 00:50:54 2013 From: luto at amacapital.net (Andy Lutomirski) Date: Fri, 29 Nov 2013 15:50:54 -0800 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <20131127235451.GW21240@localhost> Message-ID: On Thu, Nov 28, 2013 at 2:42 AM, Nikos Mavrogiannopoulos wrote: > On Thu, Nov 28, 2013 at 12:58 AM, Andy Lutomirski wrote: > >>> PKCS#11 is by definition fork-unsafe (see the PKCS#11 docs). >>> >>> Any API dealing with "tokens" (in the PKCS#11 sense) is bound to be >>> fork-unsafe for at least open sessions/objects on tokens that require >>> authentication (PIN). That's because any library using file descriptors >>> where offset is not a relevant concept will necessarily be fork-unsafe >>> by default. And: any stateful cryptography library (e.g., an >>> implementation of TLS) will tend to be fork-unsafe (imagine a process >>> trying to use a TLS connection on both sides of a fork()!). >> >> I agree with all of this, except that I don't think that GnuTLS has >> any business even trying to use PKCS11 unless something explicitly >> requests it. I've had all kinds of problems with libvmime causing >> GnuTLS to start interfacing with some mysterious GNOME PKCS11 token, >> when I don't want any of the above. > > Well, I presume you don't know how gnutls works and I suggest that you > read our online manual. Nope. I'm not a GnuTLS user. I do, however, use libvmime, and I get annoyed when GnuTLS does ridiculous things that get in the way. > > We need PKCS #11 initialization because every gnutls function that > accepts a key file may be provided with a PKCS #11 URL (or even a TPM > key) and will work the way it is expected. You can of course disable > PKCS #11 support if you don't need it, but as smart cards are getting > wirespread, I prefer to have that enabled by default for all > applications using gnutls. Otherwise we would have some gnutls > applications that work with smart cards, and others that don't, just > because someone forgot to explicitly enable smart card support. ...so initialize PKCS11 the first time someone tries to use it. I bet that a large fraction of GnuTLS users are TLS clients that will never use a client certificate, so there's no reason at all to attempt any kind of fancy key handling. The fact that this: #include #include #include int main() { vmime::platform::setHandler(); return 0; } connects to gnome-keyring-daemon is, IMO, ridiculous. PKCS11 sucks. That doesn't mean that GnuTLS shouldn't try to avoid exposing that suckage to use users. --Andy From nmav at gnutls.org Sat Nov 30 00:45:35 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 30 Nov 2013 00:45:35 +0100 Subject: [gnutls-devel] portability problem in gnutls-3.2.7: rpl_strerror missing In-Reply-To: <20131129225442.GI25304@danbala.tuwien.ac.at> References: <20131129171144.GU469@danbala.tuwien.ac.at> <20131129180320.GA3426@downhill.g.la> <20131129221422.GE17540@danbala.tuwien.ac.at> <1385765141.5937.0.camel@aspire.lan> <20131129225442.GI25304@danbala.tuwien.ac.at> Message-ID: <1385768735.5937.30.camel@aspire.lan> On Fri, 2013-11-29 at 23:54 +0100, Thomas Klausner wrote: > Thanks. Using the attached two patches gnutls compiles for me again. > > Btw, please fix the test(1) '==' usage in configure.ac -- only bash > test(1) supports that, everywhere else it's just '='. (patch attached) Applied, thank you. Nikos From nico at cryptonector.com Sat Nov 30 01:00:50 2013 From: nico at cryptonector.com (Nico Williams) Date: Fri, 29 Nov 2013 18:00:50 -0600 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: <1385768592.5937.29.camel@aspire.lan> References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <20131127235451.GW21240@localhost> <1385629830.23418.8.camel@dhcp-2-127.brq.redhat.com> <1385768592.5937.29.camel@aspire.lan> Message-ID: On Fri, Nov 29, 2013 at 5:43 PM, Nikos Mavrogiannopoulos wrote: > On Fri, 2013-11-29 at 15:35 -0800, Andy Lutomirski wrote: >> Any self-respecting pthreads implementation should implement >> PTHREAD_MUTEX_INITIALIZER in such a way that it constant-initializes >> its data, making it completely safe. An even better solution would be >> to use pthread_once. > > Unfortuntely that only works with pthreads. What about systems that > don't have static initializers for locks? Unfortunately we need a > consistent API for all the supported systems. See http://stackoverflow.com/questions/3555859/is-it-possible-to-do-static-initialization-of-mutexes-in-windows Nico -- From nmav at gnutls.org Sat Nov 30 01:01:46 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 30 Nov 2013 01:01:46 +0100 Subject: [gnutls-devel] eliminating gnutls_global_init Message-ID: <1385769706.5937.44.camel@aspire.lan> Hello, I'm considering moving parts of gnutls_global_init to a library constructor. That would mean that in ELF systems and systems that support constructors, it would be possible to use gnutls without calling gnutls_global_init(). The main parts in gnutls_global_init now are: * Initialization of libtasn1 structures (no I/O) * Initialization of mutexes (no I/O) * Detection of CPU type and loading of any possible accelerated cipher versions (may have I/O when cryptodev is compiled in) * Initialization of the random number generator (requires I/O from /dev/urandom) * Initialization of PKCS #11 modules (anything could be there -it's hell) I'm thinking to put everything except the PKCS #11 initialization in the constructor, and that functionality would only be available if the global_init is explicitly called. The issues with having the initialization the constructor are * It is not clear what to do on initialization error (e.g. when some I/O fails) * There will be different semantics in static libraries (that call no constructors), which will still need to call gnutls_global_init and ELF shared libraries that will not. Any issues I've missed, or ideas? regards, Nikos From nico at cryptonector.com Sat Nov 30 01:03:31 2013 From: nico at cryptonector.com (Nico Williams) Date: Fri, 29 Nov 2013 18:03:31 -0600 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <20131127235451.GW21240@localhost> Message-ID: On Thu, Nov 28, 2013 at 4:42 AM, Nikos Mavrogiannopoulos wrote: > On Thu, Nov 28, 2013 at 12:58 AM, Andy Lutomirski wrote: >>> PKCS#11 is by definition fork-unsafe (see the PKCS#11 docs). >>> >> It breaks fork for no good >> reason. (I'm not even trying to do crypto in the child -- I just want >> to avoid getting all kinds of random errors.) > > What do you mean it breaks fork? So far we had no issues with gnutls > and fork (and I use it on several projects like that). There could be > a bug, but I cannot find anything you reported on that. It is not safe to use PKCS#11 on the child-side of fork() without first either a) calling C_Initialize() to re-initialize PKCS#11, or b) exec*() first. Now, children of fork() are supposed to only call async-signal-safe functions, therefore PKCS#11 is out on the child-side of fork() anyways, but, the PKCS#11 docs also specifically describe PKCS#11 as fork-unsafe. Nico -- From luto at amacapital.net Sat Nov 30 01:06:27 2013 From: luto at amacapital.net (Andy Lutomirski) Date: Fri, 29 Nov 2013 16:06:27 -0800 Subject: [gnutls-devel] eliminating gnutls_global_init In-Reply-To: <1385769706.5937.44.camel@aspire.lan> References: <1385769706.5937.44.camel@aspire.lan> Message-ID: On Fri, Nov 29, 2013 at 4:01 PM, Nikos Mavrogiannopoulos wrote: > Hello, > I'm considering moving parts of gnutls_global_init to a library > constructor. That would mean that in ELF systems and systems that > support constructors, it would be possible to use gnutls without calling > gnutls_global_init(). In theory, a different library could create a thread in a constructor or try to use GnuTLS from a constructor, causing problems. (This might be unlikely.) I think that automatically initializing this stuff on the first call into GnuTLS would be ideal. --Andy From nico at cryptonector.com Sat Nov 30 01:10:42 2013 From: nico at cryptonector.com (Nico Williams) Date: Fri, 29 Nov 2013 18:10:42 -0600 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <20131127235451.GW21240@localhost> <1385629830.23418.8.camel@dhcp-2-127.brq.redhat.com> <1385768592.5937.29.camel@aspire.lan> Message-ID: On Fri, Nov 29, 2013 at 5:46 PM, Andy Lutomirski wrote: >> Unfortuntely that only works with pthreads. What about systems that >> don't have static initializers for locks? Unfortunately we need a >> consistent API for all the supported systems. > > Windows has an InitOnceInitialize, etc mechanism (on Vista and higher). > > In any case, getting this right on pthreads systems would be a major > improvement over getting it wrong everywhere. +1 to all of what you say Andy, but I'd like to add: 1) If you have enough basic primitives (like mutexes with static initializers, or mutexes and CAS, or InitOnceInitialize), then you can self-initialize in a library safely. 2) Every major OS/architecture has the primitives needed for library self-initialization. There is no excuse not to self-initialize libraries safely. 3) Every major current OS/architecture has (and has had for a long time) default threading primitives (e.g., pthreads) and atomic operations (e.g., CAS). There is no need for allowing apps to provide their own lock callbacks as in OpenSSL (although it's possible to make that work, provided that the callback-setting interface is not inherently thread-unsafe). 4) DO NOT USE ELF .ini sections for thread-safe initialization, not if the .init section has any dependencies on any other objects/libraries than the C run-time. There's no canonical ELF .ini section load/run order. On Windows you might use DllMain, but I wouldn't -- just build portable once-init infrastructure and use it everywhere. Nico -- From ametzler at bebt.de Sat Nov 30 08:26:41 2013 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 30 Nov 2013 08:26:41 +0100 Subject: [gnutls-devel] gnutls 3.2.7 FTBFS on kfreebsd - undefined reference to `rpl_strerror' In-Reply-To: <1385663658.22993.2.camel@aspire.lan> References: <20131128181348.GA3193@downhill.g.la> <1385663658.22993.2.camel@aspire.lan> Message-ID: <20131130072641.GA3267@downhill.g.la> On 2013-11-28 Nikos Mavrogiannopoulos wrote: > On Thu, 2013-11-28 at 19:13 +0100, Andreas Metzler wrote: >> gnutls 3.2.7 fails to build on kfreebsd where 3.2.6 worked: >> [...] >> -------------- >> >> Any ideas? > Hello, > I've noticed that too, unfortunately after the release. It seems there > is an issue in gnulib which replaces strerror with rpl_strerror even if > I didn't use the gnulib strerror module. I've solved that by adding > strerror in libgnutls' gnulib. [...] Thank you, pulling 31832b2d2cee8407007bb7651616bb8097d1a168 seems to have worked. 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 Nov 30 09:54:08 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 30 Nov 2013 09:54:08 +0100 Subject: [gnutls-devel] eliminating gnutls_global_init In-Reply-To: References: <1385769706.5937.44.camel@aspire.lan> Message-ID: <1385801648.12460.9.camel@aspire.lan> On Fri, 2013-11-29 at 16:06 -0800, Andy Lutomirski wrote: > On Fri, Nov 29, 2013 at 4:01 PM, Nikos Mavrogiannopoulos > wrote: > > Hello, > > I'm considering moving parts of gnutls_global_init to a library > > constructor. That would mean that in ELF systems and systems that > > support constructors, it would be possible to use gnutls without calling > > gnutls_global_init(). > > In theory, a different library could create a thread in a constructor > or try to use GnuTLS from a constructor, causing problems. (This > might be unlikely.) One cannot use gnutls from a constructor unless he calls gnutls_global_init() which has a reference counter, so there would be no issue there, since constructors are run serialized. > I think that automatically initializing this stuff on the first call > into GnuTLS would be ideal. The question is on the first call to what? There are so many functions this is hardly an option. Even if it would be an option, each call would have to check the global initialization mutex, which would slow things down when many threads are used. As it is now a constructor solves many issues, and the only cost I see is a different API when static linking which requires the gnutls_global_init call. regards, Nikos From nmav at gnutls.org Sat Nov 30 09:58:52 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 30 Nov 2013 09:58:52 +0100 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> Message-ID: <1385801932.12460.12.camel@aspire.lan> On Fri, 2013-11-29 at 18:03 -0600, Nico Williams wrote: > > What do you mean it breaks fork? So far we had no issues with gnutls > > and fork (and I use it on several projects like that). There could be > > a bug, but I cannot find anything you reported on that. > > It is not safe to use PKCS#11 on the child-side of fork() without > first either a) calling C_Initialize() to re-initialize PKCS#11, or b) > exec*() first. Now, children of fork() are supposed to only call > async-signal-safe functions, therefore PKCS#11 is out on the > child-side of fork() anyways, but, the PKCS#11 docs also specifically > describe PKCS#11 as fork-unsafe. I was referring to his issue. As far as I understood he didn't use PKCS #11 at all, so there should be no breakage. When ones uses PKCS #11 in gnutls he is (currently) required to call gnutls_pkcs11_reinit() on a fork. regards, Nikos From nmav at gnutls.org Sat Nov 30 10:00:44 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 30 Nov 2013 10:00:44 +0100 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <20131127235451.GW21240@localhost> <1385629830.23418.8.camel@dhcp-2-127.brq.redhat.com> <1385768592.5937.29.camel@aspire.lan> Message-ID: <1385802044.12460.13.camel@aspire.lan> On Fri, 2013-11-29 at 18:00 -0600, Nico Williams wrote: > On Fri, Nov 29, 2013 at 5:43 PM, Nikos Mavrogiannopoulos > wrote: > > On Fri, 2013-11-29 at 15:35 -0800, Andy Lutomirski wrote: > >> Any self-respecting pthreads implementation should implement > >> PTHREAD_MUTEX_INITIALIZER in such a way that it constant-initializes > >> its data, making it completely safe. An even better solution would be > >> to use pthread_once. > > > > Unfortuntely that only works with pthreads. What about systems that > > don't have static initializers for locks? Unfortunately we need a > > consistent API for all the supported systems. > > See http://stackoverflow.com/questions/3555859/is-it-possible-to-do-static-initialization-of-mutexes-in-windows That looks interesting thanks. regards, Nikos From nmav at gnutls.org Sat Nov 30 10:03:55 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 30 Nov 2013 10:03:55 +0100 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> <2A0EFB9C05D0164E98F19BB0AF3708C711DAEEE373@USMBX1.msg.corp.akamai.com> <528AD194.9060003@amacapital.net> <528AD326.8080908@kirils.com> <528BBD84.60700@amacapital.net> <528C4332.9060806@funwithsoftware.org> <20131127235451.GW21240@localhost> <1385629830.23418.8.camel@dhcp-2-127.brq.redhat.com> <1385768592.5937.29.camel@aspire.lan> Message-ID: <1385802235.12460.16.camel@aspire.lan> On Fri, 2013-11-29 at 15:46 -0800, Andy Lutomirski wrote: > > I don't quite understand by what you mean by synchronize. They don't > > need to synchronize, they just need to initialize the library at an > > early state. > > > >> Any self-respecting pthreads implementation should implement > >> PTHREAD_MUTEX_INITIALIZER in such a way that it constant-initializes > >> its data, making it completely safe. An even better solution would be > >> to use pthread_once. > > > > Unfortuntely that only works with pthreads. What about systems that > > don't have static initializers for locks? Unfortunately we need a > > consistent API for all the supported systems. > > Windows has an InitOnceInitialize, etc mechanism (on Vista and higher). > > In any case, getting this right on pthreads systems would be a major > improvement over getting it wrong everywhere. Right or wrong is in the eye of the beholder. A documented behavior is a documented behavior (rather than right or wrong), and calling gnutls_global_init() on each and every thread is not only unsafe but a waste of resources. Indeed, I can fix the unsafe part with static initializers, and I'll try to, but that will not fix the waste of resources. regards, Nikos From nmav at gnutls.org Sat Nov 30 10:08:04 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 30 Nov 2013 10:08:04 +0100 Subject: [gnutls-devel] [TLS] multiple clients in one process (was: Re: Deployment ... Re: This working group has failed) In-Reply-To: References: <44D7624E-75D8-47D3-93BF-97427206E800@iki.fi> Message-ID: <1385802484.12460.19.camel@aspire.lan> On Fri, 2013-11-29 at 18:10 -0600, Nico Williams wrote: > 4) DO NOT USE ELF .ini sections for thread-safe initialization, not if > the .init section has any dependencies on any other objects/libraries > than the C run-time. There's no canonical ELF .ini section load/run > order. On Windows you might use DllMain, but I wouldn't -- just build > portable once-init infrastructure and use it everywhere. Have you considered or tried using that approach in your branch of openssl and backed off? If dependencies are avoided it looks like an ideal fix, especially if you consider that a global initialization function would do much more than just initializing mutexes (e.g. precalculations or CPU type detection). regards, Nikos From dkg at fifthhorseman.net Sat Nov 30 15:15:21 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sat, 30 Nov 2013 09:15:21 -0500 Subject: [gnutls-devel] eliminating gnutls_global_init In-Reply-To: <1385769706.5937.44.camel@aspire.lan> References: <1385769706.5937.44.camel@aspire.lan> Message-ID: <5299F2F9.2080607@fifthhorseman.net> On 11/29/2013 07:01 PM, Nikos Mavrogiannopoulos wrote: > The issues with having the initialization the constructor are > * It is not clear what to do on initialization error (e.g. when some I/O > fails) > * There will be different semantics in static libraries (that call no > constructors), which will still need to call gnutls_global_init and ELF > shared libraries that will not. > > Any issues I've missed, or ideas? how does this interact with tools that load gnutls via dlopen? will they need to do anything special, or will dlopen take care of it? what happens if a process dlopen()s the library twice? (e.g. via two separate modules in the PAM stack or something horrible like that) --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Sat Nov 30 16:15:48 2013 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 30 Nov 2013 16:15:48 +0100 Subject: [gnutls-devel] eliminating gnutls_global_init In-Reply-To: <5299F2F9.2080607@fifthhorseman.net> References: <1385769706.5937.44.camel@aspire.lan> <5299F2F9.2080607@fifthhorseman.net> Message-ID: <1385824548.11639.10.camel@aspire.lan> On Sat, 2013-11-30 at 09:15 -0500, Daniel Kahn Gillmor wrote: > On 11/29/2013 07:01 PM, Nikos Mavrogiannopoulos wrote: > > The issues with having the initialization the constructor are > > * It is not clear what to do on initialization error (e.g. when some I/O > > fails) > > * There will be different semantics in static libraries (that call no > > constructors), which will still need to call gnutls_global_init and ELF > > shared libraries that will not. > > > > Any issues I've missed, or ideas? > > how does this interact with tools that load gnutls via dlopen? will > they need to do anything special, or will dlopen take care of it? what > happens if a process dlopen()s the library twice? (e.g. via two separate > modules in the PAM stack or something horrible like that) It should be fine with dlopen(). Dlopen already had provision for the _init and _fini functions and as far as I see from some googling it seems to operate as expected with library constructors and destructors (and it should as I guess they are implemented exactly the same way in an ELF system). regards, Nikos