[SCM] GNU gnutls branch, master, updated. gnutls_3_0_0-51-g466b56c

[Nikos Mavrogiannopoulos]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU gnutls".

http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=466b56cc3416ef366bbf043db7c090bd17b77e34

The branch, master has been updated
       via  466b56cc3416ef366bbf043db7c090bd17b77e34 (commit)
       via  e617a9abfd122d6b8b4eefcbded2b99d25c72868 (commit)
       via  317f8a832b1d685e7a785ced7f9741278084e243 (commit)
       via  4c722d46b244f8786c9701b042dd6bb0f8a49d8c (commit)
      from  4a91ff90f4ebf44219b228ea11bbddf52eb4b002 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
-----------------------------------------------------------------------

Summary of changes:
 doc/cha-gtls-app.texi     |   20 +++++++++-----------
 doc/cha-programs.texi     |   20 ++++++++++----------
 doc/cha-support.texi      |    7 +++----
 doc/cha-tls-app.texi      |   12 ++++++------
 doc/manpages/gnutls-cli.1 |    8 ++++----
 5 files changed, 32 insertions(+), 35 deletions(-)

diff --git a/doc/cha-gtls-app.texi b/doc/cha-gtls-app.texi
index 2b250b2..b684085 100644
--- a/doc/cha-gtls-app.texi
+++ b/doc/cha-gtls-app.texi
@@ -672,13 +672,13 @@ In user authentication protocols (e.g., EAP or SASL 
mechanisms) it is
 useful to have a unique string that identifies the secure channel that
 is used, to bind together the user authentication with the secure
 channel.  This can protect against man-in-the-middle attacks in some
-situations.  The unique strings is a ``channel bindings''.  For
-background and more discussion see @xcite{RFC5056}.
+situations.  That unique string is called a ``channel binding''.  For
+background and discussion see @xcite{RFC5056}.
 
-You can extract a channel bindings using the
+In @acronym{GnuTLS} you can extract a channel binding using the
 @funcref{gnutls_session_channel_binding} function.  Currently only the
address@hidden type is supported, which corresponds to
-the @code{tls-unique} channel bindings for TLS defined in
+type @code{GNUTLS_CB_TLS_UNIQUE} is supported, which corresponds to
+the @code{tls-unique} channel binding for TLS defined in
 @xcite{RFC5929}.
 
 The following example describes how to print the channel binding data.
@@ -711,17 +711,15 @@ Note that it must be run after a successful TLS handshake.
 @cindex OpenSSL
 
 To ease @acronym{GnuTLS}' integration with existing applications, a
-compatibility layer with the widely used OpenSSL library is included
+compatibility layer with the OpenSSL library is included
 in the @code{gnutls-openssl} library. This compatibility layer is not
 complete and it is not intended to completely re-implement the OpenSSL
 API with @acronym{GnuTLS}.  It only provides limited source-level
-compatibility. There is currently no attempt to make it
-binary-compatible with OpenSSL.
+compatibility. 
 
 The prototypes for the compatibility functions are in the
address@hidden/openssl.h} header file.
-
-Current limitations imposed by the compatibility layer include:
address@hidden/openssl.h} header file. The limitations 
+imposed by the compatibility layer include:
 
 @itemize
 
diff --git a/doc/cha-programs.texi b/doc/cha-programs.texi
index 46dfe10..b0d46cf 100644
--- a/doc/cha-programs.texi
+++ b/doc/cha-programs.texi
@@ -411,15 +411,6 @@ Usage:  gnutls-cli [options] hostname
      -v, --version            prints the program's version number
 @end example
 
-To connect to a server using PSK authentication, you may use something
-like:
-
address@hidden
-$ gnutls-cli -p 5556 test.gnutls.org --pskusername jas \
-  --pskkey 9e32cf7786321a828ef7668f09fb35db \
-  --priority NORMAL:-KX-ALL:+ECDHE-PSK:DHE-PSK:+PSK
address@hidden smallexample
-
 @menu
 * Example client PSK connection::
 @end menu
@@ -428,6 +419,15 @@ $ gnutls-cli -p 5556 test.gnutls.org --pskusername jas \
 @subsection Example client PSK connection
 @cindex PSK client
 
+To connect to a server using PSK authentication, you may use something
+like:
+
address@hidden
+$ gnutls-cli -p 5556 test.gnutls.org --pskusername jas \
+  --pskkey 9e32cf7786321a828ef7668f09fb35db \
+  --priority NORMAL:-KX-ALL:+ECDHE-PSK:+DHE-PSK:+PSK
address@hidden smallexample
+
 If your server only supports the PSK ciphersuite, connecting to it
 should be as simple as connecting to the server:
 
@@ -482,7 +482,7 @@ This program was created to assist in debugging 
@acronym{GnuTLS}, but
 it might be useful to extract a @acronym{TLS} server's capabilities.
 It's purpose is to connect onto a @acronym{TLS} server, perform some
 tests and print the server's capabilities. If called with the `-v'
-parameter a more checks will be performed. An example output is:
+parameter more checks will be performed. An example output is:
 
 @example
 crystal:/cvs/gnutls/src$ ./gnutls-cli-debug localhost -p 5556
diff --git a/doc/cha-support.texi b/doc/cha-support.texi
index 604f85f..835482f 100644
--- a/doc/cha-support.texi
+++ b/doc/cha-support.texi
@@ -56,7 +56,7 @@ E-mail: address@hidden
 @end verbatim
 
 If your company provides support related to GnuTLS and would like to
-be mentioned here, contact the authors using the address at @ref{Bug Reports}.
+be mentioned here, contact the authors.
 
 @node Downloading and Installing
 @section Downloading and Installing
@@ -155,7 +155,7 @@ Send your bug report to:
 @cindex Contributing
 @cindex Hacking
 
-If you want to submit a patch for inclusion -- from solve a typo you
+If you want to submit a patch for inclusion -- from solving a typo you
 discovered, up to adding support for a new feature -- you should
 submit it as a bug report, using the process in @ref{Bug Reports}.  There are 
some
 things that you can do to increase the chances for it to be included
@@ -168,8 +168,7 @@ already signed papers, we will send you the necessary 
information when
 you submit your contribution.
 
 For contributions that doesn't consist of actual programming code, the
-only guidelines are common sense.  Use it.
-
+only guidelines are common sense.  
 For code contributions, a number of style guides will help you:
 
 @itemize @bullet
diff --git a/doc/cha-tls-app.texi b/doc/cha-tls-app.texi
index 9344522..b8e83ed 100644
--- a/doc/cha-tls-app.texi
+++ b/doc/cha-tls-app.texi
@@ -43,12 +43,13 @@ soon obsoleted.
 
 Other application address@hidden LDAP, IMAP etc.}  use a
 different approach to enable the secure layer.  They use something
-called the ``TLS upgrade'' method. This method is quite tricky but it
+often called as the ``TLS upgrade'' method. This method is quite tricky but it
 is more flexible. The idea is to extend the application protocol to
 have a ``STARTTLS'' request, whose purpose it to start the TLS
 protocols just after the client requests it.  This approach
-does not require an extra port and is used by almost all modern protocols.
-There is even an extension to HTTP protocol to support that method 
@xcite{RFC2817}.
+does not require any extra port to be reserved.
+There is even an extension to HTTP protocol to support 
+that method @xcite{RFC2817}.
 
 The tricky part, in this method, is that the ``STARTTLS'' request is
 sent in the clear, thus is vulnerable to modifications.  A typical
@@ -94,7 +95,7 @@ CLIENT: HERE ARE SOME CONFIDENTIAL DATA
 As you can see above the client was fooled, and was dummy enough to
 send the confidential data in the clear.
 
-How to avoid the above attack? As you may have already thought this
+How to avoid the above attack? As you may have already noticed this
 one is easy to avoid. The client has to ask the user before it
 connects whether the user requests @acronym{TLS} or not. If the user
 answered that he certainly wants the secure layer the last
@@ -123,5 +124,4 @@ traditional method, and the security properties remain the 
same, since
 only denial of service is possible. The benefit is that the server may
 request additional data before the @acronym{TLS} Handshake protocol
 starts, in order to send the correct certificate, use the correct
-password address@hidden @acronym{SRP} authentication}, or anything
-else!
+password file, or anything else!
diff --git a/doc/manpages/gnutls-cli.1 b/doc/manpages/gnutls-cli.1
index 0b170ec..8a42a5c 100644
--- a/doc/manpages/gnutls-cli.1
+++ b/doc/manpages/gnutls-cli.1
@@ -123,14 +123,14 @@ SRP password to use.
 .IP "\-\-srpusername \fINAME\fR"
 SRP username to use.
 .IP "\-\-x509cafile \fIFILE\fR"
-Certificate file to use. This option accepts PKCS \#11 URLs such as
-pkcs11:token=Root%20CA%20Certificates;serial=1%3AROOTS%3ADEFAULT;model=1%2E0;manufacturer=Gnome%20Keyring
+Certificate file to use. This option accepts PKCS #11 URLs such as
+"pkcs11:token=xxx"
 .IP "\-\-x509certfile \fIFILE\fR"
-X.509 Certificate file to use, or a PKCS \#11 URL.
+X.509 Certificate file to use, or a PKCS #11 URL.
 .IP "\-\-x509fmtder"
 Use DER format for certificates
 .IP "\-\-x509keyfile \fIFILE\fR"
-X.509 key file or PKCS \#11 URL to use.
+X.509 key file or PKCS #11 URL to use.
 .IP "\-\-x509crlfile \fIFILE\fR"
 X.509 CRL file to use.
 .IP "\-\-pskusername \fINAME\fR"


hooks/post-receive
-- 
GNU gnutls