doc/cha-support.texi

   1 @node Support
   2 @appendix Support
   3
   4 @menu
   5 * Getting help::
   6 * Commercial Support::
   7 * Downloading and Installing::
   8 * Bug Reports::
   9 * Contributing::
  10 @end menu
  11
  12 @node Getting help
  13 @section Getting Help
  14
  15 A mailing list where users may help each other exists, and you can
  16 reach it by sending e-mail to @email{help-gnutls@@gnu.org}.  Archives
  17 of the mailing list discussions, and an interface to manage
  18 subscriptions, is available through the World Wide Web at
  19 @url{http://lists.gnu.org/mailman/listinfo/help-gnutls}.
  20
  21 A mailing list for developers are also available, see
  22 @url{http://www.gnu.org/software/gnutls/lists.html}.
  23 Bug reports should be sent to @email{bug-gnutls@@gnu.org}, see
  24 @ref{Bug Reports}.
  25
  26 @node Commercial Support
  27 @section Commercial Support
  28
  29 Commercial support is available for users of GnuTLS.  The kind of
  30 support that can be purchased may include:
  31
  32 @itemize
  33
  34 @item Implement new features.
  35 Such as a new TLS extension.
  36
  37 @item Port GnuTLS to new platforms.
  38 This could include porting to an embedded platforms that may need
  39 memory or size optimization.
  40
  41 @item Integrating TLS as a security environment in your existing project.
  42
  43 @item System design of components related to TLS.
  44
  45 @end itemize
  46
  47 If you are interested, please write to:
  48
  49 @verbatim
  50 Simon Josefsson Datakonsult
  51 Hagagatan 24
  52 113 47 Stockholm
  53 Sweden
  54
  55 E-mail: simon@josefsson.org
  56 @end verbatim
  57
  58 If your company provides support related to GnuTLS and would like to
  59 be mentioned here, contact the authors.
  60
  61 @node Downloading and Installing
  62 @section Downloading and Installing
  63 @cindex installation
  64 @cindex download
  65
  66 GnuTLS is available for download at:
  67 @url{http://www.gnutls.org/download.html}
  68
  69 GnuTLS uses a Linux-like development cycle: even minor version numbers
  70 indicate a stable release and a odd minor version number indicates a
  71 development release.  For example, GnuTLS 1.6.3 denote a stable
  72 release since 6 is even, and GnuTLS 1.7.11 denote a development
  73 release since 7 is odd.
  74
  75 GnuTLS depends on Libnettle, and you will need to install it
  76 before installing GnuTLS.  Libnettle is available from
  77 @url{http://www.lysator.liu.se/~nisse/nettle/}.
  78 Don't forget to verify the cryptographic signature after downloading
  79 source code packages.
  80
  81 The package is then extracted, configured and built like many other
  82 packages that use Autoconf.  For detailed information on configuring
  83 and building it, refer to the @file{INSTALL} file that is part of the
  84 distribution archive.  Typically you invoke @code{./configure} and
  85 then @code{make check install}.  There are a number of compile-time
  86 parameters, as discussed below.
  87
  88 The compression library, libz, is an optional dependency.
  89 You can get libz from @url{http://www.zlib.net/}.
  90
  91 The X.509 part of GnuTLS needs ASN.1 functionality, from a library
  92 called libtasn1.  A copy of libtasn1 is included in GnuTLS.  If you
  93 want to install it separately (e.g., to make it possibly to use
  94 libtasn1 in other programs), you can get it from
  95 @url{http://www.gnu.org/software/gnutls/download.html}.
  96
  97 A few @code{configure} options may be relevant, summarized below.
  98 They disable or enable particular features.
  99
 100 @verbatim
 101 --disable-srp-authentication
 102 --disable-psk-authentication
 103 --disable-anon-authentication
 104 --disable-extra-pki
 105 --disable-openpgp-authentication
 106 --disable-openssl-compatibility
 107 --without-p11-kit
 108 @end verbatim
 109
 110 For the complete list, refer to the output from @code{configure --help}.
 111
 112 @node Bug Reports
 113 @section Bug Reports
 114 @cindex reporting bugs
 115
 116 If you think you have found a bug in GnuTLS, please investigate it and
 117 report it.
 118
 119 @itemize @bullet
 120
 121 @item Please make sure that the bug is really in GnuTLS, and
 122 preferably also check that it hasn't already been fixed in the latest
 123 version.
 124
 125 @item You have to send us a test case that makes it possible for us to
 126 reproduce the bug.
 127
 128 @item You also have to explain what is wrong; if you get a crash, or
 129 if the results printed are not good and in that case, in what way.
 130 Make sure that the bug report includes all information you would need
 131 to fix this kind of bug for someone else.
 132
 133 @end itemize
 134
 135 Please make an effort to produce a self-contained report, with
 136 something definite that can be tested or debugged.  Vague queries or
 137 piecemeal messages are difficult to act on and don't help the
 138 development effort.
 139
 140 If your bug report is good, we will do our best to help you to get a
 141 corrected version of the software; if the bug report is poor, we won't
 142 do anything about it (apart from asking you to send better bug
 143 reports).
 144
 145 If you think something in this manual is unclear, or downright
 146 incorrect, or if the language needs to be improved, please also send a
 147 note.
 148
 149 Send your bug report to:
 150
 151 @center @samp{bug-gnutls@@gnu.org}
 152
 153 @node Contributing
 154 @section Contributing
 155 @cindex contributing
 156 @cindex hacking
 157
 158 If you want to submit a patch for inclusion -- from solving a typo you
 159 discovered, up to adding support for a new feature -- you should
 160 submit it as a bug report, using the process in @ref{Bug Reports}.  There are some
 161 things that you can do to increase the chances for it to be included
 162 in the official package.
 163
 164 Unless your patch is very small (say, under 10 lines) we require that
 165 you assign the copyright of your work to the Free Software Foundation.
 166 This is to protect the freedom of the project.  If you have not
 167 already signed papers, we will send you the necessary information when
 168 you submit your contribution.
 169
 170 For contributions that doesn't consist of actual programming code, the
 171 only guidelines are common sense.
 172 For code contributions, a number of style guides will help you:
 173
 174 @itemize @bullet
 175
 176 @item Coding Style.
 177 Follow the GNU Standards document.
 178 @c (@pxref{top, GNU Coding Standards,,standards}).
 179
 180 If you normally code using another coding standard, there is no
 181 problem, but you should use @samp{indent} to reformat the code
 182 @c (@pxref{top, GNU Indent,, indent})
 183 before submitting your work.
 184
 185 @item Use the unified diff format @samp{diff -u}.
 186
 187 @item Return errors.
 188 No reason whatsoever should abort the execution of the library.  Even
 189 memory allocation errors, e.g. when malloc return NULL, should work
 190 although result in an error code.
 191
 192 @item Design with thread safety in mind.
 193 Don't use global variables.  Don't even write to per-handle global
 194 variables unless the documented behaviour of the function you write is
 195 to write to the per-handle global variable.
 196
 197 @item Avoid using the C math library.
 198 It causes problems for embedded implementations, and in most
 199 situations it is very easy to avoid using it.
 200
 201 @item Document your functions.
 202 Use comments before each function headers, that, if properly
 203 formatted, are extracted into Texinfo manuals and GTK-DOC web pages.
 204
 205 @item Supply a ChangeLog and NEWS entries, where appropriate.
 206
 207 @end itemize
 208