From simon at josefsson.org Tue Sep 4 09:44:55 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 04 Sep 2007 09:44:55 +0200 Subject: [gnutls-dev] GnuTLS 2.0.0 Message-ID: <87myw2an7s.fsf@mocca.josefsson.org> We are pleased to announce a new stable GnuTLS release: Version 2.0.0. 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 core GnuTLS library is distribute under the terms of the GNU Lesser General Public License version 2.1 (or later). The "extra" GnuTLS libraries -- which contains OpenPGP and TLS/IA support, LZO2 compression, the OpenSSL compatibility library -- and the self tests and command line tools are distributed under the GNU General Public License version 2.0 (or later). The manual is distributed under the GNU Free Documentation License version 1.2 (or later). The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ http://josefsson.org/gnutls/ What's New ========== The following changes have been made since GnuTLS 1.6: * Support for external RSA/DSA signing for TLS client authentication. This allows you to secure the private key better, for example by using privilege-separation techniques between the private key and the network client/server. * Support for signing X.509 certificates using RSA with SHA-256/384/512. * Experimental support for TLS 1.2 (disabled by default). The TLS 1.2 specification is not finalized yet, but we implement a draft version for testing. * Support for X.509 Proxy Certificates (RFC 3820) * Support for Supplemental handshakes messages (RFC 4680). * Support for TLS authorization extension (draft-housley-tls-authz-extns-07). * Support for the X.509 'otherName' Subject Altnerative Names (for XMPP). * Guile bindings for GnuTLS have been added, thanks to Ludovic Court?s. * Improve logic of gnutls_set_default_priority() which can now be more recommended. * New APIs to enumerate supported algorithms in the library. * New APIs to access X.509 Certificate extension sequentially. * New APIs to print X.509 Certificates and CRLs in human readable formats. * New APIs to extract X.509 Distinguished Names from certificates. * New APIs to handle pathLenConstraint in X.509 Basic Constraints. * Certtool can export more than one certificate to PKCS#12. * Several message translation improvements. * Instructions and improvements to easily set up a HTTPS test server. * Included copies updated to Libtasn1 1.1 and OpenCDK 0.6.4. * Build improvements for Windows, Mac OS X, uClinux, etc. * GnuTLS is now developed in GIT. * Improved manual * Many bugfixes and minor improvements. Getting the Software ==================== GnuTLS may be downloaded from one of the mirror sites or direct from . The list of mirrors can be found at . Note, that GnuPG is not available at ftp.gnu.org. Here are the BZIP2 compressed sources (4.6MB): ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.0.0.tar.bz2 http://josefsson.org/gnutls/releases/gnutls-2.0.0.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.0.0.tar.bz2.sig http://josefsson.org/gnutls/releases/gnutls-2.0.0.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.0.0.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: 2008-06-30] 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: 2008-06-30] 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: 985d86cb942b9d79abb5c8966439f23141ad803a gnutls-2.0.0.tar.bz2 9ffe06f0fea815daaf975e39cfa0be38edc74dc8908c05a6870dede0 gnutls-2.0.0.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: . If you wish to participate in the development of GnuTLS, you are invited to join our gnutls-dev mailing list, see: . 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 consists of libgpg-error 1.5, libgcrypt 1.3.0, libtasn1 1.1, opencdk 0.6.4, and GnuTLS 2.0.0. For more information about GnuTLS for Windows: http://josefsson.org/gnutls4win/ The Windows binary installer and PGP signature: http://josefsson.org/gnutls4win/gnutls-2.0.0.exe (24MB) http://josefsson.org/gnutls4win/gnutls-2.0.0.exe.sig The checksum values for SHA-1 and SHA-224 are: 0261c116f3abdf179c0a93d04488f06b693a128a gnutls-2.0.0.exe d8af39cb1bcecd5c8dc9386c68edb171a20720c88e53f5443abd0bbb gnutls-2.0.0.exe Internationalization ==================== GnuTLS messages have been translated into German, Malay, Polish and Swedish. 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, 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 ludovic.courtes at laas.fr Tue Sep 4 14:28:55 2007 From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Tue, 04 Sep 2007 14:28:55 +0200 Subject: [gnutls-dev] GnuTLS 2.0.0 References: <87myw2an7s.fsf@mocca.josefsson.org> Message-ID: <871wdefwc8.fsf@laas.fr> Hi, Simon Josefsson writes: > We are pleased to announce a new stable GnuTLS release: Version 2.0.0. I am "pleased" to report the first bug. ;-) "make check" was failing on `x509-certificates.scm' because `x509-certificate-dn-oid' was returning a bogus string. The issue is that Guile bindings were assuming that `gnutls_x509_crt_get_dn_oid ()' returned a null-terminated string, which is apparently not the case (we should improve the documentation in that respect). I'm surprised we did not catch it earlier, though. Thanks, Ludovic. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Guile-Fix-x509-certificate-dn-oid-and-related-fun.patch Type: text/x-patch Size: 1436 bytes Desc: The patch URL: From simon at josefsson.org Wed Sep 5 17:41:29 2007 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 05 Sep 2007 17:41:29 +0200 Subject: [gnutls-dev] GnuTLS 2.0.0 In-Reply-To: <871wdefwc8.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Tue, 04 Sep 2007 14:28:55 +0200") References: <87myw2an7s.fsf@mocca.josefsson.org> <871wdefwc8.fsf@laas.fr> Message-ID: <87bqchunkm.fsf@mocca.josefsson.org> ludovic.courtes at laas.fr (Ludovic Court?s) writes: > Hi, > > Simon Josefsson writes: > >> We are pleased to announce a new stable GnuTLS release: Version 2.0.0. > > I am "pleased" to report the first bug. ;-) Whee. > "make check" was failing on `x509-certificates.scm' because > `x509-certificate-dn-oid' was returning a bogus string. The issue is > that Guile bindings were assuming that `gnutls_x509_crt_get_dn_oid ()' > returned a null-terminated string, which is apparently not the case (we > should improve the documentation in that respect). > > I'm surprised we did not catch it earlier, though. Me too, and I can't reproduce it. Perhaps this problem is related to the -rpath vs libguile in /usr/local/lib discussion that probably never were solved? Which libgnutls.so are your libguile-gnutls libraries linking to? I'd like to reproduce the problem before applying the patch. /Simon From thresh at altlinux.ru Mon Sep 10 00:51:19 2007 From: thresh at altlinux.ru (Pavlov Konstantin) Date: Mon, 10 Sep 2007 02:51:19 +0400 Subject: [gnutls-dev] GnuTLS 2.0.0 In-Reply-To: <87myw2an7s.fsf@mocca.josefsson.org> References: <87myw2an7s.fsf@mocca.josefsson.org> Message-ID: <20070909225119.GA24833@cryo.net.ru> On Tue, Sep 04, 2007 at 09:44:55AM +0200, Simon Josefsson wrote: > We are pleased to announce a new stable GnuTLS release: Version 2.0.0. Congratulations! So, this is a new stable version we all should use in stable distributions, right? -- You will be imprisoned for contributing your time and skill to a bank robbery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From ludovic.courtes at laas.fr Mon Sep 10 09:48:22 2007 From: ludovic.courtes at laas.fr (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Mon, 10 Sep 2007 09:48:22 +0200 Subject: [gnutls-dev] GnuTLS 2.0.0 References: <87myw2an7s.fsf@mocca.josefsson.org> <871wdefwc8.fsf@laas.fr> <87bqchunkm.fsf@mocca.josefsson.org> Message-ID: <87sl5nc661.fsf@laas.fr> Hi, Simon Josefsson writes: > ludovic.courtes at laas.fr (Ludovic Court?s) writes: >> "make check" was failing on `x509-certificates.scm' because >> `x509-certificate-dn-oid' was returning a bogus string. The issue is >> that Guile bindings were assuming that `gnutls_x509_crt_get_dn_oid ()' >> returned a null-terminated string, which is apparently not the case (we >> should improve the documentation in that respect). >> >> I'm surprised we did not catch it earlier, though. > > Me too, and I can't reproduce it. Perhaps this problem is related to > the -rpath vs libguile in /usr/local/lib discussion that probably never > were solved? Which libgnutls.so are your libguile-gnutls libraries > linking to? No, it's an actual bug, observed on PowerPC (and the RPATH problem _was_ solved AFAICS). Is `gnutls_x509_crt_get_dn_oid ()' supposed to return a null-terminated string? The documentation doesn't mention it and it seems that it's not returning a null-terminated string. In any case, using `scm_take_locale_stringn ()' instead of just `scm_take_locale_string ()' can't hurt. Thanks, Ludovic. From ludo at gnu.org Mon Sep 10 18:30:15 2007 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Mon, 10 Sep 2007 18:30:15 +0200 Subject: [gnutls-dev] On key usage flags References: <87ps27vsyw.fsf@chbouib.org> Message-ID: <87tzq2h4a0.fsf@chbouib.org> Hi, ludo at gnu.org (Ludovic Court?s) writes: > Recently, I tried to use OpenPGP-based authentication with the > `RSA_NULL_MD5' cipher suite (i.e., no encryption). To that end, I > generated (with GnuPG) an RSA OpenPGP key pair, and wrote a test program > that specifies the right kx/cipher/mac priorities. > > Unfortunately, that doesn't work, because the generated OpenPGP key > doesn't have the "encryption" key usage flag, which means that > `_gnutls_selected_cert_supported_kx ()' will reject it while looking for > a cipher suite. > > I don't know about X.509, but OpenPGP key usage flags are informative > rather than authoritative. Thus, I'm wondering whether we should really > systematically pay attention to them. Providing the option to honor > them (e.g., through user-definable hooks) may be wise, but enforcing it > doesn't feel right. In addition, GPG doesn't really permit usage flags > to be chosen, making it hard to create a suitable key. Ping! :-) Thanks in advance, Ludovic. From ludo at gnu.org Mon Sep 10 19:47:00 2007 From: ludo at gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Date: Mon, 10 Sep 2007 19:47:00 +0200 Subject: [gnutls-dev] On key usage flags References: <87ps27vsyw.fsf@chbouib.org> Message-ID: <87hcm2e7l7.fsf@chbouib.org> Hi, ludo at gnu.org (Ludovic Court?s) writes: > I don't know about X.509, but OpenPGP key usage flags are informative > rather than authoritative. Thus, I'm wondering whether we should really > systematically pay attention to them. Providing the option to honor > them (e.g., through user-definable hooks) may be wise, but enforcing it > doesn't feel right. In addition, GPG doesn't really permit usage flags > to be chosen, making it hard to create a suitable key. I read the relevant code again to get a better understanding of what's going on. Here are my findings and proposals. * `_gnutls_check_key_usage ()' uses CERT->KEY_USAGE. * `openpgp_pk_to_gnutls_cert ()' initializes CERT->KEY_USAGE based on the RFC 2440 key flags (Section 5.2.3.20) found in the key[*]. * Conversely, `gnutls_openpgp_key_get_key_usage ()' returns the actual capabilities of the key's algorithm rather than the OpenPGP usage flags. This shows an inconsistency with OpenPGP key usage handling: We should stick to either RFC 2440 key flags or to "actual" key flags based on the key's algorithm capabilities. For X.509, GnuTLS doesn't have this problem: `_gnutls_x509_crt_to_gcert ()' uses the result from `gnutls_x509_crt_get_key_usage ()', which is the "alleged" key usage flags found in the certificate (i.e., roughly the equivalent of RFC 2440's key flags). Therefore: * For consistency, `gnutls_openpgp_key_get_key_usage ()' should be changed to match the behavior of `openpgp_pk_to_gnutls_cert ()', i.e., to return the RFC 2440 key flags. * X.509 users can override a certificate's usage flags through `gnutls_x509_crt_set_key_usage ()'. OpenPGP should have a similar facility, namely `gnutls_openpgp_key_set_key_usage ()'. Opinions? Thanks, Ludovic. [*] Unless said flags are zeroed, in which case it defaults to actual key usage flags---but this situation is highly unlikely. From simon at josefsson.org Tue Sep 11 08:29:38 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 11 Sep 2007 08:29:38 +0200 Subject: [gnutls-dev] GnuTLS 2.0.0 In-Reply-To: <20070909225119.GA24833@cryo.net.ru> (Pavlov Konstantin's message of "Mon, 10 Sep 2007 02:51:19 +0400") References: <87myw2an7s.fsf@mocca.josefsson.org> <20070909225119.GA24833@cryo.net.ru> Message-ID: <87zlztk94d.fsf@mocca.josefsson.org> Pavlov Konstantin writes: > On Tue, Sep 04, 2007 at 09:44:55AM +0200, Simon Josefsson wrote: >> We are pleased to announce a new stable GnuTLS release: Version 2.0.0. > > Congratulations! > > So, this is a new stable version we all should use in stable > distributions, right? Yup! Of course, as with all newly released stable branches, there may be problems, but I think we'll solve them quickly if you report them. Still, I think 2.0.0 is better and more reliable than 1.6.x. /Simon From simon at josefsson.org Tue Sep 11 08:47:35 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 11 Sep 2007 08:47:35 +0200 Subject: [gnutls-dev] GnuTLS 2.0.0 In-Reply-To: <87sl5nc661.fsf@laas.fr> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Mon, 10 Sep 2007 09:48:22 +0200") References: <87myw2an7s.fsf@mocca.josefsson.org> <871wdefwc8.fsf@laas.fr> <87bqchunkm.fsf@mocca.josefsson.org> <87sl5nc661.fsf@laas.fr> Message-ID: <87veahk8ag.fsf@mocca.josefsson.org> ludovic.courtes at laas.fr (Ludovic Court?s) writes: > No, it's an actual bug, observed on PowerPC (and the RPATH problem > _was_ solved AFAICS). Ok, I applied the patch. > Is `gnutls_x509_crt_get_dn_oid ()' supposed to return a > null-terminated string? The documentation doesn't mention it and it > seems that it's not returning a null-terminated string. I'm not sure, _gnutls_x509_get_dn_oid contains this code: len = strlen (oid) + 1; if (*sizeof_oid < (unsigned) len) { *sizeof_oid = len; gnutls_assert (); return GNUTLS_E_SHORT_MEMORY_BUFFER; } memcpy (_oid, oid, len); *sizeof_oid = len - 1; Which indicate that the intention is to copy the terminating zero. However, it may be that the call to asn1_read_value did not add a zero. That may be a bug, typically asn1_read_value do zero-terminate strings if I recall correctly (although it isn't well documented either). > In any case, using `scm_take_locale_stringn ()' instead of just > `scm_take_locale_string ()' can't hurt. Right. /Simon From simon at josefsson.org Tue Sep 11 11:00:36 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 11 Sep 2007 11:00:36 +0200 Subject: [gnutls-dev] Time-based release schedule and GnuTLS v2.2 plans Message-ID: <877imxk24r.fsf@mocca.josefsson.org> I like the time-based release schedule of Gnome, Ubuntu etc, so I'd like to do the same for GnuTLS. I'm thinking of having 3 stable releases per year. I'm not sure about the timing, but considering that we just had a stable release, I'm thinking 1 January, 1 May and 1 September. What do you think? We need to begin planning for v2.2 as well. Here are some ideas: * Integrate CAMELLIA support, we have a patch and copyright papers but the patch need some attention. * Opaque PRF Input support. I'm working on this now. * Better TLS extension API. Make it possible to define a TLS extension from the application or third party library. Not sure if this is useful, it is rather simple to add it inside the library now. Wishful thinking: * Integrate tighter PKCS#11 support. * Optimization -- run cachegrind on the test-suite etc. * Separate X.509 stuff into a separate library. Especially the PKCS#8 and PKCS#7 stuff. This would lead to a smaller library for embedded systems. More ideas? /Simon From fweimer at bfk.de Tue Sep 11 11:30:41 2007 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 11 Sep 2007 11:30:41 +0200 Subject: [gnutls-dev] Time-based release schedule and GnuTLS v2.2 plans In-Reply-To: <877imxk24r.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 11 Sep 2007 11:00:36 +0200") References: <877imxk24r.fsf@mocca.josefsson.org> Message-ID: <827imxft1a.fsf@mid.bfk.de> * Simon Josefsson: > I like the time-based release schedule of Gnome, Ubuntu etc, so I'd like > to do the same for GnuTLS. I'm thinking of having 3 stable releases per > year. I'm not sure about the timing, but considering that we just had a > stable release, I'm thinking 1 January, 1 May and 1 September. What do > you think? A January 1st release date looks a bit unrealistic to me. Of course, this depends on your personal schedule and on your reliance on external contributors. Shifting a month in either direction might be a good idea. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From simon at josefsson.org Tue Sep 11 17:08:09 2007 From: simon at josefsson.org (Simon Josefsson) Date: Tue, 11 Sep 2007 17:08:09 +0200 Subject: [gnutls-dev] Time-based release schedule and GnuTLS v2.2 plans In-Reply-To: <827imxft1a.fsf@mid.bfk.de> (Florian Weimer's message of "Tue, 11 Sep 2007 11:30:41 +0200") References: <877imxk24r.fsf@mocca.josefsson.org> <827imxft1a.fsf@mid.bfk.de> Message-ID: <87zlztme92.fsf@mocca.josefsson.org> Florian Weimer writes: > * Simon Josefsson: > >> I like the time-based release schedule of Gnome, Ubuntu etc, so I'd like >> to do the same for GnuTLS. I'm thinking of having 3 stable releases per >> year. I'm not sure about the timing, but considering that we just had a >> stable release, I'm thinking 1 January, 1 May and 1 September. What do >> you think? > > A January 1st release date looks a bit unrealistic to me. Of course, > this depends on your personal schedule and on your reliance on > external contributors. Shifting a month in either direction might be > a good idea. January 1st also seems like a poor choice due to holidays. So I think we'll aim for February 1st. Regarding schedule, I don't think v2.2 should require that much effort. One of the points of having a time-based stable release policy is that we release on that day regardless of how much changes there has been. Even if we haven't made any changes at all (unlikely) we can release on time. We need a wiki to co-ordinate the release plans... although I'm quite worried about spam and having to spend time maintaining the wiki. Any volunteers here? Is it possible to setup a wiki and not having to spend significant time maintaining it (user registration, spam removal, password queries, etc..)? /Simon From mahesh.nayak at mgl.com Tue Sep 11 17:05:25 2007 From: mahesh.nayak at mgl.com (Mahesh Nayak) Date: Tue, 11 Sep 2007 15:05:25 +0000 (UTC) Subject: [gnutls-dev] =?utf-8?q?Encoding_of_Subject_Alternative_Name_havin?= =?utf-8?q?g_GNUTLS=5FSAN=5FIPADDRESS_as_data_type=2E?= Message-ID: Hello, I was trying to use the GNUTLS_SAN_IPADDRESS type for the API gnutls_x509_crt_set_subject_alternative_name(). I notice that when a X509v3 Certificate is created using certool API, the IP ADDRESS field in the packet is not being parsed by the openssl or XCA tool (OpenSSL shows the field as invalid). On further investigation, I got the following percept from the RFC 2459 ( for x509): RFC 2459 Internet X.509 Public Key Infrastructure January 1999 ? When the subjectAltName extension contains a iPAddress, the address MUST be stored in the octet string in "network byte order," as specified in RFC 791 [RFC 791]. The least significant bit (LSB) of each octet is the LSB of the corresponding byte in the network address. For IP Version 4, as specified in RFC 791, the octet string MUST contain exactly four octets. ? But I see from the GNUTLS and CERTTOOL source code that we never convert the char* to a network-byte-ordered-octet (for the IPADDRESS) (I traced from gnutls_x509_crt_set_subject_alternative_name in the gnutls source code) . We just go ahead with encoding the char* data in the certificate. Is there something that I am missing? Or is it a bug? If yes, could you please tell me an alternative method to have an IP address in the subject alternative name? Any help here is very valuable to me and is appreciated. Thanks, Mahesh. From yanagisawa at csg.is.titech.ac.jp Wed Sep 12 04:22:59 2007 From: yanagisawa at csg.is.titech.ac.jp (Yoshisato YANAGISAWA) Date: Wed, 12 Sep 2007 11:22:59 +0900 Subject: [gnutls-dev] Time-based release schedule and GnuTLS v2.2 plans In-Reply-To: <877imxk24r.fsf@mocca.josefsson.org> References: <877imxk24r.fsf@mocca.josefsson.org> Message-ID: <20070912112259.cc8cb835.yanagisawa@csg.is.titech.ac.jp> On Tue, 11 Sep 2007 11:00:36 +0200 Simon Josefsson wrote: > I like the time-based release schedule of Gnome, Ubuntu etc, so I'd > like to do the same for GnuTLS. I'm thinking of having 3 stable A periodic releasing should be a good idea to show activity. > We need to begin planning for v2.2 as well. Here are some ideas: > > * Integrate CAMELLIA support, we have a patch and copyright papers but > the patch need some attention. I update the camellia patch for v2.0. However, the patch need libgcrypt (>= 1.3.0) with camellia enabled. http://www.is.titech.ac.jp/~yanagis0/text/camellia/gnutls-2.0.0.patch http://www.is.titech.ac.jp/~yanagis0/text/camellia-e.html Does somebody know an autoconf-option to check ciphers supported by libgcrypt? Thanks, -- ------------------------------------------------------- Yoshisato YANAGISAWA Dept. of Mathematical and Computing Sciences, Graduate School of Information Science and Engineering, Tokyo Institute of Technology. /* If you are an *BSD user, let's join http://bsdstats.org/ */ From jas at pdc.kth.se Wed Sep 5 17:29:41 2007 From: jas at pdc.kth.se (Simon Josefsson) Date: Wed, 05 Sep 2007 17:29:41 +0200 Subject: [gnutls-dev] test Message-ID: <87k5r5uo4a.fsf@mocca.josefsson.org> test to see if bug-gnutls works From nobody at nowhere.josefsson.org Wed Sep 5 17:27:22 2007 From: nobody at nowhere.josefsson.org (Simon Josefsson) Date: Wed, 05 Sep 2007 17:27:22 +0200 Subject: [gnutls-dev] test Message-ID: <87odghuo85.fsf@mocca.josefsson.org> test to see if bug-gnutls works From wk at gnupg.org Wed Sep 12 22:44:13 2007 From: wk at gnupg.org (Werner Koch) Date: Wed, 12 Sep 2007 22:44:13 +0200 Subject: [gnutls-dev] Time-based release schedule and GnuTLS v2.2 plans In-Reply-To: <20070912112259.cc8cb835.yanagisawa@csg.is.titech.ac.jp> (Yoshisato YANAGISAWA's message of "Wed, 12 Sep 2007 11:22:59 +0900") References: <877imxk24r.fsf@mocca.josefsson.org> <20070912112259.cc8cb835.yanagisawa@csg.is.titech.ac.jp> Message-ID: <878x7b8vhe.fsf@wheatstone.g10code.de> On Wed, 12 Sep 2007 04:22, yanagisawa at csg.is.titech.ac.jp said: > I update the camellia patch for v2.0. However, the patch need libgcrypt > (>= 1.3.0) with camellia enabled. Yeah I know, the release of libgcryt 1.3.1 is delayed. Camellia will be enabled with that version by default. I want to check the random gatherer on Vista before doing this release. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From simon at josefsson.org Mon Sep 17 18:35:47 2007 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 17 Sep 2007 18:35:47 +0200 Subject: [gnutls-dev] Time-based release schedule and GnuTLS v2.2 plans In-Reply-To: <20070912112259.cc8cb835.yanagisawa@csg.is.titech.ac.jp> (Yoshisato YANAGISAWA's message of "Wed, 12 Sep 2007 11:22:59 +0900") References: <877imxk24r.fsf@mocca.josefsson.org> <20070912112259.cc8cb835.yanagisawa@csg.is.titech.ac.jp> Message-ID: <87y7f5ntb0.fsf@mocca.josefsson.org> Yoshisato YANAGISAWA writes: > On Tue, 11 Sep 2007 11:00:36 +0200 > Simon Josefsson wrote: > >> I like the time-based release schedule of Gnome, Ubuntu etc, so I'd >> like to do the same for GnuTLS. I'm thinking of having 3 stable > > A periodic releasing should be a good idea to show activity. Thanks for feedback on that. >> We need to begin planning for v2.2 as well. Here are some ideas: >> >> * Integrate CAMELLIA support, we have a patch and copyright papers but >> the patch need some attention. > > I update the camellia patch for v2.0. However, the patch need libgcrypt > (>= 1.3.0) with camellia enabled. > http://www.is.titech.ac.jp/~yanagis0/text/camellia/gnutls-2.0.0.patch > http://www.is.titech.ac.jp/~yanagis0/text/camellia-e.html Thanks! > Does somebody know an autoconf-option to check ciphers supported by > libgcrypt? It would not be fool-proof, so I suggest that only a warning is given in case the test fails, but the following test could work: libgcrypt-config --algorithms | grep -i camellia What do you think? I don't think we can require libgcrypt 1.3.0+ yet. Perhaps configure could disable camellia support if a sufficient recent libgcrypt is not detected? Btw, in gnutls_priority.c, the cipher_priority array is intended to be sorted by preference. I believe it is too early to prefer Camellia over AES and even 3DES by default today. Preferring Camellia over Arcfour may be a good idea though, we don't want to recommend arcfour to anyone. So please move camellia down a bit in the cipher_priority array. Opinions on this choice from others is very welcome. /Simon From yanagisawa at csg.is.titech.ac.jp Wed Sep 19 10:12:29 2007 From: yanagisawa at csg.is.titech.ac.jp (Yoshisato YANAGISAWA) Date: Wed, 19 Sep 2007 17:12:29 +0900 Subject: [gnutls-dev] Time-based release schedule and GnuTLS v2.2 plans In-Reply-To: <87y7f5ntb0.fsf@mocca.josefsson.org> References: <877imxk24r.fsf@mocca.josefsson.org> <20070912112259.cc8cb835.yanagisawa@csg.is.titech.ac.jp> <87y7f5ntb0.fsf@mocca.josefsson.org> Message-ID: <46F0D9ED.9080002@csg.is.titech.ac.jp> Simon Josefsson wrote: >> Does somebody know an autoconf-option to check ciphers supported by >> libgcrypt? > > It would not be fool-proof, so I suggest that only a warning is given in > case the test fails, but the following test could work: > > libgcrypt-config --algorithms | grep -i camellia > > What do you think? It seems to be premature to directly write code adding support for camellia. I will insert "#ifdef USE_CAMELLIA" to the source code. > I don't think we can require libgcrypt 1.3.0+ yet. Perhaps configure > could disable camellia support if a sufficient recent libgcrypt is not > detected? OK, I will change the script to disable camellia when the result of "libgcrypt --algorithms" don't have camellia. Code in configure script will be: if test "`$LIBGCRYPT_CONFIG --algorithms | grep -i camellia`"; then CFLAGS += -DUSE_CAMELLIA else echo "$as_me: WARNING: camellia feature disabled" >& 2 fi Do you think switch on and off by #ifdef in source code is good idea? > Btw, in gnutls_priority.c, the cipher_priority array is intended to be > sorted by preference. I believe it is too early to prefer Camellia over > AES and even 3DES by default today. Preferring Camellia over Arcfour > may be a good idea though, we don't want to recommend arcfour to anyone. > So please move camellia down a bit in the cipher_priority array. > Opinions on this choice from others is very welcome. I also move camellia down between 3DES and Arcfour. However, after camellia will have been diffused, it should be preferred over 3DES. According to the European NESSIE, 3DES is not recommended block cipher. Since camellia has a higher security margin than AES, it could be preferred over AES in the future. Thank you, Yoshisato YANAGISAWA. From simon at josefsson.org Wed Sep 19 13:06:34 2007 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 19 Sep 2007 13:06:34 +0200 Subject: [gnutls-dev] Time-based release schedule and GnuTLS v2.2 plans In-Reply-To: <46F0D9ED.9080002@csg.is.titech.ac.jp> (Yoshisato YANAGISAWA's message of "Wed, 19 Sep 2007 17:12:29 +0900") References: <877imxk24r.fsf@mocca.josefsson.org> <20070912112259.cc8cb835.yanagisawa@csg.is.titech.ac.jp> <87y7f5ntb0.fsf@mocca.josefsson.org> <46F0D9ED.9080002@csg.is.titech.ac.jp> Message-ID: <874phqud6t.fsf@mocca.josefsson.org> Yoshisato YANAGISAWA writes: > Simon Josefsson wrote: >>> Does somebody know an autoconf-option to check ciphers supported by >>> libgcrypt? >> >> It would not be fool-proof, so I suggest that only a warning is given in >> case the test fails, but the following test could work: >> >> libgcrypt-config --algorithms | grep -i camellia >> >> What do you think? > > It seems to be premature to directly write code adding support for > camellia. I will insert "#ifdef USE_CAMELLIA" to the source code. Sounds good, although please use ENABLE_CAMELLIA to match the existing style. >> I don't think we can require libgcrypt 1.3.0+ yet. Perhaps configure >> could disable camellia support if a sufficient recent libgcrypt is not >> detected? > > OK, I will change the script to disable camellia when the result of > "libgcrypt --algorithms" don't have camellia. Code in configure script > will be: > > if test "`$LIBGCRYPT_CONFIG --algorithms | grep -i camellia`"; then > CFLAGS += -DUSE_CAMELLIA > else > echo "$as_me: WARNING: camellia feature disabled" >& 2 > fi > > Do you think switch on and off by #ifdef in source code is good idea? Yes. I'm assuming you use AC_DEFINE(ENABLE_CAMELLIA, 1, ...) and not modifying CFLAGS directly >> Btw, in gnutls_priority.c, the cipher_priority array is intended to be >> sorted by preference. I believe it is too early to prefer Camellia over >> AES and even 3DES by default today. Preferring Camellia over Arcfour >> may be a good idea though, we don't want to recommend arcfour to anyone. >> So please move camellia down a bit in the cipher_priority array. >> Opinions on this choice from others is very welcome. > > I also move camellia down between 3DES and Arcfour. Sounds good to me. > However, after camellia will have been diffused, it should be > preferred over 3DES. According to the European NESSIE, 3DES is not > recommended block cipher. Since camellia has a higher security margin > than AES, it could be preferred over AES in the future. We'll leave that decision to later. /Simon From simon at josefsson.org Wed Sep 19 15:08:14 2007 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 19 Sep 2007 15:08:14 +0200 Subject: [gnutls-dev] Time-based release schedule and GnuTLS v2.2 plans In-Reply-To: <877imxk24r.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Tue, 11 Sep 2007 11:00:36 +0200") References: <877imxk24r.fsf@mocca.josefsson.org> Message-ID: <87ps0epzup.fsf@mocca.josefsson.org> I've created http://trac.gnutls.org/ to track issues related to the roadmap of having stable releases three times a year. This also gives us a wiki, but please don't add anything until we sort out the license issue (there was a recent discussion about this, and I think there are recommended guidelines for wiki licenses for gnu projects). /Simon From simon at josefsson.org Wed Sep 19 16:35:07 2007 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 19 Sep 2007 16:35:07 +0200 Subject: [gnutls-dev] Time-based release schedule and GnuTLS v2.2 plans In-Reply-To: <87ps0epzup.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed, 19 Sep 2007 15:08:14 +0200") References: <877imxk24r.fsf@mocca.josefsson.org> <87ps0epzup.fsf@mocca.josefsson.org> Message-ID: <87ejguoh9g.fsf@mocca.josefsson.org> Simon Josefsson writes: > I've created > > http://trac.gnutls.org/ > > to track issues related to the roadmap of having stable releases three > times a year. > > This also gives us a wiki, but please don't add anything until we sort > out the license issue (there was a recent discussion about this, and I > think there are recommended guidelines for wiki licenses for gnu > projects). The guidelines weren't that useful, so I just noted on the front page that: Feel free to add GnuTLS-related information to the Wiki. Note that unless you assign the copyright of your contribution to the FSF, we cannot use it in the official distribution (e.g., in the manual). /Simon From andrew.w.nosenko at gmail.com Thu Sep 20 12:30:12 2007 From: andrew.w.nosenko at gmail.com (Andrew W. Nosenko) Date: Thu, 20 Sep 2007 13:30:12 +0300 Subject: [gnutls-dev] Time-based release schedule and GnuTLS v2.2 plans In-Reply-To: <46F0D9ED.9080002@csg.is.titech.ac.jp> References: <877imxk24r.fsf@mocca.josefsson.org> <20070912112259.cc8cb835.yanagisawa@csg.is.titech.ac.jp> <87y7f5ntb0.fsf@mocca.josefsson.org> <46F0D9ED.9080002@csg.is.titech.ac.jp> Message-ID: <6161f3180709200330q697aac98yccbcbd50222e60ef@mail.gmail.com> On 9/19/07, Yoshisato YANAGISAWA wrote: > OK, I will change the script to disable camellia when the result of > "libgcrypt --algorithms" don't have camellia. Code in configure script > will be: > > if test "`$LIBGCRYPT_CONFIG --algorithms | grep -i camellia`"; then > CFLAGS += -DUSE_CAMELLIA > else > echo "$as_me: WARNING: camellia feature disabled" >& 2 > fi Please, use AC_MSG_WARN([camellia feature disabled]) or some another AC_MSG_*() macro at your taste instead of direct "echo". "echo" doesn't handle possible descriptor's redirection in 'configure' and doesn't duplicate message to the 'config.log'. Second: why warning at all and not something like AC_MSG_CHECKING([for camelia support in libgcrypt]) # ... actual tests here ... # following assumes that result stored in the shell variable # 'is_camelia_present' in the form 'yes' or 'no'. if test x$is_camelia_present = xyes then AC_MSG_RESULT([yes]) # ... and some additional acrtions if you want else AC_MSG_RESULT([no]) # ... and some additional acrtions if you want fi -- Andrew W. Nosenko From simon at josefsson.org Thu Sep 20 14:16:47 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 20 Sep 2007 14:16:47 +0200 Subject: [gnutls-dev] GnuTLS 2.0.1 Message-ID: <87bqbxsf9s.fsf@mocca.josefsson.org> We are pleased to announce a new stable GnuTLS release: Version 2.0.1. 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 core GnuTLS library is distribute under the terms of the GNU Lesser General Public License version 2.1 (or later). The "extra" GnuTLS libraries -- which contains OpenPGP and TLS/IA support, LZO2 compression, the OpenSSL compatibility library -- and the self tests and command line tools are distributed under the GNU General Public License version 2.0 (or later). The manual is distributed under the GNU Free Documentation License version 1.2 (or later). The project page of the library is available at: http://www.gnutls.org/ http://www.gnu.org/software/gnutls/ http://josefsson.org/gnutls/ What's New ========== The following changes have been made since GnuTLS 2.0.0: ** New directory doc/credentials/ with test credentials. This collects the test credentials from the web page and from src/. The script gnutls-http-serv has also been moved to that directory. ** Update SRP extension type and cipher suite with official IANA values. This breaks backwards compatibility with SRP in older versions of GnuTLS, but this is intentional to speed up the adoption of the official values. The old values we used were incorrect. ** Guile: Fix `x509-certificate-dn-oid' ** 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 . Note, that GnuPG is not available at ftp.gnu.org. Here are the BZIP2 compressed sources (4.7MB): ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.0.1.tar.bz2 http://josefsson.org/gnutls/releases/gnutls-2.0.1.tar.bz2 Here are OpenPGP detached signatures signed using key 0xB565716F: ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.0.1.tar.bz2.sig http://josefsson.org/gnutls/releases/gnutls-2.0.1.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.0.1.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: 2008-06-30] 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: 2008-06-30] 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: 2e5cee3021a9f8f62e4fa90c9d67f8d448dbbfcf gnutls-2.0.1.tar.bz2 b31ae61e0452fdc1a3c9c014857daf98d1a735c3cf04b7842925cf09 gnutls-2.0.1.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: . If you wish to participate in the development of GnuTLS, you are invited to join our gnutls-dev mailing list, see: . 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 consists of libgpg-error 1.5, libgcrypt 1.3.0, libtasn1 1.1, opencdk 0.6.4, and GnuTLS 2.0.0. For more information about GnuTLS for Windows: http://josefsson.org/gnutls4win/ Internationalization ==================== GnuTLS messages have been translated into German, Malay, Polish and Swedish. 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, 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 simon at josefsson.org Thu Sep 20 14:21:49 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 20 Sep 2007 14:21:49 +0200 Subject: [gnutls-dev] Time-based release schedule and GnuTLS v2.2 plans In-Reply-To: <6161f3180709200330q697aac98yccbcbd50222e60ef@mail.gmail.com> (Andrew W. Nosenko's message of "Thu, 20 Sep 2007 13:30:12 +0300") References: <877imxk24r.fsf@mocca.josefsson.org> <20070912112259.cc8cb835.yanagisawa@csg.is.titech.ac.jp> <87y7f5ntb0.fsf@mocca.josefsson.org> <46F0D9ED.9080002@csg.is.titech.ac.jp> <6161f3180709200330q697aac98yccbcbd50222e60ef@mail.gmail.com> Message-ID: <87sl59plwi.fsf@mocca.josefsson.org> "Andrew W. Nosenko" writes: > On 9/19/07, Yoshisato YANAGISAWA wrote: >> OK, I will change the script to disable camellia when the result of >> "libgcrypt --algorithms" don't have camellia. Code in configure script >> will be: >> >> if test "`$LIBGCRYPT_CONFIG --algorithms | grep -i camellia`"; then >> CFLAGS += -DUSE_CAMELLIA >> else >> echo "$as_me: WARNING: camellia feature disabled" >& 2 >> fi > > Please, use > AC_MSG_WARN([camellia feature disabled]) > or some another AC_MSG_*() macro at your taste instead of direct "echo". > "echo" doesn't handle possible descriptor's redirection in 'configure' > and doesn't duplicate message to the 'config.log'. I agree, although I think that was the intention (notice that he said 'Code in configure script' not configure.in script). > Second: why warning at all and not something like > AC_MSG_CHECKING([for camelia support in libgcrypt]) > # ... actual tests here ... > # following assumes that result stored in the shell variable > # 'is_camelia_present' in the form 'yes' or 'no'. > if test x$is_camelia_present = xyes > then > AC_MSG_RESULT([yes]) > # ... and some additional acrtions if you want > else > AC_MSG_RESULT([no]) > # ... and some additional acrtions if you want > fi Yeah, I agree with that too. /Simon From wk at gnupg.org Thu Sep 20 15:45:11 2007 From: wk at gnupg.org (Werner Koch) Date: Thu, 20 Sep 2007 15:45:11 +0200 Subject: [gnutls-dev] Time-based release schedule and GnuTLS v2.2 plans In-Reply-To: <46F0D9ED.9080002@csg.is.titech.ac.jp> (Yoshisato YANAGISAWA's message of "Wed, 19 Sep 2007 17:12:29 +0900") References: <877imxk24r.fsf@mocca.josefsson.org> <20070912112259.cc8cb835.yanagisawa@csg.is.titech.ac.jp> <87y7f5ntb0.fsf@mocca.josefsson.org> <46F0D9ED.9080002@csg.is.titech.ac.jp> Message-ID: <87sl59bgd4.fsf@wheatstone.g10code.de> On Wed, 19 Sep 2007 10:12, yanagisawa at csg.is.titech.ac.jp said: > It seems to be premature to directly write code adding support for > camellia. I will insert "#ifdef USE_CAMELLIA" to the source code. What about #define MY_GCRY_CIPHER_CAMELLIA128 310 and using a runtime test like I do in GnuPG: if (!gcry_cipher_test_algo (MY_GCRY_CIPHER_CAMELLIA128)) yes_we_can_do_with_camellia (); Make a note somewhere to revise that code as soon as libgcrypt 1.3 is required. Shalom-Salam, Werner -- Die Gedanken sind frei. Auschnahme regelt ein Bundeschgesetz. From simon at josefsson.org Thu Sep 20 16:45:22 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 20 Sep 2007 16:45:22 +0200 Subject: [gnutls-dev] GnuTLS 2.1.0 Message-ID: <87k5qlpf99.fsf@mocca.josefsson.org> I've branched off 'gnutls_2_0_x' and this release starts the 2.1.x experimental branch. The goals for the 2.1.x branch are tracked at: http://trac.gnutls.org/cgi-bin/trac.cgi/milestone/gnutls-2.2 More ideas are most welcome, just create a new ticket. News in this release: * Version 2.1.0 (released 2007-09-20) ** Support for draft-rescorla-tls-opaque-prf-input-00.txt. The support is disabled by default. Since no value has been allocated by the IANA for this extension yet, you will need to provide one yourself by invoking './configure --enable-opaque-prf-input=42'. ** Example code: Fix compilation flaw under MinGW. Note that the GnuTLS 2.1.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. Here are the compressed sources: ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.1.0.tar.bz2 http://josefsson.org/gnutls/releases/gnutls-2.1.0.tar.bz2 Here are GPG detached signatures signed using key 0xB565716F: ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.1.0.tar.bz2.sig http://josefsson.org/gnutls/releases/gnutls-2.1.0.tar.bz2.sig 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, 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. /Simon From simon at josefsson.org Thu Sep 20 17:06:10 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 20 Sep 2007 17:06:10 +0200 Subject: [gnutls-dev] GnuTLS 2.1.0 In-Reply-To: <87k5qlpf99.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Thu, 20 Sep 2007 16:45:22 +0200") References: <87k5qlpf99.fsf@mocca.josefsson.org> Message-ID: <87fy19peal.fsf@mocca.josefsson.org> Simon Josefsson writes: > ** Support for draft-rescorla-tls-opaque-prf-input-00.txt. > The support is disabled by default. Since no value has been allocated > by the IANA for this extension yet, you will need to provide one > yourself by invoking './configure --enable-opaque-prf-input=42'. FYI, I've updated the test server to run 2.1.0 with opaque prf input support enabled, see: http://www.gnu.org/software/gnutls/server.html If someone wants to do interop testing, feel free! Contact me or the post to the list if you need help or just to report success (which would be appreciated). I haven't done interop against anyone since I'm not aware of any publicly available implementations. /Simon From yanagisawa at csg.is.titech.ac.jp Fri Sep 21 20:17:23 2007 From: yanagisawa at csg.is.titech.ac.jp (Yoshisato YANAGISAWA) Date: Sat, 22 Sep 2007 03:17:23 +0900 Subject: [gnutls-dev] Time-based release schedule and GnuTLS v2.2 plans In-Reply-To: <87sl59plwi.fsf@mocca.josefsson.org> References: <877imxk24r.fsf@mocca.josefsson.org> <20070912112259.cc8cb835.yanagisawa@csg.is.titech.ac.jp> <87y7f5ntb0.fsf@mocca.josefsson.org> <46F0D9ED.9080002@csg.is.titech.ac.jp> <6161f3180709200330q697aac98yccbcbd50222e60ef@mail.gmail.com> <87sl59plwi.fsf@mocca.josefsson.org> Message-ID: <46F40AB3.3040501@csg.is.titech.ac.jp> According to Simon and Andrew's suggestions, I updated my camellia-patch. http://www.is.titech.ac.jp/~yanagis0/text/camellia/gnutls-2.0.0-0.1.patch http://www.is.titech.ac.jp/~yanagis0/text/camellia-e.html By using this patch, Camellia support will be automatically enabled and disabled according to the result of "libgcrypt-config --algorithms". I used some of autoconf and automake options to make the configure script. I will surely make a patch for 2.0.1 and 2.1.0 in a few days. I should also fix a bug. It is that program will include not the libgcrypt-header file specified by --with-libgcrypt-prefix option but --prefix option. Thank you, Yoshisato YANAGISAWA. From yanagisawa at csg.is.titech.ac.jp Sat Sep 22 04:56:25 2007 From: yanagisawa at csg.is.titech.ac.jp (Yoshisato YANAGISAWA) Date: Sat, 22 Sep 2007 11:56:25 +0900 Subject: [gnutls-dev] Time-based release schedule and GnuTLS v2.2 plans In-Reply-To: <46F40AB3.3040501@csg.is.titech.ac.jp> References: <877imxk24r.fsf@mocca.josefsson.org> <20070912112259.cc8cb835.yanagisawa@csg.is.titech.ac.jp> <87y7f5ntb0.fsf@mocca.josefsson.org> <46F0D9ED.9080002@csg.is.titech.ac.jp> <6161f3180709200330q697aac98yccbcbd50222e60ef@mail.gmail.com> <87sl59plwi.fsf@mocca.josefsson.org> <46F40AB3.3040501@csg.is.titech.ac.jp> Message-ID: <46F48459.7010507@csg.is.titech.ac.jp> I have released Camellia-patches for GNU TLS 2.0.1 and 2.1.0. http://www.is.titech.ac.jp/~yanagis0/text/camellia/gnutls-2.0.1.patch http://www.is.titech.ac.jp/~yanagis0/text/camellia/gnutls-2.1.0.patch http://www.is.titech.ac.jp/~yanagis0/text/camellia-e.html Please review them. Thank you, Yoshisato YANAGISAWA From simon at josefsson.org Mon Sep 24 13:44:30 2007 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 24 Sep 2007 13:44:30 +0200 Subject: [gnutls-dev] Time-based release schedule and GnuTLS v2.2 plans In-Reply-To: <46F48459.7010507@csg.is.titech.ac.jp> (Yoshisato YANAGISAWA's message of "Sat, 22 Sep 2007 11:56:25 +0900") References: <877imxk24r.fsf@mocca.josefsson.org> <20070912112259.cc8cb835.yanagisawa@csg.is.titech.ac.jp> <87y7f5ntb0.fsf@mocca.josefsson.org> <46F0D9ED.9080002@csg.is.titech.ac.jp> <6161f3180709200330q697aac98yccbcbd50222e60ef@mail.gmail.com> <87sl59plwi.fsf@mocca.josefsson.org> <46F40AB3.3040501@csg.is.titech.ac.jp> <46F48459.7010507@csg.is.titech.ac.jp> Message-ID: <87wsug1e5d.fsf@mocca.josefsson.org> Yoshisato YANAGISAWA writes: > I have released Camellia-patches for GNU TLS 2.0.1 and 2.1.0. > http://www.is.titech.ac.jp/~yanagis0/text/camellia/gnutls-2.0.1.patch > http://www.is.titech.ac.jp/~yanagis0/text/camellia/gnutls-2.1.0.patch > http://www.is.titech.ac.jp/~yanagis0/text/camellia-e.html Many thanks. I have integrated your patch into the 2.1.x branch. I added a NEWS entry and improved the ./configure logic slightly, to add a --disable-camellia option in case the libgcrypt auto-detect logic doesn't work reliably for someone. Regards, Simon From simon at josefsson.org Mon Sep 24 13:50:35 2007 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 24 Sep 2007 13:50:35 +0200 Subject: [gnutls-dev] GnuTLS 2.1.1 Message-ID: <87vea01dv8.fsf@mocca.josefsson.org> The GnuTLS 2.1.x branch is NOT what you want for your stable system. It is intended for developers and experienced users. News in this release: ** Added support for Camellia cipher, thanks to Yoshisato YANAGISAWA. Camellia is only enabled in GnuTLS if the installed libgcrypt has been compiled with Camellia support. See the libgcrypt documentation on how to enable it. Unconditionally disable it using the configure option --disable-camellia. Fixes #1. ** Properly document in the NEWS file the API change in the last release. The API changes made in the last release were: gnutls_oprfi_callback_func: ADD, new typedef function prototype. gnutls_oprfi_enable_client: ADD, new function. gnutls_oprfi_enable_server: ADD, new function. See the new section in the manual: http://www.gnu.org/software/gnutls/manual/html_node/Opaque-PRF-Input-TLS-Extension.html The goals for the 2.1.x branch are tracked at: http://trac.gnutls.org/cgi-bin/trac.cgi/milestone/gnutls-2.2 More ideas are welcome, just create a new ticket. Here are the compressed sources: ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.1.1.tar.bz2 http://josefsson.org/gnutls/releases/gnutls-2.1.1.tar.bz2 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, 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. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 419 bytes Desc: not available URL: From simon at josefsson.org Mon Sep 24 14:08:07 2007 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 24 Sep 2007 14:08:07 +0200 Subject: [gnutls-dev] GnuTLS 2.1.1 In-Reply-To: <87vea01dv8.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Mon, 24 Sep 2007 13:50:35 +0200") References: <87vea01dv8.fsf@mocca.josefsson.org> Message-ID: <87r6ko1d20.fsf@mocca.josefsson.org> Simon Josefsson writes: > ** Added support for Camellia cipher, thanks to Yoshisato YANAGISAWA. I've upgraded the test server, see: http://www.gnu.org/software/gnutls/server.html It now supports Camellia too. /Simon From yanagisawa at csg.is.titech.ac.jp Mon Sep 24 16:09:47 2007 From: yanagisawa at csg.is.titech.ac.jp (Yoshisato YANAGISAWA) Date: Mon, 24 Sep 2007 23:09:47 +0900 Subject: [gnutls-dev] GnuTLS 2.1.1 In-Reply-To: <87r6ko1d20.fsf@mocca.josefsson.org> References: <87vea01dv8.fsf@mocca.josefsson.org> <87r6ko1d20.fsf@mocca.josefsson.org> Message-ID: <46F7C52B.6080708@csg.is.titech.ac.jp> > I've upgraded the test server, see: > > http://www.gnu.org/software/gnutls/server.html > > It now supports Camellia too. Thank you for importing my camellia patch. I found a mistake in the document. CAMELLIA-192 should not be supported because only camellia-128 and camellia-256 are documented in the RFC 4132. Thank you, Yoshisato YANAGISAWA. From simon at josefsson.org Mon Sep 24 17:32:33 2007 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 24 Sep 2007 17:32:33 +0200 Subject: [gnutls-dev] GnuTLS 2.1.1 In-Reply-To: <46F7C52B.6080708@csg.is.titech.ac.jp> (Yoshisato YANAGISAWA's message of "Mon, 24 Sep 2007 23:09:47 +0900") References: <87vea01dv8.fsf@mocca.josefsson.org> <87r6ko1d20.fsf@mocca.josefsson.org> <46F7C52B.6080708@csg.is.titech.ac.jp> Message-ID: <87wsugxeni.fsf@mocca.josefsson.org> Yoshisato YANAGISAWA writes: >> I've upgraded the test server, see: >> >> http://www.gnu.org/software/gnutls/server.html >> >> It now supports Camellia too. > > Thank you for importing my camellia patch. > I found a mistake in the document. CAMELLIA-192 should not be supported > because only camellia-128 and camellia-256 are documented in the RFC 4132. Would you kindly provide a patch to remove all CAMELLIA-192 references? Thanks, Simon From simon at josefsson.org Mon Sep 24 17:35:58 2007 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 24 Sep 2007 17:35:58 +0200 Subject: [gnutls-dev] GnuTLS 2.1.1 In-Reply-To: <87wsugxeni.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Mon, 24 Sep 2007 17:32:33 +0200") References: <87vea01dv8.fsf@mocca.josefsson.org> <87r6ko1d20.fsf@mocca.josefsson.org> <46F7C52B.6080708@csg.is.titech.ac.jp> <87wsugxeni.fsf@mocca.josefsson.org> Message-ID: <87sl54xeht.fsf@mocca.josefsson.org> Simon Josefsson writes: > Yoshisato YANAGISAWA writes: > >>> I've upgraded the test server, see: >>> >>> http://www.gnu.org/software/gnutls/server.html >>> >>> It now supports Camellia too. >> >> Thank you for importing my camellia patch. >> I found a mistake in the document. CAMELLIA-192 should not be supported >> because only camellia-128 and camellia-256 are documented in the RFC 4132. > > Would you kindly provide a patch to remove all CAMELLIA-192 references? Sorry, I misread and thought the problem was in your patch, and not on that page. I have fixed the page now, and checked the NEWS entry to so I didn't mention 192 anywhere else as well. If you spot any other place where I might have said 192, please let me know. Thanks for your contribution! /Simon From n.mavrogiannopoulos at gmail.com Wed Sep 26 09:56:18 2007 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Wed, 26 Sep 2007 10:56:18 +0300 Subject: [gnutls-dev] [Help-gnutls] push/pull functions In-Reply-To: <20070925214829.GA27755@elmex> References: <20070925214829.GA27755@elmex> Message-ID: <200709261056.19008.n.mavrogiannopoulos@gmail.com> On Wednesday 26 September 2007, Robin Redeker wrote: > Hi! > I have a (maybe not so?) simple question: > Can I call gnutls_record_recv/gnutls_record_send safely while I'm in a > push/pull callback? As long as you don't use the same session, it should be safe. > The reason I'm asking is that I want to make bindings for GNU Smalltalk, > which has support for non-preemtive multiple threads of execution. gnutls can be used with multiple threads, as long as the gcrypt callbacks are set and the same session is not accessed by multiple threads. > What if some kind of re-handshake happens while I call > gnutls_record_recv? Will GnuTLS detect that it is still waiting for the > callback to read to return? A rehandshake will be detected by the return value of gnutls_record_recv(). It is in-band data so it should procceed normally. > And there is also another issue I stepped over while testing. I somehow > could't get the anonymous client example to work with gnutls-serv. > I've tried running the server with: > gnutls-serv -p 12331 --kx "Anon DH" > gnutls-serv -p 12331 --kx "Anon DH" -g > gnutls-serv -p 12331 --kx "Anon DH" --dhparams /tmp/dh.pem (with a > properly initialized dh.pem) Thank you for reporting this. It seems that it was a bug in the handshake function and couldn't negotiate anonymous DH if a certificate wasn't set. It must be corrected in the git repository (and attached patch). regards, Nikos -------------- next part -------------- diff --git a/lib/gnutls_handshake.c b/lib/gnutls_handshake.c index f8d2724..3787796 100644 --- a/lib/gnutls_handshake.c +++ b/lib/gnutls_handshake.c @@ -2801,11 +2801,11 @@ _gnutls_remove_unwanted_ciphersuites (gnutls_session_t session, int ret = 0; cipher_suite_st *newSuite, cs; int newSuiteSize = 0, i; - gnutls_certificate_credentials_t x509_cred; + gnutls_certificate_credentials_t cert_cred; gnutls_kx_algorithm_t kx; int server = session->security_parameters.entity == GNUTLS_SERVER ? 1 : 0; - gnutls_kx_algorithm_t *alg; - int alg_size; + gnutls_kx_algorithm_t *alg = NULL; + int alg_size = 0; /* if we should use a specific certificate, * we should remove all algorithms that are not supported @@ -2813,29 +2813,30 @@ _gnutls_remove_unwanted_ciphersuites (gnutls_session_t session, * method (CERTIFICATE). */ - x509_cred = + cert_cred = (gnutls_certificate_credentials_t) _gnutls_get_cred (session->key, GNUTLS_CRD_CERTIFICATE, NULL); - /* if x509_cred==NULL we should remove all X509 ciphersuites + /* If there are certificate credentials, find an appropriate certificate + * or disable them; */ - if (session->security_parameters.entity == GNUTLS_SERVER - && x509_cred != NULL) + && cert_cred != NULL) { ret = _gnutls_server_select_cert (session, requested_pk_algo); if (ret < 0) { gnutls_assert (); - return ret; + _gnutls_x509_log("Could not find an appropriate certificate: %s\n", gnutls_strerror(ret)); + cert_cred = NULL; } } /* get all the key exchange algorithms that are * supported by the X509 certificate parameters. */ - if ((ret = + if (cert_cred != NULL && (ret = _gnutls_selected_cert_supported_kx (session, &alg, &alg_size)) < 0) { gnutls_assert ();