[SCM] GNU gnutls branch, master, updated. gnutls_3_0_2-7-g9a733c3

[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=9a733c39944f9060df194af40a2fa3b56e39afc3

The branch, master has been updated
       via  9a733c39944f9060df194af40a2fa3b56e39afc3 (commit)
       via  87ba18ff2d3779f34327a25742b8d0a87e7bcb79 (commit)
       via  794af607bb7cbe444d84e11985416136b383553e (commit)
      from  2f7b2376439e2b04a61e48bc2efcaebe3b776323 (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:
 .gitignore            |    2 ++
 configure.ac          |    5 +++++
 doc/cha-gtls-app.texi |   30 ++++++++++++++----------------
 3 files changed, 21 insertions(+), 16 deletions(-)

diff --git a/.gitignore b/.gitignore
index 4cc3497..1440d09 100644
--- a/.gitignore
+++ b/.gitignore
@@ -508,3 +508,5 @@ src/crywrap/crywrap
 gl/dirent.h
 gl/getopt.h
 gl/math.h
+doc/doxygen/latex/
+doc/doxygen/html/
diff --git a/configure.ac b/configure.ac
index fc54eee..85916ef 100644
--- a/configure.ac
+++ b/configure.ac
@@ -130,6 +130,11 @@ if test "$with_p11_kit" != "no"; then
                AC_DEFINE([ENABLE_PKCS11], 1, [Build PKCS#11 support])
                CFLAGS="$CFLAGS $P11_KIT_CFLAGS"
                LIBS="$LIBS $P11_KIT_LIBS"
+               if test "x$GNUTLS_REQUIRES_PRIVATE" = "x"; then
+                       GNUTLS_REQUIRES_PRIVATE="Requires.private: p11-kit-1"
+               else
+                       GNUTLS_REQUIRES_PRIVATE="${GNUTLS_REQUIRES_PRIVATE}, 
p11-kit-1"
+               fi
        else
                AC_MSG_WARN([[
 *** 
diff --git a/doc/cha-gtls-app.texi b/doc/cha-gtls-app.texi
index 0c9f6a9..64fbdc6 100644
--- a/doc/cha-gtls-app.texi
+++ b/doc/cha-gtls-app.texi
@@ -275,9 +275,9 @@ denial of service attacks. @acronym{GnuTLS} requires a 
server
 to generate a secret key that is used to sign a address@hidden key of 128 bits 
or 16 bytes should be sufficient for this purpose.}. 
 That cookie is sent to the client using @funcref{gnutls_dtls_cookie_send}, and 
 the client must reply using the correct cookie. The server side
-should verify the initial message sent by client using 
@funcref{gnutls_dtls_cookie_verify},
-if successful associate a session with the cookie using 
@funcref{gnutls_dtls_prestate_set}
-and proceed to a proper handshake.
+should verify the initial message sent by client using 
@funcref{gnutls_dtls_cookie_verify}.
+If successful a the session should be initialization and associated with
+the cookie using @funcref{gnutls_dtls_prestate_set}.
 
 @showfuncdesc{gnutls_key_generate}
 
@@ -294,7 +294,7 @@ The client side cookie handling is part of 
@funcref{gnutls_handshake}.
 
 Datagrams are typically restricted by a maximum transfer unit (MTU). For that
 both client and server side should set the correct maximum transfer unit for
-the layer underneath @acronym{GnuTLS}. This would allow proper fragmentation
+the layer underneath @acronym{GnuTLS}. This will allow proper fragmentation
 of DTLS messages and prevent messages from being silently discarded by the
 transport layer. The ``correct'' maximum transfer unit can be obtained through
 a path MTU discovery mechanism @xcite{RFC4821}.
@@ -307,13 +307,12 @@ a path MTU discovery mechanism @xcite{RFC4821}.
 @node Priority Strings
 @section Priority strings
 
-In order to specify cipher suite preferences on client or server side, the
-previously mentioned priority functions accept a string
-that specifies the enabled for the handshake algorithms.
-That string may contain some high level keyword such as
-the keywords in @ref{tab:prio-keywords}
-or it might contain special keywords, to be explained
-later on.
+In order to specify cipher suite preferences on a TLS session
+there are priority functions that accept a string
+specifying the enabled for the handshake algorithms.
+That string may contain a high level keyword such as
+in @ref{tab:prio-keywords} or combination of a high level
+keyword, additional algorithm keywords and special keywords.
 
 
@showfuncD{gnutls_priority_set_direct,gnutls_priority_init,gnutls_priority_deinit,gnutls_priority_set}
 
@@ -361,14 +360,13 @@ algorithms to be enabled.
 
 Unless the first keyword is "NONE" the defaults (in preference
 order) are for TLS protocols TLS 1.2, TLS1.1, TLS1.0, SSL3.0; for
-compression NULL; for certificate types X.509, OpenPGP.
-For key exchange algorithms when in NORMAL or SECURE levels the
+compression NULL; for certificate types X.509.
+In key exchange algorithms when in NORMAL or SECURE levels the
 perfect forward secrecy algorithms take precedence of the other
 protocols.  In all cases all the supported key exchange algorithms
  are enabled (except for the RSA-EXPORT which is only enabled in
 EXPORT level).
-
-The NONE keyword must followed by the algorithms to be enabled,
+The NONE keyword, if used, must followed by the algorithms to be enabled,
 and is used to provide the exact list of requested address@hidden avoid 
collisions in order to specify a compression algorithm in
 this string you have to prefix it with "COMP-", protocol versions
 with "VERS-", signature algorithms with "SIGN-" and certificate types with 
"CTYPE-". All other
@@ -421,7 +419,7 @@ is SIGN-ALL. This is only valid for TLS 1.2 and later.
 CURVE-SECP224R1, CURVE-SECP256R1, CURVE-SECP384R1, CURVE-SECP521R1. Catch all 
is CURVE-ALL.
 
 @end multitable
address@hidden supported priority strings.}
address@hidden supported algorithm keywords in priority strings.}
 @end float
 
 


hooks/post-receive
-- 
GNU gnutls