updated addresses and URLs. Reported by Nico R.
[gnutls:gnutls.git] / 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), and in the case of algorithm verification of FIPS 140-2 it doesn't make much sense as the library is freely available and anyone can verify the correctness
172 of algorithm implementation. As such we are not actively pursuing this kind of certification. If you are, nevertheless, interested, see @ref{Commercial Support}.