doc/cha-support.texi

   1 @node Support
   2 @appendix Support
   3
   4 @menu
   5 * Getting help::
   6 * Commercial Support::
   7 * Bug Reports::
   8 * Contributing::
   9 * Certification::
  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{gnutls-help@@gnutls.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.gnutls.org/pipermail/gnutls-help/}.
  20
  21 A mailing list for developers are also available, see
  22 @url{http://www.gnutls.org/lists.html}.
  23 Bug reports should be sent to @email{bugs@@gnutls.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
  62 @node Bug Reports
  63 @section Bug Reports
  64 @cindex reporting bugs
  65
  66 If you think you have found a bug in GnuTLS, please investigate it and
  67 report it.
  68
  69 @itemize @bullet
  70
  71 @item Please make sure that the bug is really in GnuTLS, and
  72 preferably also check that it hasn't already been fixed in the latest
  73 version.
  74
  75 @item You have to send us a test case that makes it possible for us to
  76 reproduce the bug.
  77
  78 @item You also have to explain what is wrong; if you get a crash, or
  79 if the results printed are not good and in that case, in what way.
  80 Make sure that the bug report includes all information you would need
  81 to fix this kind of bug for someone else.
  82
  83 @end itemize
  84
  85 Please make an effort to produce a self-contained report, with
  86 something definite that can be tested or debugged.  Vague queries or
  87 piecemeal messages are difficult to act on and don't help the
  88 development effort.
  89
  90 If your bug report is good, we will do our best to help you to get a
  91 corrected version of the software; if the bug report is poor, we won't
  92 do anything about it (apart from asking you to send better bug
  93 reports).
  94
  95 If you think something in this manual is unclear, or downright
  96 incorrect, or if the language needs to be improved, please also send a
  97 note.
  98
  99 Send your bug report to:
 100
 101 @center @samp{bugs@@gnutls.org}
 102
 103 @node Contributing
 104 @section Contributing
 105 @cindex contributing
 106 @cindex hacking
 107
 108 If you want to submit a patch for inclusion -- from solving a typo you
 109 discovered, up to adding support for a new feature -- you should
 110 submit it as a bug report, using the process in @ref{Bug Reports}.  There are some
 111 things that you can do to increase the chances for it to be included
 112 in the official package.
 113
 114 Unless your patch is very small (say, under 10 lines) we require that
 115 you assign the copyright of your work to the Free Software Foundation.
 116 This is to protect the freedom of the project.  If you have not
 117 already signed papers, we will send you the necessary information when
 118 you submit your contribution.
 119
 120 For contributions that doesn't consist of actual programming code, the
 121 only guidelines are common sense.
 122 For code contributions, a number of style guides will help you:
 123
 124 @itemize @bullet
 125
 126 @item Coding Style.
 127 Follow the GNU Standards document.
 128 @c (@pxref{top, GNU Coding Standards,,standards}).
 129
 130 If you normally code using another coding standard, there is no
 131 problem, but you should use @samp{indent} to reformat the code
 132 @c (@pxref{top, GNU Indent,, indent})
 133 before submitting your work.
 134
 135 @item Use the unified diff format @samp{diff -u}.
 136
 137 @item Return errors.
 138 No reason whatsoever should abort the execution of the library.  Even
 139 memory allocation errors, e.g. when malloc return NULL, should work
 140 although result in an error code.
 141
 142 @item Design with thread safety in mind.
 143 Don't use global variables.  Don't even write to per-handle global
 144 variables unless the documented behaviour of the function you write is
 145 to write to the per-handle global variable.
 146
 147 @item Avoid using the C math library.
 148 It causes problems for embedded implementations, and in most
 149 situations it is very easy to avoid using it.
 150
 151 @item Document your functions.
 152 Use comments before each function headers, that, if properly
 153 formatted, are extracted into Texinfo manuals and GTK-DOC web pages.
 154
 155 @item Supply a ChangeLog and NEWS entries, where appropriate.
 156
 157 @end itemize
 158
 159 @node Certification
 160 @section Certification
 161 @cindex certification
 162
 163 Many cryptographic libraries claim certifications from national or international bodies. These certifications are tied on a specific (and often restricted) version of the library or a
 164 specific product using the library, and typically in the case of software they assure that the algorithms implemented are correct. The major certifications known are:
 165 @itemize
 166 @item USA's FIPS 140-2 at Level 1 which certifies that approved algorithms are used (see @url{http://en.wikipedia.org/wiki/FIPS_140-2});
 167 @item Common Criteria for Information Technology Security Evaluation (CC), an international standard for verification of elaborate security claims (see @url{http://en.wikipedia.org/wiki/Common_Criteria}).
 168 @end itemize
 169
 170 Obtaining such a certification is an expensive and elaborate job that has no immediate value for a continuously developed free software library (as the certification is tied to the
 171 particular version tested). While, as a free software project, we are not actively pursuing this kind of certification, GnuTLS has been FIPS-140-2 certified in several systems by
 172 third parties. If you are, interested, see @ref{Commercial Support}.