From nmav at gnutls.org Sat Aug 1 10:43:49 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 01 Aug 2015 10:43:49 +0200 Subject: [gnutls-devel] rc4 in gnutls 3.3.x Message-ID: <1438418629.5179.7.camel@gnutls.org> In the latest releases of gnutls (3.4.x) the rc4 (arcfour) cipher is already disabled. That change was not propagated to 3.3.x release to keep applications working as expected. However, given the the new biases found in that cipher I tend to believe that it is more harm done by keeping rc4 in the default priorities than good. Are there any objections to dropping rc4 in one of the next 3.3.x point releases from the default priorities? regards, Nikos From alessandro at ghedini.me Sat Aug 1 14:40:04 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Sat, 1 Aug 2015 14:40:04 +0200 Subject: [gnutls-devel] DCO Message-ID: <20150801124003.GA7010@kronk.local> Hello, here's my DCO: --- 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. --- Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nmav at gnutls.org Mon Aug 10 09:08:36 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 10 Aug 2015 09:08:36 +0200 Subject: [gnutls-devel] gnutls 3.4.4 Message-ID: <1439190516.1717.1.camel@gnutls.org> Hello, I've just released gnutls 3.4.4. This version fixes bugs and adds minor features to the next stable branch. * Version 3.4.4 (released 2015-08-10) ** libgnutls: added high level API (gnutls_prf_rfc5705) to access the PRF as specified by RFC5705. Suggestion and original patch by Rick van Rein. ** libgnutls: Link to trousers (TPM library) dynamically when this functionality is requested. ** libgnutls: Fix issue with server side sending the status request extension even when not requested. Reported by Jeremy Harris. ** libgnutls: Added support for RFC7507 by introducing the %FALLBACK_SCSV priority string option. Patch by Alessandro Ghedini. ** libgnutls: gnutls_pkcs11_privkey_generate2() will store the generated public key, unless the GNUTLS_PKCS11_OBJ_FLAG_NO_STORE_PUBKEY flag is specified. ** libgnutls: Corrected regression from 3.4.3 in loading PKCS #8 keys as fallback. Reported by Daniel Berrange. ** libgnutls: Allow the parsing of very long DNs. Also fixes double free in DN decoding [GNUTLS-SA-2015-3]. ** API and ABI modifications: gnutls_prf_rfc5705: Added gnutls_hex_encode2: Added gnutls_hex_decode2: Added Getting the Software ==================== GnuTLS may be downloaded directly from .??A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.4.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.4.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.4.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.4.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 Mon Aug 10 09:09:53 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 10 Aug 2015 09:09:53 +0200 Subject: [gnutls-devel] gnutls 3.3.17 Message-ID: <1439190593.1717.2.camel@gnutls.org> Hello, I've just released gnutls 3.3.17. This is a bug-fix release on the current stable branch. * Version 3.3.17 (released 2015-08-10) ** libgnutls: Fix issue with server side sending the status request extension even when not requested. Reported by Jeremy Harris. ** libgnutls: gnutls_pkcs11_privkey_generate2() will store the generated public key, unless the GNUTLS_PKCS11_OBJ_FLAG_NO_STORE_PUBKEY flag is specified. ** libgnutls: fixed double free in DN decoding [GNUTLS-SA-2015-3]. ** 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.17.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.17.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.17.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.17.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Mon Aug 10 16:11:14 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 10 Aug 2015 16:11:14 +0200 Subject: [gnutls-devel] gnutls 3.3.17 In-Reply-To: References: <1439190593.1717.2.camel@gnutls.org> Message-ID: On Mon, Aug 10, 2015 at 2:50 PM, Marius Schamschula wrote: > Nikos, > I?m not sure what happened between gnutls 3.3.16 and 3.3.17 to cause the > following errors: (seen under OS X 10.10.4, Note: I am passing > --enable-local-libopts which is supposed to prevent this issue. Also tried > building w/o autoconf with same result) > In file included from In file included from srptool-args.c:43: > ./srptool-args.h:61:3: error: option template version mismatches > autoopts/options.h header > # error option template version mismatches autoopts/options.h header That's a libopts issue. When the auto-generated files from autogen are regenerated using a newer autogen, the included libopts library is automatically invalidated. The check in libopts is for any version (major, minor or even patch - as in that case). A work-around would be to regenerate the autogen files locally with autogen 5.18.4 to make --enable-local-libopts work. I'd have to add some check for autogen/included libopts match to prevent this from happening again. regards, Nikos From wiz at NetBSD.org Mon Aug 10 15:53:52 2015 From: wiz at NetBSD.org (Thomas Klausner) Date: Mon, 10 Aug 2015 15:53:52 +0200 Subject: [gnutls-devel] gnutls-3.3.17: compilation error due to autoopts Message-ID: <20150810135352.GI7408@danbala.tuwien.ac.at> Hi! I just tried compiling gnutls-3.3.17 on NetBSD-7.99.20/amd64. It failed with In file included from certtool-args.c:43:0: certtool-args.h:61:3: error: #error option template version mismatches autoopts/options.h header # error option template version mismatches autoopts/options.h header ^ certtool-args.h:62:3: error: unknown type name 'Choke' Choke Me. ^ certtool-args.h:62:11: error: expected '=', ',', ';', 'asm' or '__attribute__' before '.' token Choke Me. ^ The header at this point looks like this: /** * Ensure that the library used for compiling this generated header is at * least as new as the version current when the header template was released * (not counting patch version increments). Also ensure that the oldest * tolerable version is at least as old as what was current when the header * template was released. */ #define AO_TEMPLATE_VERSION 167937 #if (AO_TEMPLATE_VERSION < OPTIONS_MINIMUM_VERSION) \ || (AO_TEMPLATE_VERSION > OPTIONS_STRUCT_VERSION) # error option template version mismatches autoopts/options.h header Choke Me. #endif grepping for the symbols gives me: gnutls-3.3.17/src/libopts/autoopts/options.h.orig:#define OPTIONS_MINIMUM_VERSION 102400 gnutls-3.3.17/src/libopts/autoopts/options.h:#define OPTIONS_STRUCT_VERSION 167936 So it looks like the included is not new enough. Thomas From lists at schamschula.com Mon Aug 10 17:39:50 2015 From: lists at schamschula.com (Marius Schamschula) Date: Mon, 10 Aug 2015 10:39:50 -0500 Subject: [gnutls-devel] gnutls 3.3.17 In-Reply-To: References: <1439190593.1717.2.camel@gnutls.org> Message-ID: <37B1ACD2-A959-4398-B2DD-91E96295E7CA@schamschula.com> Nikos, Two notes: 1) Installing autogen 5.18.4 made no difference 2) I see the identical error with gnutls 3.4.4 On Aug 10, 2015, at 9:11 AM, Nikos Mavrogiannopoulos wrote: > On Mon, Aug 10, 2015 at 2:50 PM, Marius Schamschula > wrote: >> Nikos, >> I?m not sure what happened between gnutls 3.3.16 and 3.3.17 to cause the >> following errors: (seen under OS X 10.10.4, Note: I am passing >> --enable-local-libopts which is supposed to prevent this issue. Also tried >> building w/o autoconf with same result) >> In file included from In file included from srptool-args.c:43: >> ./srptool-args.h:61:3: error: option template version mismatches >> autoopts/options.h header >> # error option template version mismatches autoopts/options.h header > > That's a libopts issue. When the auto-generated files from autogen are > regenerated > using a newer autogen, the included libopts library is automatically > invalidated. The check > in libopts is for any version (major, minor or even patch - as in that case). > > A work-around would be to regenerate the autogen files locally with > autogen 5.18.4 to make --enable-local-libopts work. > > I'd have to add some check for autogen/included libopts match to > prevent this from happening again. > > regards, > Nikos Marius -- Marius Schamschula From nmav at gnutls.org Mon Aug 10 19:56:47 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 10 Aug 2015 19:56:47 +0200 Subject: [gnutls-devel] gnutls 3.3.17 In-Reply-To: <37B1ACD2-A959-4398-B2DD-91E96295E7CA@schamschula.com> References: <1439190593.1717.2.camel@gnutls.org> <37B1ACD2-A959-4398-B2DD-91E96295E7CA@schamschula.com> Message-ID: <1439229407.12310.1.camel@gnutls.org> On Mon, 2015-08-10 at 10:39 -0500, Marius Schamschula wrote: > Nikos, > > Two notes: > > 1) Installing autogen 5.18.4 made no difference You'd need to auto-generate the files. Using touch src/*.def makes the trick on my system. I've just made released 3.3.17.1 and 3.4.4.1 which include the correct auto-generated files for --enable-local-libopts to work. regards, Nikos From lists at schamschula.com Mon Aug 10 20:35:18 2015 From: lists at schamschula.com (Marius Schamschula) Date: Mon, 10 Aug 2015 13:35:18 -0500 Subject: [gnutls-devel] gnutls 3.3.17 In-Reply-To: <1439229407.12310.1.camel@gnutls.org> References: <1439190593.1717.2.camel@gnutls.org> <37B1ACD2-A959-4398-B2DD-91E96295E7CA@schamschula.com> <1439229407.12310.1.camel@gnutls.org> Message-ID: Nikos, Thanks for the quick turn around! Both gnutls 3.3.17.1 and 3.4.4.1 build cleanly. On Aug 10, 2015, at 12:56 PM, Nikos Mavrogiannopoulos wrote: > On Mon, 2015-08-10 at 10:39 -0500, Marius Schamschula wrote: >> Nikos, >> >> Two notes: >> >> 1) Installing autogen 5.18.4 made no difference > > You'd need to auto-generate the files. Using touch src/*.def makes the > trick on my system. > > I've just made released 3.3.17.1 and 3.4.4.1 which include the correct > auto-generated files for --enable-local-libopts to work. > > regards, > Nikos > Marius -- Marius Schamschula From max.bruce12 at gmail.com Tue Aug 11 02:02:19 2015 From: max.bruce12 at gmail.com (Max Bruce) Date: Mon, 10 Aug 2015 17:02:19 -0700 Subject: [gnutls-devel] [gnutls-help] gnutls 3.3.17 In-Reply-To: <1439229407.12310.1.camel@gnutls.org> References: <1439190593.1717.2.camel@gnutls.org> <37B1ACD2-A959-4398-B2DD-91E96295E7CA@schamschula.com> <1439229407.12310.1.camel@gnutls.org> Message-ID: I'm running into this issue on version 4.3, I removed both autogen(turns out I never had it), libopts25, and libopts25-dev (mint/ubuntu) from my system after trying various configurations to get it to compile. I also tried: ./configure --enable-local-libopts but that didn't seem to change anything. I tried doing the touch src/*.def in the main gnutls directory, no change. On Mon, Aug 10, 2015 at 10:56 AM, Nikos Mavrogiannopoulos wrote: > On Mon, 2015-08-10 at 10:39 -0500, Marius Schamschula wrote: > > Nikos, > > > > Two notes: > > > > 1) Installing autogen 5.18.4 made no difference > > You'd need to auto-generate the files. Using touch src/*.def makes the > trick on my system. > > I've just made released 3.3.17.1 and 3.4.4.1 which include the correct > auto-generated files for --enable-local-libopts to work. > > regards, > Nikos > > > _______________________________________________ > Gnutls-help mailing list > Gnutls-help at lists.gnutls.org > http://lists.gnupg.org/mailman/listinfo/gnutls-help > -- Thanks, Max Bruce www.avuna.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.bruce12 at gmail.com Tue Aug 11 02:09:47 2015 From: max.bruce12 at gmail.com (Max Bruce) Date: Mon, 10 Aug 2015 17:09:47 -0700 Subject: [gnutls-devel] [gnutls-help] gnutls 3.3.17 In-Reply-To: References: <1439190593.1717.2.camel@gnutls.org> <37B1ACD2-A959-4398-B2DD-91E96295E7CA@schamschula.com> <1439229407.12310.1.camel@gnutls.org> Message-ID: Version 3.4.4* On Mon, Aug 10, 2015 at 5:02 PM, Max Bruce wrote: > I'm running into this issue on version 4.3, I removed both autogen(turns > out I never had it), libopts25, and libopts25-dev (mint/ubuntu) from my > system after trying various configurations to get it to compile. I also > tried: > ./configure --enable-local-libopts > but that didn't seem to change anything. I tried doing the touch src/*.def > in the main gnutls directory, no change. > > > On Mon, Aug 10, 2015 at 10:56 AM, Nikos Mavrogiannopoulos > wrote: > >> On Mon, 2015-08-10 at 10:39 -0500, Marius Schamschula wrote: >> > Nikos, >> > >> > Two notes: >> > >> > 1) Installing autogen 5.18.4 made no difference >> >> You'd need to auto-generate the files. Using touch src/*.def makes the >> trick on my system. >> >> I've just made released 3.3.17.1 and 3.4.4.1 which include the correct >> auto-generated files for --enable-local-libopts to work. >> >> regards, >> Nikos >> >> >> _______________________________________________ >> Gnutls-help mailing list >> Gnutls-help at lists.gnutls.org >> http://lists.gnupg.org/mailman/listinfo/gnutls-help >> > > > > -- > Thanks, > Max Bruce > www.avuna.org > -- Thanks, Max Bruce www.avuna.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From balducci at units.it Tue Aug 11 13:03:32 2015 From: balducci at units.it (balducci at units.it) Date: Tue, 11 Aug 2015 13:03:32 +0200 Subject: [gnutls-devel] gnutls-3.3.17: compilation error due to autoopts Message-ID: <1731.1439291036@dschgrazlin2.units.it> hello, same here, with both 3.3.17 and 3.4.4 System is: Linux dschgrazlin2 4.1.3 #1 SMP Wed Jul 22 13:20:40 CEST 2015 x86_64 GNU/Linux ciao gabriele From zsolt.horvath at skype.net Wed Aug 12 18:32:44 2015 From: zsolt.horvath at skype.net (Zsolt Horvath) Date: Wed, 12 Aug 2015 16:32:44 +0000 Subject: [gnutls-devel] Revoked certificate count in CRL is capped at 34 Message-ID: <5fa72c9497464b4db12b586d3688a83b@AM3PR30MB049.064d.mgd.msft.net> Dear Team, I am working on a small project where I'm planning to do periodic CRL generation with GNUTLS from concatenated to-be-revoked-certificates. The CRL is generated as per the guide: certtool --generate-crl --load-ca-privkey $CAPRIVKEY \ --load-ca-certificate $CACERT \ --load-certificate syssec-int.pem \ --template infosec-vpn-int.cfg \ --d 900 The template is really simple: # Options for generating a CRL # next CRL update will be in 43 days crl_next_update = 43 # this is the 7th CRL by this CA crl_number = 7 When running the command this is what I see in the debug: Setting log level to 900 Generating a signed CRL... Loading certificate list... |<2>| ASSERT: x509_b64.c:485 |<2>| ASSERT: x509_b64.c:453 |<2>| Could not find '-----BEGIN X509 CERTIFICATE' |<2>| ASSERT: x509.c:200 Loaded 34 certificates. Update times. |<2>| ASSERT: dn.c:305 |<2>| ASSERT: crl.c:789 X.509 Certificate Revocation List Information: Version: 2 Issuer: Update dates: Issued: Wed Aug 12 15:39:16 UTC 2015 Next at: Thu Sep 24 15:39:16 UTC 2015 Extensions: Authority Key Identifier (not critical): 655c2d73509da33031986648e57d47df78319aa9 CRL Number (not critical): 07 Revoked certificates (34): However: certtool -i --infile syssec-int.pem | grep -i subject: | wc -l 329 Using stock certtool on Debian Wheezy: certtool (GnuTLS) 2.12.20 Packaged by Debian (2.12.20-8+deb7u3) And on Debian Jessie: certtool 3.3.8 I know the Debian supplied versions are always lagging behind, but I haven't seen any open/fixed bugs with this issue. One thing that might be important to mention is that the certificates have been issued by openssl originally, but as the debug doesn't say anything if it had problems with the formatting or anything I assume this is not a problem. Also, as far as I learned, there should be no reason of any capping, as I read there could be CRLs with size reaching several MBs so I am suspecting that there is either a bug with files having too many certs in them or something is missing from the documentation. Looking forward to hearing from you, Zsolt -- Zsolt Horvath Systems Security Analyst CCIE#23475 (Security, R&S); CCDP Skype see & chat: koma931 write: zsolt.horvath at skype.net speak: +44 7814 144424 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Wed Aug 12 23:02:42 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 12 Aug 2015 23:02:42 +0200 Subject: [gnutls-devel] Revoked certificate count in CRL is capped at 34 In-Reply-To: <5fa72c9497464b4db12b586d3688a83b@AM3PR30MB049.064d.mgd.msft.net> References: <5fa72c9497464b4db12b586d3688a83b@AM3PR30MB049.064d.mgd.msft.net> Message-ID: <1439413362.4578.3.camel@gnutls.org> On Wed, 2015-08-12 at 16:32 +0000, Zsolt Horvath wrote: > Dear Team, > > I am working on a small project where I?m planning to do periodic CRL > generation with GNUTLS from concatenated to-be-revoked-certificates. > The CRL is generated as per the guide: > > certtool --generate-crl --load-ca-privkey $CAPRIVKEY \ > --load-ca-certificate $CACERT \ > --load-certificate syssec-int.pem \ > --template infosec-vpn-int.cfg \ > --d 900 Hello, Thanks for bringing that up. It seems that certain commands of certtool are limited in the amount of buffers they may use. In particular the buffers are correctly adjusted only for the options that use the --infile option. Even in that case it seems that some options are have also other arbitrary maximum limits. Maybe it is time to remove those limits completely. I don't know how helpful it would be for you, but I'll have a patch for 3.4.x soon. regards, Nikos -------------- next part -------------- An HTML attachment was scrubbed... URL: From zsolt.horvath at skype.net Thu Aug 13 11:07:19 2015 From: zsolt.horvath at skype.net (Zsolt Horvath) Date: Thu, 13 Aug 2015 09:07:19 +0000 Subject: [gnutls-devel] Revoked certificate count in CRL is capped at 34 In-Reply-To: <1439413362.4578.3.camel@gnutls.org> References: <5fa72c9497464b4db12b586d3688a83b@AM3PR30MB049.064d.mgd.msft.net> <1439413362.4578.3.camel@gnutls.org> Message-ID: <842aab7426b2407d8f1bd969e51b12ee@DB4PR30MB062.064d.mgd.msft.net> Hi Nikos, Thanks for the prompt reply, really appreciate your looking into this. Is there another way to create CRLs with certtool then that wouldn?t require revoking all certs at once? Somehow taking an existing CRL as base and add only a handful certs each time? I think that would be a good feature request as today when generating a new CRL, all serial-numbers appear as if they got revoked at the same time. If you got the patch let me know, I would be interested to try it out. Thanks again, Zsolt -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Thu Aug 13 11:32:25 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 13 Aug 2015 11:32:25 +0200 Subject: [gnutls-devel] Revoked certificate count in CRL is capped at 34 In-Reply-To: <842aab7426b2407d8f1bd969e51b12ee@DB4PR30MB062.064d.mgd.msft.net> References: <5fa72c9497464b4db12b586d3688a83b@AM3PR30MB049.064d.mgd.msft.net> <1439413362.4578.3.camel@gnutls.org> <842aab7426b2407d8f1bd969e51b12ee@DB4PR30MB062.064d.mgd.msft.net> Message-ID: On Thu, Aug 13, 2015 at 11:07 AM, Zsolt Horvath wrote: > Hi Nikos, > Thanks for the prompt reply, really appreciate your looking into this. > Is there another way to create CRLs with certtool then that wouldn?t require > revoking all certs at once? Somehow taking an existing CRL as base and add > only a handful certs each time? Not that I know of. certtool is very primitive in CRL handling. But that allows for a nice optimization though. --generate-crl could use the --load-crl if set and use that as base for the new CRL to be generated. The patch set for 3.4 is at: https://gitlab.com/gnutls/gnutls/compare/50244178cd47f01aa9f3b65c082a992166d140ca...ece060599637990bbaef132f4104d1bd53fb656c regards, Nikos From mancha1 at zoho.com Fri Aug 14 06:55:25 2015 From: mancha1 at zoho.com (mancha) Date: Fri, 14 Aug 2015 04:55:25 +0000 Subject: [gnutls-devel] gnutls-3.3.17: compilation error due to autoopts In-Reply-To: <20150810135352.GI7408@danbala.tuwien.ac.at> References: <20150810135352.GI7408@danbala.tuwien.ac.at> Message-ID: <20150814045525.GA26729@zoho.com> On Mon, Aug 10, 2015 at 03:53:52PM +0200, Thomas Klausner wrote: > Hi! > > I just tried compiling gnutls-3.3.17 on NetBSD-7.99.20/amd64. > > It failed with > > In file included from certtool-args.c:43:0: certtool-args.h:61:3: > error: #error option template version mismatches autoopts/options.h > header # error option template version mismatches autoopts/options.h > header ^ certtool-args.h:62:3: error: unknown type name 'Choke' Choke > Me. ^ certtool-args.h:62:11: error: expected '=', ',', ';', 'asm' or > '__attribute__' before '.' token Choke Me. Hi. The issue is the bundled autogen'd files (src/*.bak) were generated using autogen-5.18.5 while the bundled autoopts is from autogen-5.18.4. Nikos, this problem is happening often (I recently had to fix the same thing on 3.1.28). It might be easiest to bundle the same libopts version in all releases and make sure the autogen where you build the .bak files matches. Thomas, as for a fix, you can install autogen 5.18.5 and have GnuTLS 3.3.17 use that to autogen some of its files instead of using the bundled .bak files or you might get away with: sed -i -e 's|#define AO_TEMPLATE_VERSION 167937|#define AO_TEMPLATE_VERSION 167936|' certtool-args.h.bak cli-args.h.bak cli-debug-args.h.bak danetool-args.h.bak ocsptool-args.h.bak p11tool-args.h.bak psktool-args.h.bak serv-args.h.bak srptool-args.h.bak tpmtool-args.h.bak --mancha (https://twitter.com/mancha140) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From nmav at gnutls.org Fri Aug 14 09:58:59 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 14 Aug 2015 09:58:59 +0200 Subject: [gnutls-devel] gnutls-3.3.17: compilation error due to autoopts In-Reply-To: <20150814045525.GA26729@zoho.com> References: <20150810135352.GI7408@danbala.tuwien.ac.at> <20150814045525.GA26729@zoho.com> Message-ID: On Fri, Aug 14, 2015 at 6:55 AM, mancha wrote: >> In file included from certtool-args.c:43:0: certtool-args.h:61:3: >> error: #error option template version mismatches autoopts/options.h >> header # error option template version mismatches autoopts/options.h >> header ^ certtool-args.h:62:3: error: unknown type name 'Choke' Choke >> Me. ^ certtool-args.h:62:11: error: expected '=', ',', ';', 'asm' or >> '__attribute__' before '.' token Choke Me. > Hi. The issue is the bundled autogen'd files (src/*.bak) were generated > using autogen-5.18.5 while the bundled autoopts is from autogen-5.18.4. > Nikos, this problem is happening often (I recently had to fix the same > thing on 3.1.28). It might be easiest to bundle the same libopts version > in all releases and make sure the autogen where you build the .bak files > matches. That's much easier said than done. Autogen is often updated on my systems without me realizing it. I've now added hooks to prevent a release if there is a mismatch. > Thomas, as for a fix, you can install autogen 5.18.5 and have GnuTLS > 3.3.17 use that to autogen some of its files instead of using the > bundled .bak files or you might get away with: You can also try 3.3.17.1 and 3.4.4.1 which fix the issue. regards, Nikos From wiz at netbsd.org Fri Aug 14 13:49:18 2015 From: wiz at netbsd.org (Thomas Klausner) Date: Fri, 14 Aug 2015 13:49:18 +0200 Subject: [gnutls-devel] gnutls-3.3.17: compilation error due to autoopts In-Reply-To: References: <20150810135352.GI7408@danbala.tuwien.ac.at> <20150814045525.GA26729@zoho.com> Message-ID: <20150814114918.GD9560@danbala.tuwien.ac.at> On Fri, Aug 14, 2015 at 09:58:59AM +0200, Nikos Mavrogiannopoulos wrote: > You can also try 3.3.17.1 and 3.4.4.1 which fix the issue. Thank you, 3.3.17.1 works fine for me. Thomas From mancha1 at zoho.com Fri Aug 14 13:53:37 2015 From: mancha1 at zoho.com (mancha) Date: Fri, 14 Aug 2015 11:53:37 +0000 Subject: [gnutls-devel] gnutls-3.3.17: compilation error due to autoopts In-Reply-To: References: <20150810135352.GI7408@danbala.tuwien.ac.at> <20150814045525.GA26729@zoho.com> Message-ID: <20150814115337.GC26729@zoho.com> On Fri, Aug 14, 2015 at 09:58:59AM +0200, Nikos Mavrogiannopoulos wrote: > On Fri, Aug 14, 2015 at 6:55 AM, mancha wrote: > > >> In file included from certtool-args.c:43:0: certtool-args.h:61:3: > >> error: #error option template version mismatches autoopts/options.h > >> header # error option template version mismatches > >> autoopts/options.h header ^ certtool-args.h:62:3: error: unknown > >> type name 'Choke' Choke Me. ^ certtool-args.h:62:11: error: > >> expected '=', ',', ';', 'asm' or '__attribute__' before '.' token > >> Choke Me. > > > > Hi. The issue is the bundled autogen'd files (src/*.bak) were > > generated using autogen-5.18.5 while the bundled autoopts is from > > autogen-5.18.4. Nikos, this problem is happening often (I recently > > had to fix the same thing on 3.1.28). It might be easiest to bundle > > the same libopts version in all releases and make sure the autogen > > where you build the .bak files matches. > > That's much easier said than done. Autogen is often updated on my > systems without me realizing it. I've now added hooks to prevent a > release if there is a mismatch. Can't be that tough. > > Thomas, as for a fix, you can install autogen 5.18.5 and have GnuTLS > > 3.3.17 use that to autogen some of its files instead of using the > > bundled .bak files or you might get away with: > > You can also try 3.3.17.1 and 3.4.4.1 which fix the issue. Aha, great news. Many thanks. --mancha (https://twitter.com/mancha140) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kurt at roeckx.be Sat Aug 15 13:14:33 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 15 Aug 2015 13:14:33 +0200 Subject: [gnutls-devel] certificate I can't import Message-ID: <20150815111432.GA14273@roeckx.be> Hi, I didn't have time yet to look into this myself, but I have a bunch of certificates I can't import it with gnutls_x509_crt_import(). I can perfectly read them with openssl and can't see anything obvious wrong with them at a first look. Can someone look at this? I've attached an example. Kurt -------------- next part -------------- -----BEGIN CERTIFICATE----- MIIDOTCCAqKgAwIBAgIQP+NIaRujro1AbFbekJs2xTANBgkqhkiG9w0BAQEFADB5MQswCQYDVQQG EwJERTEOMAwGA1UECAwFQnllcm4xETAPBgNVBAcMCE3DvG5jaGVuMRUwEwYDVQQKDAxDb21waWxp b24gQUcxCzAJBgNVBAsMAklUMSMwIQYDVQQDDBpleGNoYW5nZTIwMTAuY29tcGlsaW9uLm5ldDAe Fw0xNTAzMDMxMzExNTNaFw0xNjAzMDMxMzMxNTNaMHkxCzAJBgNVBAYTAkRFMQ4wDAYDVQQIDAVC eWVybjERMA8GA1UEBwwITcO8bmNoZW4xFTATBgNVBAoMDENvbXBpbGlvbiBBRzELMAkGA1UECwwC SVQxIzAhBgNVBAMMGmV4Y2hhbmdlMjAxMC5jb21waWxpb24ubmV0MIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQCV0RAZQimoiAWZeU8IF52S9CgUjNOIONqGOLuDfBkDRlWGY13+QC1upIcfx3IJ 2+A9ga07vs4pMlXHTZspJhMkatL1Nq4WbP+IBM0EuuLcmB3gjm29Iit2sCgrsXZmQD1QlxVqrHfh CBwVMwBCQKfEw1A5MTI0UBQ+4aE5TjUnewIDAQABo4HBMIG+MA4GA1UdDwEB/wQEAwIE8DATBgNV HSUEDDAKBggrBgEFBQcDATB4BgkqhkiG9w0BCQ8EazBpMA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG 9w0DBAICAIAwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBLTALBglghkgBZQMEAQIwCwYJYIZIAWUD BAEFMAcGBSsOAwIHMAoGCCqGSIb3DQMHMB0GA1UdDgQWBBTmErn/GxJWh8kNok9Pk6JI+WG2AjAN BgkqhkiG9w0BAQUFAAOBgQB5uPqhPw5YfRnjD9bHMalT9YNet/PrSLB8R3vEqPnntlHcbMc6z1du OmGb9g4j/U3NGAiHE6iMhAVrYb9qvxcQ6uruV3ep/xR8XGNlZL8uXx9YuGz0mYc/bZb/1lZPuNxD ggFKJw5Lodm3DtBJ9K8Cbu22+QGxxiV+or1GekaeNQ== -----END CERTIFICATE----- From ametzler at bebt.de Sat Aug 15 14:28:09 2015 From: ametzler at bebt.de (Andreas Metzler) Date: Sat, 15 Aug 2015 14:28:09 +0200 Subject: [gnutls-devel] certificate I can't import In-Reply-To: <20150815111432.GA14273@roeckx.be> References: <20150815111432.GA14273@roeckx.be> Message-ID: <20150815122809.GB2319@downhill.g.la> On 2015-08-15 Kurt Roeckx wrote: > I didn't have time yet to look into this myself, but I have a > bunch of certificates I can't import it with > gnutls_x509_crt_import(). I can perfectly read them with openssl > and can't see anything obvious wrong with them at a first look. > Can someone look at this? I've attached an example. [...] Hello, ametzler at argenau:/tmp$ certtool --infile=/tmp/fail.pem -i --debug=4711 Setting log level to 4711 |<2>| Unknown SIGN OID: '1.2.840.113549.1.1.1' |<2>| signatureAlgorithm.algorithm differs from tbsCertificate.signature.algorithm: RSA-SHA1, (null) 1.2.840.113549.1.1.1 is "rsaEncryption", I *guess* that is not a valid signature algoritm, it should read somethigng like sha1WithRSAEncryption. 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 kurt at roeckx.be Sat Aug 15 15:08:25 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 15 Aug 2015 15:08:25 +0200 Subject: [gnutls-devel] certificate I can't import In-Reply-To: <20150815122809.GB2319@downhill.g.la> References: <20150815111432.GA14273@roeckx.be> <20150815122809.GB2319@downhill.g.la> Message-ID: <20150815130825.GA16125@roeckx.be> On Sat, Aug 15, 2015 at 02:28:09PM +0200, Andreas Metzler wrote: > On 2015-08-15 Kurt Roeckx wrote: > > I didn't have time yet to look into this myself, but I have a > > bunch of certificates I can't import it with > > gnutls_x509_crt_import(). I can perfectly read them with openssl > > and can't see anything obvious wrong with them at a first look. > > Can someone look at this? I've attached an example. > [...] > > Hello, > > ametzler at argenau:/tmp$ certtool --infile=/tmp/fail.pem -i --debug=4711 > Setting log level to 4711 > |<2>| Unknown SIGN OID: '1.2.840.113549.1.1.1' > |<2>| signatureAlgorithm.algorithm differs from tbsCertificate.signature.algorithm: RSA-SHA1, (null) > > 1.2.840.113549.1.1.1 is "rsaEncryption", I *guess* that is not a valid > signature algoritm, it should read somethigng like sha1WithRSAEncryption. Right, OpenSSL also says: Signature Algorithm: rsaEncryption Signature Algorithm: sha1WithRSAEncryption It clearly should not pass validation, but is that a reason not to import the certificate? Kurt From nmav at gnutls.org Sun Aug 16 09:08:44 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 16 Aug 2015 09:08:44 +0200 Subject: [gnutls-devel] certificate I can't import In-Reply-To: <20150815130825.GA16125@roeckx.be> References: <20150815111432.GA14273@roeckx.be> <20150815122809.GB2319@downhill.g.la> <20150815130825.GA16125@roeckx.be> Message-ID: On Sat, Aug 15, 2015 at 3:08 PM, Kurt Roeckx wrote: >> ametzler at argenau:/tmp$ certtool --infile=/tmp/fail.pem -i --debug=4711 >> Setting log level to 4711 >> |<2>| Unknown SIGN OID: '1.2.840.113549.1.1.1' >> |<2>| signatureAlgorithm.algorithm differs from tbsCertificate.signature.algorithm: RSA-SHA1, (null) >> 1.2.840.113549.1.1.1 is "rsaEncryption", I *guess* that is not a valid >> signature algoritm, it should read somethigng like sha1WithRSAEncryption. > Right, > OpenSSL also says: > Signature Algorithm: rsaEncryption > Signature Algorithm: sha1WithRSAEncryption > It clearly should not pass validation, but is that a reason not to > import the certificate? Hi, I decided to treat these errors as parsing errors, because their are such. A certificate should have the same OID in these two fields, and in that case it doesn't, so I believe failing to import it is the reasonable thing to do. Importing it but failing on signature verification would most likely create more confusion on why this was not accepted as valid. regards, Nikos From GMurray at webwayone.co.uk Mon Aug 17 11:10:25 2015 From: GMurray at webwayone.co.uk (Graham Murray) Date: Mon, 17 Aug 2015 10:10:25 +0100 Subject: [gnutls-devel] gnutls-3.4.4 - gnutls_psk_set_client_credentials() returns Base64 decoding error Message-ID: <1439802625.7178.25.camel@webwayone.co.uk> After upgrading to gnutls-3.4.4, gnutls_psk_set_client_credentials fails with 'Base64 decoding erro'. Reverting back to gnutls-3.4.3 (without rebuilding my application) it works correctly again. From nmav at gnutls.org Mon Aug 17 13:13:15 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 17 Aug 2015 13:13:15 +0200 Subject: [gnutls-devel] gnutls-3.4.4 - gnutls_psk_set_client_credentials() returns Base64 decoding error In-Reply-To: <1439802625.7178.25.camel@webwayone.co.uk> References: <1439802625.7178.25.camel@webwayone.co.uk> Message-ID: On Mon, Aug 17, 2015 at 11:10 AM, Graham Murray wrote: > After upgrading to gnutls-3.4.4, gnutls_psk_set_client_credentials > fails with 'Base64 decoding erro'. Reverting back to gnutls-3.4.3 > (without rebuilding my application) it works correctly again. Gnutls 3.4.4 is more strict on the hex data provided. While the previous versions would stop processing on invalid data, this one will output an error. If that is not the case of your issue, could you modify tests/pskself.c in a way which reproduces the issue? regards, Nikos From GMurray at webwayone.co.uk Mon Aug 17 14:45:06 2015 From: GMurray at webwayone.co.uk (Graham Murray) Date: Mon, 17 Aug 2015 13:45:06 +0100 Subject: [gnutls-devel] gnutls-3.4.4 - gnutls_psk_set_client_credentials() returns Base64 decoding error In-Reply-To: References: <1439802625.7178.25.camel@webwayone.co.uk> Message-ID: <1439815506.7178.27.camel@webwayone.co.uk> On Mon, 2015-08-17 at 12:13 +0100, Nikos Mavrogiannopoulos wrote: > On Mon, Aug 17, 2015 at 11:10 AM, Graham Murray < > GMurray at webwayone.co.uk> wrote: > > After upgrading to gnutls-3.4.4, gnutls_psk_set_client_credentials > > fails with 'Base64 decoding erro'. Reverting back to gnutls-3.4.3 > > (without rebuilding my application) it works correctly again. > > Gnutls 3.4.4 is more strict on the hex data provided. While the > previous versions would stop processing on invalid data, this one > will > output an error. If that is not the case of your issue, could you > modify tests/pskself.c in a way which reproduces the issue? > Thank you. That was the problem. The line terminator was not being removed from the hex key. Fixing this fixed the problem and it now works with 3.4.4 From mhw at netris.org Wed Aug 19 07:37:46 2015 From: mhw at netris.org (Mark H Weaver) Date: Wed, 19 Aug 2015 01:37:46 -0400 Subject: [gnutls-devel] Missing documentation in GnuTLS 3.4.4.1 Message-ID: <878u97ltxx.fsf@netris.org> I looked at the diffs between 3.4.4 and 3.4.4.1 and discovered that in the documentation, all of the included output of --help has been lost. For example: --8<---------------cut here---------------start------------->8--- diff -ru gnutls-3.4.4/doc/invoke-certtool.texi gnutls-3.4.4.1/doc/invoke-certtool.texi --- gnutls-3.4.4/doc/invoke-certtool.texi 2015-07-31 15:44:21.000000000 -0400 +++ gnutls-3.4.4.1/doc/invoke-certtool.texi 2015-08-10 13:43:52.000000000 -0400 @@ -41,97 +41,7 @@ @exampleindent 0 @example -certtool - GnuTLS certificate tool -Usage: certtool [ - [] | --[@{=| @}] ]... - - -d, --debug=num Enable debugging - - it must be in the range: - 0 to 9999 - -V, --verbose More verbose output - - may appear multiple times - --infile=file Input file - - file must pre-exist - --outfile=str Output file - -s, --generate-self-signed Generate a self-signed certificate - -c, --generate-certificate Generate a signed certificate - --generate-proxy Generates a proxy certificate - --generate-crl Generate a CRL - -u, --update-certificate Update a signed certificate - -p, --generate-privkey Generate a private key - -q, --generate-request Generate a PKCS #10 certificate request - - prohibits the option 'infile' - -e, --verify-chain Verify a PEM encoded certificate chain - --verify Verify a PEM encoded certificate chain using a trusted list - --verify-crl Verify a CRL using a trusted list - - requires the option 'load-ca-certificate' - --generate-dh-params Generate PKCS #3 encoded Diffie-Hellman parameters - --get-dh-params Get the included PKCS #3 encoded Diffie-Hellman parameters - --dh-info Print information PKCS #3 encoded Diffie-Hellman parameters - --load-privkey=str Loads a private key file - --load-pubkey=str Loads a public key file - --load-request=str Loads a certificate request file - --load-certificate=str Loads a certificate file - --load-ca-privkey=str Loads the certificate authority's private key file - --load-ca-certificate=str Loads the certificate authority's certificate file - --password=str Password to use - --null-password Enforce a NULL password - --empty-password Enforce an empty password - --hex-numbers Print big number in an easier format to parse - --cprint In certain operations it prints the information in C-friendly format - -i, --certificate-info Print information on the given certificate - --certificate-pubkey Print certificate's public key - --pgp-certificate-info Print information on the given OpenPGP certificate - --pgp-ring-info Print information on the given OpenPGP keyring structure - -l, --crl-info Print information on the given CRL structure - --crq-info Print information on the given certificate request - --no-crq-extensions Do not use extensions in certificate requests - --p12-info Print information on a PKCS #12 structure - --p12-name=str The PKCS #12 friendly name to use - --p7-info Print information on a PKCS #7 structure - --smime-to-p7 Convert S/MIME to PKCS #7 structure - -k, --key-info Print information on a private key - --pgp-key-info Print information on an OpenPGP private key - --pubkey-info Print information on a public key - --v1 Generate an X.509 version 1 certificate (with no extensions) - -!, --to-p12 Generate a PKCS #12 structure - - requires the option 'load-certificate' - -", --to-p8 Generate a PKCS #8 structure - -8, --pkcs8 Use PKCS #8 format for private keys - -#, --rsa Generate RSA key - -$, --dsa Generate DSA key - -%, --ecc Generate ECC (ECDSA) key - -&, --ecdsa an alias for the 'ecc' option - -', --hash=str Hash algorithm to use for signing - -(, --inder Use DER format for input certificates, private keys, and DH parameters - - disabled as '--no-inder' - -), --inraw an alias for the 'inder' option - -*, --outder Use DER format for output certificates, private keys, and DH parameters - - disabled as '--no-outder' - -+, --outraw an alias for the 'outder' option - -,, --bits=num Specify the number of bits for key generate - --, --curve=str Specify the curve used for EC key generation - -., --sec-param=str Specify the security level [low, legacy, medium, high, ultra] - -/, --disable-quick-random No effect - -0, --template=str Template file to use for non-interactive operation - -1, --stdout-info Print information to stdout instead of stderr - -2, --ask-pass Enable interaction for entering password when in batch mode. - -3, --pkcs-cipher=str Cipher to use for PKCS #8 and #12 operations - -4, --provider=str Specify the PKCS #11 provider library - -v, --version[=arg] output version information and exit - -h, --help display extended usage information and exit - -!, --more-help extended usage information passed thru pager - -Options are specified by doubled hyphens and their name or by a single -hyphen and the flag character. - -Tool to parse and generate X.509 certificates, requests and private keys. -It can be used interactively or non interactively by specifying the -template command line option. - -The tool accepts files or URLs supported by GnuTLS. In case PIN is -required for the URL access you can provide it using the environment -variables GNUTLS_PIN and GNUTLS_SO_PIN. - +certtool is unavailable - no --help @end example @exampleindent 4 --8<---------------cut here---------------end--------------->8--- Ditto for ocsptool, srptool, psktool, p11tool, gnutls-cli, gnutls-serv, and gnutls-cli-debug, and of course these problems are reflected in the pre-generated docs as well. Mark From nmav at gnutls.org Fri Aug 21 16:51:47 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 21 Aug 2015 16:51:47 +0200 Subject: [gnutls-devel] Missing documentation in GnuTLS 3.4.4.1 In-Reply-To: <878u97ltxx.fsf@netris.org> References: <878u97ltxx.fsf@netris.org> Message-ID: On Wed, Aug 19, 2015 at 7:37 AM, Mark H Weaver wrote: > I looked at the diffs between 3.4.4 and 3.4.4.1 and discovered that in > the documentation, all of the included output of --help has > been lost. For example: [...] > Ditto for ocsptool, srptool, psktool, p11tool, gnutls-cli, gnutls-serv, > and gnutls-cli-debug, and of course these problems are reflected in the > pre-generated docs as well. Thanks for reporting that. That will be fixed on the next scheduled release. regards, Nikos From n.mavrogiannopoulos at gmail.com Mon Aug 24 13:58:08 2015 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Mon, 24 Aug 2015 13:58:08 +0200 Subject: [gnutls-devel] simplifying certificate verification Message-ID: One the pains in using gnutls is the fact that there is needed quite some copy-paste code to perform certificate verification. I decided to simplify that from 3.5.0, using a function called gnutls_session_auto_verify_cert(), and the result can be seen on the following example https://gitlab.com/gnutls/gnutls/blob/master/doc/examples/ex-client-x509.c That is about ~60 lines of code less per program using gnutls. https://gitlab.com/gnutls/gnutls/commit/25f2b0814401d1e9c98f3fdc833e09b3c877fc72 I'd appreciate any comments or suggestions for improving that interface [0]. regards, Nikos [0]. https://gitlab.com/gnutls/gnutls/blob/master/lib/includes/gnutls/gnutls.h.in#L1296 From sowmini.varadhan at oracle.com Wed Aug 26 02:01:39 2015 From: sowmini.varadhan at oracle.com (Sowmini Varadhan) Date: Tue, 25 Aug 2015 17:01:39 -0700 Subject: [gnutls-devel] Documentation/examples/ex-serv-anon.c does not set priority correctly Message-ID: <55DD01E3.2020005@oracle.com> When I run the ex-serv-anon example, it errors out in gnulls_priority_set_direct because it passes in a bad string. The correct string is: diff --git a/doc/examples/ex-serv-anon.c b/doc/examples/ex-serv-anon.c index 5c164e3..abb4af5 100644 --- a/doc/examples/ex-serv-anon.c +++ b/doc/examples/ex-serv-anon.c @@ -93,7 +93,7 @@ int main(void) for (;;) { gnutls_init(&session, GNUTLS_SERVER); gnutls_priority_set_direct(session, - "NORMAL::+ANON-ECDH:+ANON-DH", + "NORMAL:+ANON-ECDH:+ANON-DH", NULL); gnutls_credentials_set(session, GNUTLS_CRD_ANON, anoncred); A separate error i sthat the example does not check if gnutls_priority_set_direct() succeeded. It should probably do so. --Sowmini From nmav at gnutls.org Wed Aug 26 09:14:58 2015 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 26 Aug 2015 09:14:58 +0200 Subject: [gnutls-devel] Documentation/examples/ex-serv-anon.c does not set priority correctly In-Reply-To: <55DD01E3.2020005@oracle.com> References: <55DD01E3.2020005@oracle.com> Message-ID: On Wed, Aug 26, 2015 at 2:01 AM, Sowmini Varadhan wrote: > When I run the ex-serv-anon example, it errors out in > gnulls_priority_set_direct because it passes in a bad string. > The correct string is: > - "NORMAL::+ANON-ECDH:+ANON-DH", > + "NORMAL:+ANON-ECDH:+ANON-DH", Corrected. Thanks.