From ametzler at bebt.de Wed Dec 3 20:01:25 2014 From: ametzler at bebt.de (Andreas Metzler) Date: Wed, 3 Dec 2014 20:01:25 +0100 Subject: [gnutls-devel] Unable to trust server certificate instead of issueing CA Message-ID: <20141203190125.GA2074@downhill.g.la> Hello, This came up on d-d : With gnutls 3.3.* it seems to be impossible to trust server certificate instead of the signing authority: -------------------------------------------- ametzler at argenau:~$ gnutls-cli --x509cafile=/tmp/GNUTLS/buildd.debian.org.pem buildd.debian.org Processed 1 CA certificate(s). Resolving 'buildd.debian.org'... Connecting to '5.153.231.18:443'... - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject `OU=Domain Control Validated,OU=Gandi Standard SSL,CN=buildd.debian.org', issuer `C=FR,O=GANDI SAS,CN=Gandi Standard SSL CA', RSA key 3072 bits, signed using RSA-SHA1, activated `2013-12-31 00:00:00 UTC', expires `2014-12-31 23:59:59 UTC', SHA-1 fingerprint `2cdbdc8f013e50e9834cbdca02ecaea7f3982ed4' Public Key ID: 787e4e3917a1f7f8962f10ea72a89e6dee922952 Public key's random art: +--[ RSA 3072]----+ | | | | | . | | . ... | | . S ..o. | | E o .o.+ | | . o.o= o... | | . . +o++oo .+ | | . o+*+o. ..o.| +-----------------+ - Certificate[1] info: - subject `C=FR,O=GANDI SAS,CN=Gandi Standard SSL CA', issuer `C=US,ST=UT,L=Salt Lake City,O=The USERTRUST Network,OU=http://www.usertrust.com,CN=UTN-USERFirst-Hardware', RSA key 2048 bits, signed using RSA-SHA1, activated `2008-10-23 00:00:00 UTC', expires `2020-05-30 10:48:38 UTC', SHA-1 fingerprint `a9f79883a075ce82d20d274d1368e876140d33b3' - Status: The certificate is NOT trusted. The certificate issuer is unknown. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. *** Handshake has failed GnuTLS error: Error in the certificate. -------------------------------------------- This used to work in 2.x. Is this an intentional change? 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 dkg at fifthhorseman.net Wed Dec 3 21:26:09 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 03 Dec 2014 15:26:09 -0500 Subject: [gnutls-devel] Unable to trust server certificate instead of issueing CA In-Reply-To: <20141203190125.GA2074@downhill.g.la> References: <20141203190125.GA2074@downhill.g.la> Message-ID: <547F71E1.1080705@fifthhorseman.net> On 12/03/2014 02:01 PM, Andreas Metzler wrote: > Hello, > > This came up on d-d > : > > With gnutls 3.3.* it seems to be impossible to trust server > certificate instead of the signing authority: > ametzler at argenau:~$ gnutls-cli --x509cafile=/tmp/GNUTLS/buildd.debian.org.pem buildd.debian.org > This used to work in 2.x. Is this an intentional change? This seems like it might be a slight shift in semantics of --x509cafile (and probably of gnutls_certificate_set_x509_trust_file() behind it). Old semantics: * If any cert in the peer's chain is found in x509cafile, the chain is valid New semantics: * If any CA cert in the peer's chain is found in the x509cafile, the chain is valid. Arguably, these are different goals, and you might want to separate out the "I think my peer has one of these keys" scenario from the "i think my peer's id is certified by one of these keys" scenario for better conceptual clarity. The --tofu and --strict-tofu option to gnutls-cli can be used to help answer "i think my peer has one of these keys". But if this is going to be a deliberate behavior shift, it probably needs explicit documentation. We might also want a runtime warning if any of the loaded certs had CA:False or were otherwise incapable of acting as a CA. But ultimately, i'm not sure that we should break the API semantics in this way even if the explicitly-split semantics would be cleaner; the non-split semantics are a fairly well-established use pattern. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From tim.ruehsen at gmx.de Thu Dec 4 14:49:41 2014 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Thu, 04 Dec 2014 14:49:41 +0100 Subject: [gnutls-devel] Failed to compile current git (3.4.0) Message-ID: <4300647.f8RFTdIlYn@blitz-lx> git clone git://gitorious.org/gnutls/gnutls.git cd gnutls make autoreconf unset CFLAGS ./configure make -j3 ... make[4]: Entering directory '/usr/oms/src/gnutls/guile/src' CC guile_gnutls_v_2_la-core.lo CC guile_gnutls_v_2_la-errors.lo CC guile_gnutls_v_2_la-utils.lo core.c: In function 'scm_gnutls_pkcs1_export_rsa_parameters': core.c:1441:36: error: 'gnutls_rsa_params_export_pkcs1' undeclared (first use in this function) gnutls_rsa_params_export_pkcs1, NEWS says that you removed this function... Maybe I miss something !? I am on Debian unstable amd64, gcc 4.9. configure: summary of build options: version: 3.4.0 shared 30:0:0 Host/Target system: x86_64-unknown-linux-gnu Build system: x86_64-unknown-linux-gnu Install prefix: /usr/local Compiler: gcc CFlags: -g -O2 Library types: Shared=yes, Static=no Local libopts: no Local libtasn1: no Use nettle-mini: no configure: External hardware support: /dev/crypto: no Hardware accel: x86-64 Padlock accel: yes getrandom variant: no PKCS#11 support: yes TPM support: no configure: Optional features: (note that included applications might not compile properly if features are disabled) DTLS-SRTP support: yes ALPN support: yes OCSP support: yes Ses. ticket support: yes OpenPGP support: yes SRP support: yes PSK support: yes DHE support: yes ECDHE support: yes Anon auth support: yes Heartbeat support: yes IDNA support: Unicode support: yes Self checks: no Non-SuiteB curves: yes FIPS140 mode: no configure: Optional applications: crywrap app: yes configure: Optional libraries: Guile wrappers: yes C++ library: yes DANE library: yes OpenSSL compat: no configure: System files: Trust store pkcs11: Trust store dir: Trust store file: /etc/ssl/certs/ca-certificates.crt Blacklist file: CRL file: Priority file: /etc/gnutls/default-priorities DNSSEC root key file: /etc/unbound/root.key configure: WARNING: *** *** The DNSSEC root key file in /etc/unbound/root.key was not found. *** This file is needed for the verification of DNSSEC responses. *** Use the command: unbound-anchor -a "/etc/unbound/root.key" *** to generate or update it. *** -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From nmav at gnutls.org Thu Dec 4 15:05:47 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 4 Dec 2014 15:05:47 +0100 Subject: [gnutls-devel] Failed to compile current git (3.4.0) In-Reply-To: <4300647.f8RFTdIlYn@blitz-lx> References: <4300647.f8RFTdIlYn@blitz-lx> Message-ID: Hello Tim, That functionality was dropped from the C library but not yet from the guile one. I'm CCing Ludo who is maintaining it. regards, Nikos On Thu, Dec 4, 2014 at 2:49 PM, Tim Ruehsen wrote: > git clone git://gitorious.org/gnutls/gnutls.git > cd gnutls > make autoreconf > unset CFLAGS > ./configure > make -j3 > > ... > make[4]: Entering directory '/usr/oms/src/gnutls/guile/src' > CC guile_gnutls_v_2_la-core.lo > CC guile_gnutls_v_2_la-errors.lo > CC guile_gnutls_v_2_la-utils.lo > core.c: In function 'scm_gnutls_pkcs1_export_rsa_parameters': > core.c:1441:36: error: 'gnutls_rsa_params_export_pkcs1' undeclared (first use > in this function) > gnutls_rsa_params_export_pkcs1, > > > NEWS says that you removed this function... > > Maybe I miss something !? > > I am on Debian unstable amd64, gcc 4.9. > > configure: summary of build options: > > version: 3.4.0 shared 30:0:0 > Host/Target system: x86_64-unknown-linux-gnu > Build system: x86_64-unknown-linux-gnu > Install prefix: /usr/local > Compiler: gcc > CFlags: -g -O2 > Library types: Shared=yes, Static=no > Local libopts: no > Local libtasn1: no > Use nettle-mini: no > > configure: External hardware support: > > /dev/crypto: no > Hardware accel: x86-64 > Padlock accel: yes > getrandom variant: no > PKCS#11 support: yes > TPM support: no > > configure: Optional features: > (note that included applications might not compile properly > if features are disabled) > > DTLS-SRTP support: yes > ALPN support: yes > OCSP support: yes > Ses. ticket support: yes > OpenPGP support: yes > SRP support: yes > PSK support: yes > DHE support: yes > ECDHE support: yes > Anon auth support: yes > Heartbeat support: yes > IDNA support: > Unicode support: yes > Self checks: no > Non-SuiteB curves: yes > FIPS140 mode: no > > configure: Optional applications: > > crywrap app: yes > > configure: Optional libraries: > > Guile wrappers: yes > C++ library: yes > DANE library: yes > OpenSSL compat: no > > configure: System files: > > Trust store pkcs11: > Trust store dir: > Trust store file: /etc/ssl/certs/ca-certificates.crt > Blacklist file: > CRL file: > Priority file: /etc/gnutls/default-priorities > DNSSEC root key file: /etc/unbound/root.key > > configure: WARNING: > *** > *** The DNSSEC root key file in /etc/unbound/root.key was not found. > *** This file is needed for the verification of DNSSEC responses. > *** Use the command: unbound-anchor -a "/etc/unbound/root.key" > *** to generate or update it. > *** > > _______________________________________________ > Gnutls-devel mailing list > Gnutls-devel at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-devel From nmav at gnutls.org Thu Dec 4 15:27:56 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 4 Dec 2014 15:27:56 +0100 Subject: [gnutls-devel] Unable to trust server certificate instead of issueing CA In-Reply-To: <20141203190125.GA2074@downhill.g.la> References: <20141203190125.GA2074@downhill.g.la> Message-ID: On Wed, Dec 3, 2014 at 8:01 PM, Andreas Metzler wrote: > Hello, > This came up on d-d > : > With gnutls 3.3.* it seems to be impossible to trust server > certificate instead of the signing authority: Thanks for bringing that up. Indeed, the use cases were separated because with the previous approach there was no way to restrict a server certificate to a particular server. You would have to trust that server to have the correct DNSnames, and the software adding them should check whether they are the intended. You could for example connect to www.example.com, but its certificate may in addition to www.example.com contain www.google.com as well (or even a wildcard). That seemed quite easy for an UI which saves them to get wrong, so support for mixing server with CA certificates was removed when trust lists were introduced. That functionality was replaced by gnutls_x509_trust_list_add_named_crt () and verify_named_crt(), and as Daniel mentioned also with trust on first use: http://www.gnutls.org/manual/gnutls.html#Verifying-a-certificate-using-trust-on-first-use-authentication . Please feel free to point out any locations in the documentation that could be improved. regards, Nikos From ludo at gnu.org Thu Dec 4 18:21:49 2014 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Thu, 04 Dec 2014 18:21:49 +0100 Subject: [gnutls-devel] Failed to compile current git (3.4.0) In-Reply-To: (Nikos Mavrogiannopoulos's message of "Thu, 4 Dec 2014 15:05:47 +0100") References: <4300647.f8RFTdIlYn@blitz-lx> Message-ID: <87zjb31gb6.fsf@gnu.org> Nikos Mavrogiannopoulos skribis: > That functionality was dropped from the C library but not yet from > the guile one. I'm CCing Ludo who is maintaining it. Right, I?m maintaining this part, but you?re maintaining the whole package. Nikos: could you make sure you compile the Guile bindings, so we address this sort of issues before users stumble upon them? > CC guile_gnutls_v_2_la-utils.lo > core.c: In function 'scm_gnutls_pkcs1_export_rsa_parameters': > core.c:1441:36: error: 'gnutls_rsa_params_export_pkcs1' undeclared (first use > in this function) At the Guile level, I would like to still export the Scheme procedure equivalent to ?gnutls_rsa_params_export_pkcs1?, marking it as deprecated. How would you recommend to do that? Thanks, Ludo?. From dkg at fifthhorseman.net Thu Dec 4 18:40:49 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 04 Dec 2014 12:40:49 -0500 Subject: [gnutls-devel] Unable to trust server certificate instead of issueing CA In-Reply-To: References: <20141203190125.GA2074@downhill.g.la> Message-ID: <54809CA1.1080305@fifthhorseman.net> On 12/04/2014 09:27 AM, Nikos Mavrogiannopoulos wrote: > . Please feel free to point out any locations in the documentation > that could be improved. What do you think about propagating a warning out to the calling app if any of the certs loaded by gnutls_certificate_set_x509_trust_file() has CA:false ? (i'm not suggesting this is the only documentation change needed, i'm just thinking through how to communicate this subtle semantic API shift to users and downstream developers) Do you think there's any additional interface that needs to be added to gnutls-cli to load (,) bindings, or should we expect people to use --tofu for this purpose? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Thu Dec 4 20:19:20 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 04 Dec 2014 20:19:20 +0100 Subject: [gnutls-devel] Failed to compile current git (3.4.0) In-Reply-To: <87zjb31gb6.fsf@gnu.org> References: <4300647.f8RFTdIlYn@blitz-lx> <87zjb31gb6.fsf@gnu.org> Message-ID: <1417720760.3242.1.camel@gnutls.org> On Thu, 2014-12-04 at 18:21 +0100, Ludovic Court?s wrote: > Nikos Mavrogiannopoulos skribis: > > > That functionality was dropped from the C library but not yet from > > the guile one. I'm CCing Ludo who is maintaining it. > > Right, I?m maintaining this part, but you?re maintaining the whole > package. Hi, I don't know scheme and I have no plans or resources to maintain the guile code. I can simply ping you if there is an issue. > Nikos: could you make sure you compile the Guile bindings, so > we address this sort of issues before users stumble upon them? > At the Guile level, I would like to still export the Scheme procedure > equivalent to ?gnutls_rsa_params_export_pkcs1?, marking it as > deprecated. > How would you recommend to do that? These functions have been deprecated since very long time and they are now useless as gnutls since 3.2.0 doesn't support RSA-EXPORT at all. My suggestion would be to keep the functions if you want to keep some ABI compatibility and simply return an error or so. regards, Nikos From ludo at gnu.org Thu Dec 4 22:20:52 2014 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Thu, 04 Dec 2014 22:20:52 +0100 Subject: [gnutls-devel] Failed to compile current git (3.4.0) In-Reply-To: <1417720760.3242.1.camel@gnutls.org> (Nikos Mavrogiannopoulos's message of "Thu, 04 Dec 2014 20:19:20 +0100") References: <4300647.f8RFTdIlYn@blitz-lx> <87zjb31gb6.fsf@gnu.org> <1417720760.3242.1.camel@gnutls.org> Message-ID: <87zjb3ru17.fsf@gnu.org> Nikos Mavrogiannopoulos skribis: > I don't know scheme and I have no plans or resources to maintain the > guile code. I can simply ping you if there is an issue. I?m only suggesting that you *build* the code, so we know about these issues before it ships. I?ve just pushed these 3 commits to ?master?: 2134c8a * guile: Build with warnings. 916b3cc * guile: Remove the deprecated priority API. 0b88d76 * guile: Remove RSA parameters and related procedures. Could you backport them as a appropriate? Thanks in advance, Ludo?. From nmav at gnutls.org Fri Dec 5 10:03:27 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 5 Dec 2014 10:03:27 +0100 Subject: [gnutls-devel] Unable to trust server certificate instead of issueing CA In-Reply-To: <54809CA1.1080305@fifthhorseman.net> References: <20141203190125.GA2074@downhill.g.la> <54809CA1.1080305@fifthhorseman.net> Message-ID: On Thu, Dec 4, 2014 at 6:40 PM, Daniel Kahn Gillmor wrote: > On 12/04/2014 09:27 AM, Nikos Mavrogiannopoulos wrote: >> . Please feel free to point out any locations in the documentation >> that could be improved. > What do you think about propagating a warning out to the calling app if > any of the certs loaded by gnutls_certificate_set_x509_trust_file() has > CA:false ? The trusted certificate loading functions never returned error codes, they returned the number of CAs that were loaded. Changing them to return error codes could break some code. What could be done is using the gnutls_audit_log() to print a warning. > Do you think there's any additional interface that needs to be added to > gnutls-cli to load (,) bindings, or should we expect > people to use --tofu for this purpose? I find tofu simpler. Giving too many options may complicate things and I don't think that this would enable an unhandled use-case. regards, Nikos From eliz at gnu.org Tue Dec 9 18:31:42 2014 From: eliz at gnu.org (Eli Zaretskii) Date: Tue, 09 Dec 2014 19:31:42 +0200 Subject: [gnutls-devel] Guile bindings for GnuTLS don't build as shared library on MinGW Message-ID: <83fvcowwzl.fsf@gnu.org> I've built GnuTLS 3.3.10 on MinGW, and noticed that the guile-gnutls-v-2 library is built only as a static library, even when --disable-static is given at configure time (and the rest of GnuTLS libraries do build as DLLs). The "librarynames" field in guile-gnutls-v-2.la is empty. I couldn't understand why that happens, the only clue is that the libtool command uses the -module option, with which I'm not familiar (why is it needed here?). Also, there's this cryptic message from libtool: make[4]: Entering directory `/d/usr/eli/utils/gnutls-3.3.10.with-guile/guile/src' CC guile_gnutls_v_2_la-core.lo CC guile_gnutls_v_2_la-errors.lo CC guile_gnutls_v_2_la-utils.lo CCLD guile-gnutls-v-2.la libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ make[4]: Leaving directory `/d/usr/eli/utils/gnutls-3.3.10.with-guile/guile/src' But I think this message is harmless, and is related to the -undefined option to libtool, or some such. Any ideas where to look for the culprit? TIA From ludo at gnu.org Tue Dec 9 21:20:44 2014 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Tue, 09 Dec 2014 21:20:44 +0100 Subject: [gnutls-devel] Guile bindings for GnuTLS don't build as shared library on MinGW In-Reply-To: <83fvcowwzl.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 09 Dec 2014 19:31:42 +0200") References: <83fvcowwzl.fsf@gnu.org> Message-ID: <871to8shgj.fsf@gnu.org> Hi Eli, Could you post config.log, to check what Libtool thinks of shared library support? Also, could you post the build log of the Guile bindings when passing V=1 as a makefile variable (or --disable-silent-rules)? The ?-module? option is used to create ?a library that can be dlopened? (info "(libtool) Link mode"), and is a prerequisite when leaving out the ?lib? prefix. Thanks, Ludo?. From ludo at gnu.org Wed Dec 10 18:45:39 2014 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Wed, 10 Dec 2014 18:45:39 +0100 Subject: [gnutls-devel] Guile bindings for GnuTLS don't build as shared library on MinGW In-Reply-To: <838uifv35b.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 10 Dec 2014 19:13:52 +0200") References: <83fvcowwzl.fsf@gnu.org> <871to8shgj.fsf@gnu.org> <838uifv35b.fsf@gnu.org> Message-ID: <87ppbrjt4s.fsf@gnu.org> Eli Zaretskii skribis: >> From: ludo at gnu.org (Ludovic Court?s) >> Cc: gnutls-devel at lists.gnutls.org >> Date: Tue, 09 Dec 2014 21:20:44 +0100 >> >> Could you post config.log, to check what Libtool thinks of shared >> library support? > > Attached below. Excerpts which looked relevant to me: OK, everything seems normal here. > $ cd guile/ > $ make -W ../config.h V=1 > Making all in modules > make[1]: Entering directory `/d/usr/eli/utils/gnutls-3.3.10.with-guile/guile/modules' > make[1]: Nothing to be done for `all'. > make[1]: Leaving directory `/d/usr/eli/utils/gnutls-3.3.10.with-guile/guile/modules' > Making all in src > make[1]: Entering directory `/d/usr/eli/utils/gnutls-3.3.10.with-guile/guile/src' > make all-am > make[2]: Entering directory `/d/usr/eli/utils/gnutls-3.3.10.with-guile/guile/src' > /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../lib/includes -I../../lib/includes -I../../extra/includes -I../.. -I. -Id:/usr/include -Wno-strict-prototypes -I../../gl -I../../gl -Id:/usr/include/guile/2.0 -Id:/usr/include -O2 -g3 -MT guile_gnutls_v_2_la-utils.lo -MD -MP -MF .deps/guile_gnutls_v_2_la-utils.Tpo -c -o guile_gnutls_v_2_la-utils.lo `test -f 'utils.c' || echo './'`utils.c > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../lib/includes -I../../lib/includes -I../../extra/includes -I../.. -I. -Id:/usr/include -Wno-strict-prototypes -I../../gl -I../../gl -Id:/usr/include/guile/2.0 -Id:/usr/include -O2 -g3 -MT guile_gnutls_v_2_la-utils.lo -MD -MP -MF .deps/guile_gnutls_v_2_la-utils.Tpo -c utils.c -DDLL_EXPORT -DPIC -o .libs/guile_gnutls_v_2_la-utils.o So it builds both the static and the PIC version. > mv -f .deps/guile_gnutls_v_2_la-utils.Tpo .deps/guile_gnutls_v_2_la-utils.Plo > /bin/sh ../../libtool --tag=CC --mode=link gcc -Wno-strict-prototypes -I../../gl -I../../gl -Id:/usr/include/guile/2.0 -Id:/usr/include -O2 -g3 -module -g3 -o guile-gnutls-v-2.la -rpath d:/usr/lib/guile/2.0 guile_gnutls_v_2_la-core.lo guile_gnutls_v_2_la-errors.lo guile_gnutls_v_2_la-utils.lo ../../lib/libgnutls.la ../../gl/libgnu.la -Ld:/usr/lib -lguile-2.0 -lgc -lintl -lregex > libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries > libtool: link: rm -fr .libs/guile-gnutls-v-2.a .libs/guile-gnutls-v-2.la .libs/guile-gnutls-v-2.lai Here it chooses to build the static library. The command line lacks -no-undefined compared to the other one you posted, which may be the explanation. Could you try: make clean -C guile make -C guile LDFLAGS=-no-undefined ? >> The ?-module? option is used to create ?a library that can be dlopened? >> (info "(libtool) Link mode"), and is a prerequisite when leaving out the >> ?lib? prefix. > > How is this ?library that can be dlopened? different from a "normal" > shared library? I think some OSes view shared libraries as something different from dlopenable modules (early OS X had .dylib for the former and .so for the latter, IIRC.) There?s also the ?dlpreopening? concept for OSes lacking dlopen?which may be irrelevant nowadays (info "(libtool) Dlpreopening"). Thanks, Ludo?. From eliz at gnu.org Wed Dec 10 18:13:52 2014 From: eliz at gnu.org (Eli Zaretskii) Date: Wed, 10 Dec 2014 19:13:52 +0200 Subject: [gnutls-devel] Guile bindings for GnuTLS don't build as shared library on MinGW In-Reply-To: <871to8shgj.fsf@gnu.org> References: <83fvcowwzl.fsf@gnu.org> <871to8shgj.fsf@gnu.org> Message-ID: <838uifv35b.fsf@gnu.org> > From: ludo at gnu.org (Ludovic Court?s) > Cc: gnutls-devel at lists.gnutls.org > Date: Tue, 09 Dec 2014 21:20:44 +0100 > > Could you post config.log, to check what Libtool thinks of shared > library support? Attached below. Excerpts which looked relevant to me: config.log:2483:configure:10311: checking for shared library run path origin config.log-2484-configure:10324: result: done -- config.log:56715:configure:40384: checking whether the gcc linker (/d/usr/bin/ld) supports shared libraries config.log-56716-configure:41541: result: yes -- config.log:56729:configure:43227: checking if libtool supports shared libraries config.log-56730-configure:43229: result: yes config.log:56731:configure:43232: checking whether to build shared libraries config.log-56732-configure:43253: result: yes -- config.log:57485:configure:43696: checking whether the g++ linker (/d/usr/bin/ld) supports shared libraries config.log-57486-configure:44698: result: yes -- config.log:57503:configure:45499: checking whether the g++ linker (/d/usr/bin/ld) supports shared libraries config.log-57504-configure:45538: result: yes -- configure:53733: summary of build options: version: 3.3.10 shared 69:2:41 Host/Target system: i686-pc-mingw32 Build system: i686-pc-mingw32 Install prefix: d:/usr Compiler: gcc CFlags: -O2 -g3 Library types: Shared=yes, Static=no Local libopts: yes Local libtasn1: no Use nettle-mini: no configure:53755: External hardware support: /dev/crypto: no Hardware accel: x86 Padlock accel: yes PKCS#11 support: yes TPM support: no configure:53785: Optional features: (note that included applications might not compile properly if features are disabled) DTLS-SRTP support: yes ALPN support: yes OCSP support: yes Ses. ticket support: yes OpenPGP support: yes SRP support: yes PSK support: yes DHE support: yes ECDHE support: yes RSA-EXPORT support: yes Anon auth support: yes Heartbeat support: yes Unicode support: yes Self checks: no Non-SuiteB curves: yes FIPS140 mode: no configure:53811: Optional applications: crywrap app: configure:53823: Optional libraries: Guile wrappers: yes C++ library: yes DANE library: no OpenSSL compat: yes configure:53841: System files: Trust store pkcs11: Trust store dir: Trust store file: Blacklist file: CRL file: Priority file: d:/usr/etc/gnutls/default-priorities DNSSEC root key file: C:\Program Files\Unbound\root.key > Also, could you post the build log of the Guile bindings when passing > V=1 as a makefile variable (or --disable-silent-rules)? $ cd guile/ $ make -W ../config.h V=1 Making all in modules make[1]: Entering directory `/d/usr/eli/utils/gnutls-3.3.10.with-guile/guile/modules' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/d/usr/eli/utils/gnutls-3.3.10.with-guile/guile/modules' Making all in src make[1]: Entering directory `/d/usr/eli/utils/gnutls-3.3.10.with-guile/guile/src' make all-am make[2]: Entering directory `/d/usr/eli/utils/gnutls-3.3.10.with-guile/guile/src' /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../lib/includes -I../../lib/includes -I../../extra/includes -I../.. -I. -Id:/usr/include -Wno-strict-prototypes -I../../gl -I../../gl -Id:/usr/include/guile/2.0 -Id:/usr/include -O2 -g3 -MT guile_gnutls_v_2_la-utils.lo -MD -MP -MF .deps/guile_gnutls_v_2_la-utils.Tpo -c -o guile_gnutls_v_2_la-utils.lo `test -f 'utils.c' || echo './'`utils.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../lib/includes -I../../lib/includes -I../../extra/includes -I../.. -I. -Id:/usr/include -Wno-strict-prototypes -I../../gl -I../../gl -Id:/usr/include/guile/2.0 -Id:/usr/include -O2 -g3 -MT guile_gnutls_v_2_la-utils.lo -MD -MP -MF .deps/guile_gnutls_v_2_la-utils.Tpo -c utils.c -DDLL_EXPORT -DPIC -o .libs/guile_gnutls_v_2_la-utils.o mv -f .deps/guile_gnutls_v_2_la-utils.Tpo .deps/guile_gnutls_v_2_la-utils.Plo /bin/sh ../../libtool --tag=CC --mode=link gcc -Wno-strict-prototypes -I../../gl -I../../gl -Id:/usr/include/guile/2.0 -Id:/usr/include -O2 -g3 -module -g3 -o guile-gnutls-v-2.la -rpath d:/usr/lib/guile/2.0 guile_gnutls_v_2_la-core.lo guile_gnutls_v_2_la-errors.lo guile_gnutls_v_2_la-utils.lo ../../lib/libgnutls.la ../../gl/libgnu.la -Ld:/usr/lib -lguile-2.0 -lgc -lintl -lregex libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries libtool: link: rm -fr .libs/guile-gnutls-v-2.a .libs/guile-gnutls-v-2.la .libs/guile-gnutls-v-2.lai libtool: link: (cd .libs/guile-gnutls-v-2.lax/libgnu.a && ar x "/d/usr/eli/utils/gnutls-3.3.10.with-guile/guile/src/../../gl/.libs/libgnu.a") libtool: link: ar cru .libs/guile-gnutls-v-2.a .libs/guile_gnutls_v_2_la-core.o .libs/guile_gnutls_v_2_la-errors.o .libs/guile_gnutls_v_2_la-utils.o .libs/guile-gnutls-v-2.lax/libgnu.a/asnprintf.o .libs/guile-gnutls-v-2.lax/libgnu.a/asprintf.o .libs/guile-gnutls-v-2.lax/libgnu.a/base64.o .libs/guile-gnutls-v-2.lax/libgnu.a/c-ctype.o .libs/guile-gnutls-v-2.lax/libgnu.a/fstat.o .libs/guile-gnutls-v-2.lax/libgnu.a/ftell.o .libs/guile-gnutls-v-2.lax/libgnu.a/ftello.o .libs/guile-gnutls-v-2.lax/libgnu.a/getdelim.o .libs/guile-gnutls-v-2.lax/libgnu.a/getline.o .libs/guile-gnutls-v-2.lax/libgnu.a/hash-pjw-bare.o .libs/guile-gnutls-v-2.lax/libgnu.a/lseek.o .libs/guile-gnutls-v-2.lax/libgnu.a/malloc.o .libs/guile-gnutls-v-2.lax/libgnu.a/memmem.o .libs/guile-gnutls-v-2.lax/libgnu.a/printf-args.o .libs/guile-gnutls-v-2.lax/libgnu.a/printf-parse.o .libs/guile-gnutls-v-2.lax/libgnu.a/read-file.o .libs/guile-gnutls-v-2.lax/libgnu.a/realloc.o .libs/guile-gnutls-v-2.lax/libgnu.a/snprintf.o .libs/guile-gnutls-v-2.lax/libgnu.a/strndup.o .libs/guile-gnutls-v-2.lax/libgnu.a/strnlen.o .libs/guile-gnutls-v-2.lax/libgnu.a/strtok_r.o .libs/guile-gnutls-v-2.lax/libgnu.a/strverscmp.o .libs/guile-gnutls-v-2.lax/libgnu.a/sys_socket.o .libs/guile-gnutls-v-2.lax/libgnu.a/time_r.o .libs/guile-gnutls-v-2.lax/libgnu.a/u64.o .libs/guile-gnutls-v-2.lax/libgnu.a/unistd.o .libs/guile-gnutls-v-2.lax/libgnu.a/vasnprintf.o .libs/guile-gnutls-v-2.lax/libgnu.a/vasprintf.o .libs/guile-gnutls-v-2.lax/libgnu.a/vsnprintf.o .libs/guile-gnutls-v-2.lax/libgnu.a/xsize.o libtool: link: ranlib .libs/guile-gnutls-v-2.a libtool: link: rm -fr .libs/guile-gnutls-v-2.lax libtool: link: ( cd ".libs" && rm -f "guile-gnutls-v-2.la" && cp -pR "../guile-gnutls-v-2.la" "guile-gnutls-v-2.la" ) make[2]: Leaving directory `/d/usr/eli/utils/gnutls-3.3.10.with-guile/guile/src' make[1]: Leaving directory `/d/usr/eli/utils/gnutls-3.3.10.with-guile/guile/src' Making all in tests make[1]: Entering directory `/d/usr/eli/utils/gnutls-3.3.10.with-guile/guile/tests' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/d/usr/eli/utils/gnutls-3.3.10.with-guile/guile/tests' make[1]: Entering directory `/d/usr/eli/utils/gnutls-3.3.10.with-guile/guile' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/d/usr/eli/utils/gnutls-3.3.10.with-guile/guile' For comparison, here's how this looks with another library built by "make V=1": make[4]: Entering directory `/d/usr/eli/utils/gnutls-3.3.10.with-guile/lib' /bin/sh ../libtool --tag=CXX --mode=link g++ -I./includes -I./includes -O2 -g3 -no-undefined -version-info 29:0:1 -g3 -o libgnutlsxx.la -rpath d:/usr/lib libgnutlsxx_la-gnutlsxx.lo libgnutls.la -lintl -lregex libtool: link: rm -fr .libs/libgnutlsxx.dll.a .libs/libgnutlsxx.la .libs/libgnutlsxx.lai libtool: link: g++ -shared -nostdlib d:/usr/bin/../lib/gcc/mingw32/4.7.2/../../../dllcrt2.o d:/usr/bin/../lib/gcc/mingw32/4.7.2/crtbegin.o .libs/libgnutlsxx_la-gnutlsxx.o ./.libs/libgnutls.dll.a -Ld:/usr/lib -Ld:/usr/lib/.libs d:/usr/bin/../lib/gcc/mingw32/4.7.2/../../../libintl.dll.a d:/usr/bin/../lib/gcc/mingw32/4.7.2/../../../libregex.dll.a -Ld:/usr/bin/../lib/gcc/mingw32/4.7.2 -Ld:/usr/bin/../lib/gcc -Ld:/usr/bin/../lib/gcc/mingw32/4.7.2/../../.. -lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt d:/usr/bin/../lib/gcc/mingw32/4.7.2/crtend.o -O2 -o .libs/libgnutlsxx-28.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libgnutlsxx.dll.a libtool: link: ( cd ".libs" && rm -f "libgnutlsxx.la" && cp -pR "../libgnutlsxx.la" "libgnutlsxx.la" ) make[4]: Leaving directory `/d/usr/eli/utils/gnutls-3.3.10.with-guile/lib' > The ?-module? option is used to create ?a library that can be dlopened? > (info "(libtool) Link mode"), and is a prerequisite when leaving out the > ?lib? prefix. How is this ?library that can be dlopened? different from a "normal" shared library? -------------- next part -------------- A non-text attachment was scrubbed... Name: config.log.gz Type: application/octet-stream Size: 80050 bytes Desc: not available URL: From nmav at gnutls.org Wed Dec 10 19:29:50 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 10 Dec 2014 19:29:50 +0100 Subject: [gnutls-devel] Guile bindings for GnuTLS don't build as shared library on MinGW In-Reply-To: <87ppbrjt4s.fsf@gnu.org> References: <83fvcowwzl.fsf@gnu.org> <871to8shgj.fsf@gnu.org> <838uifv35b.fsf@gnu.org> <87ppbrjt4s.fsf@gnu.org> Message-ID: <1418236190.2030.0.camel@gnutls.org> On Wed, 2014-12-10 at 18:45 +0100, Ludovic Court?s wrote: > > mv -f .deps/guile_gnutls_v_2_la-utils.Tpo .deps/guile_gnutls_v_2_la-utils.Plo > > /bin/sh ../../libtool --tag=CC --mode=link gcc -Wno-strict-prototypes -I../../gl -I../../gl -Id:/usr/include/guile/2.0 -Id:/usr/include -O2 -g3 -module -g3 -o guile-gnutls-v-2.la -rpath d:/usr/lib/guile/2.0 guile_gnutls_v_2_la-core.lo guile_gnutls_v_2_la-errors.lo guile_gnutls_v_2_la-utils.lo ../../lib/libgnutls.la ../../gl/libgnu.la -Ld:/usr/lib -lguile-2.0 -lgc -lintl -lregex > > libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32 shared libraries > > libtool: link: rm -fr .libs/guile-gnutls-v-2.a .libs/guile-gnutls-v-2.la .libs/guile-gnutls-v-2.lai > Here it chooses to build the static library. > The command line lacks -no-undefined compared to the other one you > posted, which may be the explanation. Could you try: > make clean -C guile > make -C guile LDFLAGS=-no-undefined > >> The ?-module? option is used to create ?a library that can be dlopened? > >> (info "(libtool) Link mode"), and is a prerequisite when leaving out the > >> ?lib? prefix. > > How is this ?library that can be dlopened? different from a "normal" > > shared library? > I think some OSes view shared libraries as something different from > dlopenable modules (early OS X had .dylib for the former and .so for the > latter, IIRC.) There?s also the ?dlpreopening? concept for OSes lacking > dlopen?which may be irrelevant nowadays (info "(libtool) Dlpreopening"). In the main library we use -no-undefined in the link flags by default. That allows to make a shared library in windows. regards, Nikos From nmav at gnutls.org Thu Dec 11 09:10:23 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 11 Dec 2014 09:10:23 +0100 Subject: [gnutls-devel] gnutls 3.2.21 Message-ID: <1418285423.2059.1.camel@gnutls.org> Hello, I've just released gnutls 3.2.21. This is a bugfix release on the previous stable branch. * Version 3.2.21 (released 2014-12-11) ** libgnutls: Corrected regression introduced in 3.2.19 related to session renegotiation. Reported by Dan Winship. ** libgnutls: Corrected parsing issue with OCSP responses. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.21.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.21.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.21.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.21.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Thu Dec 11 09:11:18 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 11 Dec 2014 09:11:18 +0100 Subject: [gnutls-devel] gnutls 3.3.11 Message-ID: <1418285478.2059.2.camel@gnutls.org> Hello, I've just released gnutls 3.3.11. This is a bug-fix release on the current stable branch. * Version 3.3.11 (released 2014-12-11) ** libgnutls: Corrected regression introduced in 3.3.9 related to session renegotiation. Reported by Dan Winship. ** libgnutls: Corrected parsing issue with OCSP responses. ** 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.3/gnutls-3.3.11.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.11.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.11.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.11.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From INVALID.NOREPLY at gnu.org Thu Dec 11 09:30:58 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Thu, 11 Dec 2014 08:30:58 +0000 Subject: [gnutls-devel] [sr #108690] gnutls 3.1.27 breaks use of GNUTLS_E_GOT_APPLICATION_DATA In-Reply-To: <20141121-214523.sv707.93297@savannah.gnu.org> References: <20141121-154832.sv0.32001@savannah.gnu.org> <20141121-214523.sv707.93297@savannah.gnu.org> Message-ID: <20141211-103058.sv707.67883@savannah.gnu.org> Update of sr #108690 (project gnutls): Status: None => Done Open/Closed: Open => Closed _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Dec 11 09:31:11 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Thu, 11 Dec 2014 08:31:11 +0000 Subject: [gnutls-devel] [sr #108679] Updated Documentation In-Reply-To: <20141104-225554.sv707.15671@savannah.gnu.org> References: <20141102-200231.sv97267.13663@savannah.gnu.org> <20141103-193528.sv707.25743@savannah.gnu.org> <20141103-215450.sv97267.23785@savannah.gnu.org> <20141104-194124.sv97267.94194@savannah.gnu.org> <20141104-225554.sv707.15671@savannah.gnu.org> Message-ID: <20141211-103111.sv707.68777@savannah.gnu.org> Update of sr #108679 (project gnutls): Status: None => Done Open/Closed: Open => Closed _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Dec 11 09:31:42 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Thu, 11 Dec 2014 08:31:42 +0000 Subject: [gnutls-devel] [sr #108552] gnutls-dane: verify_ca() function assumes that there are only two certificates In-Reply-To: <20140510-115223.sv707.97938@savannah.gnu.org> References: <20140419-184950.sv0.49671@savannah.gnu.org> <20140420-203328.sv0.15203@savannah.gnu.org> <20140428-123615.sv707.51179@savannah.gnu.org> <20140428-113842.sv0.59130@savannah.gnu.org> <20140428-151142.sv707.38931@savannah.gnu.org> <20140428-190702.sv0.44570@savannah.gnu.org> <20140510-115223.sv707.97938@savannah.gnu.org> Message-ID: <20141211-103141.sv707.62377@savannah.gnu.org> Update of sr #108552 (project gnutls): Status: Confirmed => Done Open/Closed: Open => Closed _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Dec 11 09:31:58 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Thu, 11 Dec 2014 08:31:58 +0000 Subject: [gnutls-devel] [sr #108550] It is impractical to call dane_verify_session_crt() from the gnutls_certificate_set_verify_function() In-Reply-To: <20140711-184909.sv707.92524@savannah.gnu.org> References: <20140419-152442.sv0.8040@savannah.gnu.org> <20140419-161906.sv0.73978@savannah.gnu.org> <20140428-123927.sv707.14646@savannah.gnu.org> <20140629-191005.sv0.52744@savannah.gnu.org> <20140702-145158.sv707.53124@savannah.gnu.org> <20140705-210755.sv0.73310@savannah.gnu.org> <20140706-151703.sv707.17886@savannah.gnu.org> <20140706-211145.sv95894.82631@savannah.gnu.org> <20140709-212217.sv95894.16457@savannah.gnu.org> <20140710-133501.sv707.80685@savannah.gnu.org> <20140710-211435.sv95894.25261@savannah.gnu.org> <20140711-184909.sv707.92524@savannah.gnu.org> Message-ID: <20141211-103158.sv707.73416@savannah.gnu.org> Update of sr #108550 (project gnutls): Status: None => Done Open/Closed: Open => Closed _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From n.mavrogiannopoulos at gmail.com Thu Dec 11 13:26:26 2014 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Thu, 11 Dec 2014 13:26:26 +0100 Subject: [gnutls-devel] time_t in 32-bit systems Message-ID: I recently broke binary compatibility of gnutls 3.4.0 in master, and I was wondering whether there is something we can do to allow 32-bit systems to create certificates past 2038. The issue as I understand is twofold. As glibc on these systems offers a 32-bit time_t is prevents: 1. Using these systems after 2038 2. Using dates on these systems which refer to 2038 or later The former cannot really be solved by gnutls, as it requires a co-ordination between kernel and glibc, but the latter could be worked around. We could offer a 64-bit gnutls_time_t, and then with some reimplementation of gmtime() we could allow the generation and usage of certificates which have expiration past-2038. The question is, does it worth the time and the introduction and maintainance of a special gnutls_time_t? Would it make better sense to simply wait for glibc or any other libc people to fix that issue? regards, Nikos From INVALID.NOREPLY at gnu.org Thu Dec 11 14:49:35 2014 From: INVALID.NOREPLY at gnu.org (Pierre Ossman) Date: Thu, 11 Dec 2014 13:49:35 +0000 Subject: [gnutls-devel] [sr #108703] Windows build issues Message-ID: <20141211-134934.sv97769.3976@savannah.gnu.org> URL: Summary: Windows build issues Project: GnuTLS Submitted by: cendossm Submitted on: Thu 11 Dec 2014 13:49:34 GMT Category: Core library Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: Microsoft Windows _______________________________________________________ Details: Two issues: a) On at least Win64 we trigger the check for fseek/fseeko in gnulib. But fseek.c and fseeko.c aren't included so we get missing symbols at link time. b) src/socket.c uses alarm(), which doesn't exist on Windows. Some versions of mingw/mingw64 has it, but not all. Tested with GnuTLS 3.3.11. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Thu Dec 11 18:12:46 2014 From: INVALID.NOREPLY at gnu.org (Eli Zaretskii) Date: Thu, 11 Dec 2014 17:12:46 +0000 Subject: [gnutls-devel] [sr #108703] Windows build issues In-Reply-To: <20141211-134934.sv97769.3976@savannah.gnu.org> References: <20141211-134934.sv97769.3976@savannah.gnu.org> Message-ID: <20141211-191246.sv220.76214@savannah.gnu.org> Follow-up Comment #1, sr #108703 (project gnutls): Indeed, I saw this as well (with MinGW32 and GnuTLS 3.3.10), and was about to report that. Regarding fseek, I guess this is a license-related issue, in which case I think the easiest solution would be to not try to replace the Windows function (the issue which gnulib tries to solve is AFAIK not relevant to Windows). For src/socket.c, I solved that with the patch in the attached; perhaps all other platforms could use that, in which case the cpp conditionals are not needed. Other issues I've seen: . src/certtool-cfg.c triggers a compiler warning because of the 32-bit right shift of a 'long' variable . src/pkcs11.c calls 'sleep', which MinGW doesn't have . the gnulib tests in lib/gl fail because rpl_close is not available (similar to the fseek issue) (file #32650) _______________________________________________________ Additional Item Attachment: File name: alarm.patch Size:0 KB _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From eliz at gnu.org Thu Dec 11 18:19:52 2014 From: eliz at gnu.org (Eli Zaretskii) Date: Thu, 11 Dec 2014 19:19:52 +0200 Subject: [gnutls-devel] Guile bindings for GnuTLS don't build as shared library on MinGW In-Reply-To: <87ppbrjt4s.fsf@gnu.org> References: <83fvcowwzl.fsf@gnu.org> <871to8shgj.fsf@gnu.org> <838uifv35b.fsf@gnu.org> <87ppbrjt4s.fsf@gnu.org> Message-ID: <83a92ut87b.fsf@gnu.org> > From: ludo at gnu.org (Ludovic Court?s) > Cc: gnutls-devel at lists.gnutls.org > Date: Wed, 10 Dec 2014 18:45:39 +0100 > > > /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../lib/includes -I../../lib/includes -I../../extra/includes -I../.. -I. -Id:/usr/include -Wno-strict-prototypes -I../../gl -I../../gl -Id:/usr/include/guile/2.0 -Id:/usr/include -O2 -g3 -MT guile_gnutls_v_2_la-utils.lo -MD -MP -MF .deps/guile_gnutls_v_2_la-utils.Tpo -c -o guile_gnutls_v_2_la-utils.lo `test -f 'utils.c' || echo './'`utils.c > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../lib/includes -I../../lib/includes -I../../extra/includes -I../.. -I. -Id:/usr/include -Wno-strict-prototypes -I../../gl -I../../gl -Id:/usr/include/guile/2.0 -Id:/usr/include -O2 -g3 -MT guile_gnutls_v_2_la-utils.lo -MD -MP -MF .deps/guile_gnutls_v_2_la-utils.Tpo -c utils.c -DDLL_EXPORT -DPIC -o .libs/guile_gnutls_v_2_la-utils.o > > So it builds both the static and the PIC version. Not sure I follow you here. The above is just one command, and it builds only the static version. The -DPIC is ignored on Windows, right? > The command line lacks -no-undefined compared to the other one you > posted, which may be the explanation. Could you try: > > make clean -C guile > make -C guile LDFLAGS=-no-undefined > > ? Yes, it solves the problem, thanks. Now, as long as I have your attention: having succeeded in building the Guile extensions, I've run the related tests, and saw these two problems: . anonymous-auth.scm, session-record-port.scm, x509-auth.scm, and openpgp-auth.scm tests all fail because they use primitive-fork, which isn't supported on Windows. Is there any chance these tests could be rewritten to not use that API? . openpgp-keyring.scm fails because it doesn't open openpgp-keyring.gpg, a binary file, in binary mode. Here's the patch to fix that: --- guile/tests/openpgp-keyring.scm~0 2014-07-29 22:22:47 +0300 +++ guile/tests/openpgp-keyring.scm 2014-12-11 08:16:15 +0200 @@ -49,7 +49,7 @@ ;; Return true if FILE contains a valid keyring encoded in FORMAT. (let ((raw-keyring (make-u8vector (file-size file)))) - (uniform-vector-read! raw-keyring (open-input-file file)) + (uniform-vector-read! raw-keyring (open-input-file file #:binary #t)) (let ((keyring (import-openpgp-keyring raw-keyring format)) (null-id (make-u8vector 8 0))) From INVALID.NOREPLY at gnu.org Thu Dec 11 19:06:07 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Thu, 11 Dec 2014 18:06:07 +0000 Subject: [gnutls-devel] [sr #108703] Windows build issues In-Reply-To: <20141211-191246.sv220.76214@savannah.gnu.org> References: <20141211-134934.sv97769.3976@savannah.gnu.org> <20141211-191246.sv220.76214@savannah.gnu.org> Message-ID: <20141211-200607.sv707.33956@savannah.gnu.org> Follow-up Comment #2, sr #108703 (project gnutls): I've applied Eli's patch unconditionally, select() seems to be available everywhere, as well as fixed for sleep() and certtool-cfg. For gnulib issues, I don't think I'd spend much time on it; if there are patches I'll apply them, otherwise I'd just skip them. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From ludo at gnu.org Thu Dec 11 19:12:21 2014 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Thu, 11 Dec 2014 19:12:21 +0100 Subject: [gnutls-devel] Guile bindings for GnuTLS don't build as shared library on MinGW In-Reply-To: <83a92ut87b.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 11 Dec 2014 19:19:52 +0200") References: <83fvcowwzl.fsf@gnu.org> <871to8shgj.fsf@gnu.org> <838uifv35b.fsf@gnu.org> <87ppbrjt4s.fsf@gnu.org> <83a92ut87b.fsf@gnu.org> Message-ID: <87mw6u5a4a.fsf@gnu.org> Eli Zaretskii skribis: >> From: ludo at gnu.org (Ludovic Court?s) >> Cc: gnutls-devel at lists.gnutls.org >> Date: Wed, 10 Dec 2014 18:45:39 +0100 >> >> > /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../lib/includes -I../../lib/includes -I../../extra/includes -I../.. -I. -Id:/usr/include -Wno-strict-prototypes -I../../gl -I../../gl -Id:/usr/include/guile/2.0 -Id:/usr/include -O2 -g3 -MT guile_gnutls_v_2_la-utils.lo -MD -MP -MF .deps/guile_gnutls_v_2_la-utils.Tpo -c -o guile_gnutls_v_2_la-utils.lo `test -f 'utils.c' || echo './'`utils.c >> > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../lib/includes -I../../lib/includes -I../../extra/includes -I../.. -I. -Id:/usr/include -Wno-strict-prototypes -I../../gl -I../../gl -Id:/usr/include/guile/2.0 -Id:/usr/include -O2 -g3 -MT guile_gnutls_v_2_la-utils.lo -MD -MP -MF .deps/guile_gnutls_v_2_la-utils.Tpo -c utils.c -DDLL_EXPORT -DPIC -o .libs/guile_gnutls_v_2_la-utils.o >> >> So it builds both the static and the PIC version. > > Not sure I follow you here. The above is just one command, and it > builds only the static version. Oh right, I misinterpreted that. > The -DPIC is ignored on Windows, right? Dunno, is it? >> The command line lacks -no-undefined compared to the other one you >> posted, which may be the explanation. Could you try: >> >> make clean -C guile >> make -C guile LDFLAGS=-no-undefined >> >> ? > > Yes, it solves the problem, thanks. OK. I?ve added it in 4ab5ad2. > Now, as long as I have your attention: having succeeded in building > the Guile extensions, I've run the related tests, and saw these two > problems: > > . anonymous-auth.scm, session-record-port.scm, x509-auth.scm, and > openpgp-auth.scm tests all fail because they use primitive-fork, > which isn't supported on Windows. Is there any chance these tests > could be rewritten to not use that API? I don?t see how that could be done. > . openpgp-keyring.scm fails because it doesn't open > openpgp-keyring.gpg, a binary file, in binary mode. Here's the > patch to fix that: Commit df80177 does something similar, but that works with older Guile versions. Nikos: could you cherry-pick those to the active branches? Or is there a document describing the active branches and what can or cannot go on them? That would allow me to do it by myself. Thanks Eli for your feedback, Ludo?. From INVALID.NOREPLY at gnu.org Thu Dec 11 19:35:47 2014 From: INVALID.NOREPLY at gnu.org (Eli Zaretskii) Date: Thu, 11 Dec 2014 18:35:47 +0000 Subject: [gnutls-devel] [sr #108703] Windows build issues In-Reply-To: <20141211-200607.sv707.33956@savannah.gnu.org> References: <20141211-134934.sv97769.3976@savannah.gnu.org> <20141211-191246.sv220.76214@savannah.gnu.org> <20141211-200607.sv707.33956@savannah.gnu.org> Message-ID: <20141211-203547.sv220.9119@savannah.gnu.org> Follow-up Comment #3, sr #108703 (project gnutls): Regarding the fseek issue: if you can guide me how to disable the replacement, I might take a stub at providing a patch for that. I'd rather we solved this problem, because otherwise the build is broken on Windows, and kludging around it without pulling back gnulib (which AFAIU is against your intentions) is not for the faint at heart. (The rpl_close issue can be disregarded, since "make -k check" works around it, and 'close' is not replaced in the library, so no need to test the replacement.) Thanks. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From nmav at gnutls.org Fri Dec 12 08:01:21 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 12 Dec 2014 08:01:21 +0100 Subject: [gnutls-devel] Guile bindings for GnuTLS don't build as shared library on MinGW In-Reply-To: <87mw6u5a4a.fsf@gnu.org> References: <83fvcowwzl.fsf@gnu.org> <871to8shgj.fsf@gnu.org> <838uifv35b.fsf@gnu.org> <87ppbrjt4s.fsf@gnu.org> <83a92ut87b.fsf@gnu.org> <87mw6u5a4a.fsf@gnu.org> Message-ID: <1418367681.2062.1.camel@gnutls.org> On Thu, 2014-12-11 at 19:12 +0100, Ludovic Court?s wrote: > Commit df80177 does something similar, but that works with older Guile > versions. > > Nikos: could you cherry-pick those to the active branches? Or is there > a document describing the active branches and what can or cannot go on > them? That would allow me to do it by myself. The branches I backport patches to are the stable and depending on the severity of the fix, the stable-old. These are gnutls_3_3_x and gnutls_3_2_x in git. regards, Nikos From INVALID.NOREPLY at gnu.org Fri Dec 12 08:12:50 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Fri, 12 Dec 2014 07:12:50 +0000 Subject: [gnutls-devel] [sr #108703] Windows build issues In-Reply-To: <20141211-203547.sv220.9119@savannah.gnu.org> References: <20141211-134934.sv97769.3976@savannah.gnu.org> <20141211-191246.sv220.76214@savannah.gnu.org> <20141211-200607.sv707.33956@savannah.gnu.org> <20141211-203547.sv220.9119@savannah.gnu.org> Message-ID: <20141212-091250.sv707.49118@savannah.gnu.org> Follow-up Comment #4, sr #108703 (project gnutls): About the fseek issue, I cannot see what is the issue, as we don't use the fseek module. So I cannot see why it has tried to override it, or test it at all. What I can suggest is to check gl/stdio.h and ask in the gnulib mailing list. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Fri Dec 12 08:13:18 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Fri, 12 Dec 2014 07:13:18 +0000 Subject: [gnutls-devel] [sr #108615] Regenerating documentation fails when sed is BSD sed In-Reply-To: <20140727-132348.sv64386.18748@savannah.gnu.org> References: <20140714-064046.sv64386.31705@savannah.gnu.org> <20140727-152757.sv707.24675@savannah.gnu.org> <20140727-123418.sv64386.82513@savannah.gnu.org> <20140727-153923.sv707.17910@savannah.gnu.org> <20140727-132051.sv64386.61232@savannah.gnu.org> <20140727-132348.sv64386.18748@savannah.gnu.org> Message-ID: <20141212-091318.sv707.47587@savannah.gnu.org> Update of sr #108615 (project gnutls): Open/Closed: Open => Closed _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From ludo at gnu.org Fri Dec 12 14:25:07 2014 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Fri, 12 Dec 2014 14:25:07 +0100 Subject: [gnutls-devel] Guile bindings for GnuTLS don't build as shared library on MinGW In-Reply-To: <1418367681.2062.1.camel@gnutls.org> (Nikos Mavrogiannopoulos's message of "Fri, 12 Dec 2014 08:01:21 +0100") References: <83fvcowwzl.fsf@gnu.org> <871to8shgj.fsf@gnu.org> <838uifv35b.fsf@gnu.org> <87ppbrjt4s.fsf@gnu.org> <83a92ut87b.fsf@gnu.org> <87mw6u5a4a.fsf@gnu.org> <1418367681.2062.1.camel@gnutls.org> Message-ID: <87zjat0zm4.fsf@gnu.org> Nikos Mavrogiannopoulos skribis: > On Thu, 2014-12-11 at 19:12 +0100, Ludovic Court?s wrote: > >> Commit df80177 does something similar, but that works with older Guile >> versions. >> >> Nikos: could you cherry-pick those to the active branches? Or is there >> a document describing the active branches and what can or cannot go on >> them? That would allow me to do it by myself. > > The branches I backport patches to are the stable and depending on the > severity of the fix, the stable-old. These are gnutls_3_3_x and > gnutls_3_2_x in git. OK, thanks. I?ve backported the relevant parts, and updated NEWS in each branch. Ludo?. From nmav at gnutls.org Fri Dec 12 14:54:51 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 12 Dec 2014 14:54:51 +0100 Subject: [gnutls-devel] Guile bindings for GnuTLS don't build as shared library on MinGW In-Reply-To: <87zjat0zm4.fsf@gnu.org> References: <83fvcowwzl.fsf@gnu.org> <871to8shgj.fsf@gnu.org> <838uifv35b.fsf@gnu.org> <87ppbrjt4s.fsf@gnu.org> <83a92ut87b.fsf@gnu.org> <87mw6u5a4a.fsf@gnu.org> <1418367681.2062.1.camel@gnutls.org> <87zjat0zm4.fsf@gnu.org> Message-ID: <1418392491.17333.1.camel@gnutls.org> On Fri, 2014-12-12 at 14:25 +0100, Ludovic Court?s wrote: > > The branches I backport patches to are the stable and depending on the > > severity of the fix, the stable-old. These are gnutls_3_3_x and > > gnutls_3_2_x in git. > > OK, thanks. I?ve backported the relevant parts, and updated NEWS in > each branch. Thanks. I saw however, that you have dropped the rsa-export related functions from the 3.3.x branch as well. I think it is better to align with the gnutls main library and drop them in master only (3.4.x). That way there will not be API changes in the existing stable branch. regards, Nikos From ludo at gnu.org Fri Dec 12 22:25:06 2014 From: ludo at gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Date: Fri, 12 Dec 2014 22:25:06 +0100 Subject: [gnutls-devel] Guile bindings for GnuTLS don't build as shared library on MinGW In-Reply-To: <1418392491.17333.1.camel@gnutls.org> (Nikos Mavrogiannopoulos's message of "Fri, 12 Dec 2014 14:54:51 +0100") References: <83fvcowwzl.fsf@gnu.org> <871to8shgj.fsf@gnu.org> <838uifv35b.fsf@gnu.org> <87ppbrjt4s.fsf@gnu.org> <83a92ut87b.fsf@gnu.org> <87mw6u5a4a.fsf@gnu.org> <1418367681.2062.1.camel@gnutls.org> <87zjat0zm4.fsf@gnu.org> <1418392491.17333.1.camel@gnutls.org> Message-ID: <87vblgh87h.fsf@gnu.org> Nikos Mavrogiannopoulos skribis: > On Fri, 2014-12-12 at 14:25 +0100, Ludovic Court?s wrote: > >> > The branches I backport patches to are the stable and depending on the >> > severity of the fix, the stable-old. These are gnutls_3_3_x and >> > gnutls_3_2_x in git. >> >> OK, thanks. I?ve backported the relevant parts, and updated NEWS in >> each branch. > > Thanks. I saw however, that you have dropped the rsa-export related > functions from the 3.3.x branch as well. I think it is better to align > with the gnutls main library and drop them in master only (3.4.x). That > way there will not be API changes in the existing stable branch. Right. Fixed in 119bb96. Thanks, Ludo?. From eliz at gnu.org Sat Dec 13 12:29:55 2014 From: eliz at gnu.org (Eli Zaretskii) Date: Sat, 13 Dec 2014 13:29:55 +0200 Subject: [gnutls-devel] How to configure GnuTLS on MinGW? Message-ID: <83fvcjrdn0.fsf@gnu.org> Could someone please help me figuring out how best to configure GnuTLS on MS-Windows for the MinGW build? The configure script offers a lot of optional switches, but I couldn't find guidance about which ones to use on Windows. Mind you, I know almost nothing about Internet security, so the description of the various options that could perhaps tell enough to someone who does know about security, doesn't give enough information for me. Some specific switches that I was wondering about: --without-p11-kit I do have p11-kit built and installed, but I wonder whether it is useful on Windows to build GnuTLS with it. At least for the certificate storage, I see in the sources that lib/system.c is capable of using Windows's own certificates. However, ENABLE_PKCS11 is present in quite a few other locations in the sources, so certificates seems to be not the only part of GnuTLS's functionality that needs p11-kit. What GnuTLS features might benefit from p11-kit? --with-default-trust-store-file I initially intended using it, but then I saw in lib/system.c that doing so disables the code that uses the Windows's certificate store, so I understand this option is not to be used on Windows, even if one does have a certificate bundle installed as ca-certificates.crt. Is that correct? Also, would it make sense to use ca-certificates.crt, if available, in addition to the Windows-stored certificates (by making an appropriate change in system.c)? --with-default-blacklist-file Is it advisable to use this, and if so, where and how to get the initial blacklist file, and in what format should it be? --with-system-priority-file Likewise with this option: will it be useful on Windows, and if so, how to obtain the priority file? Any other of the --enable/--disable or --with/--without options that need special considerations on Windows? Thanks in advance. (Btw, "./configure --help" implies that building Guile bindings is disabled by default, but the default is actually to enable them if Guile is found on the build system. I suggest to update configure.ac to reflect the default.) From nmav at gnutls.org Sat Dec 13 19:23:31 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 13 Dec 2014 19:23:31 +0100 Subject: [gnutls-devel] How to configure GnuTLS on MinGW? In-Reply-To: <83fvcjrdn0.fsf@gnu.org> References: <83fvcjrdn0.fsf@gnu.org> Message-ID: <1418495011.4382.1.camel@gnutls.org> On Sat, 2014-12-13 at 13:29 +0200, Eli Zaretskii wrote: > Could someone please help me figuring out how best to configure GnuTLS > on MS-Windows for the MinGW build? The configure script offers a lot > of optional switches, but I couldn't find guidance about which ones to > use on Windows. > > Mind you, I know almost nothing about Internet security, so the > description of the various options that could perhaps tell enough to > someone who does know about security, doesn't give enough information > for me. > > Some specific switches that I was wondering about: > --without-p11-kit > I do have p11-kit built and installed, but I wonder whether it is > useful on Windows to build GnuTLS with it. At least for the > certificate storage, I see in the sources that lib/system.c is > capable of using Windows's own certificates. However, > ENABLE_PKCS11 is present in quite a few other locations in the > sources, so certificates seems to be not the only part of GnuTLS's > functionality that needs p11-kit. What GnuTLS features might > benefit from p11-kit? That would be whether you need support for PKCS #11 smart cards or so. It is not straightforward to use them in windows, and unlike linux your application must setup the pkcs11 libraries etc. If you don't do that, then most probably you don't need it. It may be easier to simply support the system-keys in windows, but that's only available in master branch for now. > --with-default-trust-store-file In windows the windows CA store is being used. > --with-default-blacklist-file > Is it advisable to use this, and if so, where and how to get the > initial blacklist file, and in what format should it be? It's a PEM list of blacklisted certificates. Most systems don't have something like that, so you're safe if you don't use it. > --with-system-priority-file > Likewise with this option: will it be useful on Windows, and if > so, how to obtain the priority file? This was made for distributors of gnutls. With that you can make system-wide priority strings available to applications. regards, Nikos From eliz at gnu.org Sat Dec 13 20:23:33 2014 From: eliz at gnu.org (Eli Zaretskii) Date: Sat, 13 Dec 2014 21:23:33 +0200 Subject: [gnutls-devel] How to configure GnuTLS on MinGW? In-Reply-To: <1418495011.4382.1.camel@gnutls.org> References: <83fvcjrdn0.fsf@gnu.org> <1418495011.4382.1.camel@gnutls.org> Message-ID: <83tx0z4ami.fsf@gnu.org> > From: Nikos Mavrogiannopoulos > Cc: gnutls-devel at lists.gnutls.org > Date: Sat, 13 Dec 2014 19:23:31 +0100 Thanks for responding. > > --without-p11-kit > > I do have p11-kit built and installed, but I wonder whether it is > > useful on Windows to build GnuTLS with it. At least for the > > certificate storage, I see in the sources that lib/system.c is > > capable of using Windows's own certificates. However, > > ENABLE_PKCS11 is present in quite a few other locations in the > > sources, so certificates seems to be not the only part of GnuTLS's > > functionality that needs p11-kit. What GnuTLS features might > > benefit from p11-kit? > > That would be whether you need support for PKCS #11 smart cards or so. > It is not straightforward to use them in windows, and unlike linux your > application must setup the pkcs11 libraries etc. If you don't do that, > then most probably you don't need it. Can you elaborate a bit about "setting up the pkcs11 libraries"? I do have p11-kit built for Windows and installed, so what else is needed? Thanks for the other answers, they really help. From nmav at gnutls.org Sat Dec 13 22:31:24 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 13 Dec 2014 22:31:24 +0100 Subject: [gnutls-devel] How to configure GnuTLS on MinGW? In-Reply-To: <83tx0z4ami.fsf@gnu.org> References: <83fvcjrdn0.fsf@gnu.org> <1418495011.4382.1.camel@gnutls.org> <83tx0z4ami.fsf@gnu.org> Message-ID: <1418506284.17928.1.camel@gnutls.org> On Sat, 2014-12-13 at 21:23 +0200, Eli Zaretskii wrote: > > From: Nikos Mavrogiannopoulos > > Cc: gnutls-devel at lists.gnutls.org > > Date: Sat, 13 Dec 2014 19:23:31 +0100 > > Thanks for responding. > > > > --without-p11-kit > > > I do have p11-kit built and installed, but I wonder whether it is > > > useful on Windows to build GnuTLS with it. At least for the > > > certificate storage, I see in the sources that lib/system.c is > > > capable of using Windows's own certificates. However, > > > ENABLE_PKCS11 is present in quite a few other locations in the > > > sources, so certificates seems to be not the only part of GnuTLS's > > > functionality that needs p11-kit. What GnuTLS features might > > > benefit from p11-kit? > > > > That would be whether you need support for PKCS #11 smart cards or so. > > It is not straightforward to use them in windows, and unlike linux your > > application must setup the pkcs11 libraries etc. If you don't do that, > > then most probably you don't need it. > > Can you elaborate a bit about "setting up the pkcs11 libraries"? I do > have p11-kit built for Windows and installed, so what else is needed? With PKCS #11 you'll need to load a PKCS #11 module for the smart card you have. Some smart card providers give you one, or most rely on opensc's pkcs11 module. To load a module if you have, you use something like gnutls_pkcs11_add_provider(). In linux you don't normally need to call that because p11-kit often comes with configuration (in /etc/pkcs11) for the existing modules. regards, Nikos From eliz at gnu.org Sun Dec 14 04:34:57 2014 From: eliz at gnu.org (Eli Zaretskii) Date: Sun, 14 Dec 2014 05:34:57 +0200 Subject: [gnutls-devel] How to configure GnuTLS on MinGW? In-Reply-To: <1418506284.17928.1.camel@gnutls.org> References: <83fvcjrdn0.fsf@gnu.org> <1418495011.4382.1.camel@gnutls.org> <83tx0z4ami.fsf@gnu.org> <1418506284.17928.1.camel@gnutls.org> Message-ID: <83ppbm52fy.fsf@gnu.org> > From: Nikos Mavrogiannopoulos > Cc: gnutls-devel at lists.gnutls.org > Date: Sat, 13 Dec 2014 22:31:24 +0100 > > On Sat, 2014-12-13 at 21:23 +0200, Eli Zaretskii wrote: > > > From: Nikos Mavrogiannopoulos > > > Cc: gnutls-devel at lists.gnutls.org > > > Date: Sat, 13 Dec 2014 19:23:31 +0100 > > > > Thanks for responding. > > > > > > --without-p11-kit > > > > I do have p11-kit built and installed, but I wonder whether it is > > > > useful on Windows to build GnuTLS with it. At least for the > > > > certificate storage, I see in the sources that lib/system.c is > > > > capable of using Windows's own certificates. However, > > > > ENABLE_PKCS11 is present in quite a few other locations in the > > > > sources, so certificates seems to be not the only part of GnuTLS's > > > > functionality that needs p11-kit. What GnuTLS features might > > > > benefit from p11-kit? > > > > > > That would be whether you need support for PKCS #11 smart cards or so. > > > It is not straightforward to use them in windows, and unlike linux your > > > application must setup the pkcs11 libraries etc. If you don't do that, > > > then most probably you don't need it. > > > > Can you elaborate a bit about "setting up the pkcs11 libraries"? I do > > have p11-kit built for Windows and installed, so what else is needed? > > With PKCS #11 you'll need to load a PKCS #11 module for the smart card > you have. Some smart card providers give you one, or most rely on > opensc's pkcs11 module. To load a module if you have, you use something > like gnutls_pkcs11_add_provider(). In linux you don't normally need to > call that because p11-kit often comes with configuration > (in /etc/pkcs11) for the existing modules. Got it, thanks. From INVALID.NOREPLY at gnu.org Sun Dec 14 08:49:01 2014 From: INVALID.NOREPLY at gnu.org (David Fang) Date: Sun, 14 Dec 2014 07:49:01 +0000 Subject: [gnutls-devel] [sr #108705] test-stdalign assertion fail on powerpc-darwin8, gcc-4.0 Message-ID: <20141214-074901.sv66686.18231@savannah.gnu.org> URL: Summary: test-stdalign assertion fail on powerpc-darwin8, gcc-4.0 Project: GnuTLS Submitted by: fangism Submitted on: Sun 14 Dec 2014 07:49:01 AM GMT Category: None Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: Mac OS _______________________________________________________ Details: On good old powerpc-darwin8 (OS X 10.4), building with the system compiler, Apple's gcc-4.0.1, I get a single test failure with: % ./test-stdalign test-stdalign.c:88: assertion '(uintptr_t) &(static_char_alignas) % TEST_ALIGNMENT == 0' failed Abort I don't recall the details, but I know powerpc-darwin has some somewhat unconventional alignment rules in their ABI. What assumptions about alignment is this test making? Are those assumptions integral to the functionality of GNUTLS? Or is perhaps the test erroneous? _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Dec 14 08:54:13 2014 From: INVALID.NOREPLY at gnu.org (David Fang) Date: Sun, 14 Dec 2014 07:54:13 +0000 Subject: [gnutls-devel] [sr #108705] test-stdalign assertion fail on powerpc-darwin8, gcc-4.0 In-Reply-To: <20141214-074901.sv66686.18231@savannah.gnu.org> References: <20141214-074901.sv66686.18231@savannah.gnu.org> Message-ID: <20141214-075412.sv66686.74143@savannah.gnu.org> Follow-up Comment #1, sr #108705 (project gnutls): version GNUTLS 3.3.9 there is no system header present compiler is pre-C11 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Dec 14 11:25:32 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Sun, 14 Dec 2014 10:25:32 +0000 Subject: [gnutls-devel] [sr #108705] test-stdalign assertion fail on powerpc-darwin8, gcc-4.0 In-Reply-To: <20141214-075412.sv66686.74143@savannah.gnu.org> References: <20141214-074901.sv66686.18231@savannah.gnu.org> <20141214-075412.sv66686.74143@savannah.gnu.org> Message-ID: <20141214-122532.sv707.81216@savannah.gnu.org> Follow-up Comment #2, sr #108705 (project gnutls): This is a gnulib test and as far as I understand it checks the alignment of several types. No idea why is that, but probably it is used by gnulib itself. You may want to bring that issue to gnulib mailing list at: https://www.gnu.org/software/gnulib/ To see whether this may affect gnutls you could try gnutls' test suite directly in tests/. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Sun Dec 14 18:03:09 2014 From: INVALID.NOREPLY at gnu.org (David Fang) Date: Sun, 14 Dec 2014 17:03:09 +0000 Subject: [gnutls-devel] [sr #108705] test-stdalign assertion fail on powerpc-darwin8, gcc-4.0 In-Reply-To: <20141214-122532.sv707.81216@savannah.gnu.org> References: <20141214-074901.sv66686.18231@savannah.gnu.org> <20141214-075412.sv66686.74143@savannah.gnu.org> <20141214-122532.sv707.81216@savannah.gnu.org> Message-ID: <20141214-170309.sv66686.31418@savannah.gnu.org> Follow-up Comment #3, sr #108705 (project gnutls): I found short discussion here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023 _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From ametzler at bebt.de Mon Dec 15 19:14:03 2014 From: ametzler at bebt.de (Andreas Metzler) Date: Mon, 15 Dec 2014 19:14:03 +0100 Subject: [gnutls-devel] -VERS-DTLS-ALL and -VERS-TLS-ALL also disable TLS/DTLS respectively Message-ID: <20141215181403.GA1283@downhill.g.la> Hello, this is http://bugs.debian.org/773145 submitted by Josh Triplett: ------------------------------------- $ gnutls-cli --priority=PFS -l | grep '^Protocols:' Protocols: VERS-TLS1.2, VERS-TLS1.1, VERS-TLS1.0, VERS-DTLS1.2, VERS-DTLS1.0 $ gnutls-cli --priority=PFS:-VERS-DTLS-ALL -l | grep '^Protocols:' Protocols: none $ gnutls-cli --priority=PFS:-VERS-TLS-ALL -l | grep '^Protocols:' Protocols: none I'd expect the following instead: $ gnutls-cli --priority=PFS:-VERS-DTLS-ALL -l | grep '^Protocols:' Protocols: VERS-TLS1.2, VERS-TLS1.1, VERS-TLS1.0 $ gnutls-cli --priority=PFS:-VERS-TLS-ALL -l | grep '^Protocols:' Protocols: VERS-DTLS1.2, VERS-DTLS1.0 - Josh Triplett ------------------------------------- Not much to add, except that it also applies to 3.3.11 and is not limited to negation, s can be seen by looking at NORMAL:-VERS-DTLS-ALL:+VERS-TLS-ALL. 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 jaak.ristioja at cyber.ee Tue Dec 16 12:49:56 2014 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Tue, 16 Dec 2014 13:49:56 +0200 Subject: [gnutls-devel] GnuTLS 3.2.15 SIGSEGV in _gnutls_buffer_append_data Message-ID: <54901C64.2090407@cyber.ee> Hello! Yesterday I found myself debugging a SIGSEGV in an application which calls gnutls_record_send() on 7-byte and 16384-byte buffers during a short amount of time (the total size of data the application must pass to gnutls_record_send() exceeds 2,5 GiB). I think that GnuTLS is mostly corked during these operations. I got the following backtrace in GDB: (gdb) thread 12 [Switching to thread 12 (Thread 0x7ffff22eb700 (LWP 3461))] #0 __memmove_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:93 93 ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S: No such file or directory. (gdb) bt #0 __memmove_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:93 #1 0x00007ffff6c17c55 in memmove (__len=, __src=, __dest=) at /usr/include/bits/string3.h:57 #2 _gnutls_buffer_append_data (dest=dest at entry=0x7fff9c0012d0, data=0x7ffd158e9008, data_size=data_size at entry=16384) at gnutls_str.c:147 #3 0x00007ffff6bf5727 in gnutls_record_send (session=0x7fff9c0009c0, data=, data_size=16384) at gnutls_record.c:1456 ... (gdb) f 2 #2 _gnutls_buffer_append_data (dest=dest at entry=0x7fff9c0012d0, data=0x7ffd158e9008, data_size=data_size at entry=16384) at gnutls_str.c:147 147 memmove(dest->allocd, dest->data, dest->length); (gdb) print *dest $1 = {allocd = 0x555555974380 "\020@\227UUU", data = 0xd55340522390 , max_length = 851513336, length = 851496223} (gdb) print data $2 = (const void *) 0x7ffd158e9008 (gdb) print unused $3 = 140728541569040 (gdb) print new_len $4 = 851513336 (gdb) print tot_len $5 = 851512607 Can anybody help me understand how a gnutls_buffer_st, _gnutls_buffer_append_data and related functions should work, or why this crash happens? This code in lib/gnutls_str.[ch] could use a few more comments. Thanks! Best regards, Jaak Ristioja Cybernetica AS http://cyber.ee/ PS: A few small ideas for optimizing the current _gnutls_buffer_append_data function: 1) The line size_t unused = MEMSUB(dest->data, dest->allocd); can be deduplicated by moving it out of the if-block. 2) The variables declared in this function may be marked const. 3) In the else branch, why check for dest->data (in the if-condition for memmove) if it has previously been initialized to (dest->allocd + unused)? PPS: Why is MEMSUB in lib/gnutls_int.h defined as #define MEMSUB(x,y) ((ssize_t)((ptrdiff_t)x-(ptrdiff_t)y)) instead of #define MEMSUB(x,y) ((ssize_t)((char const *)x-(char const *)y)) The size of the result of subtracting two pointers should be of type ptrdiff_t (a signed integer type) anyway. Are we sure no errors are introduced when converting the pointers x and y to ptrdiff_t before the subtraction? In addition, using parenthesis around x and y in the macro body might help macro safety. From nmav at gnutls.org Tue Dec 16 13:05:59 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 16 Dec 2014 13:05:59 +0100 Subject: [gnutls-devel] -VERS-DTLS-ALL and -VERS-TLS-ALL also disable TLS/DTLS respectively In-Reply-To: <20141215181403.GA1283@downhill.g.la> References: <20141215181403.GA1283@downhill.g.la> Message-ID: <1418731559.6441.8.camel@gnutls.org> On Mon, 2014-12-15 at 19:14 +0100, Andreas Metzler wrote: > Hello, > > this is http://bugs.debian.org/773145 submitted by Josh Triplett: > ------------------------------------- > $ gnutls-cli --priority=PFS -l | grep '^Protocols:' > Protocols: VERS-TLS1.2, VERS-TLS1.1, VERS-TLS1.0, VERS-DTLS1.2, VERS-DTLS1.0 > $ gnutls-cli --priority=PFS:-VERS-DTLS-ALL -l | grep '^Protocols:' > Protocols: none > $ gnutls-cli --priority=PFS:-VERS-TLS-ALL -l | grep '^Protocols:' > Protocols: none Thanks for forwarding. Indeed, it looks like an issue and I'll check it, but note that it is not serious or so. Even though DTLS is enabled by default, it can only be used by applications which call gnutls_init() with the GNUTLS_DATAGRAM option. Thus disabling TLS for them, or disabling DTLS for the others wouldn't have any effect, as the applications these protocols apply are clearly distinct (negotiation of DTLS and TLS cannot be mixed). regards, Nikos From nmav at gnutls.org Tue Dec 16 13:11:51 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 16 Dec 2014 13:11:51 +0100 Subject: [gnutls-devel] GnuTLS 3.2.15 SIGSEGV in _gnutls_buffer_append_data In-Reply-To: <54901C64.2090407@cyber.ee> References: <54901C64.2090407@cyber.ee> Message-ID: <1418731911.6441.11.camel@gnutls.org> On Tue, 2014-12-16 at 13:49 +0200, Jaak Ristioja wrote: > Hello! > > Yesterday I found myself debugging a SIGSEGV in an application which > calls gnutls_record_send() on 7-byte and 16384-byte buffers during a > short amount of time (the total size of data the application must pass > to gnutls_record_send() exceeds 2,5 GiB). I think that GnuTLS is mostly > corked during these operations. I got the following backtrace in GDB: That looks like a memory corruption. For these types of errors valgrind may given more reliable information than gdb. Could you have a run with valgrind? > Can anybody help me understand how a gnutls_buffer_st, > _gnutls_buffer_append_data and related functions should work, or why > this crash happens? This code in lib/gnutls_str.[ch] could use a few > more comments. The idea is to have a buffer where data can be appended easily and quickly. > PS: A few small ideas for optimizing the current > _gnutls_buffer_append_data function: Will check and reply later. regards, Nikos From jaak.ristioja at cyber.ee Tue Dec 16 14:48:21 2014 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Tue, 16 Dec 2014 15:48:21 +0200 Subject: [gnutls-devel] GnuTLS 3.2.15 SIGSEGV in _gnutls_buffer_append_data In-Reply-To: <1418731911.6441.11.camel@gnutls.org> References: <54901C64.2090407@cyber.ee> <1418731911.6441.11.camel@gnutls.org> Message-ID: <54903825.4010409@cyber.ee> On 16.12.2014 14:11, Nikos Mavrogiannopoulos wrote: > That looks like a memory corruption. For these types of errors valgrind > may given more reliable information than gdb. Could you have a run with > valgrind? Unfortunately my minimal test case requires too much memory, Valgrind's memory manager is unable to allocate this much and exits with a verbose OOM message. > The idea is to have a buffer where data can be appended easily and > quickly. The code seems to contain a lot of complicated logic for something which should be rather simple. I don't understand why all the memmove logic is needed when appending to the buffer. To work around the valgrind issue, I just wrote a minimal test-case (sources attached to this e-mail) using the anonymous authentication examples in the manual. When run, it seems to hit some integer overflow bug in GnuTLS. I attached the modified examples to this e-mail. The server outputs: Server ready. Listening to port '5556'. - connection from 127.0.0.1, port 39196 - Handshake was completed *** Received corrupted data(-110). Closing the connection. The TLS connection was non-properly terminated The client outputs: - Session info: (TLS1.2)-(ANON-ECDH-SECP192R1)-(ARCFOUR-128)-(SHA1) 2147482624 GnuTLS fatal error (-2147483648): (unknown error code) Aborted So gnutls_record_send() returns -2147483648 (INT32_MIN). I'm not sure whether this is related to what I get in my application. Regards, Jaak Ristioja Cybernetica AS -------------- next part -------------- A non-text attachment was scrubbed... Name: client.c Type: text/x-csrc Size: 4412 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: server.c Type: text/x-csrc Size: 5782 bytes Desc: not available URL: From nmav at gnutls.org Tue Dec 16 15:33:25 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 16 Dec 2014 15:33:25 +0100 Subject: [gnutls-devel] GnuTLS 3.2.15 SIGSEGV in _gnutls_buffer_append_data In-Reply-To: <54903825.4010409@cyber.ee> References: <54901C64.2090407@cyber.ee> <1418731911.6441.11.camel@gnutls.org> <54903825.4010409@cyber.ee> Message-ID: <1418740405.3096.7.camel@gnutls.org> On Tue, 2014-12-16 at 15:48 +0200, Jaak Ristioja wrote: > On 16.12.2014 14:11, Nikos Mavrogiannopoulos wrote: > > That looks like a memory corruption. For these types of errors valgrind > > may given more reliable information than gdb. Could you have a run with > > valgrind? > Unfortunately my minimal test case requires too much memory, Valgrind's > memory manager is unable to allocate this much and exits with a verbose > OOM message. -faddress=sanitize is an alternative way to debug memory corruptions. However, I tried your test case with 3.3.11 and there hasn't been any issue. Have you tried the latest gnutls versions? > > The idea is to have a buffer where data can be appended easily and > quickly. > The code seems to contain a lot of complicated logic for something which > should be rather simple. I don't understand why all the memmove logic is > needed when appending to the buffer. The buffer has the ability for quite consumption of its data (see buffer_pop_datum), but when appending to a buffer you most probably want to re-use any space that was consumed by buffer_pop_datum(). Said that, if you think there can be optimizations please suggest them. regards, Nikos From jaak.ristioja at cyber.ee Tue Dec 16 17:18:39 2014 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Tue, 16 Dec 2014 18:18:39 +0200 Subject: [gnutls-devel] [PATCH 6/6] Removed another reduntant condition in _gnutls_buffer_append_data(). In-Reply-To: <1418746719-11091-1-git-send-email-jaak.ristioja@cyber.ee> References: <1418746719-11091-1-git-send-email-jaak.ristioja@cyber.ee> Message-ID: <1418746719-11091-6-git-send-email-jaak.ristioja@cyber.ee> A presumably non-NULL value is written to dest->data just above this condition. --- lib/gnutls_str.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/gnutls_str.c b/lib/gnutls_str.c index 29eb95e..a00f4f0 100644 --- a/lib/gnutls_str.c +++ b/lib/gnutls_str.c @@ -136,7 +136,7 @@ _gnutls_buffer_append_data(gnutls_buffer_st * dest, const void *data, dest->max_length = new_len; dest->data = dest->allocd + unused; - if (dest->length && dest->data) + if (dest->length) memmove(dest->allocd, dest->data, dest->length); dest->data = dest->allocd; } -- 2.2.0 From jaak.ristioja at cyber.ee Tue Dec 16 17:18:38 2014 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Tue, 16 Dec 2014 18:18:38 +0200 Subject: [gnutls-devel] [PATCH 5/6] Removed reduntant condition in _gnutls_buffer_append_data(). In-Reply-To: <1418746719-11091-1-git-send-email-jaak.ristioja@cyber.ee> References: <1418746719-11091-1-git-send-email-jaak.ristioja@cyber.ee> Message-ID: <1418746719-11091-5-git-send-email-jaak.ristioja@cyber.ee> The above definition of variable unused implies that it should be non-NULL. --- lib/gnutls_str.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/gnutls_str.c b/lib/gnutls_str.c index 3cc7f7e..29eb95e 100644 --- a/lib/gnutls_str.c +++ b/lib/gnutls_str.c @@ -117,7 +117,7 @@ _gnutls_buffer_append_data(gnutls_buffer_st * dest, const void *data, size_t const tot_len = data_size + dest->length; if (dest->max_length >= tot_len) { if (dest->max_length - unused <= tot_len) { - if (dest->length && dest->data) + if (dest->length) memmove(dest->allocd, dest->data, dest->length); -- 2.2.0 From jaak.ristioja at cyber.ee Tue Dec 16 17:18:35 2014 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Tue, 16 Dec 2014 18:18:35 +0200 Subject: [gnutls-devel] [PATCH 2/6] Optimized calls to _gnutls_buffer_append_data with data_size of 0. In-Reply-To: <1418746719-11091-1-git-send-email-jaak.ristioja@cyber.ee> References: <1418746719-11091-1-git-send-email-jaak.ristioja@cyber.ee> Message-ID: <1418746719-11091-2-git-send-email-jaak.ristioja@cyber.ee> --- lib/gnutls_str.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/lib/gnutls_str.c b/lib/gnutls_str.c index 13222f0..ca4eec3 100644 --- a/lib/gnutls_str.c +++ b/lib/gnutls_str.c @@ -110,11 +110,10 @@ int _gnutls_buffer_append_data(gnutls_buffer_st * dest, const void *data, size_t data_size) { - size_t const tot_len = data_size + dest->length; - if (data_size == 0) return 0; + size_t const tot_len = data_size + dest->length; if (dest->max_length >= tot_len) { size_t const unused = MEMSUB(dest->data, dest->allocd); -- 2.2.0 From jaak.ristioja at cyber.ee Tue Dec 16 17:18:34 2014 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Tue, 16 Dec 2014 18:18:34 +0200 Subject: [gnutls-devel] [PATCH 1/6] Explicitly marked some variables const in _gnutls_buffer_append_data(). Message-ID: <1418746719-11091-1-git-send-email-jaak.ristioja@cyber.ee> --- lib/gnutls_str.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/gnutls_str.c b/lib/gnutls_str.c index 250206b..13222f0 100644 --- a/lib/gnutls_str.c +++ b/lib/gnutls_str.c @@ -110,13 +110,13 @@ int _gnutls_buffer_append_data(gnutls_buffer_st * dest, const void *data, size_t data_size) { - size_t tot_len = data_size + dest->length; + size_t const tot_len = data_size + dest->length; if (data_size == 0) return 0; if (dest->max_length >= tot_len) { - size_t unused = MEMSUB(dest->data, dest->allocd); + size_t const unused = MEMSUB(dest->data, dest->allocd); if (dest->max_length - unused <= tot_len) { if (dest->length && dest->data) @@ -130,8 +130,8 @@ _gnutls_buffer_append_data(gnutls_buffer_st * dest, const void *data, return tot_len; } else { - size_t unused = MEMSUB(dest->data, dest->allocd); - size_t new_len = + size_t const unused = MEMSUB(dest->data, dest->allocd); + size_t const new_len = MAX(data_size, MIN_CHUNK) + MAX(dest->max_length, MIN_CHUNK); -- 2.2.0 From jaak.ristioja at cyber.ee Tue Dec 16 17:18:37 2014 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Tue, 16 Dec 2014 18:18:37 +0200 Subject: [gnutls-devel] [PATCH 4/6] Deduplicated some code in _gnutls_buffer_append_data(). In-Reply-To: <1418746719-11091-1-git-send-email-jaak.ristioja@cyber.ee> References: <1418746719-11091-1-git-send-email-jaak.ristioja@cyber.ee> Message-ID: <1418746719-11091-4-git-send-email-jaak.ristioja@cyber.ee> --- lib/gnutls_str.c | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/lib/gnutls_str.c b/lib/gnutls_str.c index 9e36924..3cc7f7e 100644 --- a/lib/gnutls_str.c +++ b/lib/gnutls_str.c @@ -113,10 +113,9 @@ _gnutls_buffer_append_data(gnutls_buffer_st * dest, const void *data, if (data_size == 0) return 0; + size_t const unused = MEMSUB(dest->data, dest->allocd); size_t const tot_len = data_size + dest->length; if (dest->max_length >= tot_len) { - size_t const unused = MEMSUB(dest->data, dest->allocd); - if (dest->max_length - unused <= tot_len) { if (dest->length && dest->data) memmove(dest->allocd, dest->data, @@ -124,12 +123,7 @@ _gnutls_buffer_append_data(gnutls_buffer_st * dest, const void *data, dest->data = dest->allocd; } - memcpy(&dest->data[dest->length], data, data_size); - dest->length = tot_len; - - return tot_len; } else { - size_t const unused = MEMSUB(dest->data, dest->allocd); size_t const new_len = MAX(data_size, MIN_CHUNK) + MAX(dest->max_length, MIN_CHUNK); @@ -145,12 +139,10 @@ _gnutls_buffer_append_data(gnutls_buffer_st * dest, const void *data, if (dest->length && dest->data) memmove(dest->allocd, dest->data, dest->length); dest->data = dest->allocd; - - memcpy(&dest->data[dest->length], data, data_size); - dest->length = tot_len; - - return tot_len; } + memcpy(&dest->data[dest->length], data, data_size); + dest->length = tot_len; + return tot_len; } int _gnutls_buffer_resize(gnutls_buffer_st * dest, size_t new_size) -- 2.2.0 From jaak.ristioja at cyber.ee Tue Dec 16 17:18:36 2014 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Tue, 16 Dec 2014 18:18:36 +0200 Subject: [gnutls-devel] [PATCH 3/6] Small s/memmove/memcpy/ optimization in _gnutls_buffer_append_data(). In-Reply-To: <1418746719-11091-1-git-send-email-jaak.ristioja@cyber.ee> References: <1418746719-11091-1-git-send-email-jaak.ristioja@cyber.ee> Message-ID: <1418746719-11091-3-git-send-email-jaak.ristioja@cyber.ee> Using memcpy in this context seems to be safe as it is also used in the else branch. --- lib/gnutls_str.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/gnutls_str.c b/lib/gnutls_str.c index ca4eec3..9e36924 100644 --- a/lib/gnutls_str.c +++ b/lib/gnutls_str.c @@ -124,7 +124,7 @@ _gnutls_buffer_append_data(gnutls_buffer_st * dest, const void *data, dest->data = dest->allocd; } - memmove(&dest->data[dest->length], data, data_size); + memcpy(&dest->data[dest->length], data, data_size); dest->length = tot_len; return tot_len; -- 2.2.0 From jaak.ristioja at cyber.ee Tue Dec 16 17:28:56 2014 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Tue, 16 Dec 2014 18:28:56 +0200 Subject: [gnutls-devel] GnuTLS 3.2.15 SIGSEGV in _gnutls_buffer_append_data In-Reply-To: <1418740405.3096.7.camel@gnutls.org> References: <54901C64.2090407@cyber.ee> <1418731911.6441.11.camel@gnutls.org> <54903825.4010409@cyber.ee> <1418740405.3096.7.camel@gnutls.org> Message-ID: <54905DC8.60907@cyber.ee> On 16.12.2014 16:33, Nikos Mavrogiannopoulos wrote: > -faddress=sanitize is an alternative way to debug memory corruptions. Using the sanitizers under certain Hardened Gentoo configurations is a bit complicated. But I know I should. > However, I tried your test case with 3.3.11 and there hasn't been any > issue. Have you tried the latest gnutls versions? I tried the *.c files I sent earlier with GnuTLS 3.3.10 and got the INT32_MIN issue. >>> The idea is to have a buffer where data can be appended easily and >> quickly. >> The code seems to contain a lot of complicated logic for something which >> should be rather simple. I don't understand why all the memmove logic is >> needed when appending to the buffer. > > The buffer has the ability for quite consumption of its data (see > buffer_pop_datum), but when appending to a buffer you most probably want > to re-use any space that was consumed by buffer_pop_datum(). Said that, > if you think there can be optimizations please suggest them. Please correct me if I have misunderstood this. So the buffer is a FIFO of bytes, which only reallocates the storage if full. The allocd field points to the start of the (re)allocated memory, the data field points to the data not yet popped, the max_length field is the size of the allocation, and the length field is the size of the data still in the buffer which has not yet been popped. I just submitted a small set of patches to optimize the _gnutls_buffer_append_data() function a little. Please note, however, that there are still at least 3 potential problems in that function: 1) Setting tot_len may overflow the size_t destination type: size_t const tot_len = data_size + dest->length; 2) Setting new_len may overflow the size_t destination type: size_t const new_len = MAX(data_size, MIN_CHUNK) + MAX(dest->max_length, MIN_CHUNK); 3) Returning unsigned tot_len (size_t) may overflow the return type (signed int): return tot_len; I think I'm getting one of these issues. Maybe there's something wrong with gnutls_record_send that it keeps filling the buffer even when the maximum record size has been reached? Regards, Jaak Ristioja Cybernetica AS From nmav at gnutls.org Tue Dec 16 18:37:47 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 16 Dec 2014 19:37:47 +0200 Subject: [gnutls-devel] [PATCH 1/6] Explicitly marked some variables const in _gnutls_buffer_append_data(). In-Reply-To: <1418746719-11091-1-git-send-email-jaak.ristioja@cyber.ee> References: <1418746719-11091-1-git-send-email-jaak.ristioja@cyber.ee> Message-ID: <1418751467.2336.9.camel@gnutls.org> On Tue, 2014-12-16 at 18:18 +0200, Jaak Ristioja wrote: > --- > lib/gnutls_str.c | 8 ++++---- > 1 file changed, 4 insertions(+), 4 deletions(-) Would you like to send a DCO [0] and rebase the patches on master? [0]. http://www.gnutls.org/devel.html > > However, I tried your test case with 3.3.11 and there hasn't been > any > > issue. Have you tried the latest gnutls versions? > > I tried the *.c files I sent earlier with GnuTLS 3.3.10 and got the > INT32_MIN issue. That is strange. Could it be that the applications (or one of them) were linked to an older version of the library? Are you using a 32-bit system or 64-bit? I cannot reproduce it on my x86-64. > > The buffer has the ability for quite consumption of its data (see > > buffer_pop_datum), but when appending to a buffer you most probably > want > > to re-use any space that was consumed by buffer_pop_datum(). Said > that, > > if you think there can be optimizations please suggest them. > > Please correct me if I have misunderstood this. So the buffer is a > FIFO > of bytes, which only reallocates the storage if full. The allocd field > points to the start of the (re)allocated memory, the data field points > to the data not yet popped, the max_length field is the size of the > allocation, and the length field is the size of the data still in the > buffer which has not yet been popped. Correct. > I just submitted a small set of patches to optimize the > _gnutls_buffer_append_data() function a little. Please note, however, > that there are still at least 3 potential problems in that function: > > 1) Setting tot_len may overflow the size_t destination type: > size_t const tot_len = data_size + dest->length; > 2) Setting new_len may overflow the size_t destination type: > size_t const new_len = > MAX(data_size, MIN_CHUNK) + MAX(dest->max_length, > MIN_CHUNK); Do you use such large buffers? These functions were never intended to be used with buffers even nearly close to 2^32. But returning an error code when the buffers reach some high limit should be more appropriate indeed. regards, Nikos From jaak.ristioja at cyber.ee Wed Dec 17 12:55:07 2014 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Wed, 17 Dec 2014 13:55:07 +0200 Subject: [gnutls-devel] [PATCH 1/4] Explicitly marked some variables const in _gnutls_buffer_append_data(). Message-ID: <1418817310-19257-1-git-send-email-jaak.ristioja@cyber.ee> Signed-off-by: Jaak Ristioja --- lib/gnutls_str.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/lib/gnutls_str.c b/lib/gnutls_str.c index 340463d..06141f4 100644 --- a/lib/gnutls_str.c +++ b/lib/gnutls_str.c @@ -117,20 +117,20 @@ int _gnutls_buffer_append_data(gnutls_buffer_st * dest, const void *data, size_t data_size) { - size_t tot_len = data_size + dest->length; + size_t const tot_len = data_size + dest->length; if (data_size == 0) return 0; if (dest->max_length >= tot_len) { - size_t unused = MEMSUB(dest->data, dest->allocd); + size_t const unused = MEMSUB(dest->data, dest->allocd); if (dest->max_length - unused <= tot_len) { align_allocd_with_data(dest); } } else { - size_t unused = MEMSUB(dest->data, dest->allocd); - size_t new_len = + size_t const unused = MEMSUB(dest->data, dest->allocd); + size_t const new_len = MAX(data_size, MIN_CHUNK) + MAX(dest->max_length, MIN_CHUNK); -- 2.2.0 From jaak.ristioja at cyber.ee Wed Dec 17 12:55:08 2014 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Wed, 17 Dec 2014 13:55:08 +0200 Subject: [gnutls-devel] [PATCH 2/4] Optimized calls to _gnutls_buffer_append_data with data_size of 0. In-Reply-To: <1418817310-19257-1-git-send-email-jaak.ristioja@cyber.ee> References: <1418817310-19257-1-git-send-email-jaak.ristioja@cyber.ee> Message-ID: <1418817310-19257-2-git-send-email-jaak.ristioja@cyber.ee> Signed-off-by: Jaak Ristioja --- lib/gnutls_str.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/lib/gnutls_str.c b/lib/gnutls_str.c index 06141f4..6cfbbb6 100644 --- a/lib/gnutls_str.c +++ b/lib/gnutls_str.c @@ -117,11 +117,10 @@ int _gnutls_buffer_append_data(gnutls_buffer_st * dest, const void *data, size_t data_size) { - size_t const tot_len = data_size + dest->length; - if (data_size == 0) return 0; + size_t const tot_len = data_size + dest->length; if (dest->max_length >= tot_len) { size_t const unused = MEMSUB(dest->data, dest->allocd); -- 2.2.0 From jaak.ristioja at cyber.ee Wed Dec 17 12:55:10 2014 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Wed, 17 Dec 2014 13:55:10 +0200 Subject: [gnutls-devel] [PATCH 4/4] Remove redundant condition in align_allocd_with_data(). In-Reply-To: <1418817310-19257-1-git-send-email-jaak.ristioja@cyber.ee> References: <1418817310-19257-1-git-send-email-jaak.ristioja@cyber.ee> Message-ID: <1418817310-19257-4-git-send-email-jaak.ristioja@cyber.ee> At all call-sites of align_allocd_with_data() dest->data is non-NULL. Signed-off-by: Jaak Ristioja --- lib/gnutls_str.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/gnutls_str.c b/lib/gnutls_str.c index 267b813..1a9c50d 100644 --- a/lib/gnutls_str.c +++ b/lib/gnutls_str.c @@ -108,7 +108,7 @@ void _gnutls_buffer_clear(gnutls_buffer_st * str) static void align_allocd_with_data(gnutls_buffer_st * dest) { - if (dest->length && dest->data) + if (dest->length) memmove(dest->allocd, dest->data, dest->length); dest->data = dest->allocd; } -- 2.2.0 From jaak.ristioja at cyber.ee Wed Dec 17 12:55:09 2014 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Wed, 17 Dec 2014 13:55:09 +0200 Subject: [gnutls-devel] [PATCH 3/4] Deduplicated some code in _gnutls_buffer_append_data(). In-Reply-To: <1418817310-19257-1-git-send-email-jaak.ristioja@cyber.ee> References: <1418817310-19257-1-git-send-email-jaak.ristioja@cyber.ee> Message-ID: <1418817310-19257-3-git-send-email-jaak.ristioja@cyber.ee> Signed-off-by: Jaak Ristioja --- lib/gnutls_str.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/lib/gnutls_str.c b/lib/gnutls_str.c index 6cfbbb6..267b813 100644 --- a/lib/gnutls_str.c +++ b/lib/gnutls_str.c @@ -120,15 +120,13 @@ _gnutls_buffer_append_data(gnutls_buffer_st * dest, const void *data, if (data_size == 0) return 0; + size_t const unused = MEMSUB(dest->data, dest->allocd); size_t const tot_len = data_size + dest->length; if (dest->max_length >= tot_len) { - size_t const unused = MEMSUB(dest->data, dest->allocd); - if (dest->max_length - unused <= tot_len) { align_allocd_with_data(dest); } } else { - size_t const unused = MEMSUB(dest->data, dest->allocd); size_t const new_len = MAX(data_size, MIN_CHUNK) + MAX(dest->max_length, MIN_CHUNK); @@ -141,9 +139,7 @@ _gnutls_buffer_append_data(gnutls_buffer_st * dest, const void *data, dest->max_length = new_len; dest->data = dest->allocd + unused; - if (dest->length && dest->data) - memmove(dest->allocd, dest->data, dest->length); - dest->data = dest->allocd; + align_allocd_with_data(dest); } memcpy(&dest->data[dest->length], data, data_size); -- 2.2.0 From jaak.ristioja at cyber.ee Wed Dec 17 12:57:26 2014 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Wed, 17 Dec 2014 13:57:26 +0200 Subject: [gnutls-devel] [PATCH 1/6] Explicitly marked some variables const in _gnutls_buffer_append_data(). In-Reply-To: <1418751467.2336.9.camel@gnutls.org> References: <1418746719-11091-1-git-send-email-jaak.ristioja@cyber.ee> <1418751467.2336.9.camel@gnutls.org> Message-ID: <54916FA6.5060004@cyber.ee> On 16.12.2014 19:37, Nikos Mavrogiannopoulos wrote: > Would you like to send a DCO [0] and rebase the patches > on master? > > [0]. http://www.gnutls.org/devel.html Sure. Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. Best regards, Jaak Ristioja Cybernetica AS From nmav at gnutls.org Wed Dec 17 13:55:25 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 17 Dec 2014 14:55:25 +0200 Subject: [gnutls-devel] [PATCH 1/6] Explicitly marked some variables const in _gnutls_buffer_append_data(). In-Reply-To: <54916FA6.5060004@cyber.ee> References: <1418746719-11091-1-git-send-email-jaak.ristioja@cyber.ee> <1418751467.2336.9.camel@gnutls.org> <54916FA6.5060004@cyber.ee> Message-ID: <1418820925.16656.1.camel@gnutls.org> On Wed, 2014-12-17 at 13:57 +0200, Jaak Ristioja wrote: > On 16.12.2014 19:37, Nikos Mavrogiannopoulos wrote: > > Would you like to send a DCO [0] and rebase the patches > > on master? > > [0]. http://www.gnutls.org/devel.html > Sure. Thanks. I've applied everything except the 2/4. While allowed in C99, I prefer to define variables in the beginning of the function. I've also committed an overflow check in 32-bit systems. regards, Nikos From jaak.ristioja at cyber.ee Wed Dec 17 15:04:35 2014 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Wed, 17 Dec 2014 16:04:35 +0200 Subject: [gnutls-devel] gnutls_record_cork and maximum record size Message-ID: <54918D73.1030302@cyber.ee> Hello! The documentation for gnutls_record_cork() states: If called gnutls_record_send() will no longer send partial records. All queued records will be sent when gnutls_uncork() is called, or when the maximum record size is reached. As I understand the documentation, it implies that if the session is corked by gnutls_record_cork() and the size of the data queued by successive calls to gnutls_record_send() reaches the maximum record size, then gnutls_record_get_max_size() bytes of data are passed to the underlying transport. However, the source code for gnutls_record_send() implies that if the session is corked then data is queued until gnutls_record_uncork() is called (or GNUTLS_E_MEMORY_ERROR is returned). Do I misunderstand the documentation or is there a discrepancy between the source code and the documentation? Regards, Jaak Ristioja Cybernetica AS From nmav at gnutls.org Fri Dec 19 07:55:28 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 19 Dec 2014 08:55:28 +0200 Subject: [gnutls-devel] gnutls_record_cork and maximum record size In-Reply-To: <54918D73.1030302@cyber.ee> References: <54918D73.1030302@cyber.ee> Message-ID: <1418972128.28712.3.camel@gnutls.org> On Wed, 2014-12-17 at 16:04 +0200, Jaak Ristioja wrote: > Hello! > > The documentation for gnutls_record_cork() states: > > If called gnutls_record_send() will no longer send partial records. > All queued records will be sent when gnutls_uncork() is called, or when > the maximum record size is reached. > > As I understand the documentation, it implies that if the session is > corked by gnutls_record_cork() and the size of the data queued by > successive calls to gnutls_record_send() reaches the maximum record > size, then gnutls_record_get_max_size() bytes of data are passed to the > underlying transport. However, the source code for gnutls_record_send() > implies that if the session is corked then data is queued until > gnutls_record_uncork() is called (or GNUTLS_E_MEMORY_ERROR is returned). > Do I misunderstand the documentation or is there a discrepancy between > the source code and the documentation? No you don't misunderstand the documentation, it is wrong. I'll update it to match the current behavior of the code. regards, Nikos From jaak.ristioja at cyber.ee Fri Dec 19 09:26:12 2014 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Fri, 19 Dec 2014 10:26:12 +0200 Subject: [gnutls-devel] gnutls_record_cork and maximum record size In-Reply-To: <1418972128.28712.3.camel@gnutls.org> References: <54918D73.1030302@cyber.ee> <1418972128.28712.3.camel@gnutls.org> Message-ID: <5493E124.2010509@cyber.ee> On 19.12.2014 08:55, Nikos Mavrogiannopoulos wrote: > On Wed, 2014-12-17 at 16:04 +0200, Jaak Ristioja wrote: >> Hello! >> >> The documentation for gnutls_record_cork() states: >> >> If called gnutls_record_send() will no longer send partial records. >> All queued records will be sent when gnutls_uncork() is called, or when >> the maximum record size is reached. >> >> As I understand the documentation, it implies that if the session is >> corked by gnutls_record_cork() and the size of the data queued by >> successive calls to gnutls_record_send() reaches the maximum record >> size, then gnutls_record_get_max_size() bytes of data are passed to the >> underlying transport. However, the source code for gnutls_record_send() >> implies that if the session is corked then data is queued until >> gnutls_record_uncork() is called (or GNUTLS_E_MEMORY_ERROR is returned). >> Do I misunderstand the documentation or is there a discrepancy between >> the source code and the documentation? > > No you don't misunderstand the documentation, it is wrong. I'll update > it to match the current behavior of the code. Why not instead update the code to match the documentation? :D There might also be other projects who rely on the previously released documentation to be correct and might hit similar issues with a lot of queued records. + * If called, gnutls_record_send() will no longer send partial records. + * All queued records will be sent when gnutls_uncork() is called. This is still somewhat confusing as the first sentence might imply that complete records will still be sent. Why not write something like this: If called, gnutls_record_send() will no longer send any records until gnutls_record_uncork() is called. Instead, gnutls_record_send() will try to buffer all data passed to it. The data buffered by gnutls_record_send() will be sent when gnutls_record_uncork() is called. Because essentially, a gnutls_record_cork() call, followed by a number of gnutls_record_send() calls, followed by a gnutls_record_uncork() call is just a way of concatenating the data before it is finally passed to the underlying TLS implementation as a single chunk of memory. Best regards, Jaak Ristioja Cybernetica AS PS: Please note that the documentation uses gnutls_cork() and gnutls_uncork() instead of gnutls_record_cork() and gnutls_record_uncork(). From nmav at gnutls.org Fri Dec 19 09:43:08 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 19 Dec 2014 10:43:08 +0200 Subject: [gnutls-devel] gnutls_record_cork and maximum record size In-Reply-To: <5493E124.2010509@cyber.ee> References: <54918D73.1030302@cyber.ee> <1418972128.28712.3.camel@gnutls.org> <5493E124.2010509@cyber.ee> Message-ID: <1418978588.31354.6.camel@gnutls.org> On Fri, 2014-12-19 at 10:26 +0200, Jaak Ristioja wrote: > >> As I understand the documentation, it implies that if the session is > >> corked by gnutls_record_cork() and the size of the data queued by > >> successive calls to gnutls_record_send() reaches the maximum record > >> size, then gnutls_record_get_max_size() bytes of data are passed to the > >> underlying transport. However, the source code for gnutls_record_send() > >> implies that if the session is corked then data is queued until > >> gnutls_record_uncork() is called (or GNUTLS_E_MEMORY_ERROR is returned). > >> Do I misunderstand the documentation or is there a discrepancy between > >> the source code and the documentation? > > No you don't misunderstand the documentation, it is wrong. I'll update > > it to match the current behavior of the code. > Why not instead update the code to match the documentation? :D There > might also be other projects who rely on the previously released > documentation to be correct and might hit similar issues with a lot of > queued records. Well, it was never behaving like that so they couldn't have relied on that behavior. That was the original intention of that API, but there were practical issue with supporting every networking scenario (blocking/non-blocking - tls/dtls), so it was simplified in the final implementation. > + * If called, gnutls_record_send() will no longer send partial records. > + * All queued records will be sent when gnutls_uncork() is called. > This is still somewhat confusing as the first sentence might imply that > complete records will still be sent. Why not write something like this: > If called, gnutls_record_send() will no longer send any records until > gnutls_record_uncork() is called. Instead, gnutls_record_send() will > try to buffer all data passed to it. The data buffered by > gnutls_record_send() will be sent when gnutls_record_uncork() is > called. I've updated it to be more precise along these lines. > Because essentially, a gnutls_record_cork() call, followed by a number > of gnutls_record_send() calls, followed by a gnutls_record_uncork() call > is just a way of concatenating the data before it is finally passed to > the underlying TLS implementation as a single chunk of memory. Correct. The idea is to allow implementations to use record_send() for small chunks, that will be concatenated. > PS: Please note that the documentation uses gnutls_cork() and > gnutls_uncork() instead of gnutls_record_cork() and gnutls_record_uncork(). Thanks, corrected. regards, Nikos From jaak.ristioja at cyber.ee Fri Dec 19 10:03:18 2014 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Fri, 19 Dec 2014 11:03:18 +0200 Subject: [gnutls-devel] [PATCH 1/6] Explicitly marked some variables const in _gnutls_buffer_append_data(). In-Reply-To: <1418820925.16656.1.camel@gnutls.org> References: <1418746719-11091-1-git-send-email-jaak.ristioja@cyber.ee> <1418751467.2336.9.camel@gnutls.org> <54916FA6.5060004@cyber.ee> <1418820925.16656.1.camel@gnutls.org> Message-ID: <5493E9D6.2090104@cyber.ee> On 17.12.2014 14:55, Nikos Mavrogiannopoulos wrote: > Thanks. I've applied everything except the 2/4. While allowed in C99, I > prefer to define variables in the beginning of the function. I've also > committed an overflow check in 32-bit systems. In my opinion, commit 8b592bc ("Added 32-bit overflow protection in _gnutls_buffer_append_data()") only fixes some overflows present in _gnutls_buffer_append_data(). These statements may still overflow: size_t const tot_len = data_size + dest->length; size_t const new_len = MAX(data_size, MIN_CHUNK) + MAX(dest->max_length, MIN_CHUNK); Although unlikely on x86_64, they are still an issue. On systems with 32-bit size_t this means that dealing with more than 4GB of data will be an issue. I'm too lazy to lookup the x86_64 ABI, but on my 64-bit Linux machine sizeof(int) is 4 and sizeof(size_t) is 8. Hence we still have a problem with _gnutls_buffer_append_data, because its return type is signed int. This means that the statement return tot_len; will first truncate the 64-bit value of size_t tot_len to a 32-bit signed integer value. And this is probably the issue we painfully bumped into here at Cybernetica. The result of this was that gnutls_record_send() returned an invalid result and caused our application to call gnutls_record_send() again with the same data (in part). Hence GnuTLS buffered some application data twice in the cork buffer. The remote peer, upon receiving this invalid data, noticed an invalid application message header at the next message boundary and threw an exception. Therefore we had to drop support for gnutls_record_cork() and gnutls_record_uncork() because it is still unreliable when buffering more than 2^31-1 bytes of data on 64-bit platforms. Regards, Jaak Ristioja Cybernetica AS From nmav at gnutls.org Fri Dec 19 11:10:15 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 19 Dec 2014 12:10:15 +0200 Subject: [gnutls-devel] [PATCH 1/6] Explicitly marked some variables const in _gnutls_buffer_append_data(). In-Reply-To: <5493E9D6.2090104@cyber.ee> References: <1418746719-11091-1-git-send-email-jaak.ristioja@cyber.ee> <1418751467.2336.9.camel@gnutls.org> <54916FA6.5060004@cyber.ee> <1418820925.16656.1.camel@gnutls.org> <5493E9D6.2090104@cyber.ee> Message-ID: <1418983815.7196.4.camel@gnutls.org> On Fri, 2014-12-19 at 11:03 +0200, Jaak Ristioja wrote: > On 17.12.2014 14:55, Nikos Mavrogiannopoulos wrote: > > Thanks. I've applied everything except the 2/4. While allowed in C99, I > > prefer to define variables in the beginning of the function. I've also > > committed an overflow check in 32-bit systems. > > In my opinion, commit 8b592bc ("Added 32-bit overflow protection in > _gnutls_buffer_append_data()") only fixes some overflows present in > _gnutls_buffer_append_data(). These statements may still overflow: > > size_t const tot_len = data_size + dest->length; > > size_t const new_len = > MAX(data_size, MIN_CHUNK) + MAX(dest->max_length, > MIN_CHUNK); They will, but the check below will detect it and return an error. > Although unlikely on x86_64, they are still an issue. I don't believe it makes sense to even try to detect such long buffers. gnutls_record_send() is not supposed to be used with gigabytes of data, nor petabytes or more. > I'm too lazy to lookup the x86_64 ABI, but on my 64-bit Linux machine > sizeof(int) is 4 and sizeof(size_t) is 8. Hence we still have a problem > with _gnutls_buffer_append_data, because its return type is signed int. > This means that the statement > return tot_len; I've switched it to return 0 (success), instead of the sent data. Its return value was not interpreted by any of its callers. > Therefore we had to drop support for gnutls_record_cork() and > gnutls_record_uncork() because it is still unreliable when buffering > more than 2^31-1 bytes of data on 64-bit platforms. Why would you need to buffer such large amount of data? I don't believe it would speed up much given the small packet size of TLS. regards, Nikos From jaak.ristioja at cyber.ee Fri Dec 19 11:39:28 2014 From: jaak.ristioja at cyber.ee (Jaak Ristioja) Date: Fri, 19 Dec 2014 12:39:28 +0200 Subject: [gnutls-devel] [PATCH 1/6] Explicitly marked some variables const in _gnutls_buffer_append_data(). In-Reply-To: <1418983815.7196.4.camel@gnutls.org> References: <1418746719-11091-1-git-send-email-jaak.ristioja@cyber.ee> <1418751467.2336.9.camel@gnutls.org> <54916FA6.5060004@cyber.ee> <1418820925.16656.1.camel@gnutls.org> <5493E9D6.2090104@cyber.ee> <1418983815.7196.4.camel@gnutls.org> Message-ID: <54940060.6050708@cyber.ee> On 19.12.2014 12:10, Nikos Mavrogiannopoulos wrote: > Why would you need to buffer such large amount of data? I don't believe > it would speed up much given the small packet size of TLS. Well, we don't need to buffer such large amount of data. But we didn't know that GnuTLS buffered ALL the corked data, because the documentation to gnutls_record_cork() used to imply otherwise, i.e: All queued records will be sent when gnutls_uncork() is called, **or when the maximum record size is reached**. (**emphasis** added) Our application was just sending gigabytes of data while GnuTLS was corked. We assumed that GnuTLS would buffer at most the maximum record size number of bytes. Regards, Jaak Ristioja Cybernetica AS From INVALID.NOREPLY at gnu.org Mon Dec 22 19:25:54 2014 From: INVALID.NOREPLY at gnu.org (David Fang) Date: Mon, 22 Dec 2014 18:25:54 +0000 Subject: [gnutls-devel] [sr #108705] test-stdalign assertion fail on powerpc-darwin8, gcc-4.0 In-Reply-To: <20141214-170309.sv66686.31418@savannah.gnu.org> References: <20141214-074901.sv66686.18231@savannah.gnu.org> <20141214-075412.sv66686.74143@savannah.gnu.org> <20141214-122532.sv707.81216@savannah.gnu.org> <20141214-170309.sv66686.31418@savannah.gnu.org> Message-ID: <20141222-182554.sv66686.36608@savannah.gnu.org> Follow-up Comment #4, sr #108705 (project gnutls): Paul Eggert has committed a patch upstream at gnulib. The patch detects old apple gcc and falls back to another case. Hopefully a future release of GNUTLS will pick up that change. You may close this issue. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Mon Dec 22 22:12:45 2014 From: INVALID.NOREPLY at gnu.org (Martin Lambers) Date: Mon, 22 Dec 2014 21:12:45 +0000 Subject: [gnutls-devel] [sr #108689] gnutls_x509_crt_check_hostname() and Internationalized Domain Names In-Reply-To: <20141119-202236.sv38407.51161@savannah.gnu.org> References: <20141119-125024.sv38407.9197@savannah.gnu.org> <20141119-161158.sv707.81265@savannah.gnu.org> <20141119-202236.sv38407.51161@savannah.gnu.org> Message-ID: <20141222-221245.sv38407.7025@savannah.gnu.org> Follow-up Comment #3, sr #108689 (project gnutls): I set up IDN for my mail server, got a new certificate for it, and tested GnuTLS git snapshot from Nov 19 with both msmtp (SMTP client; server is postfix) and mpop (POP3 client; server is dovecot). Works fine :) Thank you very much! I adjusted configure.ac of msmtp/mpop so that libidn is not required anymore when GnuTLS is >= 3.4.0 (and getaddrinfo() has AI_IDN). Best regards, Martin _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Dec 23 12:13:06 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Tue, 23 Dec 2014 11:13:06 +0000 Subject: [gnutls-devel] [sr #108705] test-stdalign assertion fail on powerpc-darwin8, gcc-4.0 In-Reply-To: <20141222-182554.sv66686.36608@savannah.gnu.org> References: <20141214-074901.sv66686.18231@savannah.gnu.org> <20141214-075412.sv66686.74143@savannah.gnu.org> <20141214-122532.sv707.81216@savannah.gnu.org> <20141214-170309.sv66686.31418@savannah.gnu.org> <20141222-182554.sv66686.36608@savannah.gnu.org> Message-ID: <20141223-131306.sv707.83643@savannah.gnu.org> Update of sr #108705 (project gnutls): Status: None => Done Open/Closed: Open => Closed _______________________________________________________ Follow-up Comment #5: Thank you for pursuing that. I'll update gnulib to resolve the issue. _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From git at internot.info Sun Dec 28 03:42:12 2014 From: git at internot.info (Joshua Rogers) Date: Sun, 28 Dec 2014 13:42:12 +1100 Subject: [gnutls-devel] Pointless string comparison Message-ID: <549F6E04.40906@internot.info> Hi, Using the latest git master: In lib/opencdk/keydb.c on line 482-484, what is the point of these tests? They will always evaluate to true.. Should they be removed? Thanks, -- -- Joshua Rogers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Sun Dec 28 10:18:30 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 28 Dec 2014 11:18:30 +0200 Subject: [gnutls-devel] Pointless string comparison In-Reply-To: <549F6E04.40906@internot.info> References: <549F6E04.40906@internot.info> Message-ID: <1419758310.13672.1.camel@gnutls.org> On Sun, 2014-12-28 at 13:42 +1100, Joshua Rogers wrote: > Hi, > Using the latest git master: > > In lib/opencdk/keydb.c on line 482-484, what is the point of these > tests? They will always evaluate to true.. > Should they be removed? That code seems incorrect. I've removed the complete caching feature from openpgp keydbs, as it doesn't seem to be in use or correct. regards, Nikos From ott at mirix.org Tue Dec 30 02:15:02 2014 From: ott at mirix.org (Matthias-Christian Ott) Date: Tue, 30 Dec 2014 02:15:02 +0100 Subject: [gnutls-devel] [PATCH] Don't call _gnutls_cipher_encrypt2 with textlen = 0 in _gnutls_auth_cipher_encrypt2_tag Message-ID: <54A1FC96.5090202@mirix.org> If the plaintext is shorter than the block size of the used cipher, _gnutls_auth_cipher_encrypt2_tag calls _gnutls_cipher_encrypt2 with textlen = 0. By definition _gnutls_cipher_encrypt2 does nothing in this case and thus does not need to be called. --- lib/gnutls_cipher_int.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Don-t-call-_gnutls_cipher_encrypt2-with-textlen-0-in.patch Type: text/x-patch Size: 882 bytes Desc: not available URL: From ott at mirix.org Tue Dec 30 02:14:51 2014 From: ott at mirix.org (Matthias-Christian Ott) Date: Tue, 30 Dec 2014 02:14:51 +0100 Subject: [gnutls-devel] [PATCH] Handle zero length plaintext for VIA PadLock functions Message-ID: <54A1FC8B.9030407@mirix.org> If the plaintext is shorter than the block size of the used cipher, _gnutls_auth_cipher_encrypt2_tag calls _gnutls_cipher_encrypt2 with textlen = 0. padlock_ecb_encrypt and padlock_cbc_encrypt assume that the plaintext length (last parameter) is greater than zero and segfault otherwise. The assembler code for both functions is automatically generated and imported from OpenSSL, so to ease maintenance the length should be validated in the functions that call padlock_ecb_encrypt or padlock_cbc_encrypt. --- lib/accelerated/x86/aes-gcm-padlock.c | 3 ++- lib/accelerated/x86/aes-padlock.c | 6 ++++-- 2 files changed, 6 insertions(+), 3 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Handle-zero-length-plaintext-for-VIA-PadLock-functio.patch Type: text/x-patch Size: 1221 bytes Desc: not available URL: From ott at mirix.org Tue Dec 30 03:21:55 2014 From: ott at mirix.org (Matthias-Christian Ott) Date: Tue, 30 Dec 2014 03:21:55 +0100 Subject: [gnutls-devel] [PATCH] Don't call _gnutls_cipher_encrypt2 with textlen = 0 in _gnutls_auth_cipher_encrypt2_tag In-Reply-To: <54A1FC96.5090202@mirix.org> References: <54A1FC96.5090202@mirix.org> Message-ID: <54A20C43.2070601@mirix.org> On 2014-12-30 02:15, Matthias-Christian Ott wrote: > If the plaintext is shorter than the block size of the used cipher, > _gnutls_auth_cipher_encrypt2_tag calls _gnutls_cipher_encrypt2 with > textlen = 0. By definition _gnutls_cipher_encrypt2 does nothing in this > case and thus does not need to be called. There are more uses of _gnutls_cipher_encrypt2 where textlen could be zero. Probably this needs some more thought and GnuTLS needs to make the contracts between the functions explicit, especially the preconditions. Please review the patch thoroughly. I'm not sure whether it introduces a timing side channel. Regards, Matthias-Christian From ott at mirix.org Tue Dec 30 03:34:03 2014 From: ott at mirix.org (Matthias-Christian Ott) Date: Tue, 30 Dec 2014 03:34:03 +0100 Subject: [gnutls-devel] [PATCH] Handle zero length plaintext for VIA PadLock functions In-Reply-To: <54A1FC8B.9030407@mirix.org> References: <54A1FC8B.9030407@mirix.org> Message-ID: <54A20F1B.2070900@mirix.org> On 2014-12-30 02:14, Matthias-Christian Ott wrote: > > If the plaintext is shorter than the block size of the used cipher, > _gnutls_auth_cipher_encrypt2_tag calls _gnutls_cipher_encrypt2 with > textlen = 0. padlock_ecb_encrypt and padlock_cbc_encrypt assume that the > plaintext length (last parameter) is greater than zero and segfault > otherwise. The assembler code for both functions is automatically > generated and imported from OpenSSL, so to ease maintenance the length > should be validated in the functions that call padlock_ecb_encrypt or > padlock_cbc_encrypt. It should be checked whether the resulting memory corruption is exploitable. The functions execute rep movsl with the src and destination addresses and a huge length that the attacker cannot control. I'll leave the assessment to others. Boundary value analysis and testing or design by contract would have caught this bug. Perhaps it would be a good idea to systematically test GnuTLS (testable functions, proper test suite, systematic test design, coverage metrics) to prevent similar bugs in the future. It took me a day to track this bug down. If there are more a dozen or more of these bugs in GnuTLS, such testing would be worthwhile. Regards, Matthias-Christian From nmav at gnutls.org Tue Dec 30 11:04:04 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 30 Dec 2014 12:04:04 +0200 Subject: [gnutls-devel] [PATCH] Don't call _gnutls_cipher_encrypt2 with textlen = 0 in _gnutls_auth_cipher_encrypt2_tag In-Reply-To: <54A20C43.2070601@mirix.org> References: <54A1FC96.5090202@mirix.org> <54A20C43.2070601@mirix.org> Message-ID: <1419933844.1992.1.camel@gnutls.org> On Tue, 2014-12-30 at 03:21 +0100, Matthias-Christian Ott wrote: > On 2014-12-30 02:15, Matthias-Christian Ott wrote: > > If the plaintext is shorter than the block size of the used cipher, > > _gnutls_auth_cipher_encrypt2_tag calls _gnutls_cipher_encrypt2 with > > textlen = 0. By definition _gnutls_cipher_encrypt2 does nothing in this > > case and thus does not need to be called. > > There are more uses of _gnutls_cipher_encrypt2 where textlen could be > zero. Probably this needs some more thought and GnuTLS needs to make the > contracts between the functions explicit, especially the preconditions. > > Please review the patch thoroughly. I'm not sure whether it introduces a > timing side channel. Patches applied. There is no issue of timing channel in that case, as the ciphertext length will be known in the wire anyway. regards, Nikos From nmav at gnutls.org Tue Dec 30 11:06:12 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 30 Dec 2014 12:06:12 +0200 Subject: [gnutls-devel] [PATCH] Handle zero length plaintext for VIA PadLock functions In-Reply-To: <54A20F1B.2070900@mirix.org> References: <54A1FC8B.9030407@mirix.org> <54A20F1B.2070900@mirix.org> Message-ID: <1419933972.1992.4.camel@gnutls.org> On Tue, 2014-12-30 at 03:34 +0100, Matthias-Christian Ott wrote: > Boundary value analysis and testing or design by contract would have > caught this bug. Perhaps it would be a good idea to systematically test > GnuTLS (testable functions, proper test suite, systematic test design, > coverage metrics) to prevent similar bugs in the future. It took me a > day to track this bug down. If there are more a dozen or more of these > bugs in GnuTLS, such testing would be worthwhile. Thanks. There is an extensive test suite in tests/; if there are tests you believe they should be added, please do add them. Note that the tests are typically run under valgrind but on common CPUs, I have access, prior to release. VIA as such has had less testing. regards, Nikos From INVALID.NOREPLY at gnu.org Tue Dec 30 15:12:07 2014 From: INVALID.NOREPLY at gnu.org (Andreas Schultz) Date: Tue, 30 Dec 2014 14:12:07 +0000 Subject: [gnutls-devel] [sr #108712] mutiple DTLS records in one UDP packet not handled correctly Message-ID: <20141230-141206.sv97952.32759@savannah.gnu.org> URL: Summary: mutiple DTLS records in one UDP packet not handled correctly Project: GnuTLS Submitted by: roadrunnr Submitted on: Tue 30 Dec 2014 02:12:06 PM GMT Category: Core library Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: GNU/Linux _______________________________________________________ Details: under some very special circumstance, gnutls_handshake does return E_AGAIN even when there are pending DTLS records in the buffer. I have a CAPWAP DTLS client in GNUTLS_NONBLOCK mode, talking to a server that insists to fragment it's packets to about 544 bytes (before CAPWAP encapsulation). This leads to a server handshake where the last datagram caries three DTLS records (a Certificate Fragment, a Certificate Request and the Server Hello Done). gnutls_handshake call's the pull func, get the full datagram, handls the Certificate Fragment, reassembles the full certificate chain and then return GNUTLS_E_AGAIN. The rest of the datagram is left in the internal buffer and handled on the next call to gnutls_handshake. For the application there is no indication that it should or has to call gnutls_handshake again. It's internal buffer was emptied by the pull func, no more data will arrive and GNUTLS_E_AGAIN means "wait for more data". Relevant lines from the debug log: Dec 30 14:44:57.475 capwap-mitm.c:710:dtls_pull_func: 0x15e2810: DTLS pull of size 16732 ^^^^ pull empties the application buffer gnutls[10]: READ: Got 251 bytes from 0x15e2810 gnutls[10]: READ: read 251 bytes from 0x15e2810 gnutls[10]: RB: have 0 bytes into buffer. Adding 251 bytes. ^^^^ gets the 251 bytes from the last datagram gnutls[10]: RB: Requested 13 bytes gnutls[5]: REC[0x160b170]: SSL 254.255 Handshake packet received. Epoch 0, length: 145 gnutls[5]: REC[0x160b170]: Expected Packet Handshake(22) gnutls[5]: REC[0x160b170]: Received Packet Handshake(22) with length: 145 gnutls[5]: REC[0x160b170]: Decrypted Packet[0.7] Handshake(22) with length: 145 ^^^^ process the Certificate Fragemtent 158 Bytes (145 + 13 Bytes header) gnutls[4]: HSK[0x160b170]: CERTIFICATE (11) was received. Length 2645[133], frag offset 2500, frag length: 133, sequence: 2 gnutls[3]: ASSERT: gnutls_buffers.c:1111 gnutls[3]: ASSERT: gnutls_kx.c:630 ^^^^ from here one, nothing happens on this session, gnutls_handshake returns GNUTLS_E_AGAIN and the remaining bytes in the buffer are ignored. I believe gnutls_handshake should continue to process the records in the buffer. Full debug log and sample DTLS pcap attached (needs up to date wireshark do decode properly), full DTLS application can be found at http://github.com/travelping/capwap-mitm _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Tue 30 Dec 2014 02:12:06 PM GMT Name: capwap-dtls-handshake.pcapng Size: 4kB By: roadrunnr ------------------------------------------------------- Date: Tue 30 Dec 2014 02:12:06 PM GMT Name: capwap-dtls-handshake.log Size: 47kB By: roadrunnr _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Tue Dec 30 21:58:03 2014 From: INVALID.NOREPLY at gnu.org (Rumko) Date: Tue, 30 Dec 2014 20:58:03 +0000 Subject: [gnutls-devel] [sr #108713] lib/x509/rfc2818_hostname.c: in6_addr incomplete type on at least FreeBSD 10.1 Message-ID: <20141230-215802.sv97958.61740@savannah.gnu.org> URL: Summary: lib/x509/rfc2818_hostname.c: in6_addr incomplete type on at least FreeBSD 10.1 Project: GnuTLS Submitted by: rumko Submitted on: Tue 30 Dec 2014 09:58:02 PM CET Category: Core library Priority: 5 - Normal Severity: 3 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any Operating System: *BSD _______________________________________________________ Details: Out of the box, one cannot compile gnutls on at least FreeBSD 10.1 due to structs in6_addr being an incomplete type. The problem is in lib/system.h, which includes arpa/inet.h that does not contain ipv6 related structs (also according to http://pubs.opengroup.org/onlinepubs/009695399/basedefs/arpa/inet.h.html). By including netinet/in.h, the problem is fixed, since it also contains ipv6 related data structures (also according to http://pubs.opengroup.org/onlinepubs/009695399/basedefs/netinet/in.h.html). The attached patch make system.h include netinet/in.h on systems that have it (detected using HAVE_NETINET_IN_H). _______________________________________________________ File Attachments: ------------------------------------------------------- Date: Tue 30 Dec 2014 09:58:02 PM CET Name: patch-lib_system.h Size: 420B By: rumko _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ From INVALID.NOREPLY at gnu.org Wed Dec 31 08:42:01 2014 From: INVALID.NOREPLY at gnu.org (Nikos Mavrogiannopoulos) Date: Wed, 31 Dec 2014 07:42:01 +0000 Subject: [gnutls-devel] [sr #108713] lib/x509/rfc2818_hostname.c: in6_addr incomplete type on at least FreeBSD 10.1 In-Reply-To: <20141230-215802.sv97958.61740@savannah.gnu.org> References: <20141230-215802.sv97958.61740@savannah.gnu.org> Message-ID: <20141231-094201.sv707.67097@savannah.gnu.org> Update of sr #108713 (project gnutls): Status: None => Done Open/Closed: Open => Closed _______________________________________________________ Follow-up Comment #1: Thanks, I've applied a similar patch at: https://gitorious.org/gnutls/gnutls/commit/f46b12dba883960c2b51909f362243ccb56fccec _______________________________________________________ Reply to this item at: _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/