Skip Menu |
 

This queue is for tickets about the Net-SSLeay CPAN distribution.

Report information
The Basics
Id: 77689
Status: resolved
Worked: 30 min
Priority: 0/
Queue: Net-SSLeay

People
Owner: MIKEM [...] cpan.org
Requestors: james [...] jmarshall.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: (no value)
Fixed in: (no value)



Download (untitled) / with headers
text/plain 1.2k
Many people, myself included, want to use non-blocking I/O with SSL. Some people have nice writeups how to do it, but each one I've seen comes with unacceptable limitations. This is currently a major hole in Perl network programming. So my main feature request would be a simple-as-possible, official description of what exactly must be done for non-blocking I/O, which error codes need to be checked where, etc. I'm happy to help with this writeup if I can get the needed information. At the moment I think I'd have a solution, if I could only get the return code from SSL_read() (Net::SSLeay::read() only returns the gotten data). I need this return code to use with Net::SSLeay::get_error(), to detect SSL_ERROR_WANT_READ and the other error codes. Is there a way to get this return code from SSL_read()? If not, could we perhaps add it to the return value of Net::SSLeay::read(), i.e. return a two-item array when wantarray? Also, improving the documentation on error-handling in Net::SSLeay would yield great benefits, I think. Again, I'm willing to help with this if I can get the needed info-- e.g. what's the deal with $! ? How should die_now(), die_if_ssl_error(), and print_errs() be called, and what are their return values? Thanks very much for any help. I'm currently stuck on this.
Subject: Re: [rt.cpan.org #77689]
Date: Sat, 09 Jun 2012 11:03:06 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] open.com.au>
Download (untitled) / with headers
text/plain 2.4k
Hi James, I will respond to this within the next couple of days. Thanks for your offer to assist with updating. Cheers. On Thursday, June 07, 2012 04:07:15 PM you wrote: Show quoted text
> Thu Jun 07 16:07:14 2012: Request 77689 was acted upon. > Transaction: Ticket created by JSM > Queue: Net-SSLeay > Subject: (No subject given) > Broken in: (no value) > Severity: Important > Owner: Nobody > Requestors: james@jmarshall.com > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=77689 > > > > Many people, myself included, want to use non-blocking I/O with SSL. > Some people have nice writeups how to do it, but each one I've seen > comes with unacceptable limitations. This is currently a major hole in > Perl network programming. > > So my main feature request would be a simple-as-possible, official > description of what exactly must be done for non-blocking I/O, which > error codes need to be checked where, etc. I'm happy to help with this > writeup if I can get the needed information. > > At the moment I think I'd have a solution, if I could only get the > return code from SSL_read() (Net::SSLeay::read() only returns the gotten > data). I need this return code to use with Net::SSLeay::get_error(), to > detect SSL_ERROR_WANT_READ and the other error codes. Is there a way to > get this return code from SSL_read()? If not, could we perhaps add it > to the return value of Net::SSLeay::read(), i.e. return a two-item array > when wantarray? > > Also, improving the documentation on error-handling in Net::SSLeay would > yield great benefits, I think. Again, I'm willing to help with this if > I can get the needed info-- e.g. what's the deal with $! ? How should > die_now(), die_if_ssl_error(), and print_errs() be called, and what are > their return values? > > Thanks very much for any help. I'm currently stuck on this.
-- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
Subject: Re: [rt.cpan.org #77689]
Date: Sat, 09 Jun 2012 11:15:46 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] open.com.au>
On Thursday, June 07, 2012 04:07:15 PM you wrote: Show quoted text
> Thu Jun 07 16:07:14 2012: Request 77689 was acted upon. > Transaction: Ticket created by JSM > Queue: Net-SSLeay > Subject: (No subject given) > Broken in: (no value) > Severity: Important > Owner: Nobody > Requestors: james@jmarshall.com > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=77689 > > > > Many people, myself included, want to use non-blocking I/O with SSL. > Some people have nice writeups how to do it, but each one I've seen > comes with unacceptable limitations. This is currently a major hole in > Perl network programming. > > So my main feature request would be a simple-as-possible, official > description of what exactly must be done for non-blocking I/O, which > error codes need to be checked where, etc. I'm happy to help with this > writeup if I can get the needed information.
OK, I have used Net::SSLeay in an number of async non-blocking applications, using both UDP and TCP based comms. So I know it works, but I do grant that its hard to figure out how to do it right. Show quoted text
> > At the moment I think I'd have a solution, if I could only get the > return code from SSL_read() (Net::SSLeay::read() only returns the gotten > data). I need this return code to use with Net::SSLeay::get_error(), to > detect SSL_ERROR_WANT_READ and the other error codes. Is there a way to > get this return code from SSL_read()? If not, could we perhaps add it > to the return value of Net::SSLeay::read(), i.e. return a two-item array > when wantarray?
during the handshake phase, I use my $ret = &Net::SSLeay::connect($object->{ssl_streamtls}); my $reason = &Net::SSLeay::get_error($object->{ssl_streamtls}, $ret); my $state = &Net::SSLeay::get_state($object->{ssl_streamtls}); to get the state of the connection and then: if ($ret == 1) { # Success, the SSL accept has completed successfully, # therefore the client has verified credentials. # However, there may be some more data in the output # BIO to send to the client, so we defer the ACCEPT # until it is acked $object->{handshake_finished}++; } elsif ($ret == 0) { # Handshake was not successful $object->log($main::LOG_ERR, "client Handshake unsuccessful: " . &Net::SSLeay::print_errs()); $object->stream_disconnected(); return; } elsif ( $reason == Net::SSLeay::ERROR_WANT_READ || $reason == Net::SSLeay::ERROR_WANT_WRITE) { # Looking for more read or write data, object will provide it when its available } else { # Error $object->log($main::LOG_ERR, "client error: $ret, $reason, $state, " . &Net::SSLeay::print_errs()); $object->stream_disconnected(); return; } after handshake is finished: $data = &Net::SSLeay::BIO_read($self->{wbio}, $self->{MaxBufferSize}); Show quoted text
> > Also, improving the documentation on error-handling in Net::SSLeay would > yield great benefits, I think. Again, I'm willing to help with this if > I can get the needed info-- e.g. what's the deal with $! ? How should > die_now(), die_if_ssl_error(), and print_errs() be called, and what are > their return values?
Recent versions of net-ssleay have significantly improved doc'n on these topics, thanks to KMX. Check the latest version for updates, Show quoted text
> > Thanks very much for any help. I'm currently stuck on this.
Hope that is helpful. I will be happy to aply any suitable patches you may send. -- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
Subject: Re: [rt.cpan.org #77689]
Date: Mon, 25 Jun 2012 12:20:16 -0700
To: bug-Net-SSLeay [...] rt.cpan.org
From: James Marshall <james [...] jmarshall.com>
Download (untitled) / with headers
text/plain 5.7k
I'm still working on this (juggling too many things), but the attached patch to SSLeay.xs (with its associated SSLeay.pod patch) seems to be working correctly, and it passes all tests. It modifies Net::SSLeay::read() to return the result from SSL_read() as the second return value, if Net::SSLeay::read() is called in list context. Its behavior should be unchanged if called in scalar or void context. This result code seems to be required for full support of non-blocking I/O, since users need to handle SSL_ERR_WANT_READ, SSL_ERROR_WANT_WRITE, etc. This is my first foray into XS, so given the importance of Net::SSLeay::read() , someone who knows XS should probably review this patch for memory leaks, performance hits, or other bugs. It's a short patch. Incidentally, I still can't find definitive docs for $! or the convenience error-reporting functions in the POD for Net::SSLeay, and I'm looking at the CPAN site, version 1.48 . Perhaps KMX's patch didn't make it in? Or am I missing something? Thanks for the help, James On Fri, Jun 8, 2012 at 6:16 PM, mikem@open.com.au via RT < bug-Net-SSLeay@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=77689 > > > On Thursday, June 07, 2012 04:07:15 PM you wrote:
> > Thu Jun 07 16:07:14 2012: Request 77689 was acted upon. > > Transaction: Ticket created by JSM > > Queue: Net-SSLeay > > Subject: (No subject given) > > Broken in: (no value) > > Severity: Important > > Owner: Nobody > > Requestors: james@jmarshall.com > > Status: new > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=77689 > > > > > > > Many people, myself included, want to use non-blocking I/O with SSL. > > Some people have nice writeups how to do it, but each one I've seen > > comes with unacceptable limitations. This is currently a major hole in > > Perl network programming. > > > > So my main feature request would be a simple-as-possible, official > > description of what exactly must be done for non-blocking I/O, which > > error codes need to be checked where, etc. I'm happy to help with this > > writeup if I can get the needed information.
> > OK, I have used Net::SSLeay in an number of async non-blocking > applications, > using both UDP and TCP based comms. So I know it works, but I do grant that > its hard to figure out how to do it right. > >
> > > > At the moment I think I'd have a solution, if I could only get the > > return code from SSL_read() (Net::SSLeay::read() only returns the gotten > > data). I need this return code to use with Net::SSLeay::get_error(), to > > detect SSL_ERROR_WANT_READ and the other error codes. Is there a way to > > get this return code from SSL_read()? If not, could we perhaps add it > > to the return value of Net::SSLeay::read(), i.e. return a two-item array > > when wantarray?
> > during the handshake phase, I use > > my $ret = &Net::SSLeay::connect($object->{ssl_streamtls}); > my $reason = &Net::SSLeay::get_error($object->{ssl_streamtls}, > $ret); > my $state = &Net::SSLeay::get_state($object->{ssl_streamtls}); > > to get the state of the connection > and then: > > if ($ret == 1) > { > # Success, the SSL accept has completed successfully, > # therefore the client has verified credentials. > # However, there may be some more data in the output > # BIO to send to the client, so we defer the ACCEPT > # until it is acked > $object->{handshake_finished}++; > } > elsif ($ret == 0) > { > # Handshake was not successful > $object->log($main::LOG_ERR, "client Handshake > unsuccessful: " > . &Net::SSLeay::print_errs()); > $object->stream_disconnected(); > return; > } > elsif ( $reason == Net::SSLeay::ERROR_WANT_READ > || $reason == Net::SSLeay::ERROR_WANT_WRITE) > { > # Looking for more read or write data, object will provide > it when its > available > } > else > { > # Error > $object->log($main::LOG_ERR, "client error: $ret, $reason, > $state, " > . &Net::SSLeay::print_errs()); > $object->stream_disconnected(); > return; > } > > > after handshake is finished: > > $data = &Net::SSLeay::BIO_read($self->{wbio}, > $self->{MaxBufferSize}); >
> > > > Also, improving the documentation on error-handling in Net::SSLeay would > > yield great benefits, I think. Again, I'm willing to help with this if > > I can get the needed info-- e.g. what's the deal with $! ? How should > > die_now(), die_if_ssl_error(), and print_errs() be called, and what are > > their return values?
> > Recent versions of net-ssleay have significantly improved doc'n on these > topics, thanks to KMX. Check the latest version for updates, >
> > > > Thanks very much for any help. I'm currently stuck on this.
> > Hope that is helpful. > > I will be happy to aply any suitable patches you may send. > > > -- > Mike McCauley mikem@open.com.au > Open System Consultants Pty. Ltd > 9 Bulbul Place Currumbin Waters QLD 4223 Australia > http://www.open.com.au > Phone +61 7 5598-7474 Fax +61 7 5598-7070 > > Radiator: the most portable, flexible and configurable RADIUS server > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, > Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, > TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, > DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare > etc. > > >
Download SSLeay.xs.diff
text/x-diff 1.2k

Message body is not shown because sender requested not to inline it.

Download SSLeay.pod.diff
text/x-diff 1.2k

Message body is not shown because sender requested not to inline it.

Subject: Re: [rt.cpan.org #77689]
Date: Tue, 26 Jun 2012 07:58:46 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] open.com.au>
Download (untitled) / with headers
text/plain 7.8k
Hi James, Thanks. Im a bit nervous about changing the interface to such a long and well used function but..... The patch looks OK except that I think that in the event of got < 0, I think it will return 0 as the first list element, and not undef? Is that what you really intended? Comments suggest otherwise. Cheers. On Monday, June 25, 2012 03:20:32 PM you wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=77689 > > > I'm still working on this (juggling too many things), but the attached > patch to SSLeay.xs (with its associated SSLeay.pod patch) seems to be > working correctly, and it passes all tests. It modifies > Net::SSLeay::read() to return the result from SSL_read() as the second > return value, if Net::SSLeay::read() is called in list context. Its > behavior should be unchanged if called in scalar or void context. This > result code seems to be required for full support of non-blocking I/O, > since users need to handle SSL_ERR_WANT_READ, SSL_ERROR_WANT_WRITE, etc. > > This is my first foray into XS, so given the importance of > Net::SSLeay::read() , someone who knows XS should probably review this > patch for memory leaks, performance hits, or other bugs. It's a short > patch. > > Incidentally, I still can't find definitive docs for $! or the convenience > error-reporting functions in the POD for Net::SSLeay, and I'm looking at > the CPAN site, version 1.48 . Perhaps KMX's patch didn't make it in? Or > am I missing something? > > Thanks for the help, > James > > > On Fri, Jun 8, 2012 at 6:16 PM, mikem@open.com.au via RT < > > bug-Net-SSLeay@rt.cpan.org> wrote:
> > <URL: https://rt.cpan.org/Ticket/Display.html?id=77689 > > > > > On Thursday, June 07, 2012 04:07:15 PM you wrote:
> > > Thu Jun 07 16:07:14 2012: Request 77689 was acted upon. > > > Transaction: Ticket created by JSM > > > > > > Queue: Net-SSLeay > > > > > > Subject: (No subject given) > > > > > > Broken in: (no value) > > > > > > Severity: Important > > > > > > Owner: Nobody > > > > > > Requestors: james@jmarshall.com > > > > > > Status: new > > > > > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=77689 > > > > > > > Many people, myself included, want to use non-blocking I/O with SSL. > > > Some people have nice writeups how to do it, but each one I've seen > > > comes with unacceptable limitations. This is currently a major hole > > > in > > > Perl network programming. > > > > > > So my main feature request would be a simple-as-possible, official > > > description of what exactly must be done for non-blocking I/O, which > > > error codes need to be checked where, etc. I'm happy to help with > > > this > > > writeup if I can get the needed information.
> > > > OK, I have used Net::SSLeay in an number of async non-blocking > > applications, > > using both UDP and TCP based comms. So I know it works, but I do grant > > that its hard to figure out how to do it right. > >
> > > At the moment I think I'd have a solution, if I could only get the > > > return code from SSL_read() (Net::SSLeay::read() only returns the > > > gotten data). I need this return code to use with > > > Net::SSLeay::get_error(), to detect SSL_ERROR_WANT_READ and the > > > other error codes. Is there a way to get this return code from > > > SSL_read()? If not, could we perhaps add it to the return value of > > > Net::SSLeay::read(), i.e. return a two-item array when wantarray?
> > > > during the handshake phase, I use > > > > my $ret = > > &Net::SSLeay::connect($object->{ssl_streamtls}) > > ; > > my $reason = > > &Net::SSLeay::get_error($object->{ssl_streamtls > > },> > > $ret); > > > > my $state = > > &Net::SSLeay::get_state($object->{ssl_streamtls > > });> > > to get the state of the connection > > > > and then: > > if ($ret == 1) > > { > > > > # Success, the SSL accept has completed > > successfully, > > # therefore the client has verified > > credentials. > > # However, there may be some more data > > in the output > > # BIO to send to the client, so we defer > > the ACCEPT > > # until it is acked > > $object->{handshake_finished}++; > > > > } > > elsif ($ret == 0) > > { > > > > # Handshake was not successful > > $object->log($main::LOG_ERR, "client > > Handshake > > > > unsuccessful: " > > > > . > > &Net::SSLeay: > > :print_errs()) > > ; > > > > $object->stream_disconnected(); > > return; > > > > } > > elsif ( $reason == > > Net::SSLeay::ERROR_WANT_READ > > > > || $reason == > > || Net::SSLeay::ERROR_WANT_WRI > > || TE) > > > > { > > > > # Looking for more read or write data, > > object will provide> > > it when its > > available > > > > } > > else > > { > > > > # Error > > $object->log($main::LOG_ERR, "client > > error: $ret, $reason,> > > $state, " > > > > . > > &Net::SSLeay: > > :print_errs()) > > ; > > > > $object->stream_disconnected(); > > return; > > > > } > > > > after handshake is finished: > > $data = &Net::SSLeay::BIO_read($self->{wbio}, > > > > $self->{MaxBufferSize}); > >
> > > Also, improving the documentation on error-handling in Net::SSLeay > > > would yield great benefits, I think. Again, I'm willing to help > > > with this if I can get the needed info-- e.g. what's the deal with > > > $! ? How should die_now(), die_if_ssl_error(), and print_errs() be > > > called, and what are their return values?
> > > > Recent versions of net-ssleay have significantly improved doc'n on these > > topics, thanks to KMX. Check the latest version for updates, > >
> > > Thanks very much for any help. I'm currently stuck on this.
> > > > Hope that is helpful. > > > > I will be happy to aply any suitable patches you may send. > > > > > > -- > > Mike McCauley mikem@open.com.au > > Open System Consultants Pty. Ltd > > 9 Bulbul Place Currumbin Waters QLD 4223 Australia > > http://www.open.com.au > > Phone +61 7 5598-7474 Fax +61 7 5598-7070 > > > > Radiator: the most portable, flexible and configurable RADIUS server > > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, > > Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, > > TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, > > DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, > > NetWare > > etc.
-- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
Subject: Re: [rt.cpan.org #77689]
Date: Mon, 25 Jun 2012 15:10:00 -0700
To: bug-Net-SSLeay [...] rt.cpan.org
From: James Marshall <james [...] jmarshall.com>
Download (untitled) / with headers
text/plain 8.7k
I'd be nervous too! The newSV(0) creates an undefined value, according to perlguts. The number is the amount of memory that's _allocated_ for it. See the end of this section: http://perldoc.perl.org/perlguts.html#AVs,-HVs-and-undefined-values I definitely intend to return undef on error, so as to not change anything with the current scalar-context return of Net::SSLeay::read(). As far as I can tell, the list-context return is currently undocumented, so I figured it was a safe route to take. But the call is of course yours. Cheers, James On Mon, Jun 25, 2012 at 2:58 PM, mikem@open.com.au via RT < bug-Net-SSLeay@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=77689 > > > Hi James, > > Thanks. > Im a bit nervous about changing the interface to such a long and well used > function but..... > > The patch looks OK except that I think that in the event of got < 0, I > think > it will return 0 as the first list element, and not undef? > > Is that what you really intended? Comments suggest otherwise. > > Cheers. > > On Monday, June 25, 2012 03:20:32 PM you wrote:
> > Queue: Net-SSLeay > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=77689 > > > > > I'm still working on this (juggling too many things), but the attached > > patch to SSLeay.xs (with its associated SSLeay.pod patch) seems to be > > working correctly, and it passes all tests. It modifies > > Net::SSLeay::read() to return the result from SSL_read() as the second > > return value, if Net::SSLeay::read() is called in list context. Its > > behavior should be unchanged if called in scalar or void context. This > > result code seems to be required for full support of non-blocking I/O, > > since users need to handle SSL_ERR_WANT_READ, SSL_ERROR_WANT_WRITE, etc. > > > > This is my first foray into XS, so given the importance of > > Net::SSLeay::read() , someone who knows XS should probably review this > > patch for memory leaks, performance hits, or other bugs. It's a short > > patch. > > > > Incidentally, I still can't find definitive docs for $! or the
> convenience
> > error-reporting functions in the POD for Net::SSLeay, and I'm looking at > > the CPAN site, version 1.48 . Perhaps KMX's patch didn't make it in? Or > > am I missing something? > > > > Thanks for the help, > > James > > > > > > On Fri, Jun 8, 2012 at 6:16 PM, mikem@open.com.au via RT < > > > > bug-Net-SSLeay@rt.cpan.org> wrote:
> > > <URL: https://rt.cpan.org/Ticket/Display.html?id=77689 > > > > > > > On Thursday, June 07, 2012 04:07:15 PM you wrote:
> > > > Thu Jun 07 16:07:14 2012: Request 77689 was acted upon. > > > > Transaction: Ticket created by JSM > > > > > > > > Queue: Net-SSLeay > > > > > > > > Subject: (No subject given) > > > > > > > > Broken in: (no value) > > > > > > > > Severity: Important > > > > > > > > Owner: Nobody > > > > > > > > Requestors: james@jmarshall.com > > > > > > > > Status: new > > > > > > > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=77689 > > > > > > > > > Many people, myself included, want to use non-blocking I/O with SSL. > > > > Some people have nice writeups how to do it, but each one I've seen > > > > comes with unacceptable limitations. This is currently a major hole > > > > in > > > > Perl network programming. > > > > > > > > So my main feature request would be a simple-as-possible, official > > > > description of what exactly must be done for non-blocking I/O, which > > > > error codes need to be checked where, etc. I'm happy to help with > > > > this > > > > writeup if I can get the needed information.
> > > > > > OK, I have used Net::SSLeay in an number of async non-blocking > > > applications, > > > using both UDP and TCP based comms. So I know it works, but I do grant > > > that its hard to figure out how to do it right. > > >
> > > > At the moment I think I'd have a solution, if I could only get the > > > > return code from SSL_read() (Net::SSLeay::read() only returns the > > > > gotten data). I need this return code to use with > > > > Net::SSLeay::get_error(), to detect SSL_ERROR_WANT_READ and the > > > > other error codes. Is there a way to get this return code from > > > > SSL_read()? If not, could we perhaps add it to the return value of > > > > Net::SSLeay::read(), i.e. return a two-item array when wantarray?
> > > > > > during the handshake phase, I use > > > > > > my $ret = > > > &Net::SSLeay::connect($object->{ssl_streamtls}) > > > ; > > > my $reason = > > > &Net::SSLeay::get_error($object->{ssl_streamtls > > > },> > > > $ret); > > > > > > my $state = > > > &Net::SSLeay::get_state($object->{ssl_streamtls > > > });> > > > to get the state of the connection > > > > > > and then: > > > if ($ret == 1) > > > { > > > > > > # Success, the SSL accept has completed > > > successfully, > > > # therefore the client has verified > > > credentials. > > > # However, there may be some more data > > > in the output > > > # BIO to send to the client, so we defer > > > the ACCEPT > > > # until it is acked > > > $object->{handshake_finished}++; > > > > > > } > > > elsif ($ret == 0) > > > { > > > > > > # Handshake was not successful > > > $object->log($main::LOG_ERR, "client > > > Handshake > > > > > > unsuccessful: " > > > > > > . > > > &Net::SSLeay: > > > :print_errs()) > > > ; > > > > > > $object->stream_disconnected(); > > > return; > > > > > > } > > > elsif ( $reason == > > > Net::SSLeay::ERROR_WANT_READ > > > > > > || $reason == > > > || Net::SSLeay::ERROR_WANT_WRI > > > || TE) > > > > > > { > > > > > > # Looking for more read or write data, > > > object will provide> > > > it when its > > > available > > > > > > } > > > else > > > { > > > > > > # Error > > > $object->log($main::LOG_ERR, "client > > > error: $ret, $reason,> > > > $state, " > > > > > > . > > > &Net::SSLeay: > > > :print_errs()) > > > ; > > > > > > $object->stream_disconnected(); > > > return; > > > > > > } > > > > > > after handshake is finished: > > > $data = &Net::SSLeay::BIO_read($self->{wbio}, > > > > > > $self->{MaxBufferSize}); > > >
> > > > Also, improving the documentation on error-handling in Net::SSLeay > > > > would yield great benefits, I think. Again, I'm willing to help > > > > with this if I can get the needed info-- e.g. what's the deal with > > > > $! ? How should die_now(), die_if_ssl_error(), and print_errs() be > > > > called, and what are their return values?
> > > > > > Recent versions of net-ssleay have significantly improved doc'n on
> these
> > > topics, thanks to KMX. Check the latest version for updates, > > >
> > > > Thanks very much for any help. I'm currently stuck on this.
> > > > > > Hope that is helpful. > > > > > > I will be happy to aply any suitable patches you may send. > > > > > > > > > -- > > > Mike McCauley mikem@open.com.au > > > Open System Consultants Pty. Ltd > > > 9 Bulbul Place Currumbin Waters QLD 4223 Australia > > > http://www.open.com.au > > > Phone +61 7 5598-7474 Fax +61 7 5598-7070 > > > > > > Radiator: the most portable, flexible and configurable RADIUS server > > > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, > > > Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, > > > TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, > > > DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, > > > NetWare > > > etc.
> -- > Mike McCauley mikem@open.com.au > Open System Consultants Pty. Ltd > 9 Bulbul Place Currumbin Waters QLD 4223 Australia > http://www.open.com.au > Phone +61 7 5598-7474 Fax +61 7 5598-7070 > > Radiator: the most portable, flexible and configurable RADIUS server > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, > Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, > TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, > DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare > etc. > > >
Download (untitled) / with headers
text/html 12.4k

Message body is not shown because it is too large.

Subject: Re: [rt.cpan.org #77689]
Date: Tue, 26 Jun 2012 08:51:30 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] open.com.au>
Download (untitled) / with headers
text/plain 11.1k
Hi James, On Monday, June 25, 2012 06:10:20 PM you wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=77689 > > > I'd be nervous too! > > The newSV(0) creates an undefined value, according to perlguts. The number > is the amount of memory that's _allocated_ for it. See the end of this > section: > http://perldoc.perl.org/perlguts.html#AVs,-HVs-and-undefined-values
OK, but is it mortal? I think you should be using PL_sv_undef Cheers. Show quoted text
> > I definitely intend to return undef on error, so as to not change anything > with the current scalar-context return of Net::SSLeay::read(). As far as I > can tell, the list-context return is currently undocumented, so I figured > it was a safe route to take. > > But the call is of course yours. > > Cheers, > James > > > On Mon, Jun 25, 2012 at 2:58 PM, mikem@open.com.au via RT < > > bug-Net-SSLeay@rt.cpan.org> wrote:
> > <URL: https://rt.cpan.org/Ticket/Display.html?id=77689 > > > > > Hi James, > > > > Thanks. > > Im a bit nervous about changing the interface to such a long and well > > used function but..... > > > > The patch looks OK except that I think that in the event of got < 0, I > > think > > it will return 0 as the first list element, and not undef? > > > > Is that what you really intended? Comments suggest otherwise. > > > > Cheers. > > > > On Monday, June 25, 2012 03:20:32 PM you wrote:
> > > Queue: Net-SSLeay > > > > > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=77689 > > > > > > > I'm still working on this (juggling too many things), but the > > > attached > > > patch to SSLeay.xs (with its associated SSLeay.pod patch) seems to > > > be > > > working correctly, and it passes all tests. It modifies > > > Net::SSLeay::read() to return the result from SSL_read() as the > > > second > > > return value, if Net::SSLeay::read() is called in list context. Its > > > behavior should be unchanged if called in scalar or void context. > > > This > > > result code seems to be required for full support of non-blocking > > > I/O, > > > since users need to handle SSL_ERR_WANT_READ, SSL_ERROR_WANT_WRITE, > > > etc. > > > > > > This is my first foray into XS, so given the importance of > > > Net::SSLeay::read() , someone who knows XS should probably review > > > this > > > patch for memory leaks, performance hits, or other bugs. It's a > > > short > > > patch. > > > > > > Incidentally, I still can't find definitive docs for $! or the
> > > > convenience > >
> > > error-reporting functions in the POD for Net::SSLeay, and I'm > > > looking at the CPAN site, version 1.48 . Perhaps KMX's patch > > > didn't make it in? Or am I missing something? > > > > > > Thanks for the help, > > > James > > > > > > > > > On Fri, Jun 8, 2012 at 6:16 PM, mikem@open.com.au via RT < > > > > > > bug-Net-SSLeay@rt.cpan.org> wrote:
> > > > <URL: https://rt.cpan.org/Ticket/Display.html?id=77689 > > > > > > > > > On Thursday, June 07, 2012 04:07:15 PM you wrote:
> > > > > Thu Jun 07 16:07:14 2012: Request 77689 was acted upon. > > > > > Transaction: Ticket created by JSM > > > > > > > > > > Queue: Net-SSLeay > > > > > > > > > > Subject: (No subject given) > > > > > > > > > > Broken in: (no value) > > > > > > > > > > Severity: Important > > > > > > > > > > Owner: Nobody > > > > > > > > > > Requestors: james@jmarshall.com > > > > > > > > > > Status: new > > > > > > > > > > Ticket <URL: > > > > > https://rt.cpan.org/Ticket/Display.html?id=77689 > > > > > > > > > > > Many people, myself included, want to use non-blocking I/O > > > > > with SSL. Some people have nice writeups how to do it, but > > > > > each one I've seen comes with unacceptable limitations. > > > > > This is currently a major hole in > > > > > Perl network programming. > > > > > > > > > > So my main feature request would be a simple-as-possible, > > > > > official > > > > > description of what exactly must be done for non-blocking > > > > > I/O, which error codes need to be checked where, etc. I'm > > > > > happy to help with this > > > > > writeup if I can get the needed information.
> > > > > > > > OK, I have used Net::SSLeay in an number of async non-blocking > > > > applications, > > > > using both UDP and TCP based comms. So I know it works, but I do > > > > grant that its hard to figure out how to do it right. > > > >
> > > > > At the moment I think I'd have a solution, if I could only > > > > > get the > > > > > return code from SSL_read() (Net::SSLeay::read() only > > > > > returns the > > > > > gotten data). I need this return code to use with > > > > > Net::SSLeay::get_error(), to detect SSL_ERROR_WANT_READ and > > > > > the > > > > > other error codes. Is there a way to get this return code > > > > > from > > > > > SSL_read()? If not, could we perhaps add it to the return > > > > > value of > > > > > Net::SSLeay::read(), i.e. return a two-item array when > > > > > wantarray?
> > > > > > > > during the handshake phase, I use > > > > > > > > my $ret = > > > > &Net::SSLeay::connect($object->{ssl_stre > > > > amtls}) > > > > ; > > > > my $reason = > > > > &Net::SSLeay::get_error($object->{ssl_st > > > > reamtls > > > > },> > > > > > > > > $ret); > > > > > > > > my $state = > > > > &Net::SSLeay::get_state($object->{ssl_st > > > > reamtls > > > > });> > > > > > > > > to get the state of the connection > > > > > > > > and then: > > > > if ($ret == 1) > > > > { > > > > > > > > # Success, the SSL accept has > > > > completed > > > > successfully, > > > > # therefore the client has > > > > verified > > > > credentials. > > > > # However, there may be some > > > > more data > > > > in the output > > > > # BIO to send to the client, so > > > > we defer > > > > the ACCEPT > > > > # until it is acked > > > > $object->{handshake_finished}++; > > > > > > > > } > > > > elsif ($ret == 0) > > > > { > > > > > > > > # Handshake was not successful > > > > $object->log($main::LOG_ERR, > > > > "client > > > > Handshake > > > > > > > > unsuccessful: " > > > > > > > > . > > > > > > > > &Net::SSLeay: > > > > :prin > > > > :t_er > > > > :rs() > > > > :) > > > > > > > > ; > > > > > > > > $object->stream_disconnected(); > > > > return; > > > > > > > > } > > > > elsif ( $reason == > > > > Net::SSLeay::ERROR_WANT_READ > > > > > > > > || $reason == > > > > || Net::SSLeay::ERROR_W > > > > || ANT_WRI > > > > || TE) > > > > > > > > { > > > > > > > > # Looking for more read or write > > > > data, > > > > object will provide> > > > > > > > > it when its > > > > available > > > > > > > > } > > > > else > > > > { > > > > > > > > # Error > > > > $object->log($main::LOG_ERR, > > > > "client > > > > error: $ret, $reason,> > > > > > > > > $state, " > > > > > > > > . > > > > > > > > &Net::SSLeay: > > > > :prin > > > > :t_er > > > > :rs() > > > > :) > > > > > > > > ; > > > > > > > > $object->stream_disconnected(); > > > > return; > > > > > > > > } > > > > > > > > after handshake is finished: > > > > $data = &Net::SSLeay::BIO_read($self->{wbio}, > > > > > > > > $self->{MaxBufferSize}); > > > >
> > > > > Also, improving the documentation on error-handling in > > > > > Net::SSLeay > > > > > would yield great benefits, I think. Again, I'm willing to > > > > > help > > > > > with this if I can get the needed info-- e.g. what's the > > > > > deal with > > > > > $! ? How should die_now(), die_if_ssl_error(), and > > > > > print_errs() be > > > > > called, and what are their return values?
> > > > > > > > Recent versions of net-ssleay have significantly improved doc'n > > > > on
> > > > these > >
> > > > topics, thanks to KMX. Check the latest version for updates, > > > >
> > > > > Thanks very much for any help. I'm currently stuck on this.
> > > > > > > > Hope that is helpful. > > > > > > > > I will be happy to aply any suitable patches you may send. > > > > > > > > > > > > -- > > > > Mike McCauley mikem@open.com.au > > > > Open System Consultants Pty. Ltd > > > > 9 Bulbul Place Currumbin Waters QLD 4223 Australia > > > > http://www.open.com.au > > > > Phone +61 7 5598-7474 Fax +61 7 > > > > 5598-7070 > > > > > > > > Radiator: the most portable, flexible and configurable RADIUS > > > > server > > > > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, > > > > Emerald, > > > > Platypus, Freeside, TACACS+, PAM, external, Active Directory, > > > > EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, > > > > HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, > > > > Solaris, VMS, NetWare > > > > etc.
> > > > -- > > Mike McCauley mikem@open.com.au > > Open System Consultants Pty. Ltd > > 9 Bulbul Place Currumbin Waters QLD 4223 Australia > > http://www.open.com.au > > Phone +61 7 5598-7474 Fax +61 7 5598-7070 > > > > Radiator: the most portable, flexible and configurable RADIUS server > > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, > > Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, > > TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, > > DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, > > NetWare > > etc.
-- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
Subject: Re: [rt.cpan.org #77689]
Date: Mon, 25 Jun 2012 16:25:48 -0700
To: bug-Net-SSLeay [...] rt.cpan.org
From: James Marshall <james [...] jmarshall.com>

Message body is not shown because it is too large.

Download (untitled) / with headers
text/html 18.6k

Message body is not shown because it is too large.

Subject: Re: [rt.cpan.org #77689]
Date: Tue, 26 Jun 2012 11:00:54 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] open.com.au>
Download (untitled) / with headers
text/plain 15.7k

Message body is not shown because it is too large.

Download (untitled) / with headers
text/plain 2.3k
Still working on this, and have some questions. Feel free to redirect me to another forum if that's more appropriate. Is there a way to test for EOF on an SSL socket? Perl's eof() uses buffered I/O, and would be inappropriate with SSL buffering anyway. Is there a way to flush output that's been written with Net::SSLeay::write(), so that the recipient can read it? Would a rehandshaking do this, and if so how does one trigger it? How should one select() on the underlying socket if shutdown() returns 0 and ERROR_SYSCALL? OpenSSL's doc of SSL_shutdown() is unclear on this. Is using BIOs needed for any of this? So far I don't use them, and know little about them. The program is a multiplexing secure HTTP server that supports HTTP pipelining. The behavior I'm seeing is: I start the server on localhost, and try to load a page from it with Firefox. The browser hangs with "Waiting for localhost...", even though the return from SSL_write() indicates all response bytes have been sent to the browser. When I killall the server process, the browser instantly displays the page correctly. Have you seen this behavior before? I'm attaching the commented code, even though it's 500 lines long and I don't expect anyone to read it. :) But the routines try_SSL_accept(), try_SSL_read(), try_SSL_write(), try_SSL_shutdown(), and try_syswrite() have been separated out and are mostly short; each shows how the error codes are handled. Thanks again for any answers. Cheers, James On Mon Jun 25 21:00:58 2012, mikem@open.com.au wrote: Show quoted text
> Hi James, > > On Monday, June 25, 2012 07:26:03 PM you wrote:
> > Queue: Net-SSLeay > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=77689 > > > > > Well, that same section in perlguts warns against using &PL_sv_undef
> when
> > storing an undefined value in an AV. From the last paragraph: > > > > "Generally, if you want to store an undefined value in an AV or HV,
> you
> > should not use &PL_sv_undef , but rather create a new undefined
> value using
> > the newSV function." > > > > As for mortality, I think the sv_2mortals()'s here make every return
> value
> > mortal.
> > Yes, quite right. > >
> > That's how we want it, right?
> > Yes. > > Your patch has been committed to SVN. > Thanks again. > > The doc patches from kmx have all been applied to svn, so if there is > something still missing, I will be happy to take a patch. > > Cheers. >
Subject: embedded-server.pl
Download embedded-server.pl
text/x-perl 17k

Message body is not shown because it is too large.

Subject: Re: [rt.cpan.org #77689] Need doc for non-blocking I/O, and return code from SSL_read() for same
Date: Fri, 06 Jul 2012 10:15 +1000
To: bug-Net-SSLeay [...] rt.cpan.org
From: Mike McCauley <mikem [...] open.com.au>
Download (untitled) / with headers
text/plain 4.1k
Hi James, On Monday, July 02, 2012 04:19:56 PM you wrote: Show quoted text
> Queue: Net-SSLeay > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=77689 > > > Still working on this, and have some questions. Feel free to redirect > me to another forum if that's more appropriate. > > Is there a way to test for EOF on an SSL socket? Perl's eof() uses > buffered I/O, and would be inappropriate with SSL buffering anyway.
Show quoted text
> > Is there a way to flush output that's been written with > Net::SSLeay::write(), so that the recipient can read it? Would a > rehandshaking do this, and if so how does one trigger it? > > How should one select() on the underlying socket if shutdown() returns 0 > and ERROR_SYSCALL? OpenSSL's doc of SSL_shutdown() is unclear on this. > > Is using BIOs needed for any of this? So far I don't use them, and know > little about them.
Thats the way I always use SSL with low level and non-blocking IO. BIOs are used to feed data into and get data out of the SSL engine. $context->{rbio} = &Net::SSLeay::BIO_new(&Net::SSLeay::BIO_s_mem()); $context->{wbio} = &Net::SSLeay::BIO_new(&Net::SSLeay::BIO_s_mem()); &Net::SSLeay::set_bio($context->{ssl}, $context->{rbio}, $context->{wbio}); Show quoted text
> > The program is a multiplexing secure HTTP server that supports HTTP > pipelining. The behavior I'm seeing is: I start the server on > localhost, and try to load a page from it with Firefox. The browser > hangs with "Waiting for localhost...", even though the return from > SSL_write() indicates all response bytes have been sent to the browser. > When I killall the server process, the browser instantly displays the > page correctly. Have you seen this behavior before?
I dont use SSL_write() in my code. net-ssleay's SSL_write just calls SSL_write in the SSL lib, so I think much of these questions are to do with SSL rather than Net::SSLeay. Perhaps the problem is with your FD. From the doc for SSL_set_fd(): When performing the operation, a socket BIO is automatically created to interface between the ssl and fd. The BIO and hence the SSL engine inherit the behaviour of fd. If fd is non-blocking, the ssl will also have non-blocking behaviour. Hope that helps., Cheers. Show quoted text
> > I'm attaching the commented code, even though it's 500 lines long and I > don't expect anyone to read it. :) But the routines try_SSL_accept(), > try_SSL_read(), try_SSL_write(), try_SSL_shutdown(), and try_syswrite() > have been separated out and are mostly short; each shows how the error > codes are handled. > > Thanks again for any answers. > > Cheers, > James > > On Mon Jun 25 21:00:58 2012, mikem@open.com.au wrote:
> > Hi James, > > > > On Monday, June 25, 2012 07:26:03 PM you wrote:
> > > Queue: Net-SSLeay > > > > > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=77689 > > > > > > > Well, that same section in perlguts warns against using &PL_sv_undef
> > > > when > >
> > > storing an undefined value in an AV. From the last paragraph: > > > > > > "Generally, if you want to store an undefined value in an AV or HV,
> > > > you > >
> > > should not use &PL_sv_undef , but rather create a new undefined
> > > > value using > >
> > > the newSV function." > > > > > > As for mortality, I think the sv_2mortals()'s here make every return
> > > > value > >
> > > mortal.
> > > > Yes, quite right. > >
> > > That's how we want it, right?
> > > > Yes. > > > > Your patch has been committed to SVN. > > Thanks again. > > > > The doc patches from kmx have all been applied to svn, so if there is > > something still missing, I will be happy to take a patch. > > > > Cheers.
-- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd 9 Bulbul Place Currumbin Waters QLD 4223 Australia http://www.open.com.au Phone +61 7 5598-7474 Fax +61 7 5598-7070 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.