diff options
Diffstat (limited to 'doc/cha-support.texi')
-rw-r--r-- | doc/cha-support.texi | 139 |
1 files changed, 139 insertions, 0 deletions
diff --git a/doc/cha-support.texi b/doc/cha-support.texi new file mode 100644 index 0000000..b68cd07 --- /dev/null +++ b/doc/cha-support.texi @@ -0,0 +1,139 @@ +@node Support +@appendix Support + +@menu +* Getting help:: +* Commercial Support:: +* Bug Reports:: +* Contributing:: +* Certification:: +@end menu + +@node Getting help +@section Getting Help + +A mailing list where users may help each other exists, and you can +reach it by sending e-mail to @email{gnutls-help@@gnutls.org}. Archives +of the mailing list discussions, and an interface to manage +subscriptions, is available through the World Wide Web at +@url{https://lists.gnutls.org/pipermail/gnutls-help/}. + +A mailing list for developers are also available, see +@url{https://www.gnutls.org/lists.html}. +Bug reports should be sent to @email{bugs@@gnutls.org}, see +@ref{Bug Reports}. + +@node Commercial Support +@section Commercial Support + +Commercial support is available for users of GnuTLS. See +@url{https://www.gnutls.org/commercial.html} for more information. + + +@node Bug Reports +@section Bug Reports +@cindex reporting bugs + +If you think you have found a bug in GnuTLS, please investigate it and +report it. + +@itemize @bullet + +@item Please make sure that the bug is really in GnuTLS, and +preferably also check that it hasn't already been fixed in the latest +version. + +@item You have to send us a test case that makes it possible for us to +reproduce the bug. + +@item You also have to explain what is wrong; if you get a crash, or +if the results printed are not good and in that case, in what way. +Make sure that the bug report includes all information you would need +to fix this kind of bug for someone else. + +@end itemize + +Please make an effort to produce a self-contained report, with +something definite that can be tested or debugged. Vague queries or +piecemeal messages are difficult to act on and don't help the +development effort. + +If your bug report is good, we will do our best to help you to get a +corrected version of the software; if the bug report is poor, we won't +do anything about it (apart from asking you to send better bug +reports). + +If you think something in this manual is unclear, or downright +incorrect, or if the language needs to be improved, please also send a +note. + +Send your bug report to: + +@center @samp{bugs@@gnutls.org} + +@node Contributing +@section Contributing +@cindex contributing +@cindex hacking + +If you want to submit a patch for inclusion -- from solving a typo you +discovered, up to adding support for a new feature -- you should +submit it as a bug report, using the process in @ref{Bug Reports}. There are some +things that you can do to increase the chances for it to be included +in the official package. + +Unless your patch is very small (say, under 10 lines) we require that +you assign the copyright of your work to the Free Software Foundation. +This is to protect the freedom of the project. If you have not +already signed papers, we will send you the necessary information when +you submit your contribution. + +For contributions that doesn't consist of actual programming code, the +only guidelines are common sense. +For code contributions, a number of style guides will help you: + +@itemize @bullet + +@item Coding Style. +Follow the GNU Standards document. +@c (@pxref{top, GNU Coding Standards,,standards}). + +If you normally code using another coding standard, there is no +problem, but you should use @samp{indent} to reformat the code +@c (@pxref{top, GNU Indent,, indent}) +before submitting your work. + +@item Use the unified diff format @samp{diff -u}. + +@item Return errors. +No reason whatsoever should abort the execution of the library. Even +memory allocation errors, e.g. when malloc return NULL, should work +although result in an error code. + +@item Design with thread safety in mind. +Don't use global variables. Don't even write to per-handle global +variables unless the documented behaviour of the function you write is +to write to the per-handle global variable. + +@item Avoid using the C math library. +It causes problems for embedded implementations, and in most +situations it is very easy to avoid using it. + +@item Document your functions. +Use comments before each function headers, that, if properly +formatted, are extracted into Texinfo manuals and GTK-DOC web pages. + +@item Supply a ChangeLog and NEWS entries, where appropriate. + +@end itemize + +@node Certification +@section Certification +@cindex certification + +There are certifications from national or international bodies which "prove" +to an auditor that the crypto component follows some best practices, such +as unit testing and reliance on well known crypto primitives. + +GnuTLS has support for the FIPS 140-2 certification under Red Hat Enterprise Linux. +See @ref{FIPS140-2 mode} for more information. |