This commit was manufactured by cvs2svn to create branch 'RELENG_4_5'.

6 files changed, 312 insertions, 0 deletions

diff --git a/crypto/openssl/doc/ssl/SSL_CTX_set_cert_store.pod b/crypto/openssl/doc/ssl/SSL_CTX_set_cert_store.pod
new file mode 100644
index 000000000000..3a240c4d3747
--- /dev/null
+++ b/crypto/openssl/doc/ssl/SSL_CTX_set_cert_store.pod
@@ -0,0 +1,57 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_set_cert_store, SSL_CTX_get_cert_store - manipulate X509 certificate verification storage
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ void SSL_CTX_set_cert_store(SSL_CTX *ctx, X509_STORE *store);
+ X509_STORE *SSL_CTX_get_cert_store(SSL_CTX *ctx);
+
+=head1 DESCRIPTION
+
+SSL_CTX_set_cert_store() sets/replaces the certificate verification storage
+of B<ctx> to/with B<store>. If another X509_STORE object is currently
+set in B<ctx>, it will be X509_STORE_free()ed.
+
+SSL_CTX_get_cert_store() returns a pointer to the current certificate
+verification storage.
+
+=head1 NOTES
+
+In order to verify the certificates presented by the peer, trusted CA
+certificates must be accessed. These CA certificates are made available
+via lookup methods, handled inside the X509_STORE. From the X509_STORE
+the X509_STORE_CTX used when verifying certificates is created.
+
+Typically the trusted certificate store is handled indirectly via using
+L<SSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)>.
+Using the SSL_CTX_set_cert_store() and SSL_CTX_get_cert_store() functions
+it is possible to manipulate the X509_STORE object beyond the
+L<SSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)>
+call.
+
+Currently no detailed documentation on how to use the X509_STORE
+object is available. Not all members of the X509_STORE are used when
+the verification takes place. So will e.g. the verify_callback() be
+overridden with the verify_callback() set via the
+L<SSL_CTX_set_verify(3)|SSL_CTX_set_verify(3)> family of functions.
+This document must therefore be updated when documentation about the
+X509_STORE object and its handling becomes available.
+
+=head1 RETURN VALUES
+
+SSL_CTX_set_cert_store() does not return diagnostic output.
+
+SSL_CTX_get_cert_store() returns the current setting.
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>,
+L<SSL_CTX_load_verify_locations(3)|SSL_CTX_load_verify_locations(3)>,
+L<SSL_CTX_set_verify(3)|SSL_CTX_set_verify(3)>
+
+=cut
diff --git a/crypto/openssl/doc/ssl/SSL_CTX_set_client_cert_cb.pod b/crypto/openssl/doc/ssl/SSL_CTX_set_client_cert_cb.pod
new file mode 100644
index 000000000000..3465b5c7bbaf
--- /dev/null
+++ b/crypto/openssl/doc/ssl/SSL_CTX_set_client_cert_cb.pod
@@ -0,0 +1,94 @@
+=pod
+
+=head1 NAME
+
+SSL_CTX_set_client_cert_cb, SSL_CTX_get_client_cert_cb - handle client certificate callback function
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ void SSL_CTX_set_client_cert_cb(SSL_CTX *ctx, int (*client_cert_cb)(SSL *ssl, X509 **x509, EVP_PKEY **pkey));
+ int (*SSL_CTX_get_client_cert_cb(SSL_CTX *ctx))(SSL *ssl, X509 **x509, EVP_PKEY **pkey);
+ int (*client_cert_cb)(SSL *ssl, X509 **x509, EVP_PKEY **pkey);
+
+=head1 DESCRIPTION
+
+SSL_CTX_set_client_cert_cb() sets the B<client_cert_cb()> callback, that is
+called when a client certificate is requested by a server and no certificate
+was yet set for the SSL object.
+
+When B<client_cert_cb()> is NULL, no callback function is used.
+
+SSL_CTX_get_client_cert_cb() returns a pointer to the currently set callback
+function.
+
+client_cert_cb() is the application defined callback. If it wants to
+set a certificate, a certificate/private key combination must be set
+using the B<x509> and B<pkey> arguments and "1" must be returned. The
+certificate will be installed into B<ssl>, see the NOTES and BUGS sections.
+If no certificate should be set, "0" has to be returned and no certificate
+will be sent. A negative return value will suspend the handshake and the
+handshake function will return immediatly. L<SSL_get_error(3)|SSL_get_error(3)>
+will return SSL_ERROR_WANT_X509_LOOKUP to indicate, that the handshake was
+suspended. The next call to the handshake function will again lead to the call
+of client_cert_cb(). It is the job of the client_cert_cb() to store information
+about the state of the last call, if required to continue.
+
+=head1 NOTES
+
+During a handshake (or renegotiation) a server may request a certificate
+from the client. A client certificate must only be sent, when the server
+did send the request.
+
+When a certificate was set using the
+L<SSL_CTX_use_certificate(3)|SSL_CTX_use_certificate(3)> family of functions,
+it will be sent to the server. The TLS standard requires that only a
+certificate is sent, if it matches the list of acceptable CAs sent by the
+server. This constraint is violated by the default behavior of the OpenSSL
+library. Using the callback function it is possible to implement a proper
+selection routine or to allow a user interaction to choose the certificate to
+be sent.
+
+If a callback function is defined and no certificate was yet defined for the
+SSL object, the callback function will be called.
+If the callback function returns a certificate, the OpenSSL library
+will try to load the private key and certificate data into the SSL
+object using the SSL_use_certificate() and SSL_use_private_key() functions.
+Thus it will permanently install the certificate and key for this SSL
+object. It will not be reset by calling L<SSL_clear(3)|SSL_clear(3)>.
+If the callback returns no certificate, the OpenSSL library will not send
+a certificate.
+
+=head1 BUGS
+
+The client_cert_cb() cannot return a complete certificate chain, it can
+only return one client certificate. If the chain only has a length of 2,
+the root CA certificate may be omitted according to the TLS standard and
+thus a standard conforming answer can be sent to the server. For a
+longer chain, the client must send the complete chain (with the option
+to leave out the root CA certificate). This can only be accomplished by
+either adding the intermediate CA certificates into the trusted
+certificate store for the SSL_CTX object (resulting in having to add
+CA certificates that otherwise maybe would not be trusted), or by adding
+the chain certificates using the
+L<SSL_CTX_add_extra_chain_cert(3)|SSL_CTX_add_extra_chain_cert(3)>
+function, which is only available for the SSL_CTX object as a whole and that
+therefore probably can only apply for one client certificate, making
+the concept of the callback function (to allow the choice from several
+certificates) questionable.
+
+Once the SSL object has been used in conjunction with the callback function,
+the certificate will be set for the SSL object and will not be cleared
+even when L<SSL_clear(3)|SSL_clear(3)> is being called. It is therefore
+mandatory to destroy the SSL object using L<SSL_free(3)|SSL_free(3)>
+and create a new one to return to the previous state.
+
+=head1 SEE ALSO
+
+L<ssl(3)|ssl(3)>, L<SSL_CTX_use_certificate(3)|SSL_CTX_use_certificate(3)>,
+L<SSL_CTX_add_extra_chain_cert(3)|SSL_CTX_add_extra_chain_cert(3)>,
+L<SSL_get_client_CA_list(3)|SSL_get_client_CA_list(3)>,
+L<SSL_clear(3)|SSL_clear(3)>, L<SSL_free(3)|SSL_free(3)>
+
+=cut
diff --git a/crypto/openssl/doc/ssl/SSL_do_handshake.pod b/crypto/openssl/doc/ssl/SSL_do_handshake.pod
new file mode 100644
index 000000000000..243576451b7f
--- /dev/null
+++ b/crypto/openssl/doc/ssl/SSL_do_handshake.pod
@@ -0,0 +1,75 @@
+=pod
+
+=head1 NAME
+
+SSL_do_handshake - perform a TLS/SSL handshake
+
+=head1 SYNOPSIS
+
+ #include <openssl/ssl.h>
+
+ int SSL_do_handshake(SSL *ssl);
+
+=head1 DESCRIPTION
+
+SSL_do_handshake() will wait for a SSL/TLS handshake to take place. If the
+connection is in client mode, the handshake will be started. The handshake
+routines may have to be explicitly set in advance using either
+L<SSL_set_connect_state(3)|SSL_set_connect_state(3)> or
+L<SSL_set_accept_state(3)|SSL_set_accept_state(3)>.
+
+=head1 NOTES
+
+The behaviour of SSL_do_handshake() depends on the underlying BIO.
+
+If the underlying BIO is B<blocking>, SSL_do_handshake() will only return
+once the handshake has been finished or an error occurred, except for SGC
+(Server Gated Cryptography). For SGC, SSL_do_handshake() may return with -1,
+but SSL_get_error() will yield B<SSL_ERROR_WANT_READ/WRITE> and
+SSL_do_handshake() should be called again.
+
+If the underlying BIO is B<non-blocking>, SSL_do_handshake() will also return
+when the underlying BIO could not satisfy the needs of SSL_do_handshake()
+to continue the handshake. In this case a call to SSL_get_error() with the
+return value of SSL_do_handshake() will yield B<SSL_ERROR_WANT_READ> or
+B<SSL_ERROR_WANT_WRITE>. The calling process then must repeat the call after
+taking appropriate action to satisfy the needs of SSL_do_handshake().
+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 for the required
+condition. When using a buffering BIO, like a BIO pair, data must be written
+into or retrieved out of the BIO before being able to continue.
+
+=head1 RETURN VALUES
+
+The following return values can occur:
+
+=over 4
+
+=item 1
+
+The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
+established.
+
+=item 0
+
+The TLS/SSL handshake was not successful but was shut down controlled and
+by the specifications of the TLS/SSL protocol. Call SSL_get_error() with the
+return value B<ret> to find out the reason.
+
+=item E<lt>0
+
+The TLS/SSL handshake was not successful because a fatal error occurred either
+at the protocol level or a connection failure occurred. The shutdown was
+not clean. It can also occur of action is need to continue the operation
+for non-blocking BIOs. Call SSL_get_error() with the return value B<ret>
+to find out the reason.
+
+=back
+
+=head1 SEE ALSO
+
+L<SSL_get_error(3)|SSL_get_error(3)>, L<SSL_connect(3)|SSL_connect(3)>,
+L<SSL_accept(3)|SSL_accept(3)>, L<ssl(3)|ssl(3)>, L<bio(3)|bio(3)>,
+L<SSL_set_connect_state(3)|SSL_set_connect_state(3)>
+
+=cut
diff --git a/crypto/openssl/util/dirname.pl b/crypto/openssl/util/dirname.pl
new file mode 100644
index 000000000000..d7a66d96accf
--- /dev/null
+++ b/crypto/openssl/util/dirname.pl
@@ -0,0 +1,18 @@
+#!/usr/local/bin/perl
+
+if ($#ARGV < 0) {
+    die "dirname.pl: too few arguments\n";
+} elsif ($#ARGV > 0) {
+    die "dirname.pl: too many arguments\n";
+}
+
+my $d = $ARGV[0];
+
+if ($d =~ m|.*/.*|) {
+    $d =~ s|/[^/]*$||;
+} else {
+    $d = ".";
+}
+
+print $d,"\n";
+exit(0);
diff --git a/crypto/openssl/util/pod2mantest b/crypto/openssl/util/pod2mantest
new file mode 100755
index 000000000000..449ef14f1b43
--- /dev/null
+++ b/crypto/openssl/util/pod2mantest
@@ -0,0 +1,53 @@
+#!/bin/sh
+
+# This script is used by test/Makefile.ssl to check whether a sane 'pod2man'
+# is installed.
+# ('make install' should not try to run 'pod2man' if it does not exist or if
+# it is a broken 'pod2man' version that is known to cause trouble. if we find
+# the system 'pod2man' to be broken, we use our own copy instead)
+#
+# In any case, output an appropriate command line for running (or not
+# running) pod2man.
+
+
+IFS=:
+try_without_dir=false
+# First we try "pod2man", then "$dir/pod2man" for each item in $PATH.
+for dir in dummy:$PATH; do
+    if [ "$try_without_dir" = true ]; then
+      # first iteration
+      pod2man=pod2man
+      try_without_dir=false
+    else
+      # second and later iterations
+      pod2man="$dir/pod2man"
+      if [ ! -f "$pod2man" ]; then  # '-x' is not available on Ultrix
+        pod2man=''
+      fi
+    fi
+
+    if [ ! "$pod2man" = '' ]; then
+        failure=none
+
+
+	if "$pod2man" --section=1 --center=OpenSSL --release=dev pod2mantest.pod | grep '^MARKER - ' >/dev/null 2>&1; then
+	    failure=MultilineTest
+	fi
+
+
+        if [ "$failure" = none ]; then
+            echo "$pod2man"
+            exit 0
+        fi
+
+        echo "$pod2man does not work properly ('$failure' failed).  Looking for another pod2man ..." >&2
+    fi
+done
+
+echo "No working pod2man found.  Consider installing a new version." >&2
+if [ "$1" = ignore ]; then
+  echo "As a workaround, we'll use a bundled old copy of pod2man.pl." >&2
+  echo "../../util/pod2man.pl"
+  exit 0
+fi
+exit 1
diff --git a/crypto/openssl/util/pod2mantest.pod b/crypto/openssl/util/pod2mantest.pod
new file mode 100644
index 000000000000..5d2539a17fb1
--- /dev/null
+++ b/crypto/openssl/util/pod2mantest.pod
@@ -0,0 +1,15 @@
+=pod
+
+=head1 NAME
+
+foo, bar,
+MARKER - test of multiline name section
+
+=head1 DESCRIPTION
+
+This is a test .pod file to see if we have a buggy pod2man or not.
+If we have a buggy implementation, we will get a line matching the
+regular expression "^ +MARKER - test of multiline name section *$"
+at the end of the resulting document.
+
+=cut