Skip to contentSkip to conversation

OpenVPN Doxygen patches

PATCH In review Adriaan de Jong 2 participants 19 messages Jun 22, 2011 – Jul 29, 2011

lore
Share & tools
lore
#0 lore raw

cover OpenVPN Doxygen patches

Hi everyone,

Here's the first series of promised patches, many others will follow in the next few weeks. Although these are meant to be ready for the master branch, the actual process of generating patches with git is new to me, so please forgive any errors :).

This first series adds Doxygen documentation to OpenVPN, which can be generated using 'doxygen openvpn.doxyfile'. The graphviz and doxygen packages must be installed on your system to do so.

Regards,

Adriaan de Jong
Fox-IT

#1 lore raw

PATCH 1/8 Added Doxygen doxyfile

---
 openvpn.doxyfile |  279 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 279 insertions(+), 0 deletions(-)
 create mode 100644 openvpn.doxyfile
openvpn.doxyfile new file +279 -0
new file mode 100644
index 0000000..be06bfb
@@ -0,0 +1,279 @@
+# Doxyfile 1.5.5
+
+#---------------------------------------------------------------------------
+# Project related configuration options
+#---------------------------------------------------------------------------
+DOXYFILE_ENCODING      = UTF-8
+PROJECT_NAME           = "OpenVPN"
+PROJECT_NUMBER         = 
+OUTPUT_DIRECTORY       = doxygen/output
+CREATE_SUBDIRS         = NO
+OUTPUT_LANGUAGE        = English
+BRIEF_MEMBER_DESC      = YES
+REPEAT_BRIEF           = YES
+ABBREVIATE_BRIEF       = "The $name class" \
+                         "The $name widget" \
+                         "The $name file" \
+                         is \
+                         provides \
+                         specifies \
+                         contains \
+                         represents \
+                         a \
+                         an \
+                         the
+ALWAYS_DETAILED_SEC    = NO
+INLINE_INHERITED_MEMB  = NO
+FULL_PATH_NAMES        = YES
+STRIP_FROM_PATH        = ""
+STRIP_FROM_INC_PATH    = 
+SHORT_NAMES            = NO
+JAVADOC_AUTOBRIEF      = YES # NO
+QT_AUTOBRIEF           = NO
+MULTILINE_CPP_IS_BRIEF = NO
+DETAILS_AT_TOP         = NO
+INHERIT_DOCS           = YES
+SEPARATE_MEMBER_PAGES  = NO
+TAB_SIZE               = 8
+ALIASES                = 
+OPTIMIZE_OUTPUT_FOR_C  = YES
+OPTIMIZE_OUTPUT_JAVA   = NO
+OPTIMIZE_FOR_FORTRAN   = NO
+OPTIMIZE_OUTPUT_VHDL   = NO
+BUILTIN_STL_SUPPORT    = NO
+CPP_CLI_SUPPORT        = NO
+SIP_SUPPORT            = NO
+DISTRIBUTE_GROUP_DOC   = NO
+SUBGROUPING            = YES
+TYPEDEF_HIDES_STRUCT   = NO
+#---------------------------------------------------------------------------
+# Build related configuration options
+#---------------------------------------------------------------------------
+EXTRACT_ALL            = YES
+EXTRACT_PRIVATE        = YES
+EXTRACT_STATIC         = YES
+EXTRACT_LOCAL_CLASSES  = YES
+EXTRACT_LOCAL_METHODS  = YES
+EXTRACT_ANON_NSPACES   = YES
+HIDE_UNDOC_MEMBERS     = NO
+HIDE_UNDOC_CLASSES     = NO
+HIDE_FRIEND_COMPOUNDS  = NO
+HIDE_IN_BODY_DOCS      = NO
+INTERNAL_DOCS          = NO
+CASE_SENSE_NAMES       = NO
+HIDE_SCOPE_NAMES       = NO
+SHOW_INCLUDE_FILES     = YES
+INLINE_INFO            = YES
+SORT_MEMBER_DOCS       = YES
+SORT_BRIEF_DOCS        = NO
+SORT_GROUP_NAMES       = NO
+SORT_BY_SCOPE_NAME     = NO
+GENERATE_TODOLIST      = YES
+GENERATE_TESTLIST      = YES
+GENERATE_BUGLIST       = YES
+GENERATE_DEPRECATEDLIST= YES
+ENABLED_SECTIONS       = 
+MAX_INITIALIZER_LINES  = 30
+SHOW_USED_FILES        = YES
+SHOW_DIRECTORIES       = NO
+FILE_VERSION_FILTER    = 
+#---------------------------------------------------------------------------
+# configuration options related to warning and progress messages
+#---------------------------------------------------------------------------
+QUIET                  = NO
+WARNINGS               = YES
+WARN_IF_UNDOCUMENTED   = YES
+WARN_IF_DOC_ERROR      = YES
+WARN_NO_PARAMDOC       = NO
+WARN_FORMAT            = "$file:$line: $text"
+WARN_LOGFILE           = 
+#---------------------------------------------------------------------------
+# configuration options related to the input files
+#---------------------------------------------------------------------------
+INPUT                  = .
+INPUT_ENCODING         = UTF-8
+FILE_PATTERNS          = *.c \
+                         *.cc \
+                         *.cxx \
+                         *.cpp \
+                         *.c++ \
+                         *.d \
+                         *.java \
+                         *.ii \
+                         *.ixx \
+                         *.ipp \
+                         *.i++ \
+                         *.inl \
+                         *.h \
+                         *.hh \
+                         *.hxx \
+                         *.hpp \
+                         *.h++ \
+                         *.idl \
+                         *.odl \
+                         *.cs \
+                         *.php \
+                         *.php3 \
+                         *.inc \
+                         *.m \
+                         *.mm \
+                         *.dox \
+                         *.py \
+                         *.f90 \
+                         *.f \
+                         *.vhd \
+                         *.vhdl
+RECURSIVE              = YES
+EXCLUDE                = 
+EXCLUDE_SYMLINKS       = NO
+EXCLUDE_PATTERNS       = 
+EXCLUDE_SYMBOLS        = 
+EXAMPLE_PATH           = 
+EXAMPLE_PATTERNS       = *
+EXAMPLE_RECURSIVE      = NO
+IMAGE_PATH             = 
+INPUT_FILTER           = 
+FILTER_PATTERNS        = 
+FILTER_SOURCE_FILES    = NO
+#---------------------------------------------------------------------------
+# configuration options related to source browsing
+#---------------------------------------------------------------------------
+SOURCE_BROWSER         = YES
+INLINE_SOURCES         = NO
+STRIP_CODE_COMMENTS    = YES
+REFERENCED_BY_RELATION = YES
+REFERENCES_RELATION    = YES
+REFERENCES_LINK_SOURCE = YES
+USE_HTAGS              = NO
+VERBATIM_HEADERS       = YES
+#---------------------------------------------------------------------------
+# configuration options related to the alphabetical class index
+#---------------------------------------------------------------------------
+ALPHABETICAL_INDEX     = NO
+COLS_IN_ALPHA_INDEX    = 5
+IGNORE_PREFIX          = 
+#---------------------------------------------------------------------------
+# configuration options related to the HTML output
+#---------------------------------------------------------------------------
+GENERATE_HTML          = YES
+HTML_OUTPUT            = html
+HTML_FILE_EXTENSION    = .html
+HTML_HEADER            = 
+HTML_FOOTER            = 
+HTML_STYLESHEET        = 
+HTML_ALIGN_MEMBERS     = YES
+GENERATE_HTMLHELP      = NO
+GENERATE_DOCSET        = NO
+DOCSET_FEEDNAME        = "Doxygen generated docs"
+DOCSET_BUNDLE_ID       = org.doxygen.Project
+HTML_DYNAMIC_SECTIONS  = NO
+CHM_FILE               = 
+HHC_LOCATION           = 
+GENERATE_CHI           = NO
+BINARY_TOC             = NO
+TOC_EXPAND             = NO
+DISABLE_INDEX          = NO
+ENUM_VALUES_PER_LINE   = 4
+GENERATE_TREEVIEW      = NO
+TREEVIEW_WIDTH         = 250
+#---------------------------------------------------------------------------
+# configuration options related to the LaTeX output
+#---------------------------------------------------------------------------
+GENERATE_LATEX         = YES
+LATEX_OUTPUT           = latex
+LATEX_CMD_NAME         = latex
+MAKEINDEX_CMD_NAME     = makeindex
+COMPACT_LATEX          = YES # NO
+PAPER_TYPE             = a4wide
+EXTRA_PACKAGES         = 
+LATEX_HEADER           = 
+PDF_HYPERLINKS         = YES
+USE_PDFLATEX           = YES
+LATEX_BATCHMODE        = NO
+LATEX_HIDE_INDICES     = NO
+#---------------------------------------------------------------------------
+# configuration options related to the RTF output
+#---------------------------------------------------------------------------
+GENERATE_RTF           = NO
+RTF_OUTPUT             = rtf
+COMPACT_RTF            = NO
+RTF_HYPERLINKS         = NO
+RTF_STYLESHEET_FILE    = 
+RTF_EXTENSIONS_FILE    = 
+#---------------------------------------------------------------------------
+# configuration options related to the man page output
+#---------------------------------------------------------------------------
+GENERATE_MAN           = NO
+MAN_OUTPUT             = man
+MAN_EXTENSION          = .3
+MAN_LINKS              = NO
+#---------------------------------------------------------------------------
+# configuration options related to the XML output
+#---------------------------------------------------------------------------
+GENERATE_XML           = NO
+XML_OUTPUT             = xml
+XML_SCHEMA             = 
+XML_DTD                = 
+XML_PROGRAMLISTING     = YES
+#---------------------------------------------------------------------------
+# configuration options for the AutoGen Definitions output
+#---------------------------------------------------------------------------
+GENERATE_AUTOGEN_DEF   = NO
+#---------------------------------------------------------------------------
+# configuration options related to the Perl module output
+#---------------------------------------------------------------------------
+GENERATE_PERLMOD       = NO
+PERLMOD_LATEX          = NO
+PERLMOD_PRETTY         = YES
+PERLMOD_MAKEVAR_PREFIX = 
+#---------------------------------------------------------------------------
+# Configuration options related to the preprocessor   
+#---------------------------------------------------------------------------
+ENABLE_PREPROCESSING   = YES
+MACRO_EXPANSION        = NO
+EXPAND_ONLY_PREDEF     = NO
+SEARCH_INCLUDES        = YES
+INCLUDE_PATH           = 
+INCLUDE_FILE_PATTERNS  = 
+PREDEFINED             = WIN32 NTLM USE_LZO ENABLE_FRAGMENT P2MP P2MP_SERVER USE_CRYPTO USE_SSL ENABLE_PLUGIN ENABLE_MANAGEMENT ENABLE_OCC HAVE_GETTIMEOFDAY
+EXPAND_AS_DEFINED      = 
+SKIP_FUNCTION_MACROS   = YES
+#---------------------------------------------------------------------------
+# Configuration::additions related to external references   
+#---------------------------------------------------------------------------
+TAGFILES               = 
+GENERATE_TAGFILE       = 
+ALLEXTERNALS           = NO
+EXTERNAL_GROUPS        = YES
+PERL_PATH              = /usr/bin/perl
+#---------------------------------------------------------------------------
+# Configuration options related to the dot tool   
+#---------------------------------------------------------------------------
+CLASS_DIAGRAMS         = NO
+MSCGEN_PATH            = 
+HIDE_UNDOC_RELATIONS   = YES
+HAVE_DOT               = YES
+CLASS_GRAPH            = YES
+COLLABORATION_GRAPH    = YES
+GROUP_GRAPHS           = YES
+UML_LOOK               = NO
+TEMPLATE_RELATIONS     = NO
+INCLUDE_GRAPH          = YES
+INCLUDED_BY_GRAPH      = YES
+CALL_GRAPH             = NO # YES
+CALLER_GRAPH           = NO # YES
+GRAPHICAL_HIERARCHY    = YES
+DIRECTORY_GRAPH        = YES
+DOT_IMAGE_FORMAT       = png
+DOT_PATH               = "/usr/bin/dot"
+DOTFILE_DIRS           = 
+DOT_GRAPH_MAX_NODES    = 50
+MAX_DOT_GRAPH_DEPTH    = 1000
+DOT_TRANSPARENT        = YES
+DOT_MULTI_TARGETS      = NO
+GENERATE_LEGEND        = YES
+DOT_CLEANUP            = YES
+#---------------------------------------------------------------------------
+# Configuration::additions related to the search engine   
+#---------------------------------------------------------------------------
+SEARCHENGINE           = NO
Signature · 1 line
1.7.4.1
#2 lore raw

Re: [Openvpn-devel] [PATCH 1/8] Added Doxygen doxyfile

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 6 lines · Adriaan de Jong
---
 openvpn.doxyfile |  279 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 279 insertions(+), 0 deletions(-)
 create mode 100644 openvpn.doxyfile

ACK.

Wondering if we should enable SEARCHENGINE, for convenience, but that can be done later on.

kind regards,

David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk4TU6MACgkQDC186MBRfrrS8wCfU1J6nMDTHKoW0lrJC5qo50hL 51MAn3dukXUoLhf+n70WVBipj2zJQWcF
=JEN7
-----END PGP SIGNATURE-----

#3 lore raw

PATCH 2/8 Added data channel crypto docs

In reply to Adriaan de Jong
---
 crypto.h          |  168 +++++++++++++++++++++++++++++++++++++++++++++--------
 doc_data_crypto.h |   75 ++++++++++++++++++++++++
 2 files changed, 218 insertions(+), 25 deletions(-)
 create mode 100644 doc_data_crypto.h
crypto.h +143 -25
index fcd4661..973677d 100644
@@ -22,6 +22,12 @@
  *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
+
+/**
+ * @file
+ */
+
+
 #ifndef CRYPTO_H
 #define CRYPTO_H
 #ifdef USE_CRYPTO
@@ -199,72 +205,118 @@ struct key_type
   const EVP_MD *digest;
 };
 
-/*
- * A random key.
+
+/**
+ * Container for unidirectional cipher and HMAC %key material.
+ * @ingroup control_processor
  */
 struct key
 {
   uint8_t cipher[MAX_CIPHER_KEY_LENGTH];
+                                /**< %Key material for cipher operations. */
   uint8_t hmac[MAX_HMAC_KEY_LENGTH];
+                                /**< %Key material for HMAC operations. */
 };
 
 #define KEY_DIRECTION_BIDIRECTIONAL 0 /* same keys for both directions */
 #define KEY_DIRECTION_NORMAL        1 /* encrypt with keys[0], decrypt with keys[1] */
 #define KEY_DIRECTION_INVERSE       2 /* encrypt with keys[1], decrypt with keys[0] */
 
-/*
- * Dual random keys (for encrypt/decrypt)
+/**
+ * Container for bidirectional cipher and HMAC %key material.
+ * @ingroup control_processor
  */
 struct key2
 {
-  int n;
-  struct key keys[2];
+  int n;                        /**< The number of \c key objects stored
+                                 *   in the \c key2.keys array. */
+  struct key keys[2];           /**< Two unidirectional sets of %key
+                                 *   material. */
 };
 
-/*
- * Used for controlling bidirectional keys
- * vs. a separate key for each direction.
+/**
+ * %Key ordering of the \c key2.keys array.
+ * @ingroup control_processor
+ * 
+ * This structure takes care of correct ordering when using unidirectional
+ * or bidirectional %key material, and allows the same shared secret %key
+ * file to be loaded in the same way by client and server by having one of
+ * the hosts use an reversed ordering.
  */
 struct key_direction_state
 {
-  int out_key;
-  int in_key;
-  int need_keys;
+  int out_key;                  /**< Index into the \c key2.keys array for
+                                 *   the sending direction. */
+  int in_key;                   /**< Index into the \c key2.keys array for
+                                 *   the receiving direction. */
+  int need_keys;                /**< The number of key objects necessary
+                                 *   to support both sending and
+                                 *   receiving.
+                                 *   
+                                 *   This will be 1 if the same keys are
+                                 *   used in both directions, or 2 if
+                                 *   there are two sets of unidirectional
+                                 *   keys. */
 };
 
-/*
- * A key context for cipher and/or HMAC.
+/**
+ * Container for one set of OpenSSL cipher and/or HMAC contexts.
+ * @ingroup control_processor
  */
 struct key_ctx
 {
-  EVP_CIPHER_CTX *cipher;
-  HMAC_CTX *hmac;
+  EVP_CIPHER_CTX *cipher;       /**< OpenSSL cipher %context. */
+  HMAC_CTX *hmac;               /**< OpenSSL HMAC %context. */
 };
 
-/*
- * Cipher/HMAC key context for both sending and receiving
- * directions.
+/**
+ * Container for two sets of OpenSSL cipher and/or HMAC contexts for both
+ * sending and receiving directions.
+ * @ingroup control_processor
  */
 struct key_ctx_bi
 {
-  struct key_ctx encrypt;
-  struct key_ctx decrypt;
+  struct key_ctx encrypt;       /**< OpenSSL cipher and/or HMAC contexts
+                                 *   for sending direction. */
+  struct key_ctx decrypt;       /**< OpenSSL cipher and/or HMAC contexts
+                                 *   for receiving direction. */
 };
 
-/*
- * Options for encrypt/decrypt.
+/**
+ * Security parameter state for processing data channel packets.
+ * @ingroup data_crypto
  */
 struct crypto_options
 {
   struct key_ctx_bi *key_ctx_bi;
-  struct packet_id *packet_id;
+                                /**< OpenSSL cipher and HMAC contexts for
+                                 *   both sending and receiving
+                                 *   directions. */
+  struct packet_id *packet_id;  /**< Current packet ID state for both
+                                 *   sending and receiving directions. */
   struct packet_id_persist *pid_persist;
+                                /**< Persistent packet ID state for
+                                 *   keeping state between successive
+                                 *   OpenVPN process startups. */
 
 # define CO_PACKET_ID_LONG_FORM  (1<<0)
+                                /**< Bit-flag indicating whether to use
+                                 *   OpenVPN's long packet ID format. */
 # define CO_USE_IV               (1<<1)
+                                /**< Bit-flag indicating whether to
+                                 *   generate a pseudo-random IV for each
+                                 *   packet being encrypted. */
 # define CO_IGNORE_PACKET_ID     (1<<2)
+                                /**< Bit-flag indicating whether to ignore
+                                 *   the packet ID of a received packet. 
+                                 *   This flag is used during processing
+                                 *   of the first packet received from a
+                                 *   client. */
 # define CO_MUTE_REPLAY_WARNINGS (1<<3)
-  unsigned int flags;
+                                /**< Bit-flag indicating not to display
+                                 *   replay warnings. */
+  unsigned int flags;           /**< Bit-flags determining behavior of
+                                 *   security operation functions. */
 };
 
 void init_key_type (struct key_type *kt, const char *ciphername,
@@ -313,14 +365,80 @@ void init_key_ctx (struct key_ctx *ctx, struct key *key,
 void free_key_ctx (struct key_ctx *ctx);
 void free_key_ctx_bi (struct key_ctx_bi *ctx);
 
+
+/**************************************************************************/
+/** @name Functions for performing security operations on data channel packets
+ *  @{ */
+
+/**
+ * Encrypt and HMAC sign a packet so that it can be sent as a data channel
+ * VPN tunnel packet to a remote OpenVPN peer.
+ * @ingroup data_crypto
+ * 
+ * This function handles encryption and HMAC signing of a data channel
+ * packet before it is sent to its remote OpenVPN peer.  It receives the
+ * necessary security parameters in the \a opt argument, which should have
+ * been set to the correct values by the \c tls_pre_encrypt() function.
+ * 
+ * This function calls the \c EVP_Cipher* and \c HMAC_* functions of the
+ * OpenSSL library to perform the actual security operations.
+ * 
+ * If an error occurs during processing, then the \a buf %buffer is set to
+ * empty.
+ * 
+ * @param buf          - The %buffer containing the packet on which to
+ *                       perform security operations.
+ * @param work         - A working %buffer.
+ * @param opt          - The security parameter state for this VPN tunnel.
+ * @param frame        - The packet geometry parameters for this VPN
+ *                       tunnel.
+ * @return This function returns void.\n On return, the \a buf argument
+ *     will point to the resulting %buffer.  This %buffer will either
+ *     contain the processed packet ready for sending, or be empty if an
+ *     error occurred.
+ */
 void openvpn_encrypt (struct buffer *buf, struct buffer work,
 		      const struct crypto_options *opt,
 		      const struct frame* frame);
 
+
+/**
+ * HMAC verify and decrypt a data channel packet received from a remote
+ * OpenVPN peer.
+ * @ingroup data_crypto
+ * 
+ * This function handles authenticating and decrypting a data channel
+ * packet received from a remote OpenVPN peer.  It receives the necessary
+ * security parameters in the \a opt argument, which should have been set
+ * to the correct values by the \c tls_pre_decrypt() function.
+ * 
+ * This function calls the \c EVP_Cipher* and \c HMAC_* functions of the
+ * OpenSSL library to perform the actual security operations.
+ * 
+ * If an error occurs during processing, then the \a buf %buffer is set to
+ * empty.
+ * 
+ * @param buf          - The %buffer containing the packet received from a
+ *                       remote OpenVPN peer on which to perform security
+ *                       operations.
+ * @param work         - A working %buffer.
+ * @param opt          - The security parameter state for this VPN tunnel.
+ * @param frame        - The packet geometry parameters for this VPN
+ *                       tunnel.
+ * 
+ * @return
+ * @li True, if the packet was authenticated and decrypted successfully.
+ * @li False, if an error occurred. \n On return, the \a buf argument will
+ *     point to the resulting %buffer.  This %buffer will either contain
+ *     the plaintext packet ready for further processing, or be empty if
+ *     an error occurred.
+ */
 bool openvpn_decrypt (struct buffer *buf, struct buffer work,
 		      const struct crypto_options *opt,
 		      const struct frame* frame);
 
+/** @} name Functions for performing security operations on data channel packets */
+
 
 void crypto_adjust_frame_parameters(struct frame *frame,
 				    const struct key_type* kt,
doc_data_crypto.h new file +75 -0

75 lines not on this page · raw message

Signature · 1 line
1.7.4.1
#4 lore raw

Re: [Openvpn-devel] [PATCH 2/8] Added data channel crypto docs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[resending with Cc: to mailing list]

Quoted 7 lines · Adriaan de Jong
---
 crypto.h          |  168 +++++++++++++++++++++++++++++++++++++++++++++--------
 doc_data_crypto.h |   75 ++++++++++++++++++++++++
 2 files changed, 218 insertions(+), 25 deletions(-)
 create mode 100644 doc_data_crypto.h

ACK. Documentation makes sense. Even though I'm missing overview over the details, but the overall information is at least close enough to help further understanding.

kind regards,

David Sommerseth

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk4T+lUACgkQDC186MBRfroZYgCePU+IbsXzR7POcDVgPjFgojIU SSQAn2TsnXB+9mNZmrqgp2o5ZVngwDUD
=erwT
-----END PGP SIGNATURE-----

#5 lore raw

PATCH 3/8 Added control channel crypto docs

In reply to Adriaan de Jong
---
 doc_control_tls.h    |  105 ++++++++++
 doc_key_generation.h |  148 ++++++++++++++
 ssl.c                |  303 ++++++++++++++++++++++++++---
 ssl.h                |  528 +++++++++++++++++++++++++++++---------------------
 4 files changed, 841 insertions(+), 243 deletions(-)
 create mode 100644 doc_control_tls.h
 create mode 100644 doc_key_generation.h
doc_control_tls.h new file +105 -0
new file mode 100644
index 0000000..dd3a41c
@@ -0,0 +1,105 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ *             over a single TCP/UDP port, with support for SSL/TLS-based
+ *             session authentication and key exchange,
+ *             packet encryption, packet authentication, and
+ *             packet compression.
+ *
+ *  Copyright (C) 2010 Fox Crypto B.V. <[email protected]...>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+/**
+ * @file
+ * Control Channel TLS module documentation file.
+ */
+
+/**
+ * @defgroup control_tls Control Channel TLS module
+ * 
+ * This module provides secure encapsulation of control channel messages
+ * exchanged between OpenVPN peers.
+ * 
+ * The Control Channel TLS module uses the Transport Layer Security (TLS)
+ * protocol to provide an encrypted communication channel between the
+ * local OpenVPN process and a remote peer.  This protocol simultaneously
+ * offers certificate-based authentication of the communicating parties.
+ * 
+ * @par This module's roles
+ * The Control Channel TLS module is essential for the security of any
+ * OpenVPN-based system.  On the one hand, it performs the security
+ * operations necessary to protect control channel messages exchanged
+ * between OpenVPN peers.  On the other hand, before the control and data
+ * channels are even setup, it controls the exchange of certificates and
+ * verification of the remote's identity during negotiation of VPN
+ * tunnels.
+ * 
+ * @par
+ * The former role is described below.  The latter is described in the
+ * documentation for the \c verify_callback() function.
+ * 
+ * @par
+ * In other words, this module takes care of the confidentiality and
+ * integrity of data channel communications, and the authentication of
+ * both the communicating parties and the control channel messages
+ * exchanged.
+ * 
+ * @par Initialization and cleanup
+ * Because of the one-to-one relationship between control channel TLS
+ * state and \c key_state structures, the initialization and cleanup of an
+ * instance of the Control Channel TLS module's state happens within the
+ * \c key_state_init() and \c key_state_free() functions.  In other words,
+ * each \c key_state object contains exactly one OpenSSL SSL-BIO object,
+ * which is initialized and cleaned up together with the rest of the \c
+ * key_state object.
+ * 
+ * @par Packet processing functions
+ * This object behaves somewhat like a black box with a ciphertext and a
+ * plaintext I/O port. Its interaction with OpenVPN's control channel
+ * during operation takes place within the \c tls_process() function of
+ * the \link control_processor Control Channel Processor\endlink.  The
+ * following functions are available for processing packets:
+ * - If ciphertext received from the remote peer is available in the \link
+ *   reliable Reliability Layer\endlink:
+ *   - Insert it into the ciphertext-side of the SSL-BIO.
+ *   - Use function: \c key_state_write_ciphertext()
+ * - If ciphertext can be extracted from the ciphertext-side of the
+ *   SSL-BIO:
+ *   - Pass it to the \link reliable Reliability Layer\endlink for sending
+ *     to the remote peer.
+ *   - Use function: \c key_state_read_ciphertext()
+ * - If plaintext can be extracted from the plaintext-side of the SSL-BIO:
+ *   - Pass it on to the \link control_processor Control Channel
+ *     Processor\endlink for local processing.
+ *   - Use function: \c key_state_read_plaintext()
+ * - If plaintext from the \link control_processor Control Channel
+ *   Processor\endlink is available to be sent to the remote peer:
+ *   - Insert it into the plaintext-side of the SSL-BIO.
+ *   - Use function: \c key_state_write_plaintext() or \c
+ *     key_state_write_plaintext_const()
+ * 
+ * @par Transport Layer Security protocol implementation
+ * This module uses the OpenSSL library's implementation of the TLS
+ * protocol in the form of an OpenSSL SSL-BIO object.
+ * 
+ * @par
+ * For more information on the OpenSSL library's BIO objects, please see:
+ *  - OpenSSL's generic BIO objects:
+ *    http://www.openssl.org/docs/crypto/bio.html
+ *  - OpenSSL's SSL-BIO object:
+ *    http://www.openssl.org/docs/crypto/BIO_f_ssl.html
+ */
doc_key_generation.h new file +148 -0

148 lines not on this page · raw message

ssl.c +278 -25

401 lines not on this page · raw message

ssl.h +310 -218

619 lines not on this page · raw message

Signature · 1 line
1.7.4.1
#6 lore raw

Re: [Openvpn-devel] [PATCH 3/8] Added control channel crypto docs

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 9 lines · Adriaan de Jong
---
 doc_control_tls.h    |  105 ++++++++++
 doc_key_generation.h |  148 ++++++++++++++
 ssl.c                |  303 ++++++++++++++++++++++++++---
 ssl.h                |  528 +++++++++++++++++++++++++++++---------------------
 4 files changed, 841 insertions(+), 243 deletions(-)
 create mode 100644 doc_control_tls.h
 create mode 100644 doc_key_generation.h

More comments in between ... look carefully.

[...snip...]

Quoted 6 lines

+ * @subsection key_generation_method_2 Key method 2
+ *
+ * -# The client generates random material in the following amounts:

+ *    - Pre-master secret: 48 bytes
+ *    - Client's PRF seed for master secret: 32 bytes
+ *    - Client's PRF seed for %key expansion: 32 bytes
Quoted 13 lines

+ * -# The client sends its share of random material to the server.
+ * -# The server generates random material in the following amounts:
+ * - Server's PRF seed for master secret: 32 bytes
+ * - Server's PRF seed for %key expansion: 32 bytes
+ * -# The server computes the %key expansion using its own and the
+ * client's random material.
+ * -# The server sends its share of random material to the client.
+ * -# The client computes the %key expansion using its own and the
+ * server's random material.
+ *
+ * %Key method 2 %key expansion is performed by the \c
+ * generate_key_expansion() function. Please refer to its source code for
+ * details of the %key expansion process.

My memory is a bit rusty ... but isn't this part of the standard KEX process in SSL/TLS?

Quoted 4 lines

+/**
+ * Insert a plaintext buffer into the TLS module.
+ *
+ * After successfully processing the data, the data in \a buf is zeroized,

I believe "zeroed" is a better expression ... found more places.

[...snip...]

Quoted 8 lines

+ * This function cleans up a \c key_state structure. It frees the
+ * associated SSL-BIO, and the structures allocated for the \link reliable
+ * Reliability Layer\endlink.
+ *
+ * @param ks - A pointer to the \c key_state structure to be
+ * cleaned up.
+ * @param clear - Whether the memory allocated for the \a ks object
+ * should be overwritten with 0s.

Wouldn't it be better to say "... ks object should be zeroed" ?

[...snip...]

Quoted 5 lines

+ * @param clear - Whether the memory allocated for the \a session
+ * object should be overwritten with 0s.
+ */
static void
tls_session_free (struct tls_session *session, bool clear)

Same comment as above

Quoted 53 lines

-/*
- * OpenVPN Protocol, taken from ssl.h in OpenVPN source code.
- *
- * TCP/UDP Packet: This represents the top-level encapsulation.
- *
- * TCP/UDP packet format:
- *
- * Packet length (16 bits, unsigned) -- TCP only, always sent as
- * plaintext. Since TCP is a stream protocol, the packet
- * length words define the packetization of the stream.
- *
- * Packet opcode/key_id (8 bits) -- TLS only, not used in
- * pre-shared secret mode.
- * packet message type, a P_* constant (high 5 bits)
- * key_id (low 3 bits, see key_id in struct tls_session

- *              below for comment).  The key_id refers to an
- *              already negotiated TLS session.  OpenVPN seamlessly
- *              renegotiates the TLS session by using a new key_id
- *              for the new session.  Overlap (controlled by
- *              user definable parameters) between old and new TLS
- *              sessions is allowed, providing a seamless transition
- *              during tunnel operation.

- *
- * Payload (n bytes), which may be a P_CONTROL, P_ACK, or P_DATA
- * message.
- * Message types:
- *
- * P_CONTROL_HARD_RESET_CLIENT_V1 -- Key method 1, initial key from
- * client, forget previous state.
- *
- * P_CONTROL_HARD_RESET_SERVER_V1 -- Key method 2, initial key
- * from server, forget previous state.
- *
- * P_CONTROL_SOFT_RESET_V1 -- New key, with a graceful transition

- *    from old to new key in the sense that a transition window
- *    exists where both the old or new key_id can be used.  OpenVPN
- *    uses two different forms of key_id.  The first form is 64 bits
- *    and is used for all P_CONTROL messages.  P_DATA messages on the
- *    other hand use a shortened key_id of 3 bits for efficiency
- *    reasons since the vast majority of OpenVPN packets in an
- *    active tunnel will be P_DATA messages.  The 64 bit form
- *    is referred to as a session_id, while the 3 bit form is
- *    referred to as a key_id.

- *
- * P_CONTROL_V1 -- Control channel packet (usually TLS ciphertext).
- *
- * P_ACK_V1 -- Acknowledgement for P_CONTROL packets received.
- *
- * P_DATA_V1 -- Data channel packet containing actual tunnel data
- * ciphertext.
- *
- * P_CONTROL_HARD_RESET_CLIENT_V2 -- Key method 2, initial key from
- * client, forget previous state.

Quoted 8 lines

- *
- * P_CONTROL_HARD_RESET_SERVER_V2 -- Key method 2, initial key from
- * server, forget previous state.
- *
- * P_CONTROL* and P_ACK Payload: The P_CONTROL message type
- * indicates a TLS ciphertext packet which has been encapsulated
- * inside of a reliability layer. The reliability layer is
- * implemented as a straightforward ACK and retransmit model.

Is this documented somewhere else? The same goes for the following message types. Seems to be some details here which is missing in the previous description of the key methods.

Quoted 83 lines

- * P_CONTROL message format:
- *
- * local session_id (random 64 bit value to identify TLS session).
- * HMAC signature of entire encapsulation header for integrity
- * check if --tls-auth is specified (usually 16 or 20 bytes).
- * packet-id for replay protection (4 or 8 bytes, includes
- * sequence number and optional time_t timestamp).

- *   P_ACK packet_id array length (1 byte).
- *   P_ACK packet-id array (if length > 0).
- *   P_ACK remote session_id (if length > 0).
- *   message packet-id (4 bytes).
- *   TLS payload ciphertext (n bytes) (only for P_CONTROL).

- *
- * Once the TLS session has been initialized and authenticated,
- * the TLS channel is used to exchange random key material for
- * bidirectional cipher and HMAC keys which will be
- * used to secure actual tunnel packets. OpenVPN currently
- * implements two key methods. Key method 1 directly
- * derives keys using random bits obtained from the RAND_bytes
- * OpenSSL function. Key method 2 mixes random key material
- * from both sides of the connection using the TLS PRF mixing
- * function. Key method 2 is the preferred method and is the default
- * for OpenVPN 2.0.
- *
- * TLS plaintext content:
- *
- * TLS plaintext packet (if key_method == 1):
- *

- *   Cipher key length in bytes (1 byte).
- *   Cipher key (n bytes).
- *   HMAC key length in bytes (1 byte).
- *   HMAC key (n bytes).
- *   Options string (n bytes, null terminated, client/server options

- * string should match).
- *
- * TLS plaintext packet (if key_method == 2):
- *

- *   Literal 0 (4 bytes).
- *   key_method type (1 byte).
- *   key_source structure (pre_master only defined for client ->

- * server).
- * options_string_length, including null (2 bytes).
- * Options string (n bytes, null terminated, client/server options
- * string must match).
- * [The username/password data below is optional, record can end
- * at this point.]

- *   username_string_length, including null (2 bytes).
- *   Username string (n bytes, null terminated).
- *   password_string_length, including null (2 bytes).
- *   Password string (n bytes, null terminated).

- *
- * The P_DATA payload represents encrypted, encapsulated tunnel
- * packets which tend to be either IP packets or Ethernet frames.
- * This is essentially the "payload" of the VPN.
- *
- * P_DATA message content:
- * HMAC of ciphertext IV + ciphertext (if not disabled by
- * --auth none).
- * Ciphertext IV (size is cipher-dependent, if not disabled by
- * --no-iv).
- * Tunnel packet ciphertext.
- *
- * P_DATA plaintext
- * packet_id (4 or 8 bytes, if not disabled by --no-replay).

- *       In SSL/TLS mode, 4 bytes are used because the implementation
- *       can force a TLS renegotation before 2^32 packets are sent.
- *       In pre-shared key mode, 8 bytes are used (sequence number
- *       and time_t value) to allow long-term key usage without
- *       packet_id collisions.

- * User plaintext (n bytes).
- *
- * Notes:
- * (1) ACK messages can be encoded in either the dedicated
- * P_ACK record or they can be prepended to a P_CONTROL message.
- * (2) P_DATA and P_CONTROL/P_ACK use independent packet-id

- *       sequences because P_DATA is an unreliable channel while
- *       P_CONTROL/P_ACK is a reliable channel.  Each use their
- *       own independent HMAC keys.
- *   (3) Note that when --tls-auth is used, all message types are
- *       protected with an HMAC signature, even the initial packets
- *       of the TLS handshake.  This makes it easy for OpenVPN to
- *       throw away bogus packets quickly, without wasting resources
- *       on attempting a TLS handshake which will ultimately fail.
Quoted 1 line

- */

Just beginning to wonder if this big block is moved over to doxygen/doc_protocol_overview.h?

[...snip...]

Generally looks good. Some "typos" here, but this can be fixed in an additional patch. I'm mostly concerned about the big block which this patch seems to remove. If it is moved to other files, then it is fine.

So that this needs to be solved with an additional patch and confirm that the documentation taken out of this file is not lost, then I'll give this one an ACK.

kind regards,

David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk4TU6wACgkQDC186MBRfrpWSQCbBf1uhje3NBByZX6qF4f7Yro3 J5EAn1URq+YbO/nQoKo/GcIBdlhXZ1mk
=640T
-----END PGP SIGNATURE-----

#7 lore raw

Re: [Openvpn-devel] [PATCH 3/8] Added control channel crypto docs

Quoted 6 lines

-----Original Message-----
From: David Sommerseth [mailto:[email protected]...]
Sent: dinsdag 5 juli 2011 20:11

More comments in between ... look carefully.

Thanks, I've answered your comments inline too :)

Quoted 19 lines

[...snip...]

Quoted 6 lines

+ * @subsection key_generation_method_2 Key method 2
+ *
+ * -# The client generates random material in the following amounts:

+ *    - Pre-master secret: 48 bytes
+ *    - Client's PRF seed for master secret: 32 bytes
+ *    - Client's PRF seed for %key expansion: 32 bytes
Quoted 12 lines

+ * -# The client sends its share of random material to the server.
+ * -# The server generates random material in the following amounts:
+ * - Server's PRF seed for master secret: 32 bytes
+ * - Server's PRF seed for %key expansion: 32 bytes
+ * -# The server computes the %key expansion using its own and the
+ * client's random material.
+ * -# The server sends its share of random material to the client.
+ * -# The client computes the %key expansion using its own and the
+ * server's random material.
+ *
+ * %Key method 2 %key expansion is performed by the \c
+ * generate_key_expansion() function. Please refer to its source

Quoted 6 lines

code for

Quoted 1 line

+ * details of the %key expansion process.

My memory is a bit rusty ... but isn't this part of the standard KEX process in SSL/TLS?

Yes, but this one is used for setting up the data channel keys, not the control channel keys. I believe it's based on OpenSSL's PRF.

Quoted 8 lines
Quoted 4 lines

+/**
+ * Insert a plaintext buffer into the TLS module.
+ *
+ * After successfully processing the data, the data in \a buf is

zeroized,

I believe "zeroed" is a better expression ... found more places.

Hmm, I thought zeroisation was the common term in the crypto world (http://en.wikipedia.org/wiki/Zeroisation).

Quoted 7 lines

[...snip...]

Quoted 2 lines

+ * This function cleans up a \c key_state structure. It frees the
+ * associated SSL-BIO, and the structures allocated for the \link

reliable

Quoted 3 lines

+ * Reliability Layer\endlink.
+ *
+ * @param ks - A pointer to the \c key_state structure to

Quoted 8 lines

be

Quoted 2 lines

+ * cleaned up.
+ * @param clear - Whether the memory allocated for the \a ks

object

Quoted 1 line

+ * should be overwritten with 0s.

Wouldn't it be better to say "... ks object should be zeroed" ?

Cleared/zeroised would probably be better still, but I think this still makes matters pretty clear.

Quoted 168 lines

[...snip...]

Quoted 1 line

+ * @param clear - Whether the memory allocated for the \a

session

Quoted 4 lines

+ * object should be overwritten with 0s.
+ */
static void
tls_session_free (struct tls_session *session, bool clear)

Same comment as above

Quoted 34 lines

-/*
- * OpenVPN Protocol, taken from ssl.h in OpenVPN source code.
- *
- * TCP/UDP Packet: This represents the top-level encapsulation.
- *
- * TCP/UDP packet format:
- *
- * Packet length (16 bits, unsigned) -- TCP only, always sent as
- * plaintext. Since TCP is a stream protocol, the packet
- * length words define the packetization of the stream.
- *
- * Packet opcode/key_id (8 bits) -- TLS only, not used in
- * pre-shared secret mode.
- * packet message type, a P_* constant (high 5 bits)
- * key_id (low 3 bits, see key_id in struct tls_session

- *              below for comment).  The key_id refers to an
- *              already negotiated TLS session.  OpenVPN seamlessly
- *              renegotiates the TLS session by using a new key_id
- *              for the new session.  Overlap (controlled by
- *              user definable parameters) between old and new TLS
- *              sessions is allowed, providing a seamless transition
- *              during tunnel operation.

- *
- * Payload (n bytes), which may be a P_CONTROL, P_ACK, or P_DATA
- * message.
- * Message types:
- *
- * P_CONTROL_HARD_RESET_CLIENT_V1 -- Key method 1, initial key from
- * client, forget previous state.
- *
- * P_CONTROL_HARD_RESET_SERVER_V1 -- Key method 2, initial key
- * from server, forget previous state.
- *
- * P_CONTROL_SOFT_RESET_V1 -- New key, with a graceful transition

Quoted 4 lines
- *    from old to new key in the sense that a transition window
- *    exists where both the old or new key_id can be used.  OpenVPN
- *    uses two different forms of key_id.  The first form is 64 bits
- *    and is used for all P_CONTROL messages.  P_DATA messages on

the

Quoted 15 lines
- *    other hand use a shortened key_id of 3 bits for efficiency
- *    reasons since the vast majority of OpenVPN packets in an
- *    active tunnel will be P_DATA messages.  The 64 bit form
- *    is referred to as a session_id, while the 3 bit form is
- *    referred to as a key_id.

- *
- * P_CONTROL_V1 -- Control channel packet (usually TLS ciphertext).
- *
- * P_ACK_V1 -- Acknowledgement for P_CONTROL packets received.
- *
- * P_DATA_V1 -- Data channel packet containing actual tunnel data
- * ciphertext.
- *
- * P_CONTROL_HARD_RESET_CLIENT_V2 -- Key method 2, initial key from
- * client, forget previous state.

Quoted 8 lines

- *
- * P_CONTROL_HARD_RESET_SERVER_V2 -- Key method 2, initial key from
- * server, forget previous state.
- *
- * P_CONTROL* and P_ACK Payload: The P_CONTROL message type
- * indicates a TLS ciphertext packet which has been encapsulated
- * inside of a reliability layer. The reliability layer is
- * implemented as a straightforward ACK and retransmit model.

Is this documented somewhere else? The same goes for the following message
types. Seems to be some details here which is missing in the previous description of the key methods.

Quoted 12 lines

- * P_CONTROL message format:
- *
- * local session_id (random 64 bit value to identify TLS session).
- * HMAC signature of entire encapsulation header for integrity
- * check if --tls-auth is specified (usually 16 or 20 bytes).
- * packet-id for replay protection (4 or 8 bytes, includes
- * sequence number and optional time_t timestamp).

- *   P_ACK packet_id array length (1 byte).
- *   P_ACK packet-id array (if length > 0).
- *   P_ACK remote session_id (if length > 0).
- *   message packet-id (4 bytes).
- *   TLS payload ciphertext (n bytes) (only for P_CONTROL).
Quoted 10 lines

- *
- * Once the TLS session has been initialized and authenticated,
- * the TLS channel is used to exchange random key material for
- * bidirectional cipher and HMAC keys which will be
- * used to secure actual tunnel packets. OpenVPN currently
- * implements two key methods. Key method 1 directly
- * derives keys using random bits obtained from the RAND_bytes
- * OpenSSL function. Key method 2 mixes random key material
- * from both sides of the connection using the TLS PRF mixing
- * function. Key method 2 is the preferred method and is the

default

Quoted 28 lines

- * for OpenVPN 2.0.
- *
- * TLS plaintext content:
- *
- * TLS plaintext packet (if key_method == 1):
- *

- *   Cipher key length in bytes (1 byte).
- *   Cipher key (n bytes).
- *   HMAC key length in bytes (1 byte).
- *   HMAC key (n bytes).
- *   Options string (n bytes, null terminated, client/server options

- * string should match).
- *
- * TLS plaintext packet (if key_method == 2):
- *

- *   Literal 0 (4 bytes).
- *   key_method type (1 byte).
- *   key_source structure (pre_master only defined for client ->

- * server).
- * options_string_length, including null (2 bytes).
- * Options string (n bytes, null terminated, client/server options
- * string must match).
- * [The username/password data below is optional, record can end
- * at this point.]

- *   username_string_length, including null (2 bytes).
- *   Username string (n bytes, null terminated).
- *   password_string_length, including null (2 bytes).
- *   Password string (n bytes, null terminated).
Quoted 15 lines

- *
- * The P_DATA payload represents encrypted, encapsulated tunnel
- * packets which tend to be either IP packets or Ethernet frames.
- * This is essentially the "payload" of the VPN.
- *
- * P_DATA message content:
- * HMAC of ciphertext IV + ciphertext (if not disabled by
- * --auth none).
- * Ciphertext IV (size is cipher-dependent, if not disabled by
- * --no-iv).
- * Tunnel packet ciphertext.
- *
- * P_DATA plaintext
- * packet_id (4 or 8 bytes, if not disabled by --no-replay).
- * In SSL/TLS mode, 4 bytes are used because the

implementation

Quoted 9 lines
- *       can force a TLS renegotation before 2^32 packets are sent.
- *       In pre-shared key mode, 8 bytes are used (sequence number
- *       and time_t value) to allow long-term key usage without
- *       packet_id collisions.

- * User plaintext (n bytes).
- *
- * Notes:
- * (1) ACK messages can be encoded in either the dedicated
- * P_ACK record or they can be prepended to a P_CONTROL

message.

Quoted 10 lines

- * (2) P_DATA and P_CONTROL/P_ACK use independent packet-id

- *       sequences because P_DATA is an unreliable channel while
- *       P_CONTROL/P_ACK is a reliable channel.  Each use their
- *       own independent HMAC keys.
- *   (3) Note that when --tls-auth is used, all message types are
- *       protected with an HMAC signature, even the initial packets
- *       of the TLS handshake.  This makes it easy for OpenVPN to
- *       throw away bogus packets quickly, without wasting resources
- *       on attempting a TLS handshake which will ultimately fail.

- */

Quoted 3 lines

Just beginning to wonder if this big block is moved over to doxygen/doc_protocol_overview.h?

You're right, the block was moved out to a documentation-only header to improve legibility of the actual source code. I just double checked to see if anything was missing, but it seems complete. (https://github.com/andj/openvpn-ssl-refactoring/blob/4970f1485d4d2117ccb3b1932965809fc51d8efe/doxygen/doc_protocol_overview.h)

Quoted 6 lines

[...snip...]

Generally looks good. Some "typos" here, but this can be fixed in an additional patch. I'm mostly concerned about the big block which this patch seems to remove. If it is moved to other files, then it is fine.

Quoted 6 lines

So that this needs to be solved with an additional patch and confirm that
the documentation taken out of this file is not lost, then I'll give this
one an ACK.

Thanks! If you think it's necessary I'll change the "should be overwritten with 0s." in a patch, other than that, are you satisfied with the answers?

Kind Regards,

Adriaan de Jong

#8 lore raw

PATCH 4/8 Added compression docs

In reply to Adriaan de Jong
---
 doc_compression.h |   92 ++++++++++++++++++
 lzo.c             |   19 ++--
 lzo.h             |  279 +++++++++++++++++++++++++++++++++++++++++++++--------
 3 files changed, 341 insertions(+), 49 deletions(-)
 create mode 100644 doc_compression.h
doc_compression.h new file +92 -0
new file mode 100644
index 0000000..0296b27
@@ -0,0 +1,92 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ *             over a single TCP/UDP port, with support for SSL/TLS-based
+ *             session authentication and key exchange,
+ *             packet encryption, packet authentication, and
+ *             packet compression.
+ *
+ *  Copyright (C) 2010 Fox Crypto B.V. <[email protected]...>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+/**
+ * @file Data Channel Compression module documentation file.
+ */
+
+/**
+ * @defgroup compression Data Channel Compression module
+ * 
+ * This module offers compression of data channel packets.
+ * 
+ * @par State structures
+ * The Data Channel Compression module stores its internal state in a \c
+ * lzo_compress_workspace structure.  This state includes flags which
+ * control the module's behavior and preallocated working memory.  One
+ * such structure is present for each VPN tunnel, and is stored in the \c
+ * context.c2.lzo_compwork of the \c context associated with that VPN
+ * tunnel.
+ * 
+ * @par Initialization and cleanup
+ * Every time a new \c lzo_compress_workspace is needed, it must be
+ * initialized using the \c lzo_compress_init() function.  Similarly,
+ * every time a \c lzo_compress_workspace is no longer needed, it must be
+ * cleaned up using the \c lzo_compress_uninit() function.  These
+ * functions take care of the allocation and freeing of internal working
+ * memory, but not of the \c lzo_compress_workspace structures themselves.
+ * 
+ * @par
+ * Because of the one-to-one relationship between \c
+ * lzo_compress_workspace structures and VPN tunnels, the above-mentioned
+ * initialization and cleanup functions are called directly from the \c
+ * init_instance() and \c close_instance() functions, which control the
+ * initialization and cleanup of VPN tunnel instances and their associated
+ * \c context structures.
+ * 
+ * @par Packet processing functions
+ * This module receives data channel packets from the \link data_control
+ * Data Channel Control module\endlink and processes them according to the
+ * settings of the packet's VPN tunnel.  The \link data_control Data
+ * Channel Control module\endlink uses the following interface functions:
+ * - For packets which will be sent to a remote OpenVPN peer: \c
+ *   lzo_compress()
+ * - For packets which have been received from a remote OpenVPN peer: \c
+ *   lzo_decompress()
+ * 
+ * @par Settings that control this module's activity
+ * Whether or not the Data Channel Compression module is active depends on
+ * the compile-time \c USE_LZO preprocessor macro and the runtime flags
+ * stored in \c lzo_compress_workspace.flags of the associated VPN tunnel.
+ * The latter are initialized from \c options.lzo, which gets its value
+ * from the process's configuration sources, such as its configuration
+ * file or command line %options.
+ * 
+ * @par Adaptive compression
+ * The compression module supports adaptive compression.  If this feature
+ * is enabled, the compression routines monitor their own performance and
+ * turn compression on or off depending on whether it is leading to
+ * significantly reduced payload size.
+ * 
+ * @par Compression algorithms
+ * This module uses the Lempel-Ziv-Oberhumer (LZO) compression algorithms.
+ * These offer lossless compression and are designed for high-performance
+ * decompression.  This module uses the external \c lzo library's
+ * implementation of the algorithms.
+ * 
+ * @par
+ * For more information on the LZO library, see:\n
+ * http://www.oberhumer.com/opensource/lzo/
+ */
lzo.c +11 -8
index 3d6aa5a..64945d0 100644
@@ -22,6 +22,10 @@
  *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
+/**
+ * @file Data Channel Compression module function definitions.
+ */
+
 #include "syshead.h"
 
 #ifdef USE_LZO
@@ -33,7 +37,13 @@
 #include "memdbg.h"
 
 #ifndef LZO_STUB
-
+/**
+ * Perform adaptive compression housekeeping.
+ * 
+ * @param ac the adaptive compression state structure.
+ * 
+ * @return 
+ */
 static bool
 lzo_adaptive_compress_test (struct lzo_adaptive_compress *ac)
 {
@@ -142,10 +152,6 @@ lzo_compression_enabled (struct lzo_compress_workspace *lzowork)
   return false;
 }
 
-/* Magic numbers to tell our peer if we compressed or not */
-#define YES_COMPRESS 0x66
-#define NO_COMPRESS  0xFA
-
 void
 lzo_compress (struct buffer *buf, struct buffer work,
 	      struct lzo_compress_workspace *lzowork,
@@ -281,9 +287,6 @@ lzo_modify_flags (struct lzo_compress_workspace *lzowork, unsigned int flags)
   lzowork->flags = flags;
 }
 
-/*
- * Print statistics
- */
 void lzo_print_stats (const struct lzo_compress_workspace *lzo_compwork, struct status_output *so)
 {
   ASSERT (lzo_compwork->defined);
lzo.h +238 -41

338 lines not on this page · raw message

Signature · 1 line
1.7.4.1
#9 lore raw

PATCH 5/8 Added reliability layer documentation

In reply to Adriaan de Jong
---
 doc_reliable.h |   49 ++++++
 reliable.h     |  445 ++++++++++++++++++++++++++++++++++++++++++++++++--------
 2 files changed, 430 insertions(+), 64 deletions(-)
 create mode 100644 doc_reliable.h
doc_reliable.h new file +49 -0
new file mode 100644
index 0000000..9877d8c
@@ -0,0 +1,49 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ *             over a single TCP/UDP port, with support for SSL/TLS-based
+ *             session authentication and key exchange,
+ *             packet encryption, packet authentication, and
+ *             packet compression.
+ *
+ *  Copyright (C) 2010 Fox Crypto B.V. <[email protected]...>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+/**
+ * @file
+ * Reliability Layer module documentation file.
+ */
+
+/**
+ * @defgroup reliable Reliability Layer module
+ * 
+ * The Reliability Layer is part of OpenVPN's control channel.  It
+ * provides a reliable and sequential transport mechanism for control
+ * channel messages between OpenVPN peers.  This module forms the
+ * interface between the \link external_multiplexer External
+ * Multiplexer\endlink and the \link control_tls Control Channel TLS
+ * module\endlink.
+ * 
+ * @par UDP or TCP as VPN tunnel transport
+ * 
+ * This is especially important when OpenVPN is configured to communicate
+ * over UDP, because UDP does not offer a reliable and sequential
+ * transport.  OpenVPN endpoints can also communicate over TCP which does
+ * provide a reliable and sequential transport.  In both cases, using UDP
+ * or TCP as an external transport, the internal Reliability Layer is
+ * active.
+ */
reliable.h +381 -64

510 lines not on this page · raw message

Signature · 1 line
1.7.4.1
#10 lore raw

PATCH 6/8 Added memory management documentation

In reply to Adriaan de Jong
---
 buffer.h                |   57 +++++++++++++++++++++++----
 doc_memory_management.h |   99 +++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 147 insertions(+), 9 deletions(-)
 create mode 100644 doc_memory_management.h
buffer.h +48 -9
index 1fe3c08..06d5e84 100644
@@ -42,14 +42,30 @@
 #define BUF_INIT_TRACKING
 #endif
 
-/* basic buffer class for OpenVPN */
-
+/**************************************************************************/
+/**
+ * Wrapper structure for dynamically allocated memory.
+ * 
+ * The actual content stored in a \c buffer structure starts at the memory
+ * location \c buffer.data \c + \c buffer.offset, and has a length of \c
+ * buffer.len bytes.  This, together with the space available before and
+ * after the content, is represented in the pseudocode below:
+@code
+uint8_t *content_start    = buffer.data + buffer.offset;
+uint8_t *content_end      = buffer.data + buffer.offset + buffer.len;
+int      prepend_capacity = buffer.offset;
+int      append_capacity  = buffer.capacity - (buffer.offset + buffer.len);
+@endcode
+ */
 struct buffer
 {
-  int capacity;	   /* size of buffer allocated by malloc */
-  int offset;	   /* data starts at data + offset, offset > 0 to allow for efficient prepending */
-  int len;	   /* length of data that starts at data + offset */
-  uint8_t *data;
+  int capacity;                 /**< Size in bytes of memory allocated by
+                                 *   \c malloc(). */
+  int offset;                   /**< Offset in bytes of the actual content
+                                 *   within the allocated memory. */
+  int len;                      /**< Length in bytes of the actual content
+                                 *   within the allocated memory. */
+  uint8_t *data;                /**< Pointer to the allocated memory. */
 
 #ifdef BUF_INIT_TRACKING
   const char *debug_file;
@@ -57,18 +73,41 @@ struct buffer
 #endif
 };
 
-/* for garbage collection */
 
+/**************************************************************************/
+/**
+ * Garbage collection entry for one dynamically allocated block of memory.
+ * 
+ * This structure represents one link in the linked list contained in a \c
+ * gc_arena structure.  Each time the \c gc_malloc() function is called,
+ * it allocates \c sizeof(gc_entry) + the requested number of bytes.  The
+ * \c gc_entry is then stored as a header in front of the memory address
+ * returned to the caller.
+ */
 struct gc_entry
 {
-  struct gc_entry *next;
+  struct gc_entry *next;        /**< Pointer to the next item in the
+                                 *   linked list. */
 };
 
+
+/**
+ * Garbage collection arena used to keep track of dynamically allocated
+ * memory.
+ * 
+ * This structure contains a linked list of \c gc_entry structures.  When
+ * a block of memory is allocated using the \c gc_malloc() function, the
+ * allocation is registered in the function's \c gc_arena argument.  All
+ * the dynamically allocated memory registered in a \c gc_arena can be
+ * freed using the \c gc_free() function.
+ */
 struct gc_arena
 {
-  struct gc_entry *list;
+  struct gc_entry *list;        /**< First element of the linked list of
+                                 *   \c gc_entry structures. */
 };
 
+
 #define BPTR(buf)  (buf_bptr(buf))
 #define BEND(buf)  (buf_bend(buf))
 #define BLAST(buf) (buf_blast(buf))
doc_memory_management.h new file +99 -0

99 lines not on this page · raw message

Signature · 1 line
1.7.4.1
#11 lore raw

PATCH 7/8 Added data channel fragmentation docs

In reply to Adriaan de Jong
---
 doc_fragmentation.h |   96 +++++++++++
 fragment.h          |  439 ++++++++++++++++++++++++++++++++++++++++++---------
 2 files changed, 461 insertions(+), 74 deletions(-)
 create mode 100644 doc_fragmentation.h
doc_fragmentation.h new file +96 -0
new file mode 100644
index 0000000..e7e9c1e
@@ -0,0 +1,96 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ *             over a single TCP/UDP port, with support for SSL/TLS-based
+ *             session authentication and key exchange,
+ *             packet encryption, packet authentication, and
+ *             packet compression.
+ *
+ *  Copyright (C) 2010 Fox Crypto B.V. <[email protected]...>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+/**
+ * @file
+ * Data Channel Fragmentation module documentation file.
+ */
+
+/**
+ * @defgroup fragmentation Data Channel Fragmentation module
+ * 
+ * The Data Channel Fragmentation module offers fragmentation of data
+ * channel packets.
+ * 
+ * @par State structures
+ * The Data Channel Fragmentation module stores its internal state in a \c
+ * fragment_master structure.  One such structure is present for each VPN
+ * tunnel, and is stored in \c context.c2.fragment of the \c context
+ * associated with that VPN tunnel.
+ * 
+ * @par
+ * The \c fragment_master structure contains one \c fragment_list
+ * structure \c fragment_master.incoming.  This is a list of \c fragment
+ * structures, each of which can store the parts of one fragmented packet
+ * while it is being reassembled.  The \c fragment_master structure also
+ * contains one \c buffer called \c fragment_master.outgoing, in which a
+ * data channel large packet to be sent to a remote OpenVPN peer can be
+ * broken up into parts to be sent one by one.
+ * 
+ * @par Initialization and cleanup
+ * Every time a new \c fragment_master is needed, it must be allocated and
+ * initialized by the \c fragment_init() function.  Similarly, every time
+ * a \c fragment_master is no longer needed, it must be cleaned up using
+ * the \c fragment_free() function.  These functions take care of the
+ * allocation and freeing of the \c fragment_master structure itself and
+ * all internal memory required for the use of that structure.  Note that
+ * this behavior is different from that displayed by the \link compression
+ * Data Channel Compression module\endlink.
+ * 
+ * @par
+ * Because of the one-to-one relationship between \c fragment_master
+ * structures and VPN tunnels, the above-mentioned initialization and
+ * cleanup functions are called directly from the \c init_instance() and
+ * \c close_instance() functions, which control the initialization and
+ * cleanup of VPN tunnel instances and their associated \c context
+ * structures.
+ * 
+ * @par Packet processing functions
+ * This module receives data channel packets from the \link data_control
+ * Data Channel Control module\endlink and processes them according to the
+ * settings of the packet's VPN tunnel.  The \link data_control Data
+ * Channel Control module\endlink uses the following interface functions:
+ * - For packets which will be sent to a remote OpenVPN peer: \c
+ *   fragment_outgoing() \n This function inspects data channel packets as
+ *   they are being made ready to be sent as VPN tunnel packets to a
+ *   remote OpenVPN peer.  If a packet's size is larger than its
+ *   destination VPN tunnel's maximum transmission unit (MTU), then this
+ *   module breaks that packet up into smaller parts, each of which is
+ *   smaller than or equal to the VPN tunnel's MTU.  See \c
+ *   fragment_outgoing() for details.
+ * - For packets which have been received from a remote OpenVPN peer: \c
+ *   fragment_incoming() \n This function inspects data channel packets
+ *   that have been received from a remote OpenVPN peer through a VPN
+ *   tunnel.  It reads the fragmentation header of the packet, and
+ *   depending on its value performs the appropriate action.  See \c
+ *   fragment_incoming() for details.
+ * 
+ * @par Settings that control this module's activity
+ * Whether the Data Channel Fragmentation module is active or not depends
+ * on the compile-time \c ENABLE_FRAGMENT preprocessor macro and the
+ * runtime flag \c options.fragment, which gets its value from the
+ * process's configuration sources, such as the configuration file and
+ * commandline %options.
+ */
fragment.h +365 -74

527 lines not on this page · raw message

Signature · 1 line
1.7.4.1
#12 lore raw

PATCH 8/8 Added main/control docs

In reply to Adriaan de Jong
---
 doc_control_processor.h    |  189 +++++++++++++++++++++++++++++++++++++++++
 doc_data_control.h         |  103 +++++++++++++++++++++++
 doc_eventloop.h            |   67 +++++++++++++++
 doc_external_multiplexer.h |   46 ++++++++++
 doc_internal_multiplexer.h |   44 ++++++++++
 doc_mainpage.h             |  162 +++++++++++++++++++++++++++++++++++
 doc_protocol_overview.h    |  199 ++++++++++++++++++++++++++++++++++++++++++++
 doc_tunnel_state.h         |  155 ++++++++++++++++++++++++++++++++++
 forward.h                  |  163 +++++++++++++++++++++++++++++++++++-
 mtcp.h                     |    9 ++
 mtu.h                      |   68 ++++++++-------
 mudp.c                     |   14 +++-
 mudp.h                     |   29 +++++++
 multi.h                    |  161 ++++++++++++++++++++++++++++++++----
 openvpn.c                  |   31 +++++++
 openvpn.h                  |  153 ++++++++++++++++++++--------------
 16 files changed, 1476 insertions(+), 117 deletions(-)
 create mode 100644 doc_control_processor.h
 create mode 100644 doc_data_control.h
 create mode 100644 doc_eventloop.h
 create mode 100644 doc_external_multiplexer.h
 create mode 100644 doc_internal_multiplexer.h
 create mode 100644 doc_mainpage.h
 create mode 100644 doc_protocol_overview.h
 create mode 100644 doc_tunnel_state.h
doc_control_processor.h new file +189 -0
new file mode 100644
index 0000000..506f8ab
@@ -0,0 +1,189 @@
+/*
+ *  OpenVPN -- An application to securely tunnel IP networks
+ *             over a single TCP/UDP port, with support for SSL/TLS-based
+ *             session authentication and key exchange,
+ *             packet encryption, packet authentication, and
+ *             packet compression.
+ *
+ *  Copyright (C) 2010 Fox Crypto B.V. <[email protected]...>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2
+ *  as published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program (see the file COPYING included with this
+ *  distribution); if not, write to the Free Software Foundation, Inc.,
+ *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+
+/**
+ * @file
+ * Control Channel Processor module documentation file.
+ */
+
+/**
+ * @defgroup control_processor Control Channel Processor module
+ * 
+ * This module controls the setup and maintenance of VPN tunnels and the
+ * associated security parameters.
+ * 
+ * @par This module's role
+ * The Control Channel Processor module lies at the core of OpenVPN's
+ * activities.  It handles the setup of new VPN tunnels, the negotiation
+ * of data channel security parameters, the managing of active VPN
+ * tunnels, and finally the cleanup of expired VPN tunnels.
+ * 
+ * @par State structures
+ * A large amount of VPN tunnel state information must be stored within an
+ * OpenVPN process.  A wide variety of container structures are used by
+ * this module for that purpose.  Several of these structures are listed
+ * below, and the function of the first three VPN tunnel state containers
+ * is described in more detail later.
+ *  - VPN tunnel state containers:
+ *     - \c tls_multi, security parameter state for a single VPN tunnel.
+ *       Contains three instances of the \c tls_session structure.
+ *     - \c tls_session, security parameter state of a single session
+ *       within a VPN tunnel.  Contains two instances of the \c key_state
+ *       structure.
+ *     - \c key_state, security parameter state of one TLS and data
+ *       channel %key set.
+ *  - Data channel security parameter containers:
+ *     - \c key_ctx_bi, container for two sets of OpenSSL cipher and/or
+ *       HMAC context (both directions).  Contains two instances of the \c
+ *       key_ctx structure.
+ *     - \c key_ctx, container for one set of OpenSSL cipher and/or HMAC
+ *       context (one directions.
+ *  - Key material containers:
+ *     - \c key2, container for two sets of cipher and/or HMAC %key
+ *       material (both directions).  Contains two instances of the \c key
+ *       structure.
+ *     - \c key, container for one set of cipher and/or HMAC %key material
+ *       (one direction).
+ *     - \c key_direction_state, ordering of %key material within the \c
+ *       key2.key array.
+ *  - Key method 2 random material containers:
+ *     - \c key_source2, container for both halves of random material used
+ *       for %key method 2.  Contains two instances of the \c key_source
+ *       structure.
+ *     - \c key_source, container for one half of random material used for
+ *       %key method 2.
+ * 
+ * @par The life of a \c tls_multi object
+ * A \c tls_multi structure contains all the security parameter state
+ * information related to the control and data channels of one VPN tunnel.
+ * Its life cycle can be summarized as follows:
+ *  -# Initialization: \c tls_multi_init() and \c
+ *     tls_multi_init_finalize(), which are called (indirectly) from \c
+ *     init_instance() when initializing a new \c context structure.
+ *     - Initializes a \c tls_multi structure.
+ *     - Allocates the three \c tls_session objects contained by the \c
+ *       tls_multi structure, and initializes as appropriate.
+ *  -# Management: \c tls_multi_process() and \c tls_pre_decrypt()
+ *     - If a new session is initiated by the remote peer, then \c
+ *       tls_pre_decrypt() starts the new session negotiation in the
+ *       un-trusted \c tls_session.
+ *     - If the, as yet, un-trusted \c tls_session authenticates
+ *       successfully, then \c tls_multi_process() moves it so as to be
+ *       the active \c tls_session.
+ *     - If an error occurs during processing of a \c key_state object,
+ *       then \c tls_multi_process() cleans up and initializes the
+ *       associated \c tls_session object.  If the error occurred in the
+ *       active \c key_state of the active \c tls_session and the
+ *       lame-duck \c key_state of that \c tls_session has not yet
+ *       expired, it is preserved as fallback.
+ *  -# Cleanup: \c tls_multi_free(), which is called (indirectly) from \c
+ *     close_instance() when cleaning up a \c context structure.
+ *     - Cleans up a \c tls_multi structure.
+ *     - Cleans up the three \c tls_session objects contained by the \c
+ *       tls_multi structure.
+ * 
+ * @par The life of a \c tls_session object
+ * A \c tls_session structure contains the state information related to an
+ * active and a lame-duck \c key_state.  Its life cycle can be summarized
+ * as follows:
+ *  -# Initialization: \c tls_session_init()
+ *     - Initializes a \c tls_session structure.
+ *     - Initializes the primary \c key_state by calling \c
+ *       key_state_init().
+ *  -# Renegotiation: \c key_state_soft_reset()
+ *     - Cleans up the old lame-duck \c key_state by calling \c
+ *       key_state_free().
+ *     - Moves the old primary \c key_state to be the new lame-duck \c
+ *       key_state.
+ *     - Initializes a new primary \c key_state by calling \c
+ *       key_state_init().
+ *  -# Cleanup: \c tls_session_free()
+ *     - Cleans up a \c tls_session structure.
+ *     - Cleans up all \c key_state objects associated with the session by
+ *       calling \c key_state_free() for each.
+ * 
+ * @par The life of a \c key_state object
+ * A \c key_state structure represents one control and data channel %key
+ * set.  It contains an OpenSSL TLS object that encapsulates the control
+ * channel, and the data channel security parameters needed by the \link
+ * data_crypto Data Channel Crypto module\endlink to perform cryptographic
+ * operations on data channel packets.  Its life cycle can be summarized
+ * as follows:
+ *  -# Initialization: \c key_state_init()
+ *     - Initializes a \c key_state structure.
+ *     - Creates a new OpenSSL TLS object to encapsulate this new control
+ *       channel session.
+ *     - Sets \c key_state.state to \c S_INITIAL.
+ *     - Allocates several internal buffers.
+ *     - Initializes new reliability layer structures for this key set.
+ *  -# Negotiation: \c tls_process()
+ *     - The OpenSSL TLS object negotiates a TLS session between itself
+ *       and the remote peer's TLS object.
+ *     - Key material is generated and exchanged through the TLS session
+ *       between OpenVPN peers.
+ *     - Both peers initialize their data channel cipher and HMAC key
+ *       contexts.
+ *     - On successful negotiation, the \c key_state.state will progress
+ *       from \c S_INITIAL to \c S_ACTIVE and \c S_NORMAL.
+ *  -# Active tunneling: \link data_crypto Data Channel Crypto
+ *     module\endlink
+ *     - Data channel packet to be sent to a remote OpenVPN peer:
+ *        - \c tls_pre_encrypt() loads the security parameters from the \c
+ *          key_state into a \c crypto_options structure.
+ *        - \c openvpn_encrypt() uses the \c crypto_options to an encrypt
+ *          and HMAC sign the data channel packet.
+ *     - Data channel packet received from a remote OpenVPN peer:
+ *        - \c tls_pre_decrypt() loads the security parameters from the \c
+ *          key_state into a \c crypto_options structure.
+ *        - \c openvpn_encrypt() uses the \c crypto_options to
+ *          authenticate and decrypt the data channel packet.
+ *  -# Cleanup: \c key_state_free()
+ *     - Cleans up a \c key_state structure together with its OpenSSL TLS
+ *       object, key material, internal buffers, and reliability layer
+ *       structures.
+ * 
+ * @par Control functions
+ * The following two functions drive the Control Channel Processor's
+ * activities.
+ *  - \c tls_multi_process(), iterates through the \c tls_session objects
+ *    within a given \c tls_multi of a VPN tunnel, and calls \c
+ *    tls_process() for each \c tls_session which is being set up, is
+ *    already active, or is busy expiring.
+ *  - \c tls_process(), performs the Control Channel Processor module's
+ *    core handling of received control channel messages, and generates
+ *    appropriate messages to be sent.
+ * 
+ * @par Functions which control data channel key generation
+ *  - Key method 1 key exchange functions:
+ *     - \c key_method_1_write(), generates and processes key material to
+ *       be sent to the remote OpenVPN peer.
+ *     - \c key_method_1_read(), processes key material received from the
+ *       remote OpenVPN peer.
+ *  - Key method 2 key exchange functions:
+ *     - \c key_method_2_write(), generates and processes key material to
+ *       be sent to the remote OpenVPN peer.
+ *     - \c key_method_2_read(), processes key material received from the
+ *       remote OpenVPN peer.
+ */
doc_data_control.h new file +103 -0

103 lines not on this page · raw message

doc_eventloop.h new file +67 -0

67 lines not on this page · raw message

doc_external_multiplexer.h new file +46 -0

46 lines not on this page · raw message

doc_internal_multiplexer.h new file +44 -0

44 lines not on this page · raw message

doc_mainpage.h new file +162 -0

162 lines not on this page · raw message

doc_protocol_overview.h new file +199 -0

199 lines not on this page · raw message

doc_tunnel_state.h new file +155 -0

155 lines not on this page · raw message

forward.h +159 -4

187 lines not on this page · raw message

mtcp.h +9 -0
index 3585af4..0b5308d 100644
@@ -60,8 +60,17 @@ void multi_tcp_instance_specific_free (struct multi_instance *mi);
 
 void multi_tcp_link_out_deferred (struct multi_context *m, struct multi_instance *mi);
 
+
+/**************************************************************************/
+/**
+ * Main event loop for OpenVPN in TCP server mode.
+ * @ingroup eventloop
+ * 
+ * @param top - Top-level context structure.
+ */
 void tunnel_server_tcp (struct context *top);
 
+
 void multi_tcp_delete_event (struct multi_tcp *mtcp, event_t event);
 
 #endif
mtu.h +36 -32

75 lines not on this page · raw message

mudp.c +11 -3
index a478b29..1e17299 100644
@@ -199,9 +199,17 @@ p2mp_iow_flags (const struct multi_context *m)
   return flags;
 }
 
-/*
- * Top level event loop for single-threaded operation.
- * UDP mode.
+
+/**************************************************************************/
+/**
+ * Main event loop for OpenVPN in UDP server mode.
+ * @ingroup eventloop
+ * 
+ * This function implements OpenVPN's main event loop for UDP server mode.
+ *  At this time, OpenVPN does not yet support multithreading.  This
+ * function's name is therefore slightly misleading.
+ * 
+ * @param top - Top-level context structure.
  */
 static void
 tunnel_server_udp_single_threaded (struct context *top)
mudp.h +29 -0
index dc9cfde..5d347fa 100644
@@ -34,8 +34,37 @@
 struct context;
 struct multi_context;
 
+
+/**************************************************************************/
+/**
+ * Main event loop wrapper function for OpenVPN in UDP server mode.
+ * @ingroup eventloop
+ * 
+ * This function simply calls \c tunnel_server_udp_single_threaded().
+ * 
+ * @param top          - Top-level context structure.
+ */
 void tunnel_server_udp (struct context *top);
 
+
+/**************************************************************************/
+/**
+ * Get, and if necessary create, the multi_instance associated with a
+ * packet's source address.
+ * @ingroup external_multiplexer
+ * 
+ * This function extracts the source address of a recently read packet
+ * from \c m->top.c2.from and uses that source address as a hash key for
+ * the hash table \c m->hash.  If an entry exists, this function returns
+ * it.  If no entry exists, this function handles its creation, and if
+ * successful, returns the newly created instance.
+ * 
+ * @param m            - The single multi_context structure.
+ * 
+ * @return A pointer to a multi_instance if one already existed for the
+ *     packet's source address or if one was a newly created successfully.
+ *      NULL if one did not yet exist and a new one was not created.
+ */
 struct multi_instance *multi_get_create_instance_udp (struct multi_context *m);
 
 #endif
multi.h +144 -17

233 lines not on this page · raw message

openvpn.c +31 -0
index 99b343b..faf2858 100644
@@ -42,6 +42,16 @@ process_signal_p2p (struct context *c)
   return process_signal (c);
 }
 
+
+
+/**************************************************************************/
+/**
+ * Main event loop for OpenVPN in client mode, where only one VPN tunnel
+ * is active.
+ * @ingroup eventloop
+ * 
+ * @param c - The context structure of the single active VPN tunnel.
+ */
 static void
 tunnel_point_to_point (struct context *c)
 {
@@ -90,6 +100,27 @@ tunnel_point_to_point (struct context *c)
 
 #undef PROCESS_SIGNAL_P2P
 
+
+/**************************************************************************/
+/**
+ * OpenVPN's main init-run-cleanup loop.
+ * @ingroup eventloop
+ * 
+ * This function contains the two outer OpenVPN loops.  Its structure is
+ * as follows:
+ *  - Once-per-process initialization.
+ *  - Outer loop, run at startup and then once per \c SIGHUP:
+ *    - Level 1 initialization
+ *    - Inner loop, run at startup and then once per \c SIGUSR1:
+ *      - Call event loop function depending on client or server mode:
+ *        - \c tunnel_point_to_point()
+ *        - \c tunnel_server()
+ *    - Level 1 cleanup
+ *  - Once-per-process cleanup.
+ * 
+ * @param argc - Commandline argument count.
+ * @param argv - Commandline argument values.
+ */
 int
 main (int argc, char *argv[])
 {
openvpn.h +92 -61

238 lines not on this page · raw message

Signature · 1 line
1.7.4.1
#13 lore raw
In reply to Adriaan de Jong

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 11 lines · Adriaan de Jong

Hi everyone,

Here's the first series of promised patches, many others will follow in the next few weeks. Although these are meant to be ready for the master branch, the actual process of generating patches with git is new to me, so please forgive any errors :).

This first series adds Doxygen documentation to OpenVPN, which can be generated using 'doxygen openvpn.doxyfile'. The graphviz and doxygen packages must be installed on your system to do so.

First of all, thanks a lot for this effort! This is really valuable! You seem to have managed to tackle this git patch submission just perfect, btw. I'll try to apply them soonish too, to test their integrity.

One immediate comment, though. Is there a reason the doc_*.[ch] files are not in a separate sub-directory? Would it be possible to move all the new doxygen related files into, say, a ./doxygen directory? This is just to isolate all which is purely doxygen stuff in one place.

kind regards,

David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk4BpdsACgkQDC186MBRfroObgCfbi3kwos10xOYTSVh1UueB4SQ cLQAmwSWREU18R0QYn3pfZgmkkhcRhZ+
=q5UP
-----END PGP SIGNATURE-----

#14 lore raw

PATCH 9/9 Moved doxygen-specific files to a separate directory

---
 doc_compression.h                  |   92 ------------
 doc_control_processor.h            |  189 ------------------------
 doc_control_tls.h                  |  105 --------------
 doc_data_control.h                 |  103 -------------
 doc_data_crypto.h                  |   75 ----------
 doc_eventloop.h                    |   67 ---------
 doc_external_multiplexer.h         |   46 ------
 doc_fragmentation.h                |   96 ------------
 doc_internal_multiplexer.h         |   44 ------
 doc_key_generation.h               |  148 -------------------
 doc_mainpage.h                     |  162 ---------------------
 doc_memory_management.h            |   99 -------------
 doc_protocol_overview.h            |  199 -------------------------
 doc_reliable.h                     |   49 -------
 doc_tunnel_state.h                 |  155 --------------------
 doxygen/doc_compression.h          |   92 ++++++++++++
 doxygen/doc_control_processor.h    |  189 ++++++++++++++++++++++++
 doxygen/doc_control_tls.h          |  105 ++++++++++++++
 doxygen/doc_data_control.h         |  103 +++++++++++++
 doxygen/doc_data_crypto.h          |   75 ++++++++++
 doxygen/doc_eventloop.h            |   67 +++++++++
 doxygen/doc_external_multiplexer.h |   46 ++++++
 doxygen/doc_fragmentation.h        |   96 ++++++++++++
 doxygen/doc_internal_multiplexer.h |   44 ++++++
 doxygen/doc_key_generation.h       |  148 +++++++++++++++++++
 doxygen/doc_mainpage.h             |  162 +++++++++++++++++++++
 doxygen/doc_memory_management.h    |   99 +++++++++++++
 doxygen/doc_protocol_overview.h    |  199 +++++++++++++++++++++++++
 doxygen/doc_reliable.h             |   49 +++++++
 doxygen/doc_tunnel_state.h         |  155 ++++++++++++++++++++
 doxygen/openvpn.doxyfile           |  279 ++++++++++++++++++++++++++++++++++++
 openvpn.doxyfile                   |  279 ------------------------------------
 32 files changed, 1908 insertions(+), 1908 deletions(-)
 delete mode 100644 doc_compression.h
 delete mode 100644 doc_control_processor.h
 delete mode 100644 doc_control_tls.h
 delete mode 100644 doc_data_control.h
 delete mode 100644 doc_data_crypto.h
 delete mode 100644 doc_eventloop.h
 delete mode 100644 doc_external_multiplexer.h
 delete mode 100644 doc_fragmentation.h
 delete mode 100644 doc_internal_multiplexer.h
 delete mode 100644 doc_key_generation.h
 delete mode 100644 doc_mainpage.h
 delete mode 100644 doc_memory_management.h
 delete mode 100644 doc_protocol_overview.h
 delete mode 100644 doc_reliable.h
 delete mode 100644 doc_tunnel_state.h
 create mode 100644 doxygen/doc_compression.h
 create mode 100644 doxygen/doc_control_processor.h
 create mode 100644 doxygen/doc_control_tls.h
 create mode 100644 doxygen/doc_data_control.h
 create mode 100644 doxygen/doc_data_crypto.h
 create mode 100644 doxygen/doc_eventloop.h
 create mode 100644 doxygen/doc_external_multiplexer.h
 create mode 100644 doxygen/doc_fragmentation.h
 create mode 100644 doxygen/doc_internal_multiplexer.h
 create mode 100644 doxygen/doc_key_generation.h
 create mode 100644 doxygen/doc_mainpage.h
 create mode 100644 doxygen/doc_memory_management.h
 create mode 100644 doxygen/doc_protocol_overview.h
 create mode 100644 doxygen/doc_reliable.h
 create mode 100644 doxygen/doc_tunnel_state.h
 create mode 100644 doxygen/openvpn.doxyfile
 delete mode 100644 openvpn.doxyfile
doc_compression.h deleted +0 -92
deleted file mode 100644
index 0296b27..0000000
@@ -1,92 +0,0 @@
-/*
- *  OpenVPN -- An application to securely tunnel IP networks
- *             over a single TCP/UDP port, with support for SSL/TLS-based
- *             session authentication and key exchange,
- *             packet encryption, packet authentication, and
- *             packet compression.
- *
- *  Copyright (C) 2010 Fox Crypto B.V. <[email protected]...>
- *
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License version 2
- *  as published by the Free Software Foundation.
- *
- *  This program is distributed in the hope that it will be useful,
- *  but WITHOUT ANY WARRANTY; without even the implied warranty of
- *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- *  GNU General Public License for more details.
- *
- *  You should have received a copy of the GNU General Public License
- *  along with this program (see the file COPYING included with this
- *  distribution); if not, write to the Free Software Foundation, Inc.,
- *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- */
-
-/**
- * @file Data Channel Compression module documentation file.
- */
-
-/**
- * @defgroup compression Data Channel Compression module
- * 
- * This module offers compression of data channel packets.
- * 
- * @par State structures
- * The Data Channel Compression module stores its internal state in a \c
- * lzo_compress_workspace structure.  This state includes flags which
- * control the module's behavior and preallocated working memory.  One
- * such structure is present for each VPN tunnel, and is stored in the \c
- * context.c2.lzo_compwork of the \c context associated with that VPN
- * tunnel.
- * 
- * @par Initialization and cleanup
- * Every time a new \c lzo_compress_workspace is needed, it must be
- * initialized using the \c lzo_compress_init() function.  Similarly,
- * every time a \c lzo_compress_workspace is no longer needed, it must be
- * cleaned up using the \c lzo_compress_uninit() function.  These
- * functions take care of the allocation and freeing of internal working
- * memory, but not of the \c lzo_compress_workspace structures themselves.
- * 
- * @par
- * Because of the one-to-one relationship between \c
- * lzo_compress_workspace structures and VPN tunnels, the above-mentioned
- * initialization and cleanup functions are called directly from the \c
- * init_instance() and \c close_instance() functions, which control the
- * initialization and cleanup of VPN tunnel instances and their associated
- * \c context structures.
- * 
- * @par Packet processing functions
- * This module receives data channel packets from the \link data_control
- * Data Channel Control module\endlink and processes them according to the
- * settings of the packet's VPN tunnel.  The \link data_control Data
- * Channel Control module\endlink uses the following interface functions:
- * - For packets which will be sent to a remote OpenVPN peer: \c
- *   lzo_compress()
- * - For packets which have been received from a remote OpenVPN peer: \c
- *   lzo_decompress()
- * 
- * @par Settings that control this module's activity
- * Whether or not the Data Channel Compression module is active depends on
- * the compile-time \c USE_LZO preprocessor macro and the runtime flags
- * stored in \c lzo_compress_workspace.flags of the associated VPN tunnel.
- * The latter are initialized from \c options.lzo, which gets its value
- * from the process's configuration sources, such as its configuration
- * file or command line %options.
- * 
- * @par Adaptive compression
- * The compression module supports adaptive compression.  If this feature
- * is enabled, the compression routines monitor their own performance and
- * turn compression on or off depending on whether it is leading to
- * significantly reduced payload size.
- * 
- * @par Compression algorithms
- * This module uses the Lempel-Ziv-Oberhumer (LZO) compression algorithms.
- * These offer lossless compression and are designed for high-performance
- * decompression.  This module uses the external \c lzo library's
- * implementation of the algorithms.
- * 
- * @par
- * For more information on the LZO library, see:\n
- * http://www.oberhumer.com/opensource/lzo/
- */
doc_control_processor.h deleted +0 -189

189 lines not on this page · raw message

doc_control_tls.h deleted +0 -105

105 lines not on this page · raw message

doc_data_control.h deleted +0 -103

103 lines not on this page · raw message

doc_data_crypto.h deleted +0 -75

75 lines not on this page · raw message

doc_eventloop.h deleted +0 -67

67 lines not on this page · raw message

doc_external_multiplexer.h deleted +0 -46

46 lines not on this page · raw message

doc_fragmentation.h deleted +0 -96

96 lines not on this page · raw message

doc_internal_multiplexer.h deleted +0 -44

44 lines not on this page · raw message

doc_key_generation.h deleted +0 -148

148 lines not on this page · raw message

doc_mainpage.h deleted +0 -162

162 lines not on this page · raw message

doc_memory_management.h deleted +0 -99

99 lines not on this page · raw message

doc_protocol_overview.h deleted +0 -199

199 lines not on this page · raw message

doc_reliable.h deleted +0 -49

49 lines not on this page · raw message

doc_tunnel_state.h deleted +0 -155

155 lines not on this page · raw message

doxygen/doc_compression.h new file +92 -0

92 lines not on this page · raw message

doxygen/doc_control_processor.h new file +189 -0

189 lines not on this page · raw message

doxygen/doc_control_tls.h new file +105 -0

105 lines not on this page · raw message

doxygen/doc_data_control.h new file +103 -0

103 lines not on this page · raw message

doxygen/doc_data_crypto.h new file +75 -0

75 lines not on this page · raw message

doxygen/doc_eventloop.h new file +67 -0

67 lines not on this page · raw message

doxygen/doc_external_multiplexer.h new file +46 -0

46 lines not on this page · raw message

doxygen/doc_fragmentation.h new file +96 -0

96 lines not on this page · raw message

doxygen/doc_internal_multiplexer.h new file +44 -0

44 lines not on this page · raw message

doxygen/doc_key_generation.h new file +148 -0

148 lines not on this page · raw message

doxygen/doc_mainpage.h new file +162 -0

162 lines not on this page · raw message

doxygen/doc_memory_management.h new file +99 -0

99 lines not on this page · raw message

doxygen/doc_protocol_overview.h new file +199 -0

145 lines not on this page · raw message

doxygen/doc_reliable.h new file +49 -0

49 lines not on this page · raw message

doxygen/doc_tunnel_state.h new file +155 -0

155 lines not on this page · raw message

doxygen/openvpn.doxyfile new file +279 -0

279 lines not on this page · raw message

openvpn.doxyfile deleted +0 -279

279 lines not on this page · raw message

The rest of this diff is not shown. View the raw message.

Signature · 1 line
1.7.4.1

Part of the diff is not shown here. View the raw message.

#15 lore raw

Re: [Openvpn-devel] [PATCH 9/9] Moved doxygen-specific files to a separate directory

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 58 lines · Adriaan de Jong
---
 doc_compression.h                  |   92 ------------
 doc_control_processor.h            |  189 ------------------------
 doc_control_tls.h                  |  105 --------------
 doc_data_control.h                 |  103 -------------
 doc_data_crypto.h                  |   75 ----------
 doc_eventloop.h                    |   67 ---------
 doc_external_multiplexer.h         |   46 ------
 doc_fragmentation.h                |   96 ------------
 doc_internal_multiplexer.h         |   44 ------
 doc_key_generation.h               |  148 -------------------
 doc_mainpage.h                     |  162 ---------------------
 doc_memory_management.h            |   99 -------------
 doc_protocol_overview.h            |  199 -------------------------
 doc_reliable.h                     |   49 -------
 doc_tunnel_state.h                 |  155 --------------------
 doxygen/doc_compression.h          |   92 ++++++++++++
 doxygen/doc_control_processor.h    |  189 ++++++++++++++++++++++++
 doxygen/doc_control_tls.h          |  105 ++++++++++++++
 doxygen/doc_data_control.h         |  103 +++++++++++++
 doxygen/doc_data_crypto.h          |   75 ++++++++++
 doxygen/doc_eventloop.h            |   67 +++++++++
 doxygen/doc_external_multiplexer.h |   46 ++++++
 doxygen/doc_fragmentation.h        |   96 ++++++++++++
 doxygen/doc_internal_multiplexer.h |   44 ++++++
 doxygen/doc_key_generation.h       |  148 +++++++++++++++++++
 doxygen/doc_mainpage.h             |  162 +++++++++++++++++++++
 doxygen/doc_memory_management.h    |   99 +++++++++++++
 doxygen/doc_protocol_overview.h    |  199 +++++++++++++++++++++++++
 doxygen/doc_reliable.h             |   49 +++++++
 doxygen/doc_tunnel_state.h         |  155 ++++++++++++++++++++
 doxygen/openvpn.doxyfile           |  279 ++++++++++++++++++++++++++++++++++++
 openvpn.doxyfile                   |  279 ------------------------------------
 32 files changed, 1908 insertions(+), 1908 deletions(-)
 delete mode 100644 doc_compression.h
 delete mode 100644 doc_control_processor.h
 delete mode 100644 doc_control_tls.h
 delete mode 100644 doc_data_control.h
 delete mode 100644 doc_data_crypto.h
 delete mode 100644 doc_eventloop.h
 delete mode 100644 doc_external_multiplexer.h
 delete mode 100644 doc_fragmentation.h
 delete mode 100644 doc_internal_multiplexer.h
 delete mode 100644 doc_key_generation.h
 delete mode 100644 doc_mainpage.h
 delete mode 100644 doc_memory_management.h
 delete mode 100644 doc_protocol_overview.h
 delete mode 100644 doc_reliable.h
 delete mode 100644 doc_tunnel_state.h
 create mode 100644 doxygen/doc_compression.h
 create mode 100644 doxygen/doc_control_processor.h
 create mode 100644 doxygen/doc_control_tls.h
 create mode 100644 doxygen/doc_data_control.h
 create mode 100644 doxygen/doc_data_crypto.h
 create mode 100644 doxygen/doc_eventloop.h
 create mode 100644 doxygen/doc_external_multiplexer.h
 create mode 100644 doxygen/doc_fragmentation.h
 create mode 100644 doxygen/doc_internal_multiplexer.h
Quoted 8 lines
 create mode 100644 doxygen/doc_key_generation.h
 create mode 100644 doxygen/doc_mainpage.h
 create mode 100644 doxygen/doc_memory_management.h
 create mode 100644 doxygen/doc_protocol_overview.h
 create mode 100644 doxygen/doc_reliable.h
 create mode 100644 doxygen/doc_tunnel_state.h
 create mode 100644 doxygen/openvpn.doxyfile
 delete mode 100644 openvpn.doxyfile

As this is a pure file move, moving all doc files into doxygen, this gets an ACK.

kind regards,

David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk4UAbYACgkQDC186MBRfrqPDgCeNR+nsdEQiDo0eZ4nX5Gd+KTQ LZQAn3bCrGK+rrU6FtdwGHct5DIcInlm
=pyM5
-----END PGP SIGNATURE-----

#16 lore raw
In reply to David Sommerseth
Quoted 7 lines

One immediate comment, though. Is there a reason the doc_*.[ch] files are
not in a separate sub-directory? Would it be possible to move all the new
doxygen related files into, say, a ./doxygen directory? This is just to
isolate all which is purely doxygen stuff in one place.

Good idea, I've sent out a patch that does exactly that!

Adriaan

#17 lore raw
In reply to Adriaan de Jong

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoted 10 lines · Adriaan de Jong

Hi everyone,

Here's the first series of promised patches, many others will follow in the next few weeks. Although these are meant to be ready for the master branch, the actual process of generating patches with git is new to me, so please forgive any errors :).

This first series adds Doxygen documentation to OpenVPN, which can be generated using 'doxygen openvpn.doxyfile'. The graphviz and doxygen packages must be installed on your system to do so.

Regards,

Adriaan de Jong
Fox-IT

All doxygen patches have now been accepted into the git tree. Most of them have been reviewed by James Yonan, and I've made sure there is no feature changes in the code.

I realised after the git push that I've done a mistake. When applying these patches, I fixed a lot of whitespace errors which git complained about (mostly trailing spaces, before newline). In this process, I didn't notice that the patch author got changed in the git commit. So it now might look like I'm the author. However, the Signed-off-by: lines are intact, and all have the proper credit to Adriaan de Jong.

So unless there are any objections or Adriaan insists on having his name as the patch authors, I will leave it how it is now. Otherwise, I'll need to reset the git tree and push out a new one. But I'm willing to do that if people wants it like that.

kind regards,

David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk4x3qoACgkQDC186MBRfrqF1gCeKIFsTK5WwyDZ8XKzvdMtNuP9 vlAAn0Nl5nPWsRJS2l6ScGVEZPLetP0S
=h05L
-----END PGP SIGNATURE-----

#18 lore raw
Quoted 14 lines

All doxygen patches have now been accepted into the git tree. Most of them
have been reviewed by James Yonan, and I've made sure there is no feature
changes in the code.

I realised after the git push that I've done a mistake. When applying these patches, I fixed a lot of whitespace errors which git complained about (mostly trailing spaces, before newline). In this process, I didn't
notice that the patch author got changed in the git commit. So it now might look like I'm the author. However, the Signed-off-by: lines are intact, and all have the proper credit to Adriaan de Jong.

Quoted 8 lines

So unless there are any objections or Adriaan insists on having his name as
the patch authors, I will leave it how it is now. Otherwise, I'll need to
reset the git tree and push out a new one. But I'm willing to do that if
people wants it like that.

Great news! I'll be fine without the author credits there :). Thanks for reviewing the patches, I'm glad they were included.

Adriaan