From simon at josefsson.org Sun Feb 1 11:07:31 2009 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 01 Feb 2009 11:07:31 +0100 Subject: [Help-gnutls] Re: client certificate authentication In-Reply-To: <497C8588.3000904@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sun, 25 Jan 2009 17:30:16 +0200") References: <1231356138.7163.7.camel@nimitz.example.org> <4974DD81.4020400@gnutls.org> <1232484433.7434.31.camel@nimitz.example.org> <1232883443.19927.20.camel@nimitz.example.org> <497C8588.3000904@gnutls.org> Message-ID: <87eiyimpwc.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > The attached patch tries stay on the safe side and don't try to upgrade > the TLS version on a rehandshake. I'm not sure whether this is the right > thing to do, although performing a rehandshake to upgrade the TLS > version seems quite unlikely. I suspect it will become more likely given TLS 1.1 and TLS 1.2: you may want to try TLS 1.0 on initial handshake, and then want to attempt more recent TLS versions to get more advanced features from the other end -- however I think we use the patch for now and revisit this if someone runs into this limit in the future. This seems like a protocol issue, so we could ask on the IETF list too... /Simon From magnus.henoch at gmail.com Sun Feb 1 16:36:30 2009 From: magnus.henoch at gmail.com (Magnus Henoch) Date: Sun, 01 Feb 2009 16:36:30 +0100 Subject: [Help-gnutls] Windows: gnutls-cli 2.7.3 doesn't work Message-ID: Hi, I'm using the Windows version of GnuTLS from http://josefsson.org/gnutls4win/ to connect to Google Talk. I found that version 2.6.3 works, but version 2.7.3 doesn't. c:/program files/GnuTLS-2.7.3 $ bin/gnutls-cli.exe -p 5223 talk.google.com Resolving 'talk.google.com'... Connecting to '209.85.137.125:5223'... *** Fatal error: Error in the push function. *** Handshake has failed GNUTLS ERROR: Error in the push function. I expect it to do what 2.6.3 does (see attachment). Of course, that is to be expected for using an unstable version. My reason for trying it is that I want to track down and fix another problem: I can't read incoming data without sending something myself. This problem was discussed and diagnosed, and a fix for gnutls proposed, in this thread: http://www.archivum.info/gnu.emacs.help/2008-04/msg00369.html Is there anything I should be aware of before spending time on that? Magnus -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 2.6.txt URL: From simon at josefsson.org Mon Feb 2 09:57:49 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 02 Feb 2009 09:57:49 +0100 Subject: [Help-gnutls] Re: Windows: gnutls-cli 2.7.3 doesn't work In-Reply-To: (Magnus Henoch's message of "Sun, 01 Feb 2009 16:36:30 +0100") References: Message-ID: <87ljspkygi.fsf@mocca.josefsson.org> Magnus Henoch writes: > Hi, > > I'm using the Windows version of GnuTLS from > http://josefsson.org/gnutls4win/ to connect to Google Talk. I found > that version 2.6.3 works, but version 2.7.3 doesn't. > > c:/program files/GnuTLS-2.7.3 $ bin/gnutls-cli.exe -p 5223 talk.google.com > Resolving 'talk.google.com'... > Connecting to '209.85.137.125:5223'... > *** Fatal error: Error in the push function. > *** Handshake has failed > GNUTLS ERROR: Error in the push function. > > I expect it to do what 2.6.3 does (see attachment). This is a known (to me) problem with 2.7.x., it uses gnulib's new socket code for Windows, but doesn't pass the proper fd to gnutls, so reading/writing to the socket inside gnutls fails. The solution has been discussed on the gnulib list earlier, and is relatively simple. I'll try to fix it, but will be quite busy this week so I may not find time before FOSDEM. /Simon From andremailinglist at gmail.com Fri Feb 6 19:33:44 2009 From: andremailinglist at gmail.com (Andrew Hole) Date: Fri, 6 Feb 2009 18:33:44 +0000 Subject: [Help-gnutls] GnuTLS: Failed to Import Certificate '/usr/local/httpd2.2/conf/ssl.pfh/certificate.crt': (-34) Base64 decoding error. Message-ID: <640358900902061033p4c71aebeva7d957f6a761bd43@mail.gmail.com> Hi guys! We are getting the following error: GnuTLS: Failed to Import Certificate '/usr/local/httpd2.2/conf/ssl.pfh/certificate.crt': (-34) Base64 decoding error. We cannot find any documentation regarding this error. Do you have any idea what's the problem and how to solve it? Thanks a lot A. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Fri Feb 6 19:53:20 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 06 Feb 2009 19:53:20 +0100 Subject: [Help-gnutls] Re: GnuTLS: Failed to Import Certificate '/usr/local/httpd2.2/conf/ssl.pfh/certificate.crt': (-34) Base64 decoding error. In-Reply-To: <640358900902061033p4c71aebeva7d957f6a761bd43@mail.gmail.com> (Andrew Hole's message of "Fri, 6 Feb 2009 18:33:44 +0000") References: <640358900902061033p4c71aebeva7d957f6a761bd43@mail.gmail.com> Message-ID: <87zlgz75y7.fsf@mocca.josefsson.org> Andrew Hole writes: > Hi guys! > > We are getting the following error: > > GnuTLS: Failed to Import Certificate > '/usr/local/httpd2.2/conf/ssl.pfh/certificate.crt': (-34) Base64 decoding > error. > > We cannot find any documentation regarding this error. Do you have any idea > what's the problem and how to solve it? What is the content of the file? The error is a low-level parse error, so most likely there is something wrong with the file. /Simon From simon at josefsson.org Fri Feb 6 21:53:48 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 06 Feb 2009 21:53:48 +0100 Subject: [Help-gnutls] GnuTLS 2.6.4 and 2.4.3 Message-ID: <878woj70df.fsf@mocca.josefsson.org> We are proud to announce two new stable GnuTLS releases: Version 2.6.4 and 2.4.3. Normally we only make stable releases on the latest stable branch, i.e., currently 2.6.x. Many users appears to still be using the 2.4.x branch. To make it easier for these users to upgrade to a secure version, we have back-ported all of the X.509 chain verification fixes from the 2.6.x branch to the 2.4.x branch. These two releases should solve the [CVE-2008-4989] security problem and fix the problems with incorrectly rejected chains that were reported for earlier 2.6.x releases. GnuTLS is a modern C library that implement the standard network security protocol Transport Layer Security (TLS), for use by network applications. GnuTLS is developed for GNU/Linux, but works on many Unix-like systems and comes with a binary installer for Windows. The GnuTLS library is distributed under the terms of the GNU Lesser General Public License version 2.1 (or later). The "extra" GnuTLS library (which contains TLS/IA support, LZO compression and Libgcrypt FIPS-mode handler), the OpenSSL compatibility library, the self tests and the command line tools are all distributed under the GNU General Public License version 3.0 (or later). The manual is distributed under the GNU Free Documentation License version 1.3 (or later). The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ What's New ========== Version 2.6.4 is a maintenance release on our stable branch. ** libgnutls: Accept chains where intermediary certs are trusted. Before GnuTLS needed to validate the entire chain back to a self-signed certificate. GnuTLS will now stop looking when it has found an intermediary trusted certificate. The new behaviour is useful when chains, for example, contains a top-level CA, an intermediary CA signed using RSA-MD5, and an end-entity certificate. To avoid chain validation errors due to the RSA-MD5 cert, you can explicitly add the intermediary RSA-MD5 cert to your trusted certs. The signature on trusted certificates are not checked, so the chain has a chance to validate correctly. Reported by "Douglas E. Engert" in . ** libgnutls: result_size in gnutls_hex_encode now holds the size of the result. Report by John Brooks . ** libgnutls: gnutls_handshake when sending client hello during a rehandshake, will not offer a version number larger than the current. Reported by Tristan Hill . ** libgnutls: Permit V1 Certificate Authorities properly. Before they were mistakenly rejected even though GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT and/or GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT were supplied. Reported by "Douglas E. Engert" in . ** libgnutls: deprecate X.509 validation chains using MD5 and MD2 signatures. This is a bugfix -- the previous attempt to do this from internal x509 certificate verification procedures did not return the correct value for certificates using a weak hash. Reported by Daniel Kahn Gillmor in , debugged and patch by Tomas Mraz and Daniel Kahn Gillmor . ** libgnutls: Fix compile error with Sun CC. Reported by Jeff Cai in . ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded from one of the mirror sites or direct from . The list of mirrors can be found at . Here are the BZIP2 compressed sources (4.9MB): ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.6.4.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.6.4.tar.bz2 ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.4.3.tar.bz2 http://ftp.gnu.org/gnu/gnutls/gnutls-2.4.3.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.6.4.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.6.4.tar.bz2.sig ftp://ftp.gnu.org/gnu/gnutls/gnutls-2.4.3.tar.bz2.sig http://ftp.gnu.org/gnu/gnutls/gnutls-2.4.3.tar.bz2.sig Note, that we don't distribute gzip compressed tarballs. In order to check that the version of GnuTLS which you are going to install is an original and unmodified one, you should verify the OpenPGP signature. You can use the command gpg --verify gnutls-2.6.4.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. The signing key can be identified with the following information: pub 1280R/B565716F 2002-05-05 [expires: 2009-04-21] Key fingerprint = 0424 D4EE 81A0 E3D1 19C6 F835 EDA2 1E94 B565 716F uid Simon Josefsson uid Simon Josefsson sub 1280R/4D5D40AE 2002-05-05 [expires: 2009-04-21] The key is available from: http://josefsson.org/key.txt dns:b565716f.josefsson.org?TYPE=CERT Alternatively, after successfully verifying the OpenPGP signature of this announcement, you could verify that the files match the following checksum values. The values are for SHA-1 and SHA-224 respectively: 11dd1e11599906a32b3ff92308f4c4dbaadbad58 gnutls-2.6.4.tar.bz2 83289283739e168f346427784cc9a58c248c3363d1dc346674a54b15 gnutls-2.6.4.tar.bz2 0f4e6ed9ae5939bb9a63bb95722a25e2f6e32fae gnutls-2.4.3.tar.bz2 b8daacc55a67048c241686d2567eb9797af486c6920bd5c59774c981 gnutls-2.4.3.tar.bz2 Documentation ============= The manual is available online at: http://www.gnu.org/software/gnutls/documentation.html In particular the following formats are available: HTML: http://www.gnu.org/software/gnutls/manual/html_node/index.html PDF: http://www.gnu.org/software/gnutls/manual/gnutls.pdf For developers there is a GnuTLS API reference manual formatted using the GTK-DOC tools: http://www.gnu.org/software/gnutls/reference/gnutls-gnutls.html Community ========= If you need help to use GnuTLS, or want to help others, you are invited to join our help-gnutls mailing list, see: http://lists.gnu.org/mailman/listinfo/help-gnutls If you wish to participate in the development of GnuTLS, you are invited to join our gnutls-dev mailing list, see: http://lists.gnu.org/mailman/listinfo/gnutls-devel Windows installer ================= GnuTLS has been ported to the Windows operating system, and a binary installer is available. The installer contains DLLs for application development, manuals, examples, and source code. The installer uses libgpg-error v1.7, libgcrypt v1.4.4, libtasn1 v1.8, and GnuTLS v2.6.4. For more information about GnuTLS for Windows: http://josefsson.org/gnutls4win/ The Windows binary installer and PGP signature: http://josefsson.org/gnutls4win/gnutls-2.6.4.exe (14MB) http://josefsson.org/gnutls4win/gnutls-2.6.4.exe.sig The checksum values for SHA-1 and SHA-224 are: 25975ee8ff0dea1acfb75d5c0bf12ffe7453136d gnutls-2.6.4.exe 83da845fa1436dc6efc78f39c10bea9a6831191720ad10743ec30915 gnutls-2.6.4.exe Thanks to Enrico Tassi, we also have mingw32 *.deb's available: http://josefsson.org/gnutls4win/mingw32-gnutls_2.6.4-1_all.deb The checksum values for SHA-1 and SHA-224 are: 310b4a0f8953927517d7ce600ff24b88c1deada5 mingw32-gnutls_2.6.4-1_all.deb b251518c49d0ab04246b726a4171796d602b5cbbd8a7dd12f58c584b mingw32-gnutls_2.6.4-1_all.deb Internationalization ==================== GnuTLS messages have been translated into Dutch, French, German, Malay, Polish, Swedish, and Vietnamese. We welcome the addition of more translations. Support ======= Improving GnuTLS is costly, but you can help! We are looking for organizations that find GnuTLS useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for GnuTLS are available, and they help finance continued maintenance. Simon Josefsson Datakonsult AB, a Stockholm based privately held company, is currently funding GnuTLS maintenance. We are always looking for interesting development projects. See http://josefsson.org/ for more details. The GnuTLS service directory is available at: http://www.gnu.org/software/gnutls/commercial.html Happy Hacking, Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From bejnet at yahoo.com Sat Feb 7 19:12:52 2009 From: bejnet at yahoo.com (Bejoy Abraham Mathews) Date: Sat, 7 Feb 2009 23:42:52 +0530 (IST) Subject: [Help-gnutls] GnuTLS program not compiling on Windows Message-ID: <249452.19612.qm@web95412.mail.in2.yahoo.com> Hi I have followed the steps on http://www.josefsson.org/gnutls4win/. Installation got over without any extra assistance. But foo.c is not getting compiled as it is not able to reader the header file(gnutls\gnutls.h "or gnutls\compat.h - once gnutls.h path is mentioned"). bejoy at josnet ~ $ gcc -o foo foo.c -I/cygdrive/c/Program\ Files/GnuTLS-2.7.3/include/ /cygdrive/c/Program\ Files/GnuTLS-2.7.3/lib/libgnutls.dll.a gcc.exe: /cygdrive/c/Program Files/GnuTLS-2.7.3/lib/libgnutls.dll.a: No such file or directory foo.c:1:27: gnutls/gnutls.h: No such file or directory foo.c: In function `main': foo.c:4: error: `NULL' undeclared (first use in this function) foo.c:4: error: (Each undeclared identifier is reported only once foo.c:4: error: for each function it appears in.) If I provide the complete path(Eg. C:\Program Files\GnuTLS-2.7.3\include\gnutls\gnutls.h), it shows error for full path for compat.h inside gnutls.h file $ gcc -o foo foo.c -I/cygdrive/c/Program\ Files/GnuTLS-2.7.3/include/ -L/cygdrive/c/Program\ Files/GnuTLS-2.7.3/lib/libgnutls.dll.a In file included from foo.c:1: C:\Program Files\GnuTLS-2.7.3\include\gnutls\gnutls.h:48:64: gnutls/compat.h: No such file or directory In file included from foo.c:1: C:\Program Files\GnuTLS-2.7.3\include\gnutls\gnutls.h:754: error: syntax error before '*' token After correcting the path to compat.h in gnutls.h, I get the following error $ gcc -o foo foo.c -I/cygdrive/c/Program\ Files/GnuTLS-2.7.3/include/ -L/cygdrive/c/Program\ Files/GnuTLS-2.7.3/lib/libgnutls.dll.a C:\DOCUME~1\bejoy\LOCALS~1\Temp/ccMPmztm.o:foo.c:(.text+0x32): undefined referece to `gnutls_check_version' collect2: ld returned 1 exit status I tried Cygwin and MinGW environments. Same error...!!! Could you please someone help me correct this error? Thank you. With Regards Bejoy Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Sat Feb 7 19:56:11 2009 From: simon at josefsson.org (Simon Josefsson) Date: Sat, 07 Feb 2009 19:56:11 +0100 Subject: [Help-gnutls] Re: GnuTLS program not compiling on Windows In-Reply-To: <249452.19612.qm@web95412.mail.in2.yahoo.com> (Bejoy Abraham Mathews's message of "Sat, 7 Feb 2009 23:42:52 +0530 (IST)") References: <249452.19612.qm@web95412.mail.in2.yahoo.com> Message-ID: <8763jmoz3o.fsf@mocca.josefsson.org> Bejoy Abraham Mathews writes: > Hi > > I have followed the steps on http://www.josefsson.org/gnutls4win/. Installation got over without any extra assistance. But foo.c is not getting compiled as it is not able to reader the header file(gnutls\gnutls.h "or gnutls\compat.h - once gnutls.h path is mentioned"). > > bejoy at josnet ~ > $ gcc -o foo foo.c -I/cygdrive/c/Program\ Files/GnuTLS-2.7.3/include/ /cygdrive/c/Program\ Files/GnuTLS-2.7.3/lib/libgnutls.dll.a > gcc.exe: /cygdrive/c/Program Files/GnuTLS-2.7.3/lib/libgnutls.dll.a: No such file or directory > foo.c:1:27: gnutls/gnutls.h: No such file or directory > foo.c: In function `main': > foo.c:4: error: `NULL' undeclared (first use in this function) > foo.c:4: error: (Each undeclared identifier is reported only once > foo.c:4: error: for each function it appears in.) > > > If I provide the complete path(Eg. C:\Program Files\GnuTLS-2.7.3\include\gnutls\gnutls.h), it shows error for full path for compat.h inside gnutls.h file > > $ gcc -o foo foo.c -I/cygdrive/c/Program\ Files/GnuTLS-2.7.3/include/ -L/cygdrive/c/Program\ Files/GnuTLS-2.7.3/lib/libgnutls.dll.a > In file included from foo.c:1: > C:\Program Files\GnuTLS-2.7.3\include\gnutls\gnutls.h:48:64: gnutls/compat.h: No such file or directory > In file included from foo.c:1: > C:\Program Files\GnuTLS-2.7.3\include\gnutls\gnutls.h:754: error: syntax error before '*' token > > After correcting the path to compat.h in gnutls.h, I get the following error > > $ gcc -o foo foo.c -I/cygdrive/c/Program\ Files/GnuTLS-2.7.3/include/ -L/cygdrive/c/Program\ Files/GnuTLS-2.7.3/lib/libgnutls.dll.a > C:\DOCUME~1\bejoy\LOCALS~1\Temp/ccMPmztm.o:foo.c:(.text+0x32): undefined referece to `gnutls_check_version' > collect2: ld returned 1 exit status > > I tried Cygwin and MinGW environments. Same error...!!! > > Could you please someone help me correct this error? The last error is a link error, which should be solved if you just remove the two characters '-L' that you added. /Simon From bejnet at yahoo.com Sun Feb 8 06:05:53 2009 From: bejnet at yahoo.com (Bejoy Abraham Mathews) Date: Sun, 8 Feb 2009 10:35:53 +0530 (IST) Subject: [Help-gnutls] Re: GnuTLS program not compiling on Windows References: <249452.19612.qm@web95412.mail.in2.yahoo.com> <8763jmoz3o.fsf@mocca.josefsson.org> Message-ID: <647294.24679.qm@web95413.mail.in2.yahoo.com> $ gcc -o foo foo.c -I/cygdrive/c/Program\ Files/GnuTLS-2.7.3/include/ /cygdrive/c/Program\ Files/GnuTLS-2.7.3/lib/libgnutls.dll.a gcc.exe: /cygdrive/c/Program\ Files/GnuTLS-2.7.3/lib/libgnutls.dll.a: No such file or directory This is what I get if I remove the "-L" Bejoy ________________________________ From: Simon Josefsson To: Bejoy Abraham Mathews Cc: help-gnutls at gnu.org Sent: Saturday, 7 February, 2009 9:56:11 PM Subject: Re: GnuTLS program not compiling on Windows Bejoy Abraham Mathews writes: > Hi > > I have followed the steps on http://www.josefsson.org/gnutls4win/. Installation got over without any extra assistance. But foo.c is not getting compiled as it is not able to reader the header file(gnutls\gnutls.h "or gnutls\compat.h - once gnutls.h path is mentioned"). > > bejoy at josnet ~ > $ gcc -o foo foo.c -I/cygdrive/c/Program\ Files/GnuTLS-2.7.3/include/ /cygdrive/c/Program\ Files/GnuTLS-2.7.3/lib/libgnutls.dll.a > gcc.exe: /cygdrive/c/Program Files/GnuTLS-2.7.3/lib/libgnutls.dll.a: No such file or directory > foo.c:1:27: gnutls/gnutls.h: No such file or directory > foo.c: In function `main': > foo.c:4: error: `NULL' undeclared (first use in this function) > foo.c:4: error: (Each undeclared identifier is reported only once > foo.c:4: error: for each function it appears in..) > > > If I provide the complete path(Eg. C:\Program Files\GnuTLS-2..7.3\include\gnutls\gnutls.h), it shows error for full path for compat.h inside gnutls.h file > > $ gcc -o foo foo.c -I/cygdrive/c/Program\ Files/GnuTLS-2.7.3/include/ -L/cygdrive/c/Program\ Files/GnuTLS-2.7.3/lib/libgnutls.dll.a > In file included from foo.c:1: > C:\Program Files\GnuTLS-2.7..3\include\gnutls\gnutls.h:48:64: gnutls/compat.h: No such file or directory > In file included from foo.c:1: > C:\Program Files\GnuTLS-2.7.3\include\gnutls\gnutls.h:754: error: syntax error before '*' token > > After correcting the path to compat.h in gnutls.h, I get the following error > > $ gcc -o foo foo.c -I/cygdrive/c/Program\ Files/GnuTLS-2.7.3/include/ -L/cygdrive/c/Program\ Files/GnuTLS-2.7.3/lib/libgnutls.dll.a > C:\DOCUME~1\bejoy\LOCALS~1\Temp/ccMPmztm.o:foo.c:(.text+0x32): undefined referece to `gnutls_check_version' > collect2: ld returned 1 exit status > > I tried Cygwin and MinGW environments. Same error...!!! > > Could you please someone help me correct this error? The last error is a link error, which should be solved if you just remove the two characters '-L' that you added. /Simon Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Sun Feb 8 09:39:32 2009 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 08 Feb 2009 09:39:32 +0100 Subject: [Help-gnutls] Re: GnuTLS program not compiling on Windows In-Reply-To: <647294.24679.qm@web95413.mail.in2.yahoo.com> (Bejoy Abraham Mathews's message of "Sun, 8 Feb 2009 10:35:53 +0530 (IST)") References: <249452.19612.qm@web95412.mail.in2.yahoo.com> <8763jmoz3o.fsf@mocca.josefsson.org> <647294.24679.qm@web95413.mail.in2.yahoo.com> Message-ID: <877i41b9vf.fsf@mocca.josefsson.org> Bejoy Abraham Mathews writes: > $ gcc -o foo foo.c -I/cygdrive/c/Program\ Files/GnuTLS-2.7.3/include/ /cygdrive/c/Program\ Files/GnuTLS-2.7.3/lib/libgnutls.dll.a > gcc.exe: /cygdrive/c/Program\ Files/GnuTLS-2.7.3/lib/libgnutls.dll.a: No such file or directory > > This is what I get if I remove the "-L" > Bejoy Does the path and file exist if you use command line completion? Note that the path will only exist when you use cygwin. Possibly there could be some problem with SPC in paths, try installing gnutls to another place without SPC in the path. /Simon From bejnet at yahoo.com Sun Feb 8 10:05:08 2009 From: bejnet at yahoo.com (Bejoy Abraham Mathews) Date: Sun, 8 Feb 2009 14:35:08 +0530 (IST) Subject: [Help-gnutls] Re: GnuTLS program not compiling on Windows References: <249452.19612.qm@web95412.mail.in2.yahoo.com> <8763jmoz3o.fsf@mocca.josefsson.org> <647294.24679.qm@web95413.mail.in2.yahoo.com> <877i41b9vf.fsf@mocca.josefsson.org> Message-ID: <620705.3552.qm@web95409.mail.in2.yahoo.com> Yes - command line completion has the path and file. I tried this on normal command prompt with MinGW as well. ________________________________ From: Simon Josefsson To: Bejoy Abraham Mathews Cc: help-gnutls at gnu.org Sent: Sunday, 8 February, 2009 11:39:32 AM Subject: Re: GnuTLS program not compiling on Windows Bejoy Abraham Mathews writes: > $ gcc -o foo foo.c -I/cygdrive/c/Program\ Files/GnuTLS-2.7.3/include/ /cygdrive/c/Program\ Files/GnuTLS-2.7.3/lib/libgnutls.dll.a > gcc.exe: /cygdrive/c/Program\ Files/GnuTLS-2.7.3/lib/libgnutls.dll.a: No such file or directory > > This is what I get if I remove the "-L" > Bejoy Does the path and file exist if you use command line completion? Note that the path will only exist when you use cygwin. Possibly there could be some problem with SPC in paths, try installing gnutls to another place without SPC in the path. /Simon Unlimited freedom, unlimited storage. Get it now, on http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rickard at rtvi.se Sun Feb 8 10:49:44 2009 From: Rickard at rtvi.se (Rickard Eriksson) Date: Sun, 08 Feb 2009 10:49:44 +0100 Subject: [Help-gnutls] Can't compile Echo Server with Anonymous Authentication Message-ID: <498EAAB8.5000503@rtvi.se> Hi I am trying to compile the Echo Server with Anonymous Authentication but i just get errors. # gcc -o test main.cpp -lgnutls -lgcrypt main.cpp: In function 'int main()': main.cpp:107: error: invalid conversion from 'int*' to 'socklen_t*' main.cpp:107: error: initializing argument 3 of 'int accept(int, sockaddr*, socklen_t*)' The box i try to compile it on is a Gentoo linux with net-libs/gnutls version 2.4.1-r2 installed. What do i do wrong? :) -------------- next part -------------- A non-text attachment was scrubbed... Name: Rickard.vcf Type: text/x-vcard Size: 332 bytes Desc: not available URL: From simon at josefsson.org Fri Feb 13 13:11:23 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 13 Feb 2009 13:11:23 +0100 Subject: [Help-gnutls] FOSDEM GnuTLS lightning talk Message-ID: <873aeiiljo.fsf@mocca.josefsson.org> I forgot to announce this before the event, but I made a brief talk about GnuTLS at FOSDEM. The presentation is here: http://josefsson.org/talks/fosdem2009-gnutls.pdf I won't dig up a URL to the video recoding to reduce my embarrassment of poor english and poor presentation skillz.. ;) If someone has suggestion on the presentation, we could improve it. Perhaps it can serve as a quick introduction to GnuTLS and be placed on the GnuTLS web page. /Simon From mrsam at courier-mta.com Sat Feb 14 05:25:05 2009 From: mrsam at courier-mta.com (Sam Varshavchik) Date: Fri, 13 Feb 2009 23:25:05 -0500 Subject: [Help-gnutls] Does verify_peers2 check cert expiration? Message-ID: After calling gnutls_certificate_verify_peers2(), I call gnutls_certificate_get_peers(), take the first cert, and call gnutls_x509_crt_get_activation_time() and gnutls_x509_crt_get_expiration_time(), and verify that the certificate has not expired. Am I doing too much work? The man page for gnutls_certificate_verify_peers2() isn't quite clear if it does any more validation besides verifying the cert chain. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From Martin.vGagern at gmx.net Sun Feb 15 11:15:04 2009 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Sun, 15 Feb 2009 11:15:04 +0100 Subject: [Help-gnutls] Default record version Message-ID: <4997EB28.8090100@gmx.net> Hi! I could use a bit of adivce regarding an issue in pidgin talking to MSN servers, see http://developer.pidgin.im/ticket/3456 for the full report. One of the MSN servers, 65.54.170.19, immediately terminates a connection started by GnuTLS using TLS 1.1. When restricting the protocol to TLS 1.0, the connection works all right. This behaviour can be reproduced using gnutls-cli, and also shows up as a failed fallback from TLS 1.1 in gnutls-cli-debug [1]. darkrain42 noticed that according to RFC4346 (TLS 1.1) Appendix E [2], a TLS client should use an older record version for the sake of backwards compatibility. And indeed, when using an older record version (SSL 3.0 or TLS 1.0) but indicating TLS 1.1 in the client hello, the connection with the server in question can be established successfully. My first question is this: is there a good reason that GnuTLS doesn't indicate an older record version in accordance with appendix E by default? It seems that _gnutls_record_set_default_version would provide a way to get the intended behaviour of an older record version but a recent client hello version. That function doesn't seem to be intended as part of the public interface of GnuTLS, though [3]. Why is that? Do you have any other suggestions as to how to achive backwards compatibility with such servers without too much programming overhead, and without denying more recent TLS versions in cases where both sides can use them? I'd appriciate your opinion on this. Greetings, Martin von Gagern [1] http://developer.pidgin.im/ticket/3456#comment:10 [2] http://tools.ietf.org/html/rfc4346#appendix-E [3] http://developer.pidgin.im/ticket/3456#comment:22 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Sun Feb 15 18:30:27 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 15 Feb 2009 19:30:27 +0200 Subject: [Help-gnutls] Default record version In-Reply-To: <4997EB28.8090100@gmx.net> References: <4997EB28.8090100@gmx.net> Message-ID: <49985133.4010508@gnutls.org> Martin von Gagern wrote: > Hi! > > I could use a bit of adivce regarding an issue in pidgin talking to MSN > servers, see http://developer.pidgin.im/ticket/3456 for the full report. > > One of the MSN servers, 65.54.170.19, immediately terminates a > connection started by GnuTLS using TLS 1.1. When restricting the > protocol to TLS 1.0, the connection works all right. This behaviour can > be reproduced using gnutls-cli, and also shows up as a failed fallback > from TLS 1.1 in gnutls-cli-debug [1]. > > darkrain42 noticed that according to RFC4346 (TLS 1.1) Appendix E [2], a > TLS client should use an older record version for the sake of backwards > compatibility. And indeed, when using an older record version (SSL 3.0 > or TLS 1.0) but indicating TLS 1.1 in the client hello, the connection > with the server in question can be established successfully. > > My first question is this: is there a good reason that GnuTLS doesn't > indicate an older record version in accordance with appendix E by default? This is tricky. There are other servers that do not operate well if the client hello version does not match record version. This is the reason why gnutls has this behavior. Of course this was noticed many years ago. I don't know how many servers now have this problem. > It seems that _gnutls_record_set_default_version would provide a way to > get the intended behaviour of an older record version but a recent > client hello version. That function doesn't seem to be intended as part > of the public interface of GnuTLS, though [3]. Why is that? It was meant as a hack to test for buggy servers that I mentioned above. I don't think it should be normally used. A better solution would be to have a priority string %RFC4346 that would enforce that behavior. What do you think on that? regards, Nikos From nmav at gnutls.org Sun Feb 15 18:56:13 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 15 Feb 2009 19:56:13 +0200 Subject: [Help-gnutls] Does verify_peers2 check cert expiration? In-Reply-To: References: Message-ID: <4998573D.1010808@gnutls.org> Sam Varshavchik wrote: > After calling gnutls_certificate_verify_peers2(), I call > gnutls_certificate_get_peers(), take the first cert, and call > gnutls_x509_crt_get_activation_time() and > gnutls_x509_crt_get_expiration_time(), and verify that the certificate > has not expired. > > Am I doing too much work? The man page for No. Your checks are fine. regards, Nikos From Martin.vGagern at gmx.net Sun Feb 15 20:32:28 2009 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Sun, 15 Feb 2009 20:32:28 +0100 Subject: [Help-gnutls] Default record version In-Reply-To: <49985133.4010508@gnutls.org> References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org> Message-ID: <49986DCC.3030102@gmx.net> Hi Nikos, thanks for your reply! Nikos Mavrogiannopoulos wrote: >> My first question is this: is there a good reason that GnuTLS doesn't >> indicate an older record version in accordance with appendix E by default? > > This is tricky. There are other servers that do not operate well if the > client hello version does not match record version. This is the reason > why gnutls has this behavior. Of course this was noticed many years ago. > I don't know how many servers now have this problem. I see, and in that light it might make sense to not have the Appendix E behaviour by default. In my opinion, it would be desirable if you could at least configure GnuTLS to use that approach, though. >> It seems that _gnutls_record_set_default_version would provide a way to >> get the intended behaviour of an older record version but a recent >> client hello version. That function doesn't seem to be intended as part >> of the public interface of GnuTLS, though [3]. Why is that? > > It was meant as a hack to test for buggy servers that I mentioned above. > I don't think it should be normally used. A better solution would be to > have a priority string %RFC4346 that would enforce that behavior. What > do you think on that? The reference to RFC 4346 in your sentence confuses me, especially as I see no reference to a "priority string" in that RFC. The only possible interpretation of your suggestion would be to use a call to gnutls_protocol_set_priority in order to disable TLS 1.1, thus enforcing a TLS 1.0 record header and client hello. While this approach does solve the backwards compatibility problem, it breaks forward compatibility. There is a good chance that the restriction will stay in the client code long after all servers have been updated to deal with TLS 1.1 or later, maybe even long after newly found security issues with TLS 1.0 advise against its use. So while feasible, I'm not happy with this approach. With only the record version changed, the backwards compatibility would be ensured (at least with the server in question), while there is a good chance that future implementations might negotiate a higher version based on the hello messages. If _gnutls_record_set_default_version can do this, and there is no plan that forces the removal of this functionality in the near future, I'd love to see it made official, so that clients can configure their own backwards compatibility, based on whether high record versions or record versions not matching hello versions are more likely to cause trouble. Would I have to take the issues to the dev mailing list to get a decision on this? Greetings, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Mon Feb 16 02:18:35 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 16 Feb 2009 03:18:35 +0200 Subject: [Help-gnutls] Default record version In-Reply-To: <49986DCC.3030102@gmx.net> References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org> <49986DCC.3030102@gmx.net> Message-ID: <4998BEEB.1060004@gnutls.org> Martin von Gagern wrote: >>> It seems that _gnutls_record_set_default_version would provide a way to >>> get the intended behaviour of an older record version but a recent >>> client hello version. That function doesn't seem to be intended as part >>> of the public interface of GnuTLS, though [3]. Why is that? >> It was meant as a hack to test for buggy servers that I mentioned above. >> I don't think it should be normally used. A better solution would be to >> have a priority string %RFC4346 that would enforce that behavior. What >> do you think on that? > > The reference to RFC 4346 in your sentence confuses me, especially as I > see no reference to a "priority string" in that RFC. The only possible > interpretation of your suggestion would be to use a call to > gnutls_protocol_set_priority in order to disable TLS 1.1, thus enforcing > a TLS 1.0 record header and client hello. Hello, What I meant is to have this %RFC4346 option in the priority string in order to specify that the way the client hello and first record version will be according to appendix E as you quoted before (lowest supported record version -SSL 3.0 and highest supported client hello version -TLS1.1). The priority string is gnutls specific and means the string you specify in the set_priority functions. regards, Nikos From simon at josefsson.org Mon Feb 16 09:42:48 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 16 Feb 2009 09:42:48 +0100 Subject: [Help-gnutls] Re: Default record version In-Reply-To: <4998BEEB.1060004@gnutls.org> (Nikos Mavrogiannopoulos's message of "Mon, 16 Feb 2009 03:18:35 +0200") References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org> <49986DCC.3030102@gmx.net> <4998BEEB.1060004@gnutls.org> Message-ID: <87ab8m93hz.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Martin von Gagern wrote: > >>>> It seems that _gnutls_record_set_default_version would provide a way to >>>> get the intended behaviour of an older record version but a recent >>>> client hello version. That function doesn't seem to be intended as part >>>> of the public interface of GnuTLS, though [3]. Why is that? >>> It was meant as a hack to test for buggy servers that I mentioned above. >>> I don't think it should be normally used. A better solution would be to >>> have a priority string %RFC4346 that would enforce that behavior. What >>> do you think on that? >> >> The reference to RFC 4346 in your sentence confuses me, especially as I >> see no reference to a "priority string" in that RFC. The only possible >> interpretation of your suggestion would be to use a call to >> gnutls_protocol_set_priority in order to disable TLS 1.1, thus enforcing >> a TLS 1.0 record header and client hello. > > Hello, > What I meant is to have this %RFC4346 option in the priority string in > order to specify that the way the client hello and first record version > will be according to appendix E as you quoted before (lowest supported > record version -SSL 3.0 and highest supported client hello version > -TLS1.1). The priority string is gnutls specific and means the string > you specify in the set_priority functions. I think a priority string to configure this seems like a good idea, however, please use a more descriptive name than %RFC4346 (which has already been obsoleted by RFC 5246). How about %USE-TLS1.0-RECORD-VERSION? And %USE-SSL3-RECORD-VERSION if we need to be able to set both SSL 3.0 and TLS 1.0 record versions. /Simon From wkfta at hotmail.com Fri Feb 20 14:20:04 2009 From: wkfta at hotmail.com (liuxiaoyu) Date: Fri, 20 Feb 2009 21:20:04 +0800 Subject: [Help-gnutls] How to resume a previous session Message-ID: Hi, I notice that there is a procedure described in RFC 4346 Page 33 that a session can be resummed by reusing the previous Session ID. The orginal text is as following: "When the client and server decide to resume a previous session or duplicate an existing session (instead of negotiating new security parameters), the message flow is as follows: The client sends a ClientHello using the Session ID of the session to be resumed. The server then checks its session cache for a match. If a match is found, and the server is willing to re-establish the connection under the specified session state, it will send a ServerHello with the same Session ID value. At this point, both client and server MUST send change cipher spec messages and proceed directly to finished messages. Once the re-establishment is complete, the client and server MAY begin to exchange application layer data. (See flow chart below.) If a Session ID match is not found, the server generates a new session ID and the TLS client and server perform a full handshake. Client Server ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data Fig. 2. Message flow for an abbreviated handshake The contents and significance of each message will be presented in detail in the following sections." I am using GnuTls 2.6.3. I tried it this way: first initialize a TLS session, and then perform 2 handshakes continuously before deinitializing the TLS session. The result is the second handshake will be failed. So I am wondering whether the procedure described above has been supported by GnuTls 2.6.3. If Yes, how can I make it happen by using GnuTls? Thanks and Regards, Sean _________________________________________________________________ MSN??????????????????MSN??? http://im.live.cn/safe/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Fri Feb 20 14:32:58 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 20 Feb 2009 14:32:58 +0100 Subject: [Help-gnutls] Re: How to resume a previous session In-Reply-To: (liuxiaoyu's message of "Fri, 20 Feb 2009 21:20:04 +0800") References: Message-ID: <87ab8hi67p.fsf@mocca.josefsson.org> liuxiaoyu writes: > So I am wondering whether the procedure described above has been > supported by GnuTls 2.6.3. If Yes, how can I make it happen by using > GnuTls? Have you seen the example code included in the manual? http://www.gnu.org/software/gnutls/manual/html_node/Client-with-Resume-capability-example.html A server using resumption uses the same APIs. You could check the source to gnutls-serv for inspiration. /Simon From flobolob at gmail.com Fri Feb 20 14:53:30 2009 From: flobolob at gmail.com (Peter Tenalp) Date: Fri, 20 Feb 2009 13:53:30 +0000 Subject: [Help-gnutls] gnutls_record_send() without CR/LF? Message-ID: <2b429bba0902200553x251ded09kf8a008b6a0a05e46@mail.gmail.com> Hi folks, I am trying to send a message via the gnutls library, but it seems that the gnutls_record_send() function appends either one or both of a CR/LF pair to the outgoing message. How can I avoid this behavior please? Thanks, Peter From nmav at gnutls.org Fri Feb 20 16:53:36 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Fri, 20 Feb 2009 17:53:36 +0200 Subject: [Help-gnutls] gnutls_record_send() without CR/LF? In-Reply-To: <2b429bba0902200553x251ded09kf8a008b6a0a05e46@mail.gmail.com> References: <2b429bba0902200553x251ded09kf8a008b6a0a05e46@mail.gmail.com> Message-ID: On Fri, Feb 20, 2009 at 3:53 PM, Peter Tenalp wrote: > Hi folks, > > I am trying to send a message via the gnutls library, but it seems > that the gnutls_record_send() function appends either one or both of a > CR/LF pair to the outgoing message. How can I avoid this behavior > please? It doesn't append anything. It sends raw data. Check the functions that call it. regards, Nikos From nmav at gnutls.org Sat Feb 21 12:25:21 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 21 Feb 2009 13:25:21 +0200 Subject: [Help-gnutls] Default record version In-Reply-To: <49986DCC.3030102@gmx.net> References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org> <49986DCC.3030102@gmx.net> Message-ID: <499FE4A1.3000805@gnutls.org> Martin von Gagern wrote: > Hi Nikos, thanks for your reply! > > Nikos Mavrogiannopoulos wrote: >>> My first question is this: is there a good reason that GnuTLS doesn't >>> indicate an older record version in accordance with appendix E by default? >> This is tricky. There are other servers that do not operate well if the >> client hello version does not match record version. This is the reason >> why gnutls has this behavior. Of course this was noticed many years ago. >> I don't know how many servers now have this problem. > > I see, and in that light it might make sense to not have the Appendix E > behaviour by default. In my opinion, it would be desirable if you could > at least configure GnuTLS to use that approach, though. The commit below[0] adds a priority string called SSL3_RECORD_VERSION that forces a compatibility mode where an SSL 3.0 record version is set on the client hello. I have backported it to 2.6 branch as well. [0]. http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=27a05b85c390f3192fcf0c55c1b5c0196e33c727 regards, Nikos From Martin.vGagern at gmx.net Sat Feb 21 13:31:13 2009 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Sat, 21 Feb 2009 13:31:13 +0100 Subject: [Help-gnutls] Default record version In-Reply-To: <499FE4A1.3000805@gnutls.org> References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org> <49986DCC.3030102@gmx.net> <499FE4A1.3000805@gnutls.org> Message-ID: <499FF411.40009@gmx.net> Nikos Mavrogiannopoulos wrote: > The commit below adds a priority string called SSL3_RECORD_VERSION > that forces a compatibility mode where an SSL 3.0 record version is set > on the client hello. I have backported it to 2.6 branch as well. Thanks a lot! I'll test that, and get back to you if anything doesn't work as expected. Otherwise that seems like a suitable solution. Greetings, Martin von Gagern -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From Martin.vGagern at gmx.net Sat Feb 21 14:57:42 2009 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Sat, 21 Feb 2009 14:57:42 +0100 Subject: [Help-gnutls] Default record version In-Reply-To: <499FF411.40009@gmx.net> References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org> <49986DCC.3030102@gmx.net> <499FE4A1.3000805@gnutls.org> <499FF411.40009@gmx.net> Message-ID: <49A00856.1040707@gmx.net> Martin von Gagern wrote: > Nikos Mavrogiannopoulos wrote: >> The commit below adds a priority string called SSL3_RECORD_VERSION >> that forces a compatibility mode where an SSL 3.0 record version is set >> on the client hello. I have backported it to 2.6 branch as well. > > Thanks a lot! I'll test that, and get back to you if anything doesn't > work as expected. Otherwise that seems like a suitable solution. The implementation itself seems to work well enough, thanks for that! You might want to check the generated documentation, though. Looking at the man page of gnutls_priority_init(3), it looks like gdoc was eating the percent signs, while nroff eats lines starting with an apostrophe. It would also be nice to have a test in gnutls-cli-debug, to see whether a connection can be established with SSL3 record version but TLS1.1 client hello version, and if so, what version was actually negotiated. Greetings, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Sat Feb 21 16:23:21 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sat, 21 Feb 2009 17:23:21 +0200 Subject: [Help-gnutls] Default record version In-Reply-To: <49A00856.1040707@gmx.net> References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org> <49986DCC.3030102@gmx.net> <499FE4A1.3000805@gnutls.org> <499FF411.40009@gmx.net> <49A00856.1040707@gmx.net> Message-ID: <49A01C69.2000708@gnutls.org> Martin von Gagern wrote: > You might want to check the generated documentation, though. Looking at > the man page of gnutls_priority_init(3), it looks like gdoc was eating > the percent signs, while nroff eats lines starting with an apostrophe. Corrected. Thank you. regards, Nikos From Martin.vGagern at gmx.net Sat Feb 21 17:17:54 2009 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Sat, 21 Feb 2009 17:17:54 +0100 Subject: [Help-gnutls] Default record version In-Reply-To: <49A01C69.2000708@gnutls.org> References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org> <49986DCC.3030102@gmx.net> <499FE4A1.3000805@gnutls.org> <499FF411.40009@gmx.net> <49A00856.1040707@gmx.net> <49A01C69.2000708@gnutls.org> Message-ID: <49A02932.6060306@gmx.net> Nikos Mavrogiannopoulos wrote: > Corrected. Thank you. No, that's not the one I'm talking about. I wrote about gnutls_priority_init(3) while you fixed gnutls-cli(1). The attached patch fixes gnutls_priority_init(3), but in a very hackish way, treating a percent sign as indicating a constant only if it is not immediately preceded by a double quote. I guess it would be nice to have some kind of generic escaping mechanism in order to include verbatim % and @ characters. Up to you to decide how you would like to encode this. The current hack works for current gnutls, as the gnutls_priority_init contains the only occurrences of ``"%'' inside a documentation comment, and none of them is a constant. Greetings, Martin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: percent-hack.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From nmav at gnutls.org Sun Feb 22 10:10:04 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 22 Feb 2009 11:10:04 +0200 Subject: [Help-gnutls] Default record version In-Reply-To: <49A02932.6060306@gmx.net> References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org> <49986DCC.3030102@gmx.net> <499FE4A1.3000805@gnutls.org> <499FF411.40009@gmx.net> <49A00856.1040707@gmx.net> <49A01C69.2000708@gnutls.org> <49A02932.6060306@gmx.net> Message-ID: <49A1166C.6000703@gnutls.org> Martin von Gagern wrote: > Nikos Mavrogiannopoulos wrote: >> Corrected. Thank you. > > No, that's not the one I'm talking about. I wrote about > gnutls_priority_init(3) while you fixed gnutls-cli(1). The attached > patch fixes gnutls_priority_init(3), but in a very hackish way, treating > a percent sign as indicating a constant only if it is not immediately > preceded by a double quote. Applied as is. Thank you! regards, Nikos From Martin.vGagern at gmx.net Sun Feb 22 10:19:50 2009 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Sun, 22 Feb 2009 10:19:50 +0100 Subject: [Help-gnutls] Default record version In-Reply-To: <499FE4A1.3000805@gnutls.org> References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org> <49986DCC.3030102@gmx.net> <499FE4A1.3000805@gnutls.org> Message-ID: <49A118B6.8020102@gmx.net> Nikos Mavrogiannopoulos wrote: > The commit below adds a priority string called SSL3_RECORD_VERSION > that forces a compatibility mode where an SSL 3.0 record version is set > on the client hello. I have backported it to 2.6 branch as well. Pidgin is now using %SSL3_RECORD_VERSION, so I'm looking forward to the next releases to actually contain this feature. When will they happen? Thanks and greetings, Martin http://developer.pidgin.im/viewmtn/revision/info/c84a41f40179331c218ac05005ce7805129049e5 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From simon at josefsson.org Sun Feb 22 12:39:55 2009 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 22 Feb 2009 12:39:55 +0100 Subject: [Help-gnutls] Re: Default record version In-Reply-To: <49A118B6.8020102@gmx.net> (Martin von Gagern's message of "Sun, 22 Feb 2009 10:19:50 +0100") References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org> <49986DCC.3030102@gmx.net> <499FE4A1.3000805@gnutls.org> <49A118B6.8020102@gmx.net> Message-ID: <87ljrybsz8.fsf@mocca.josefsson.org> Martin von Gagern writes: > Nikos Mavrogiannopoulos wrote: >> The commit below adds a priority string called SSL3_RECORD_VERSION >> that forces a compatibility mode where an SSL 3.0 record version is set >> on the client hello. I have backported it to 2.6 branch as well. > > Pidgin is now using %SSL3_RECORD_VERSION, so I'm looking forward to the > next releases to actually contain this feature. When will they happen? The gnutls 2.7.x branch is in a pretty good state. The only thing I'm aware of is that we should finish the TLS 1.2 implementation. Alternatively, we could also disable the TLS 1.2 support until we have finished the implementation. (The current TLS 1.2 support is for an old TLS 1.2 draft which doesn't interoperate with the final TLS 1.2...) I don't think I will have time to look into this in the next few weeks though. Also, this isn't a regression over GnuTLS 2.6.x which has the same partial TLS 1.2 implementation. So we could also just document this fact, and release now. /Simon From nmav at gnutls.org Sun Feb 22 17:14:28 2009 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Sun, 22 Feb 2009 18:14:28 +0200 Subject: [Help-gnutls] Re: Default record version In-Reply-To: <87ljrybsz8.fsf@mocca.josefsson.org> References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org> <49986DCC.3030102@gmx.net> <499FE4A1.3000805@gnutls.org> <49A118B6.8020102@gmx.net> <87ljrybsz8.fsf@mocca.josefsson.org> Message-ID: <49A179E4.7050004@gnutls.org> Simon Josefsson wrote: > I don't think I will have time to look into this in the next few weeks > though. > > Also, this isn't a regression over GnuTLS 2.6.x which has the same > partial TLS 1.2 implementation. So we could also just document this > fact, and release now. I have backported the fix to 2.6 release as well so it doesn't have to be 2.7 only for that. regards, Nikos From simon at josefsson.org Mon Feb 23 17:50:42 2009 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 23 Feb 2009 17:50:42 +0100 Subject: [Help-gnutls] Re: Default record version In-Reply-To: <49A1166C.6000703@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sun, 22 Feb 2009 11:10:04 +0200") References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org> <49986DCC.3030102@gmx.net> <499FE4A1.3000805@gnutls.org> <499FF411.40009@gmx.net> <49A00856.1040707@gmx.net> <49A01C69.2000708@gnutls.org> <49A02932.6060306@gmx.net> <49A1166C.6000703@gnutls.org> Message-ID: <87wsbh2j31.fsf@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > Martin von Gagern wrote: >> Nikos Mavrogiannopoulos wrote: >>> Corrected. Thank you. >> >> No, that's not the one I'm talking about. I wrote about >> gnutls_priority_init(3) while you fixed gnutls-cli(1). The attached >> patch fixes gnutls_priority_init(3), but in a very hackish way, treating >> a percent sign as indicating a constant only if it is not immediately >> preceded by a double quote. > > Applied as is. Thank you! This seems to break texinfo building: http://autobuild.josefsson.org/gnutls/log-200902222047566880000.txt /Simon From Martin.vGagern at gmx.net Mon Feb 23 23:33:26 2009 From: Martin.vGagern at gmx.net (Martin von Gagern) Date: Mon, 23 Feb 2009 23:33:26 +0100 Subject: [Help-gnutls] Re: Default record version In-Reply-To: <87wsbh2j31.fsf@mocca.josefsson.org> References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org> <49986DCC.3030102@gmx.net> <499FE4A1.3000805@gnutls.org> <499FF411.40009@gmx.net> <49A00856.1040707@gmx.net> <49A01C69.2000708@gnutls.org> <49A02932.6060306@gmx.net> <49A1166C.6000703@gnutls.org> <87wsbh2j31.fsf@mocca.josefsson.org> Message-ID: <49A32436.60503@gmx.net> Simon Josefsson schrieb: > This seems to break texinfo building: > > http://autobuild.josefsson.org/gnutls/log-200902222047566880000.txt > > /Simon Probably because percent signs introduce a comment in texinfo, as they do in tex. The attached patch might fix that. Haven't tested it myself, as I only have remote access over a slow link to my build environment right now. I have to admit that things become even more hackish with this patch in place, as there are now even more places where the sequence "% receives special treatment. The main reason for this is that the replacements are stored in hashes, not lists, so I can't rely on the order of substitutions, therefore I can't first replace the constants and then replace all remaining percent signs. Maybe the replacement of % were better done somewhere in the corresponding output function, along with sepcial treatment for any other kind of special characters for the corresponding output language. Maybe those highlighting substitutions were better saved as arrays. Maybe those arrays should employ qr/.../ and '...' to avoid half of the backslashes and make things more readable. As you can see, there is a lot which could be improved about that script. And most improvements are not obvious, but require some kind of design decision, like what characters are special, how to escape them, where to handle what special cases, what other documentation syntax to emulate, stuff like that. If I don't forget it, maybe I can write a major patch for some of this some time next week. Before I start that, I would like to hear that you are interested in such a general improvement. You should also voice any thoughts you have as to what direction such improvements should take. Of course, I'd be more than happy if you fix this yourself. I'm not that eager to read and understand someone else's Perl code, even if that script seems to be a fairly tame specimen. Greetings, Martin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: percent-hack2.patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature URL: From simon at josefsson.org Thu Feb 26 12:13:38 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 26 Feb 2009 12:13:38 +0100 Subject: [Help-gnutls] GnuTLS 2.6.5 release candidate In-Reply-To: <49A179E4.7050004@gnutls.org> (Nikos Mavrogiannopoulos's message of "Sun, 22 Feb 2009 18:14:28 +0200") References: <4997EB28.8090100@gmx.net> <49985133.4010508@gnutls.org> <49986DCC.3030102@gmx.net> <499FE4A1.3000805@gnutls.org> <49A118B6.8020102@gmx.net> <87ljrybsz8.fsf@mocca.josefsson.org> <49A179E4.7050004@gnutls.org> Message-ID: <87iqmxwivx.fsf_-_@mocca.josefsson.org> Nikos Mavrogiannopoulos writes: > I have backported the fix to 2.6 release as well so it doesn't have to > be 2.7 only for that. I have prepared a 2.6.5 release candidate, please test it: http://daily.josefsson.org/gnutls-2.6/gnutls-2.6-20090226.tar.gz Right now it only contains this change: ** libgnutls: Added %SSL3_RECORD_VERSION priority string that allows to specify the client hello message record version. Used to overcome buggy TLS servers. Report by Martin von Gagern. Which really is a new feature rather than a fix, so I'd like to defer making the release until we have some more critical problems to fix, or when 6 weeks have passed, whichever comes first. Please test it as if it were a proper release, and let us know about any problems. /Simon