From Jefferson.Ogata at noaa.gov  Thu Jul 13 02:53:00 2006
From: Jefferson.Ogata at noaa.gov (Jefferson Ogata)
Date: Thu, 13 Jul 2006 00:53:00 +0000
Subject: [gnutls-dev] SSL_connect and non-blocking i/o
Message-ID: <44B5996C.4060601@noaa.gov>

In libextra/gnutls_openssl.c, we have:

int
SSL_connect (SSL * ssl)
{
...
  err = gnutls_handshake (ssl->gnutls_state);

Meanwhile, the gnutls_handshake() docs indicate that gnutls_handshake()
should be called repeatedly until err == 0 or gnutls_error_is_fatal(err)
is true.

So I'm debugging an application that uses the gnutls/OpenSSL
compatibility and is using a non-blocking socket for the underlying
transport; it returns from SSL_connect() without completing a handshake.
I tweak gnutls libextra/gnutls_openssl.c as follows and that fixes my
problem:

-    err = gnutls_handshake(ssl->gnutls_state);
+    do
+    {
+       err = gnutls_handshake(ssl->gnutls_state);
+    } while (err < 0 && !gnutls_error_is_fatal (err));

I can't be the only person who has run into this, can I?

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
"Never try to retrieve anything from a bear."--National Park Service



From jas at extundo.com  Thu Jul 13 09:29:42 2006
From: jas at extundo.com (Simon Josefsson)
Date: Thu, 13 Jul 2006 09:29:42 +0200
Subject: [gnutls-dev] Re: SSL_connect and non-blocking i/o
In-Reply-To: <44B5996C.4060601@noaa.gov> (Jefferson Ogata's message of "Thu,
	13 Jul 2006 00:53:00 +0000")
References: <44B5996C.4060601@noaa.gov>
Message-ID: <87u05mx8rd.fsf@latte.josefsson.org>

Jefferson Ogata <Jefferson.Ogata at noaa.gov> writes:

> In libextra/gnutls_openssl.c, we have:
>
> int
> SSL_connect (SSL * ssl)
> {
> ...
>   err = gnutls_handshake (ssl->gnutls_state);
>
> Meanwhile, the gnutls_handshake() docs indicate that gnutls_handshake()
> should be called repeatedly until err == 0 or gnutls_error_is_fatal(err)
> is true.
>
> So I'm debugging an application that uses the gnutls/OpenSSL
> compatibility and is using a non-blocking socket for the underlying
> transport; it returns from SSL_connect() without completing a handshake.
> I tweak gnutls libextra/gnutls_openssl.c as follows and that fixes my
> problem:
>
> -    err = gnutls_handshake(ssl->gnutls_state);
> +    do
> +    {
> +       err = gnutls_handshake(ssl->gnutls_state);
> +    } while (err < 0 && !gnutls_error_is_fatal (err));
>
> I can't be the only person who has run into this, can I?

I installed this in SSL_connect and SSL_accept.

Thanks,
Simon



From emile-gnutls at e-advies.nl  Thu Jul 13 11:44:53 2006
From: emile-gnutls at e-advies.nl (Emile van Bergen)
Date: Thu, 13 Jul 2006 11:44:53 +0200
Subject: [gnutls-dev] SSL_connect and non-blocking i/o
In-Reply-To: <44B5996C.4060601@noaa.gov>
References: <44B5996C.4060601@noaa.gov>
Message-ID: <20060713094453.GA2990@web1>

Hi,

On Thu, Jul 13, 2006 at 12:53:00AM +0000, Jefferson Ogata wrote:

> In libextra/gnutls_openssl.c, we have:
> 
> int
> SSL_connect (SSL * ssl)
> {
> ...
>   err = gnutls_handshake (ssl->gnutls_state);
> 
> Meanwhile, the gnutls_handshake() docs indicate that gnutls_handshake()
> should be called repeatedly until err == 0 or gnutls_error_is_fatal(err)
> is true.
> 
> So I'm debugging an application that uses the gnutls/OpenSSL
> compatibility and is using a non-blocking socket for the underlying
> transport; it returns from SSL_connect() without completing a handshake.
> I tweak gnutls libextra/gnutls_openssl.c as follows and that fixes my
> problem:
> 
> -    err = gnutls_handshake(ssl->gnutls_state);
> +    do
> +    {
> +       err = gnutls_handshake(ssl->gnutls_state);
> +    } while (err < 0 && !gnutls_error_is_fatal (err));
> 
> I can't be the only person who has run into this, can I?

The idea is that you only repeat the call, but wait first till you
estimate it can now do a bit more, eg. because select has indicated data
has become available in the socket.

Simply adding a loop would seem to create a busy wait for data to
appear, and that can't be good.

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen           emile at e-advies.nl      
tel. +31 (0)78 6136282           http://www.e-advies.nl    



From jas at extundo.com  Thu Jul 13 13:28:48 2006
From: jas at extundo.com (Simon Josefsson)
Date: Thu, 13 Jul 2006 13:28:48 +0200
Subject: [gnutls-dev] GnuTLS for Windows
Message-ID: <87fyh52173.fsf@latte.josefsson.org>

Hi All,

I'm happy to announce that I've been working on porting GnuTLS to
Windows, and I have some results to show.  See:

http://josefsson.org/gnutls4win/

This is a call for people to test this.  There hasn't been a release
yet, and most likely things are broken.  This is work in progress, but
hopefully all my changes can be integrated back into the various
projects involved.

The goal is to support a Windows version of GnuTLS for future
releases.  I've tested it on Wine, Windows XP and Windows 2000, but if
someone would like to test it on other systems too, that would be
valuable.

This work was sponsored by Transcend IT, Inc. and Lumiad.

Cheers,
Simon



From jas at extundo.com  Thu Jul 13 14:15:42 2006
From: jas at extundo.com (Simon Josefsson)
Date: Thu, 13 Jul 2006 14:15:42 +0200
Subject: [gnutls-dev] Re: SSL_connect and non-blocking i/o
In-Reply-To: <20060713094453.GA2990@web1> (Emile van Bergen's message of "Thu, 
	13 Jul 2006 11:44:53 +0200")
References: <44B5996C.4060601@noaa.gov> <20060713094453.GA2990@web1>
Message-ID: <87bqrt1z0x.fsf@latte.josefsson.org>

Emile van Bergen <emile-gnutls at e-advies.nl> writes:

> Hi,
>
> On Thu, Jul 13, 2006 at 12:53:00AM +0000, Jefferson Ogata wrote:
>
>> In libextra/gnutls_openssl.c, we have:
>> 
>> int
>> SSL_connect (SSL * ssl)
>> {
>> ...
>>   err = gnutls_handshake (ssl->gnutls_state);
>> 
>> Meanwhile, the gnutls_handshake() docs indicate that gnutls_handshake()
>> should be called repeatedly until err == 0 or gnutls_error_is_fatal(err)
>> is true.
>> 
>> So I'm debugging an application that uses the gnutls/OpenSSL
>> compatibility and is using a non-blocking socket for the underlying
>> transport; it returns from SSL_connect() without completing a handshake.
>> I tweak gnutls libextra/gnutls_openssl.c as follows and that fixes my
>> problem:
>> 
>> -    err = gnutls_handshake(ssl->gnutls_state);
>> +    do
>> +    {
>> +       err = gnutls_handshake(ssl->gnutls_state);
>> +    } while (err < 0 && !gnutls_error_is_fatal (err));
>> 
>> I can't be the only person who has run into this, can I?
>
> The idea is that you only repeat the call, but wait first till you
> estimate it can now do a bit more, eg. because select has indicated data
> has become available in the socket.
>
> Simply adding a loop would seem to create a busy wait for data to
> appear, and that can't be good.

I thought that the SSL_connect API in OpenSSL was supposed to block,
but the man page reads:

       If the underlying BIO is blocking, SSL_connect() will only return once
       the handshake has been finished or an error occurred.

       If the underlying BIO is non-blocking, SSL_connect() will also return
       when the underlying BIO could not satisfy the needs of SSL_connect() to
       continue the handshake, indicating the problem by the return value -1.

So I have reverted the patch.  Sorry for the trigger happy commit.

/Simon



From Jefferson.Ogata at noaa.gov  Thu Jul 13 16:41:48 2006
From: Jefferson.Ogata at noaa.gov (Jefferson Ogata)
Date: Thu, 13 Jul 2006 14:41:48 +0000
Subject: [gnutls-dev] Re: SSL_connect and non-blocking i/o
In-Reply-To: <87bqrt1z0x.fsf@latte.josefsson.org>
References: <44B5996C.4060601@noaa.gov> <20060713094453.GA2990@web1>
	<87bqrt1z0x.fsf@latte.josefsson.org>
Message-ID: <44B65BAC.7070700@noaa.gov>

On 2006-07-13 12:15, Simon Josefsson wrote:
> Emile van Bergen <emile-gnutls at e-advies.nl> writes:
>> On Thu, Jul 13, 2006 at 12:53:00AM +0000, Jefferson Ogata wrote:
>>> So I'm debugging an application that uses the gnutls/OpenSSL
>>> compatibility and is using a non-blocking socket for the underlying
>>> transport; it returns from SSL_connect() without completing a handshake.
>>> I tweak gnutls libextra/gnutls_openssl.c as follows and that fixes my
>>> problem:
>>>
>>> -    err = gnutls_handshake(ssl->gnutls_state);
>>> +    do
>>> +    {
>>> +       err = gnutls_handshake(ssl->gnutls_state);
>>> +    } while (err < 0 && !gnutls_error_is_fatal (err));
>>>
>>> I can't be the only person who has run into this, can I?
>> The idea is that you only repeat the call, but wait first till you
>> estimate it can now do a bit more, eg. because select has indicated data
>> has become available in the socket.
>>
>> Simply adding a loop would seem to create a busy wait for data to
>> appear, and that can't be good.

First of all, my diff was not intended as a final patch, but merely to
document that something is not implemented correctly in SSL_connect().

> I thought that the SSL_connect API in OpenSSL was supposed to block,
> but the man page reads:
> 
>        If the underlying BIO is blocking, SSL_connect() will only return once
>        the handshake has been finished or an error occurred.
> 
>        If the underlying BIO is non-blocking, SSL_connect() will also return
>        when the underlying BIO could not satisfy the needs of SSL_connect() to
>        continue the handshake, indicating the problem by the return value -1.

Let's look at a little more context in SSL_connect():

  memset (x_priority, 0, sizeof (x_priority));
  if (ssl->options & SSL_OP_NO_TLSv1)
    {
      for (i = 0, j = 0;
           i < GNUTLS_MAX_ALGORITHM_NUM && x_priority[i] != 0; i++, j++)
        {
          if (ssl->ctx->method->protocol_priority[j] == GNUTLS_TLS1)
            j++;
          else
            x_priority[i] = ssl->ctx->method->protocol_priority[j];
        }
      if (i < GNUTLS_MAX_ALGORITHM_NUM)
        x_priority[i] = 0;
      gnutls_protocol_set_priority (ssl->gnutls_state,
                                    ssl->ctx->method->protocol_priority);
    }

  err = gnutls_handshake (ssl->gnutls_state);
  ssl->last_error = err;

  if (err < 0)
    {
      last_error = err;
      return 0;
    }

As you can see, your SSL_connect() returns 0 regardless of the error, so
the caller won't know that SSL_connect() needs to be called again.

In addition, you have this loop to call gnutls_protocol_set_priority()
on every entrance to SSL_connect() regardless of the connection state.
Is it safe/advisable to call gnutls SSL_connect() repeatedly?

Then there's the fact that you ignore the return value from the
verification callback, fail to implement SSL_*_set_verify_depth(), fail
to #define or implement SSL_VERIFY_PEER, SSL_VERIFY_IF_NO_PEER_CERT,
SSL_VERIFY_CLIENT_ONCE, fail to do certificate preverification, fail to
implement SSL_*_load_verify_locations(), but we can get to all that
later (I'll be happy to help). :^)

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
"Never try to retrieve anything from a bear."--National Park Service



From jas at extundo.com  Thu Jul 13 16:55:23 2006
From: jas at extundo.com (Simon Josefsson)
Date: Thu, 13 Jul 2006 16:55:23 +0200
Subject: [gnutls-dev] Re: SSL_connect and non-blocking i/o
In-Reply-To: <44B65BAC.7070700@noaa.gov> (Jefferson Ogata's message of "Thu,
	13 Jul 2006 14:41:48 +0000")
References: <44B5996C.4060601@noaa.gov> <20060713094453.GA2990@web1>
	<87bqrt1z0x.fsf@latte.josefsson.org> <44B65BAC.7070700@noaa.gov>
Message-ID: <87wtahy2p0.fsf@latte.josefsson.org>

Jefferson Ogata <Jefferson.Ogata at noaa.gov> writes:

> First of all, my diff was not intended as a final patch, but merely to
> document that something is not implemented correctly in SSL_connect().

Understood, thanks.  By the look of the code, I think
libgnutls-openssl is a somewhat neglected part of GnuTLS.  It isn't
really a priority for me, but I'd be happy to install patches.

> As you can see, your SSL_connect() returns 0 regardless of the error, so
> the caller won't know that SSL_connect() needs to be called again.

A bug, it seems.

> In addition, you have this loop to call gnutls_protocol_set_priority()
> on every entrance to SSL_connect() regardless of the connection state.
> Is it safe/advisable to call gnutls SSL_connect() repeatedly?

Since the OpenSSL API says you should do that, the GnuTLS emulation
API should be the same.  I think it should work.

> Then there's the fact that you ignore the return value from the
> verification callback, fail to implement SSL_*_set_verify_depth(), fail
> to #define or implement SSL_VERIFY_PEER, SSL_VERIFY_IF_NO_PEER_CERT,
> SSL_VERIFY_CLIENT_ONCE, fail to do certificate preverification, fail to
> implement SSL_*_load_verify_locations(), but we can get to all that
> later (I'll be happy to help). :^)

I'm sure you are right here.  As they say, patches welcome. :-)

/Simon



From jas at extundo.com  Fri Jul 14 12:27:56 2006
From: jas at extundo.com (Simon Josefsson)
Date: Fri, 14 Jul 2006 12:27:56 +0200
Subject: [gnutls-dev] GnuTLS 1.4.1
Message-ID: <87irm0wker.fsf@latte.josefsson.org>

I am happy to announce GnuTLS 1.4.1, a bugfix release on the stable
1.4 branch.  This version is what we recommend for those who need a
stable version of GnuTLS.

We've had problems with the ftp.gnutls.org server lately, and I
couldn't upload this release to it.  Hence, this release is only
available from my server below.  We're looking into moving the ftp
server to ftp.gnu.org instead.

GnuTLS is a modern C library that implement the standard network
security protocol Transport Layer Security (TLS), for use by network
applications.

Noteworthy changes since 1.4.0:

** Replaced inactive ifdefs to enable openpgp support in test programs.

** Fixed bug in OpenPGP authentication handshake.

** Fixed typographical in man pages.

** Build fixes of the manual.

** Added Swedish translation.

** API and ABI modifications:
No changes since last version.

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.

All manual formats are available from:
  http://www.gnutls.org/manual/

Direct link to the most popular formats:
  http://www.gnutls.org/manual/gnutls.html - HTML format
  http://www.gnutls.org/manual/gnutls.pdf  - PDF format
  http://www.gnutls.org/reference/ch01.html  - API Reference, GTK-DOC HTML

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>.

The project page of the library is available at:
  http://www.gnutls.org/
  http://www.gnu.org/software/gnutls/
  http://josefsson.org/gnutls/ (updated fastest)

Here are the compressed sources (3.9MB):
  http://josefsson.org/gnutls/releases/gnutls-1.4.1.tar.bz2

Here are GPG detached signatures signed using key 0xB565716F:
  http://josefsson.org/gnutls/releases/gnutls-1.4.1.tar.bz2.sig

The software is cryptographically signed by the author using an
OpenPGP key identified by the following information:

pub   1280R/B565716F 2002-05-05 [expires: 2006-08-14]
      Key fingerprint = 0424 D4EE 81A0 E3D1 19C6  F835 EDA2 1E94 B565 716F
uid                  Simon Josefsson <simon at josefsson.org>
uid                  Simon Josefsson <jas at extundo.com>
sub   1280R/4D5D40AE 2002-05-05 [expires: 2006-08-14]
sub   1024R/09CC4670 2006-03-18 [expires: 2007-04-22]
sub   1024R/AABB1F7B 2006-03-18 [expires: 2007-04-22]
sub   1024R/A14C401A 2006-03-18 [expires: 2007-04-22]

The key is available from:
  http://josefsson.org/key.txt
  dns:b565716f.josefsson.org?TYPE=CERT

Here are the SHA-1 and SHA-224 checksums:

25d183fef21abbcaab0afe6b5809893aa70b577d  gnutls-1.4.1.tar.bz2
65547a50e5b3e2158d46972d4eee882d3a404338  gnutls-1.4.1.tar.bz2.sig

1bc91d0abfb5ae847cc06ae2df841ff39682b2574c6dba0cf80e1f0e  gnutls-1.4.1.tar.bz2
afadd68e1b75b241a96364c4436b00ea2a8eeca156cd9fe1da775bf5  gnutls-1.4.1.tar.bz2.sig

Enjoy,
Nikos and Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 419 bytes
Desc: not available
URL: </pipermail/attachments/20060714/fbc41d78/attachment.pgp>

From jas at extundo.com  Fri Jul 14 17:14:37 2006
From: jas at extundo.com (Simon Josefsson)
Date: Fri, 14 Jul 2006 17:14:37 +0200
Subject: [gnutls-dev] Re: GnuTLS for Windows
In-Reply-To: <87fyh52173.fsf@latte.josefsson.org> (Simon Josefsson's message
	of "Thu, 13 Jul 2006 13:28:48 +0200")
References: <87fyh52173.fsf@latte.josefsson.org>
Message-ID: <87zmfcuski.fsf@latte.josefsson.org>

Simon Josefsson <jas at extundo.com> writes:

> http://josefsson.org/gnutls4win/

I've added instructions on how to use the GnuTLS DLL from your
MinGW/Cygwin or Microsoft Visual Studio program.

/Simon



From angeli at caeruleus.net  Sun Jul 16 10:24:01 2006
From: angeli at caeruleus.net (Ralf Angeli)
Date: Sun, 16 Jul 2006 10:24:01 +0200
Subject: [gnutls-dev] Re: GnuTLS for Windows
References: <87fyh52173.fsf@latte.josefsson.org>
Message-ID: <e9ct31$38t$1@sea.gmane.org>

* Simon Josefsson (2006-07-13) writes:

> I'm happy to announce that I've been working on porting GnuTLS to
> Windows, and I have some results to show.

Cool!  Thanks!

> This is a call for people to test this.  There hasn't been a release
> yet, and most likely things are broken.  This is work in progress, but
> hopefully all my changes can be integrated back into the various
> projects involved.

Okay, unfortunately the first test I conducted already failed:

$ gnutls-cli --version
GNU TLS test client, version 1.5.0. Libgnutls 1.5.0.

$ gnutls-cli --print-cert --port 25 --starttls smtp.web.de
Resolving 'smtp.web.de'...
Connecting to '217.72.192.157:25'...

- Simple Client Mode:


After that message appears it sits there and consumes 100% CPU.  Just
tell me if you need more information.

-- 
Ralf




From jas at extundo.com  Sun Jul 16 15:18:46 2006
From: jas at extundo.com (Simon Josefsson)
Date: Sun, 16 Jul 2006 15:18:46 +0200
Subject: [gnutls-dev] Re: GnuTLS for Windows
In-Reply-To: <e9ct31$38t$1@sea.gmane.org> (Ralf Angeli's message of "Sun, 16
	Jul 2006 10:24:01 +0200")
References: <87fyh52173.fsf@latte.josefsson.org> <e9ct31$38t$1@sea.gmane.org>
Message-ID: <87fyh1vgax.fsf@latte.josefsson.org>

Ralf Angeli <angeli at caeruleus.net> writes:

>> This is a call for people to test this.  There hasn't been a release
>> yet, and most likely things are broken.  This is work in progress, but
>> hopefully all my changes can be integrated back into the various
>> projects involved.
>
> Okay, unfortunately the first test I conducted already failed:

Thanks for testing!

> $ gnutls-cli --version
> GNU TLS test client, version 1.5.0. Libgnutls 1.5.0.
>
> $ gnutls-cli --print-cert --port 25 --starttls smtp.web.de
> Resolving 'smtp.web.de'...
> Connecting to '217.72.192.157:25'...
>
> - Simple Client Mode:
>
>
> After that message appears it sits there and consumes 100% CPU.  Just
> tell me if you need more information.

Alas, Windows' select() only works on sockets, not file descriptors.
gnutls-cli uses select to find out whether there is data on stdin and
from the server, and it is the stdin part that doesn't work.  I think
there are some solutions to this, but it's not clear to me how to
implement them yet.

Note that the GnuTLS library itself does not use select, so it doesn't
have this problem.

I'll probably be away on vacation most of the next two or three weeks,
but after that I'll resume working on this.

Thanks,
Simon



From jas at extundo.com  Sun Jul 16 16:28:16 2006
From: jas at extundo.com (Simon Josefsson)
Date: Sun, 16 Jul 2006 16:28:16 +0200
Subject: [gnutls-dev] Re: GnuTLS for Windows
In-Reply-To: <87wtadslm5.fsf@neutrino.caeruleus.net> (Ralf Angeli's message of
	"Sun, 16 Jul 2006 15:52:18 +0200")
References: <87fyh52173.fsf@latte.josefsson.org> <e9ct31$38t$1@sea.gmane.org>
	<87fyh1vgax.fsf@latte.josefsson.org>
	<87wtadslm5.fsf@neutrino.caeruleus.net>
Message-ID: <87bqrpvd33.fsf@latte.josefsson.org>

Ralf Angeli <angeli at caeruleus.net> writes:

> * Simon Josefsson (2006-07-16) writes:
>
>> Alas, Windows' select() only works on sockets, not file descriptors.
>> gnutls-cli uses select to find out whether there is data on stdin and
>> from the server, and it is the stdin part that doesn't work.  I think
>> there are some solutions to this, but it's not clear to me how to
>> implement them yet.
>
> Unfortunately this is beyond me.
>
>> Note that the GnuTLS library itself does not use select, so it doesn't
>> have this problem.
>
> Hm, but for using GnuTLS with Gnus (for TLS-enabled SMTP connections)
> using the library itself is not an option IIUC.

Right.  Hopefully I can solve this soon.  I have some ideas that I'm
trying out now...

/Simon



From satyam_kkd at hyd.hellosoft.com  Mon Jul 17 16:02:37 2006
From: satyam_kkd at hyd.hellosoft.com (satyakumar)
Date: Mon, 17 Jul 2006 19:32:37 +0530
Subject: [gnutls-dev] non-blocking sockets in GNUTLS-1.4.0
Message-ID: <44BB987D.4090701@hyd.hellosoft.com>

Hi,

Does GNUTLS- 1.4.0 works on non-blocking sockets.
How to set it to work on non-blocking sockets.

Regards,
Satyakumar


The information contained in this e-mail message and/or attachments to it may
contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail immediately and permanently delete the message and any attachments.




From wk at gnupg.org  Tue Jul 18 11:26:12 2006
From: wk at gnupg.org (Werner Koch)
Date: Tue, 18 Jul 2006 11:26:12 +0200
Subject: [gnutls-dev] Re: GnuTLS for Windows
In-Reply-To: <87fyh1vgax.fsf@latte.josefsson.org> (Simon Josefsson's message
	of "Sun, 16 Jul 2006 15:18:46 +0200")
References: <87fyh52173.fsf@latte.josefsson.org> <e9ct31$38t$1@sea.gmane.org>
	<87fyh1vgax.fsf@latte.josefsson.org>
Message-ID: <87zmf79scr.fsf@wheatstone.g10code.de>

On Sun, 16 Jul 2006 15:18, Simon Josefsson said:

> Alas, Windows' select() only works on sockets, not file descriptors.
> gnutls-cli uses select to find out whether there is data on stdin and
> from the server, and it is the stdin part that doesn't work.  I think
> there are some solutions to this, but it's not clear to me how to
> implement them yet.

Checkout gpgme: gpgme/w32-io.c shows how to do it. There is also a
posix-io.c of course.  The latest glib has similar code now as well as
special cases for sockets.  It is all a mess: WaitForMultipleObjects
is not able to wait on all types of file descriptors. In particular if
you are working with CreatePipe, you need to have a thread for each fd
you want to wait on.

Salam-Shalom,

   Werner




From satyam_kkd at hyd.hellosoft.com  Sat Jul 29 11:32:36 2006
From: satyam_kkd at hyd.hellosoft.com (satyakumar)
Date: Sat, 29 Jul 2006 15:02:36 +0530
Subject: [gnutls-dev] [Fwd: crash in GNUTLS-1.4.0]
Message-ID: <44CB2B34.3030401@hyd.hellosoft.com>



The information contained in this e-mail message and/or attachments to it may
contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail immediately and permanently delete the message and any attachments.

-------------- next part --------------
An embedded message was scrubbed...
From: satyakumar <satyam_kkd at hyd.hellosoft.com>
Subject: crash in GNUTLS-1.4.0
Date: Thu, 27 Jul 2006 12:30:00 +0530
Size: 8335
URL: </pipermail/attachments/20060729/8bad0779/attachment.eml>

From jas at extundo.com  Sat Jul 29 12:29:11 2006
From: jas at extundo.com (Simon Josefsson)
Date: Sat, 29 Jul 2006 12:29:11 +0200
Subject: [gnutls-dev] Re: [Fwd: crash in GNUTLS-1.4.0]
In-Reply-To: <44CB2B34.3030401@hyd.hellosoft.com> (satyakumar's message of
	"Sat, 29 Jul 2006 15:02:36 +0530")
References: <44CB2B34.3030401@hyd.hellosoft.com>
Message-ID: <87irlg7lhk.fsf@latte.josefsson.org>

satyakumar <satyam_kkd at hyd.hellosoft.com> writes:

> Hi,
>             The below is a coredump of GNUTLS 1.4.0 library, when
> testing with the key/certificate pair and root certificate are
> attached here with.
>
> The certificate and key are generated using openssl.

Can you reproduce this using gnutls-cli?  If so, which command line
parameters?  What is the password for the encrypted RSA key?

> #0  0x4207940a in strcmp () from /lib/tls/libc.so.6
> #1  0x40034bdf in check_server_params (session=0x441310dc,
> kx=1142100280, alg=0x4413110c, alg_size=1142100200)
>    at gnutls_handshake.c:2674

Line 2674 reads:

	  gnutls_assert ();

If that crashes in strcmp, something is seriously wrong.  Maybe
running the program under valgrind helps to find the real cause.

Anyway, I'm on vacation now so I have limited time to look into this
further.

/Simon



From jas at extundo.com  Sat Jul 29 12:33:51 2006
From: jas at extundo.com (Simon Josefsson)
Date: Sat, 29 Jul 2006 12:33:51 +0200
Subject: [gnutls-dev] Re: GnuTLS for Windows
In-Reply-To: <87zmf79scr.fsf@wheatstone.g10code.de> (Werner Koch's message of
	"Tue, 18 Jul 2006 11:26:12 +0200")
References: <87fyh52173.fsf@latte.josefsson.org> <e9ct31$38t$1@sea.gmane.org>
	<87fyh1vgax.fsf@latte.josefsson.org>
	<87zmf79scr.fsf@wheatstone.g10code.de>
Message-ID: <87ejw47l9s.fsf@latte.josefsson.org>

Werner Koch <wk at gnupg.org> writes:

> On Sun, 16 Jul 2006 15:18, Simon Josefsson said:
>
>> Alas, Windows' select() only works on sockets, not file descriptors.
>> gnutls-cli uses select to find out whether there is data on stdin and
>> from the server, and it is the stdin part that doesn't work.  I think
>> there are some solutions to this, but it's not clear to me how to
>> implement them yet.
>
> Checkout gpgme: gpgme/w32-io.c shows how to do it. There is also a
> posix-io.c of course.  The latest glib has similar code now as well as
> special cases for sockets.  It is all a mess: WaitForMultipleObjects
> is not able to wait on all types of file descriptors. In particular if
> you are working with CreatePipe, you need to have a thread for each fd
> you want to wait on.

Yes, it looks slightly messy.  GDB has some code for it too
(mingw-hdep.c).

It may be possible to use a simpler select() replacement in cli.c,
because it only waits for stdin and one network stream.  For
reference, I'm currently experimenting with something like the
below...  Obviously not perfect, but it is a test tool after all.

Eventually, I think we should have a gnulib module with a proper w32
select call.

/Simon

int
w32_select (int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds,
	    struct timeval *timeout)
{
  int fd;

  for (fd = 0; fd < n; fd++)
    {
      if (readfds && FD_ISSET (fd, readfds))
	{
	  HANDLE h;
	  DWORD available;
	  h = (HANDLE) _get_osfhandle (fd);
	  if (h != -1 && PeekNamedPipe (h, NULL, 0, NULL, &available, NULL))
	    {
	      if (available == 0)
		FD_CLR (fd, readfds);
	    }
	  else
	    {
	      int err;
	      struct timeval tv;
	      fd_set new;
	      WSANETWORKEVENTS events;

	      err = WSAEnumNetworkEvents(fd, NULL, &events);
	      if (events.lNetworkEvents)
		printf ("ff %d\n", events.lNetworkEvents);

	      FD_ZERO (&new);
	      FD_SET (fd, &new);
	      tv.tv_sec = 0;
	      tv.tv_usec = 100;

	      err = select (fd + 1, &new, NULL, NULL, &tv);
	      if (err == 0)
		  FD_CLR (fd, readfds);
	      else if (err < 0)
		printf ("bad\n");
	    }
	}
    }
  return 0;
}



From jas at extundo.com  Sat Jul 29 12:37:03 2006
From: jas at extundo.com (Simon Josefsson)
Date: Sat, 29 Jul 2006 12:37:03 +0200
Subject: [gnutls-dev] Re: non-blocking sockets in GNUTLS-1.4.0
In-Reply-To: <44BB987D.4090701@hyd.hellosoft.com> (satyakumar's message of
	"Mon, 17 Jul 2006 19:32:37 +0530")
References: <44BB987D.4090701@hyd.hellosoft.com>
Message-ID: <87ac6s7l4g.fsf@latte.josefsson.org>

satyakumar <satyam_kkd at hyd.hellosoft.com> writes:

> Hi,
>
> Does GNUTLS- 1.4.0 works on non-blocking sockets.
> How to set it to work on non-blocking sockets.

See the node "The transport layer" in the manual.  Specifically, I
believe setting the sockets to non-blocking mode, and making sure to
call GnuTLS functions again for `GNUTLS_E_INTERRUPTED' and
`GNUTLS_E_AGAIN' errors is sufficient.  You may want to look at
gnutls_transport_set_lowat() too.

/Simon



From mario.lenz at gmx.net  Mon Jul 31 21:22:23 2006
From: mario.lenz at gmx.net (Mario Lenz)
Date: Mon, 31 Jul 2006 21:22:23 +0200
Subject: [gnutls-dev] Client OpenPGP verification fails
In-Reply-To: <200607261602.14817.nmav@gnutls.org>
References: <1153254133.13947.35.camel@mario>
	<200607252017.38245.nmav@gnutls.org> <1153863676.4355.46.camel@mario>
	<200607261602.14817.nmav@gnutls.org>
Message-ID: <1154373744.29702.32.camel@mario>

Hi!

> > OK, next try: cert->subject_pk_algorithm in _gnutls_tls_sign_hdata
> > (lib/gnutls_sig.c) is unknown, so the function returns
> > GNUTLS_E_INTERNAL_ERROR.
> 
> Why is subject_pk_algorithm  unknown? For openpgp keys it should be set 
> in openpgp_pk_to_gnutls_cert().

I'm not sure, but it looks like this to me:

_gnutls_handshake_client (lib/gutls_handshake.c) calls
_gnutls_send_client_certificate_verify (lib/gnutls_kx.c) which calls
_gnutls_gen_cert_client_cert_vrfy (lib/auth_cert.c). This one calls
_gnutls_get_selected_cert (same file) to get the certificate. This
certificate is handed to _gnutls_tls_sign_hdata (lib/gnutls_sig.c) which
breaks because cert->subject_pk_algorithm is unknown.

The "selected cert" is set as follows:

_gnutls_handshake_client calls _gnutls_recv_server_certificate_request
(lib/gnutls_kx.c) which calls _gnutls_proc_cert_cert_req
(lib/auth_cert.c). This one calls _select_client_cert (same file) wich
calls cred->client_get_cert_callback (call_get_cert_callback in same
file). This one calls cred->client_get_cert_callback (cert_callback in
src/cli.c). Then there are calls to alloc_and_load_pgp_certs and
alloc_and_load_pgp_key, and then _gnutls_selected_certs_set is called.
To me, it doesn't look like openpgp_pk_to_gnutls_cert() is involved
somewhere.

cu

   Mario