From simon.posnjak at cetrtapot.si  Wed Sep 10 23:49:01 2003
From: simon.posnjak at cetrtapot.si (Simon Posnjak)
Date: Wed Sep 10 23:49:01 2003
Subject: [gnutls-dev] How stable...
Message-ID: <1063230716.4786.7.camel@hlod.dyndns.org>

Hi,

I`m working on a project that requires TLS layer for all
communications.  We are thinking of using gnutls for it, because of it
small size (verses openssl) - we are on an embedded platform.

My question is how stable is gnutls (for use in production environment)
- especially the development series. 

When do you plan to release 1.0 version? 

Is any body using your library in production (Any open source project
that are using it?)

Thank you.

		Regards Simon

-- 
Shhh... be vewy, vewy, quiet! I'm hunting wabbits...




From nmav at gnutls.org  Thu Sep 11 08:21:02 2003
From: nmav at gnutls.org (Nikos Mavroyanopoulos)
Date: Thu Sep 11 08:21:02 2003
Subject: [gnutls-dev] How stable...
In-Reply-To: <1063230716.4786.7.camel@hlod.dyndns.org>
References: <1063230716.4786.7.camel@hlod.dyndns.org>
Message-ID: <20030911062401.GA925@gnutls.org>

On Wed, Sep 10, 2003 at 11:51:56PM +0200, Simon Posnjak wrote:

> Hi,
> I`m working on a project that requires TLS layer for all
> communications.  We are thinking of using gnutls for it, because of it
> small size (verses openssl) - we are on an embedded platform.
> My question is how stable is gnutls (for use in production environment)
> - especially the development series. 
The stable series is tested in several projects and is stable
enough, although several features are missing. The development
series has several new features, but they have not been heavily
tested.

> When do you plan to release 1.0 version? 
The first prerelease will be out just after the openpgp part is
finished. This might take some weeks.

> Is any body using your library in production (Any open source project
> that are using it?)
Most GNU projects use gnutls. The larger project I can think of
is exim, but there are others as well.

> Thank you.
> 		Regards Simon

-- 
Nikos Mavroyanopoulos



From ivo at o2w.nl  Thu Sep 11 09:59:02 2003
From: ivo at o2w.nl (Ivo Timmermans)
Date: Thu Sep 11 09:59:02 2003
Subject: [gnutls-dev] [charlesduffy@isgenesis.com: Bug#210358: gnutls-bin: client fails out on supposedly non-fatal errors (regression)]
Message-ID: <20030911080035.GA23806@juarez>

FYI


	Ivo

-- 
`Contrariwise,' continued Tweedledee, `if it was so, it might be; and
if it were so, it would be; but as it isn't, it ain't. That's logic.'
	- Lewis Carroll, `Through the Looking-Glass'
-------------- next part --------------
An embedded message was scrubbed...
From: Charles Duffy <charlesduffy at isgenesis.com>
Subject: Bug#210358: gnutls-bin: client fails out on supposedly non-fatal errors (regression)
Date: Wed, 10 Sep 2003 18:55:27 -0500
Size: 4310
URL: </pipermail/attachments/20030911/b8dbf945/attachment.eml>

From nmav at gnutls.org  Thu Sep 11 15:08:02 2003
From: nmav at gnutls.org (Nikos Mavroyanopoulos)
Date: Thu Sep 11 15:08:02 2003
Subject: [gnutls-dev] [charlesduffy@isgenesis.com: Bug#210358: gnutls-bin: client fails out on supposedly non-fatal errors (regression)]
In-Reply-To: <20030911080035.GA23806@juarez>
References: <20030911080035.GA23806@juarez>
Message-ID: <20030911123617.GA3330@gnutls.org>

On Thu, Sep 11, 2003 at 10:00:35AM +0200, Ivo Timmermans wrote:

> FYI

I've just fixed that in the 0.9.x branch.

> 	Ivo
> 
> -- 
> `Contrariwise,' continued Tweedledee, `if it was so, it might be; and
> if it were so, it would be; but as it isn't, it ain't. That's logic.'
> 	- Lewis Carroll, `Through the Looking-Glass'

> From: Charles Duffy <charlesduffy at isgenesis.com>
> To: Debian Bug Tracking System <submit at bugs.debian.org>
> Subject: Bug#210358: gnutls-bin: client fails out on supposedly non-fatal errors (regression)
> Reply-To: Charles Duffy <charlesduffy at isgenesis.com>,
> 	210358 at bugs.debian.org
> X-Mailer: Ximian Evolution 1.4.4 
> Date: Wed, 10 Sep 2003 18:55:27 -0500
> X-Spam-Status: No, hits=-1.9 required=5.0
> 	tests=DEBIAN_BTS_BUG,RESENT_TO,X_LOOP
> 	version=2.55
> 
> Subject: gnutls-bin: client fails out on supposedly non-fatal errors (regression)
> Package: gnutls-bin
> Version: 0.8.9-2
> Severity: normal
> 
> The gnutls-cli from 0.8.9-2 doesn't handle incoming alerts except during the
> handshake process -- unlike the 0.3.5 release which, despite its other
> failings, has proper error handling for said case.
> 
> Most particularly, cli.c includes no gnutls_error_is_fatal call (in "simple
> client mode" after the handshake) to check the fatality of any negative return
> values from gnutls_read; rather, all errors are assumed to be fatal.
> Correspondingly, there is no support except during the handshake for printing
> alerts received to the user -- which also existed in 0.3.5 code.
> 
> This is additionally an issue for developers writing code based off the
> included sample client, who may be lead to believe that all error codes are
> necessarily fatal at this point.


-- 
Nikos Mavroyanopoulos



From me at rs3.ch  Mon Sep 15 18:12:01 2003
From: me at rs3.ch (Roman Hoog Antink)
Date: Mon Sep 15 18:12:01 2003
Subject: [gnutls-dev] Diffie Hellman interoperability problem with OpenSSL
Message-ID: <200309151810.48547.me@rs3.ch>

Hi

When SSL handshaking with a OpenSSL 0.9.6 server using DH key exchange, gnutls 
version 0.9.7 complains "The Diffie Hellman prime sent by the server is not 
acceptable (not long enough)." and aborts.

After removing the corresponding if-block in lib/auth_dh_common.c line 221, 
the handshake is accomplished as expected and the connection works.

Can someone please explain, what bits = _gnutls_dh_get_prime_bits( session); 
in this context means and why this if-block is important?

How do I have to initialize DH params in my application to avoid this problem?

For easier reading the gnutls code I'm talking about:

    bits = _gnutls_dh_get_prime_bits( session);
    if (bits < 0) {
        gnutls_assert();
        return bits;
    }

    if ( _gnutls_mpi_get_nbits( session->key->client_p) < (size_t)bits) {
        /* the prime used by the peer is not acceptable
         */
        gnutls_assert();
        return GNUTLS_E_DH_PRIME_UNACCEPTABLE;
    }


Roman



From me at rs3.ch  Mon Sep 15 18:49:02 2003
From: me at rs3.ch (Roman Hoog Antink)
Date: Mon Sep 15 18:49:02 2003
Subject: [gnutls-dev] Diffie Hellman interoperability problem with OpenSSL
In-Reply-To: <200309151810.48547.me@rs3.ch>
References: <200309151810.48547.me@rs3.ch>
Message-ID: <200309151847.34863.me@rs3.ch>

Hi folks,

I solved my problem using gnutls_dh_set_prime_bits(session, bits). Setting the 
number of bits to 512 did the job. 768 was still too big for a OpenSSL 0.9.6 
server.

Greetings from Roman




From simon+gnutls-dev at josefsson.org  Sun Sep 21 03:07:01 2003
From: simon+gnutls-dev at josefsson.org (Simon Josefsson)
Date: Sun Sep 21 03:07:01 2003
Subject: [gnutls-dev] gnutls-cli -s triggered by SIGALRM too?
Message-ID: <ilufzir6j85.fsf@latte.josefsson.org>

Hello, I'm working on a STARTTLS interface for Emacs using GNUTLS,
since the current Emacs solution uses a non-standard command line
application based on OpenSSL, so moving to gnutls-cli seems better.

However, triggering the STARTTLS negotiation by EOF seem slightly
problematic to do in a portable way from Emacs.  The old starttls
application triggered the STARTTLS negotiation by SIGALRM.  Would it
be possible to support this as well, in gnutls-cli?  Suggested patch
attached.

Btw, elisp code is at
<http://quimby.gnus.org/cgi-bin/cvsweb.cgi/gnus/contrib/starttls.el?rev=1.3&content-type=text/x-cvsweb-markup>.
As you can see, it searches for certain strings that gnutls-cli
prints, so it would be good if those didn't change too much.

Thanks.

Index: src/cli.c
===================================================================
RCS file: /cvs/gnutls/gnutls/src/cli.c,v
retrieving revision 2.211
diff -u -p -r2.211 cli.c
--- src/cli.c	17 Sep 2003 20:00:14 -0000	2.211
+++ src/cli.c	21 Sep 2003 01:04:42 -0000
@@ -236,6 +236,12 @@ static int handle_error(socket_st hd, in
 	return ret;
 }
 
+int starttls_alarmed;
+
+void starttls_alarm (int signum)
+{
+  starttls_alarmed = 1;
+}
 
 int main(int argc, char **argv)
 {
@@ -358,6 +364,8 @@ int main(int argc, char **argv)
 
 	printf("\n- Simple Client Mode:\n\n");
 
+	signal (SIGALRM, &starttls_alarm);
+
 	FD_ZERO(&rset);
 	for (;;) {
 		FD_SET(fileno(stdin), &rset);
@@ -366,7 +374,26 @@ int main(int argc, char **argv)
 		maxfd = MAX(fileno(stdin), sd);
 		tv.tv_sec = 3;
 		tv.tv_usec = 0;
-		select(maxfd + 1, &rset, NULL, NULL, &tv);
+		err = select(maxfd + 1, &rset, NULL, NULL, &tv);
+
+		if (err < 0) {
+		  if (errno == EINTR && starttls_alarmed) {
+		    if (hd.secure == 0) {
+		      fprintf(stderr,
+			      "*** Starting TLS handshake\n");
+		      ret = do_handshake(&hd);
+		      if (ret < 0) {
+			fprintf(stderr,
+				"*** Handshake has failed\n");
+			socket_bye(&hd);
+			user_term = 1;
+		      }
+		    } else {
+		      user_term = 1;
+		    }
+		  }
+		  continue;
+		}
 
 		if (FD_ISSET(sd, &rset)) {
 			bzero(buffer, MAX_BUF + 1);
Index: src/common.c
===================================================================
RCS file: /cvs/gnutls/gnutls/src/common.c,v
retrieving revision 2.61
diff -u -p -r2.61 common.c
--- src/common.c	17 Sep 2003 20:00:14 -0000	2.61
+++ src/common.c	21 Sep 2003 01:04:43 -0000
@@ -362,6 +362,8 @@ int print_info(gnutls_session session, c
 	tmp = gnutls_compression_get_name(gnutls_compression_get(session));
 	printf("- Compression: %s\n", tmp);
 
+	fflush (stdout);
+
 	return 0;
 }
 




From ianw at gelato.unsw.edu.au  Thu Sep 25 05:03:02 2003
From: ianw at gelato.unsw.edu.au (Ian Wienand)
Date: Thu Sep 25 05:03:02 2003
Subject: [gnutls-dev] Unaligned access on IA64
Message-ID: <20030925030431.GD27605@cse.unsw.EDU.AU>

Hi,

GNUTLS is causing some unaligned access warnings on IA64.  See
http://www.gelato.unsw.edu.au/linux-ia64/0309/6847.html for a small
discussion about my findings.

Anyway, suggested patch attached.  

2003-09-25  Ian Wienand <ianw at ieee.org> 
 
	* lib/gnutls_handshake.c : modifiy to use memcpy in 
	_gnutls_server_select_suite and 
	_gnutls_server_find_pk_algos_in_ciphersuites
	to stop alignment problems on IA64.

-i
ianw at gelato.unsw.edu.au
http://www.gelato.unsw.edu.au 

-------------- next part --------------
--- ./gnutls7-0.8.9/lib/gnutls_handshake.c	2003-02-04 23:52:24.000000000 +1100
+++ gnutls7-0.8.9-align/lib/gnutls_handshake.c	2003-09-25 13:03:22.000000000 +1000
@@ -509,9 +509,11 @@
 int j;
 gnutls_pk_algorithm algo=-1, prev_algo = 0;
 gnutls_kx_algorithm kx;
+GNUTLS_CipherSuite cs;
 
 	for (j = 0; j < datalen; j += 2) {
-		kx = _gnutls_cipher_suite_get_kx_algo(*((GNUTLS_CipherSuite *) & data[j]));
+		memcpy(&cs, &data[j], sizeof(GNUTLS_CipherSuite));
+		kx = _gnutls_cipher_suite_get_kx_algo(cs);
 		
 		if ( _gnutls_map_kx_get_cred( kx, 1) == GNUTLS_CRD_CERTIFICATE) {
 			algo = _gnutls_map_pk_get_pk( kx);
@@ -531,7 +533,7 @@
 int _gnutls_server_select_suite(gnutls_session session, opaque *data, int datalen)
 {
 	int x, i, j;
-	GNUTLS_CipherSuite *ciphers;
+	GNUTLS_CipherSuite *ciphers,cs;
 	int retval, err;
 	gnutls_pk_algorithm pk_algo; /* will hold the pk algorithms
 			      * supported by the peer.
@@ -558,10 +560,10 @@
 
 #ifdef HANDSHAKE_DEBUG
 	_gnutls_handshake_log("HSK: Requested cipher suites: \n");
-	for (j = 0; j < datalen; j += 2)
-		_gnutls_handshake_log("\t%s\n",
-			    _gnutls_cipher_suite_get_name(*
-							  ((GNUTLS_CipherSuite *) & data[j])));
+	for (j = 0; j < datalen; j += 2) {
+		memcpy(&cs, &data[j], sizeof(GNUTLS_CipherSuite));
+		_gnutls_handshake_log("\t%s\n", _gnutls_cipher_suite_get_name(cs));
+	}
 	_gnutls_handshake_log("HSK: Supported cipher suites: \n");
 	for (j = 0; j < x; j++)
 		_gnutls_handshake_log("\t%s\n",
@@ -575,11 +577,11 @@
 		for (i = 0; i < x; i++) {
 			if (memcmp(ciphers[i].CipherSuite, &data[j], 2) ==
 			    0) {
+				memcpy(&cs, &data[j], sizeof(GNUTLS_CipherSuite));
 				_gnutls_handshake_log("HSK: Selected cipher suite: ");
-				_gnutls_handshake_log("%s\n",
-					    _gnutls_cipher_suite_get_name(*
-									  ((GNUTLS_CipherSuite *) & data[j])));
-				memcpy(session->security_parameters.current_cipher_suite.CipherSuite, ciphers[i].CipherSuite, 2);
+				_gnutls_handshake_log("%s\n", _gnutls_cipher_suite_get_name(cs));
+				memcpy(session->security_parameters.current_cipher_suite.CipherSuite, 
+				       ciphers[i].CipherSuite, 2);
 				retval = 0;
 				goto finish;
 			}

From rsdio at metastatic.org  Tue Sep 30 13:51:01 2003
From: rsdio at metastatic.org (Casey Marshall)
Date: Tue Sep 30 13:51:01 2003
Subject: [gnutls-dev] Small bug in SRP
Message-ID: <20030921181504.GA12823@metastatic.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi.

I think, from what I know of SRP, that the function _gnutls_calc_srp_u
should return an MPI of the hash result, which is in the variable `hd',
not `holder'. Patch is:
 
////
Index: libextra/gnutls_srp.c
===================================================================
RCS file: /cvs/gnutls/gnutls/libextra/gnutls_srp.c,v
retrieving revision 1.31
diff -u -r1.31 gnutls_srp.c
- --- libextra/gnutls_srp.c	8 May 2003 20:03:33 -0000	1.31
+++ libextra/gnutls_srp.c	21 Sep 2003 18:02:15 -0000
@@ -137,7 +137,7 @@
 {
 	size_t b_size, a_size;
 	opaque *holder, hd[MAX_HASH_SIZE];
- -	size_t holder_size;
+	size_t holder_size, hash_size;
 	GNUTLS_HASH_HANDLE td;
 	int ret;
 	GNUTLS_MPI res;
@@ -159,12 +159,13 @@
 		gnutls_assert();
 		return NULL;
 	}
+	hash_size = _gnutls_hash_get_algo_len(td->algorithm);
 	_gnutls_hash(td, holder, holder_size);
 	_gnutls_hash_deinit(td, hd);
 	
 	/* convert the first 4 bytes of hd to uint32
 	 */
- -	ret = _gnutls_mpi_scan( &res, holder, &holder_size);
+	ret = _gnutls_mpi_scan( &res, hd, &hash_size);
 	gnutls_afree(holder);
 
 	if (ret < 0) {
////

With this patch my own in-progress Java implementation of TLS can
negotiate an SRP secret properly with a GnuTLS client. So maybe,
perhaps, possibly, this is the right way to do it (the Internet Draft
being light on details).

(Incidentally, the example SRP parameter files do not seem to contain a
prime modulus, which the implementation of SRP I am using rejects.)

Cheers,

- -- 
Casey Marshall || rsdio at metastatic.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/bepygAuWMgRGsWsRAnRsAJ93xXaUvYPSXcu7t9ovAoftJQhPwgCfeUT9
xXF0JEE6wiE1a/NWdfeiNYs=
=9bpC
-----END PGP SIGNATURE-----



From mi+mx at aldan.algebra.com  Tue Sep 30 13:51:02 2003
From: mi+mx at aldan.algebra.com (Mikhail Teterin)
Date: Tue Sep 30 13:51:02 2003
Subject: [gnutls-dev] security/gnutls does not build
Message-ID: <200309251740.28563@misha-mx.virtual-estates.net>

Apparently, gnutls was not prepared for the changes, that are in the new
OpenCDK-0.5.1... Attached is the lengthy patch, which adapts to the new
API. Not that it changed much -- mostly the data-types renaming and some
symbols obsoleted before finaly removed. Please, permit commit.

Thanks,

	-mi

P.S. The software still generates some warnings -- including value-less
returns in non-void functions. Scary for a security-related package...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-opencdk
Type: text/x-diff
Size: 10270 bytes
Desc: not available
URL: </pipermail/attachments/20030930/c348b14a/attachment.diff>

From marcus at marcuscom.com  Tue Sep 30 13:51:03 2003
From: marcus at marcuscom.com (Joe Marcus Clarke)
Date: Tue Sep 30 13:51:03 2003
Subject: [gnutls-dev] Re: security/gnutls does not build
In-Reply-To: <200309251740.28563@misha-mx.virtual-estates.net>
References: <200309251740.28563@misha-mx.virtual-estates.net>
Message-ID: <1064526265.724.66.camel@gyros>

On Thu, 2003-09-25 at 17:40, Mikhail Teterin wrote:
> Apparently, gnutls was not prepared for the changes, that are in the new
> OpenCDK-0.5.1... Attached is the lengthy patch, which adapts to the new
> API. Not that it changed much -- mostly the data-types renaming and some
> symbols obsoleted before finaly removed. Please, permit commit.

The ports tree is only semi-frozen now.  You can commit this, but it
won't be available for 4.9-RELEASE.

Joe

> 
> Thanks,
> 
> 	-mi
> 
> P.S. The software still generates some warnings -- including value-less
> returns in non-void functions. Scary for a security-related package...
-- 
PGP Key : http://www.marcuscom.com/pgp.asc


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: </pipermail/attachments/20030930/c9ee06aa/attachment.pgp>