Merge from main trunk, conflicts resolved.BRANCH_engine

Change what needs to be changed in crypto/engine to adapt to the new
way DSO works.
Change hw_nuron.c to use DSO functions instead of using dl*()
functions directly.

9 files changed, 115 insertions, 75 deletions

diff --git a/doc/apps/s_server.pod b/doc/apps/s_server.pod
index 3a5bf46e28..fcb52226dd 100644
--- a/doc/apps/s_server.pod
+++ b/doc/apps/s_server.pod
@@ -7,7 +7,7 @@ s_server - SSL/TLS server program
 
 =head1 SYNOPSIS
 
-B<openssl> B<s_client>
+B<openssl> B<s_server>
 [B<-accept port>]
 [B<-context id>]
 [B<-verify depth>]
diff --git a/doc/crypto/BIO_s_accept.pod b/doc/crypto/BIO_s_accept.pod
index b2b8e911e8..55e4b730b9 100644
--- a/doc/crypto/BIO_s_accept.pod
+++ b/doc/crypto/BIO_s_accept.pod
@@ -10,31 +10,31 @@ BIO_get_bind_mode, BIO_do_accept - accept BIO
 
  #include <openssl/bio.h>
 
- BIO_METHOD * BIO_s_accept(void);
+ BIO_METHOD *BIO_s_accept(void);
 
- #define BIO_set_accept_port(b,name) BIO_ctrl(b,BIO_C_SET_ACCEPT,0,(char *)name)
- #define BIO_get_accept_port(b)	BIO_ptr_ctrl(b,BIO_C_GET_ACCEPT,0)
+ long BIO_set_accept_port(BIO *b, char *name);
+ char *BIO_get_accept_port(BIO *b);
 
  BIO *BIO_new_accept(char *host_port);
 
- #define BIO_set_nbio_accept(b,n) BIO_ctrl(b,BIO_C_SET_ACCEPT,1,(n)?"a":NULL)
- #define BIO_set_accept_bios(b,bio) BIO_ctrl(b,BIO_C_SET_ACCEPT,2,(char *)bio)
+ long BIO_set_nbio_accept(BIO *b, int n);
+ long BIO_set_accept_bios(BIO *b, char *bio);
 
- #define BIO_set_bind_mode(b,mode) BIO_ctrl(b,BIO_C_SET_BIND_MODE,mode,NULL)
- #define BIO_get_bind_mode(b,mode) BIO_ctrl(b,BIO_C_GET_BIND_MODE,0,NULL)
+ long BIO_set_bind_mode(BIO *b, long mode);
+ long BIO_get_bind_mode(BIO *b, long dummy);
 
  #define BIO_BIND_NORMAL		0
  #define BIO_BIND_REUSEADDR_IF_UNUSED	1
  #define BIO_BIND_REUSEADDR		2
 
- #define BIO_do_accept(b)	BIO_do_handshake(b)
+ int BIO_do_accept(BIO *b);
 
 =head1 DESCRIPTION
 
 BIO_s_accept() returns the accept BIO method. This is a wrapper
 round the platform's TCP/IP socket accept routines.
 
-Using accept BIOs TCP/IP connections can be accepted and data
+Using accept BIOs, TCP/IP connections can be accepted and data
 transferred using only BIO routines. In this way any platform
 specific operations are hidden by the BIO abstraction.
 
@@ -130,13 +130,17 @@ however because the accept BIO will still accept additional incoming
 connections. This can be resolved by using BIO_pop() (see above)
 and freeing up the accept BIO after the initial connection.
 
-If the underlying accept socket is non blocking and BIO_do_accept() is
+If the underlying accept socket is non-blocking and BIO_do_accept() is
 called to await an incoming connection it is possible for
 BIO_should_io_special() with the reason BIO_RR_ACCEPT. If this happens
 then it is an indication that an accept attempt would block: the application
 should take appropriate action to wait until the underlying socket has
 accepted a connection and retry the call.
 
+BIO_set_accept_port(), BIO_get_accept_port(), BIO_set_nbio_accept(),
+BIO_set_accept_bios(), BIO_set_bind_mode(), BIO_get_bind_mode() and
+BIO_do_accept() are macros.
+
 =head1 RETURN VALUES
 
 TBA
diff --git a/doc/crypto/BIO_s_connect.pod b/doc/crypto/BIO_s_connect.pod
index fe1aa679d4..bcf7d8dcac 100644
--- a/doc/crypto/BIO_s_connect.pod
+++ b/doc/crypto/BIO_s_connect.pod
@@ -13,25 +13,27 @@ BIO_set_nbio, BIO_do_connect - connect BIO
 
  BIO_METHOD * BIO_s_connect(void);
 
- #define BIO_set_conn_hostname(b,name) BIO_ctrl(b,BIO_C_SET_CONNECT,0,(char *)name)
- #define BIO_set_conn_port(b,port) BIO_ctrl(b,BIO_C_SET_CONNECT,1,(char *)port)
- #define BIO_set_conn_ip(b,ip)	  BIO_ctrl(b,BIO_C_SET_CONNECT,2,(char *)ip)
- #define BIO_set_conn_int_port(b,port) BIO_ctrl(b,BIO_C_SET_CONNECT,3,(char *)port)
- #define BIO_get_conn_hostname(b)  BIO_ptr_ctrl(b,BIO_C_GET_CONNECT,0)
- #define BIO_get_conn_port(b)      BIO_ptr_ctrl(b,BIO_C_GET_CONNECT,1)
- #define BIO_get_conn_ip(b,ip) BIO_ptr_ctrl(b,BIO_C_SET_CONNECT,2)
- #define BIO_get_conn_int_port(b,port) BIO_int_ctrl(b,BIO_C_SET_CONNECT,3,port)
+ BIO *BIO_new_connect(char *name);
 
- #define BIO_set_nbio(b,n)	BIO_ctrl(b,BIO_C_SET_NBIO,(n),NULL)
+ long BIO_set_conn_hostname(BIO *b, char *name);
+ long BIO_set_conn_port(BIO *b, char *port);
+ long BIO_set_conn_ip(BIO *b, char *ip);
+ long BIO_set_conn_int_port(BIO *b, char *port);
+ char *BIO_get_conn_hostname(BIO *b);
+ char *BIO_get_conn_port(BIO *b);
+ char *BIO_get_conn_ip(BIO *b, dummy);
+ long BIO_get_conn_int_port(BIO *b, int port);
 
- #define BIO_do_connect(b)	BIO_do_handshake(b)
+ long BIO_set_nbio(BIO *b, long n);
+
+ int BIO_do_connect(BIO *b);
 
 =head1 DESCRIPTION
 
 BIO_s_connect() returns the connect BIO method. This is a wrapper
 round the platform's TCP/IP socket connection routines.
 
-Using connect BIOs TCP/IP connections can be made and data
+Using connect BIOs, TCP/IP connections can be made and data
 transferred using only BIO routines. In this way any platform
 specific operations are hidden by the BIO abstraction.
 
@@ -54,7 +56,7 @@ BIO_get_fd() places the underlying socket in B<c> if it is not NULL,
 it also returns the socket . If B<c> is not NULL it should be of
 type (int *).
 
-BIO_set_conn_hostname() uses the string B<name> to set the hostname
+BIO_set_conn_hostname() uses the string B<name> to set the hostname.
 The hostname can be an IP address. The hostname can also include the
 port in the form hostname:port . It is also acceptable to use the
 form "hostname/any/other/path" or "hostname:port/any/other/path".
@@ -87,6 +89,9 @@ is set. Blocking I/O is the default. The call to BIO_set_nbio()
 should be made before the connection is established because 
 non blocking I/O is set during the connect process.
 
+BIO_new_connect() combines BIO_new() and BIO_set_conn_hostname() into
+a single call: that is it creates a new connect BIO with B<name>.
+
 BIO_do_connect() attempts to connect the supplied BIO. It returns 1
 if the connection was established successfully. A zero or negative
 value is returned if the connection could not be established, the
@@ -123,6 +128,11 @@ then this is an indication that a connection attempt would block,
 the application should then take appropriate action to wait until
 the underlying socket has connected and retry the call.
 
+BIO_set_conn_hostname(), BIO_set_conn_port(), BIO_set_conn_ip(),
+BIO_set_conn_int_port(), BIO_get_conn_hostname(), BIO_get_conn_port(),
+BIO_get_conn_ip(), BIO_get_conn_int_port(), BIO_set_nbio() and
+BIO_do_connect() are macros.
+
 =head1 RETURN VALUES
 
 BIO_s_connect() returns the connect BIO method.
diff --git a/doc/crypto/BIO_s_socket.pod b/doc/crypto/BIO_s_socket.pod
index 253185185c..1c8d3a9110 100644
--- a/doc/crypto/BIO_s_socket.pod
+++ b/doc/crypto/BIO_s_socket.pod
@@ -8,10 +8,10 @@ BIO_s_socket, BIO_new_socket - socket BIO
 
  #include <openssl/bio.h>
 
- BIO_METHOD *	BIO_s_socket(void);
+ BIO_METHOD *BIO_s_socket(void);
 
- #define BIO_set_fd(b,fd,c)	BIO_int_ctrl(b,BIO_C_SET_FD,c,fd)
- #define BIO_get_fd(b,c)	BIO_ctrl(b,BIO_C_GET_FD,0,(char *)c)
+ long BIO_set_fd(BIO *b, int fd, long close_flag);
+ long BIO_get_fd(BIO *b, int *c);
 
  BIO *BIO_new_socket(int sock, int close_flag);
 
@@ -27,10 +27,10 @@ If the close flag is set then the socket is shut down and closed
 when the BIO is freed.
 
 BIO_set_fd() sets the socket of BIO B<b> to B<fd> and the close
-flag to B<c>.
+flag to B<close_flag>.
 
 BIO_get_fd() places the socket in B<c> if it is not NULL, it also
-returns the socket . If B<c> is not NULL it should be of type (int *).
+returns the socket. If B<c> is not NULL it should be of type (int *).
 
 BIO_new_socket() returns a socket BIO using B<sock> and B<close_flag>.
 
@@ -44,6 +44,8 @@ platforms sockets are not file descriptors and use distinct I/O routines,
 Windows is one such platform. Any code mixing the two will not work on
 all platforms.
 
+BIO_set_fd() and BIO_get_fd() are macros.
+
 =head1 RETURN VALUES
 
 BIO_s_socket() returns the socket BIO method.
diff --git a/doc/ssl/SSL_CTX_new.pod b/doc/ssl/SSL_CTX_new.pod
index e166c692c3..8b16ea3c90 100644
--- a/doc/ssl/SSL_CTX_new.pod
+++ b/doc/ssl/SSL_CTX_new.pod
@@ -33,9 +33,9 @@ understand SSLv2 client hello messages.
 =item SSLv3_method(void), SSLv3_server_method(void), SSLv3_client_method(void)
 
 A TLS/SSL connection established with these methods will only understand the
-SSLv3 and TLSv1 protocol. A client will send out SSLv3 client hello messages
-and will indicate that it also understands TLSv1. A server will only understand
-SSLv3 and TLSv1 client hello messages. This especially means, that it will
+SSLv3 protocol. A client will send out SSLv3 client hello messages
+and will indicate that it only understands SSLv3. A server will only understand
+SSLv3 client hello messages. This especially means, that it will
 not understand SSLv2 client hello messages which are widely used for
 compatibility reasons, see SSLv23_*_method().
 
@@ -46,7 +46,8 @@ TLSv1 protocol. A client will send out TLSv1 client hello messages
 and will indicate that it only understands TLSv1. A server will only understand
 TLSv1 client hello messages. This especially means, that it will
 not understand SSLv2 client hello messages which are widely used for
-compatibility reasons, see SSLv23_*_method().
+compatibility reasons, see SSLv23_*_method(). It will also not understand
+SSLv3 client hello messages.
 
 =item SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)
 
diff --git a/doc/ssl/SSL_CTX_set_verify.pod b/doc/ssl/SSL_CTX_set_verify.pod
index f405a6a5c3..9d7b7a9070 100644
--- a/doc/ssl/SSL_CTX_set_verify.pod
+++ b/doc/ssl/SSL_CTX_set_verify.pod
@@ -187,7 +187,7 @@ certificates.
      * SSL_CTX_set_verify_depth() is by purpose set to "limit+1" so
      * that whenever the "depth>verify_depth" condition is met, we
      * have violated the limit and want to log this error condition.
-     * We must do it here, because the CHAIN_TO_LONG error would not
+     * We must do it here, because the CHAIN_TOO_LONG error would not
      * be found explicitly; only errors introduced by cutting off the
      * additional certificates would be logged.
      */
diff --git a/doc/ssl/SSL_connect.pod b/doc/ssl/SSL_connect.pod
index 0316f8df1c..00813ecfff 100644
--- a/doc/ssl/SSL_connect.pod
+++ b/doc/ssl/SSL_connect.pod
@@ -64,6 +64,6 @@ to find out the reason.
 =head1 SEE ALSO
 
 L<SSL_get_error(3)|SSL_get_error(3)>, L<SSL_accept(3)|SSL_accept(3)>,
-L<SSL_shutdown(3)|SSL_shutdown(3)>, L<ssl(3)|ssl(3)> , L<bio(3)|bio(3)>
+L<SSL_shutdown(3)|SSL_shutdown(3)>, L<ssl(3)|ssl(3)>, L<bio(3)|bio(3)>
 
 =cut
diff --git a/doc/ssl/SSL_write.pod b/doc/ssl/SSL_write.pod
index 7ce625ac21..01e3d2c596 100644
--- a/doc/ssl/SSL_write.pod
+++ b/doc/ssl/SSL_write.pod
@@ -31,7 +31,7 @@ when the underlying BIO could not satisfy the needs of SSL_write()
 to continue the operation. In this case a call to SSL_get_error() with the
 return value of SSL_write() will yield B<SSL_ERROR_WANT_READ> or
 B<SSL_ERROR_WANT_WRITE>. As at any time a re-negotiation is possible, a
-call to SSL_write() can also cause write operations! The calling process
+call to SSL_write() can also cause read operations! The calling process
 then must repeat the call after taking appropriate action to satisfy the
 needs of SSL_write(). The action depends on the underlying BIO. When using a
 non-blocking socket, nothing is to be done, but select() can be used to check
diff --git a/doc/ssl/ssl.pod b/doc/ssl/ssl.pod
index 557378d723..87f698fba9 100644
--- a/doc/ssl/ssl.pod
+++ b/doc/ssl/ssl.pod
@@ -13,6 +13,69 @@ The OpenSSL B<ssl> library implements the Secure Sockets Layer (SSL v2/v3) and
 Transport Layer Security (TLS v1) protocols. It provides a rich API which is
 documented here.
 
+At first the library must be initialized; see
+L<SSL_library_init(3)|SSL_library_init(3)>.
+
+Then an B<SSL_CTX> object is created as a framework to establish
+TLS/SSL enabled connections (see L<SSL_CTX_new(3)|SSL_CTX_new(3)>).
+Various options regarding certificates, algorithms etc. can be set
+in this object.
+
+When a network connection has been created, it can be assigned to an
+B<SSL> object. After the B<SSL> object has been created using
+L<SSL_new(3)|SSL_new(3)>, L<SSL_set_fd(3)|SSL_set_fd(3)> or
+L<SSL_set_bio(3)|SSL_set_bio(3)> can be used to associate the network
+connection with the object.
+
+Then the TLS/SSL handshake is performed using
+L<SSL_accept(3)|SSL_accept(3)> or L<SSL_connect(3)|SSL_connect(3)>
+respectively.
+L<SSL_read(3)|SSL_read(3)> and L<SSL_write(3)|SSL_write(3)> are used
+to read and write data on the TLS/SSL connection.
+L<SSL_shutdown(3)|SSL_shutdown(3)> can be used to shut down the
+TLS/SSL connection.
+
+=head1 DATA STRUCTURES
+
+Currently the OpenSSL B<ssl> library functions deals with the following data
+structures:
+
+=over 4
+
+=item B<SSL_METHOD> (SSL Method)
+
+That's a dispatch structure describing the internal B<ssl> library
+methods/functions which implement the various protocol versions (SSLv1, SSLv2
+and TLSv1). It's needed to create an B<SSL_CTX>.
+
+=item B<SSL_CIPHER> (SSL Cipher)
+
+This structure holds the algorithm information for a particular cipher which
+are a core part of the SSL/TLS protocol. The available ciphers are configured
+on a B<SSL_CTX> basis and the actually used ones are then part of the
+B<SSL_SESSION>.
+
+=item B<SSL_CTX> (SSL Context)
+
+That's the global context structure which is created by a server or client
+once per program life-time and which holds mainly default values for the
+B<SSL> structures which are later created for the connections.
+
+=item B<SSL_SESSION> (SSL Session)
+
+This is a structure containing the current TLS/SSL session details for a
+connection: B<SSL_CIPHER>s, client and server certificates, keys, etc.
+
+=item B<SSL> (SSL Connection)
+
+That's the main SSL/TLS structure which is created by a server or client per
+established connection. This actually is the core structure in the SSL API.
+Under run-time the application usually deals with this structure which has
+links to mostly all other structures.
+
+=back
+
+
 =head1 HEADER FILES
 
 Currently the OpenSSL B<ssl> library provides the following C header files
@@ -55,46 +118,6 @@ it's already included by ssl.h>.
 
 =back
 
-=head1 DATA STRUCTURES
-
-Currently the OpenSSL B<ssl> library functions deals with the following data
-structures:
-
-=over 4
-
-=item B<SSL_METHOD> (SSL Method)
-
-That's a dispatch structure describing the internal B<ssl> library
-methods/functions which implement the various protocol versions (SSLv1, SSLv2
-and TLSv1). It's needed to create an B<SSL_CTX>.
-
-=item B<SSL_CIPHER> (SSL Cipher)
-
-This structure holds the algorithm information for a particular cipher which
-are a core part of the SSL/TLS protocol. The available ciphers are configured
-on a B<SSL_CTX> basis and the actually used ones are then part of the
-B<SSL_SESSION>.
-
-=item B<SSL_CTX> (SSL Context)
-
-That's the global context structure which is created by a server or client
-once per program life-time and which holds mainly default values for the
-B<SSL> structures which are later created for the connections.
-
-=item B<SSL_SESSION> (SSL Session)
-
-This is a structure containing the current TLS/SSL session details for a
-connection: B<SSL_CIPHER>s, client and server certificates, keys, etc.
-
-=item B<SSL> (SSL Connection)
-
-That's the main SSL/TLS structure which is created by a server or client per
-established connection. This actually is the core structure in the SSL API.
-Under run-time the application usually deals with this structure which has
-links to mostly all other structures.
-
-=back
-
 =head1 API FUNCTIONS
 
 Currently the OpenSSL B<ssl> library exports 214 API functions.