[Openvas-commits] r11934 - trunk/doc/website

[scm-commit@wald.intevation.org]

Author: mwiegand
Date: 2011-11-02 10:24:34 +0100 (Wed, 02 Nov 2011)
New Revision: 11934

Modified:
   trunk/doc/website/openvas-cr-56.htm4
   trunk/doc/website/openvas-cr-57.htm4
   trunk/doc/website/openvas-cr-58.htm4
   trunk/doc/website/openvas-cr-59.htm4
Log:
Fix small typos in recent change requests.


Modified: trunk/doc/website/openvas-cr-56.htm4
===================================================================
--- trunk/doc/website/openvas-cr-56.htm4	2011-11-02 07:14:57 UTC (rev 11933)
+++ trunk/doc/website/openvas-cr-56.htm4	2011-11-02 09:24:34 UTC (rev 11934)
@@ -64,7 +64,7 @@
          though agreed already.
 </li> </p>
 
-<li> <p> Add creation and last modfication timestamps as meta information:
+<li> <p> Add creation and last modification timestamps as meta information:
          Several users asked for this to better judge how old the test
          routine is. This is analog to for example the CVE information
          where both timestamps are always available.
@@ -121,7 +121,7 @@
 Therefore the script files need to be prepared for this for SVN
 and the script_version() command in the NVTs must be present and
 contain the correct "Revision" SVN tag. Henri Doreau already started
-to fix various scritps. This activity can be continued in conjunction
+to fix various scripts. This activity can be continued in conjunction
 with the other changes.
 </p>
 
@@ -135,7 +135,7 @@
 is better to stick with the rule that the OpenVAS NVT feed started at
 a specific date. Thomas Reinke offered some information from his own repository
 about the creation timestamps. However, it is to be decided whether to
-undertake the efford to merge the timestamp or whether to simply use what
+undertake the effort to merge the timestamp or whether to simply use what
 SVN offers (consistently).
 </p>
 

Modified: trunk/doc/website/openvas-cr-57.htm4
===================================================================
--- trunk/doc/website/openvas-cr-57.htm4	2011-11-02 07:14:57 UTC (rev 11933)
+++ trunk/doc/website/openvas-cr-57.htm4	2011-11-02 09:24:34 UTC (rev 11934)
@@ -57,7 +57,7 @@
 
 <ul>
 
-<li> <p> Have a separation beween service detection (protocols) and actual products
+<li> <p> Have a separation between service detection (protocols) and actual products
          so that ultimately developers have a precise guide and examples how
          to write new ones, where to find existing ones and how to use the product
          detections for actual vulnerability assessment.
@@ -67,7 +67,7 @@
          of a product should not raise an alarm. Thus reports should contain less noise.
 </li> </p>
 
-<li> <p> Inform the user always how a vulnerability test aquired the product information.
+<li> <p> Inform the user always how a vulnerability test acquired the product information.
          It is often relevant whether it was a remote banner or a direct package version detection.
 </li> </p>
 
@@ -124,7 +124,7 @@
 </ul>
 
 <p>
-One intention of the detection method is a ranking of reliability. A direct package vesion is more realiable
+One intention of the detection method is a ranking of reliability. A direct package version is more reliable
 than the associated banner (typical e.g. for Debian where the patches are applied, but not the version indications).
 Having them as a tag will allow users to search on categories in the NVT database more easily than it would
 be the case if detection method would only be mentioned in description text.

Modified: trunk/doc/website/openvas-cr-58.htm4
===================================================================
--- trunk/doc/website/openvas-cr-58.htm4	2011-11-02 07:14:57 UTC (rev 11933)
+++ trunk/doc/website/openvas-cr-58.htm4	2011-11-02 09:24:34 UTC (rev 11934)
@@ -53,7 +53,7 @@
 
 <p>
 Currently the risk categorisation is redundant. risk_factor derives from
-CVSS and thus would not be neccessary. However, dropping risk_factor is
+CVSS and thus would not be necessary. However, dropping risk_factor is
 only possible once all NVTs are associated with a CVSS.
 </p>
 

Modified: trunk/doc/website/openvas-cr-59.htm4
===================================================================
--- trunk/doc/website/openvas-cr-59.htm4	2011-11-02 07:14:57 UTC (rev 11933)
+++ trunk/doc/website/openvas-cr-59.htm4	2011-11-02 09:24:34 UTC (rev 11934)
@@ -46,7 +46,7 @@
 
 <p>
 Consolidation of messages sent by NVTs in order to
-simplify writing a NVT,  lower maintenance efford
+simplify writing a NVT, lower maintenance effort
 and avoid mistakes due to redundancies.
 </p>
 
@@ -102,7 +102,7 @@
 
 <p>
 It needs to be decided whether the Scanner will add the CVSS
-when a security_message is sent or wether it is entirely left
+when a security_message is sent or whether it is entirely left
 to the client (the Manager) and add the CVSS when receiving
 this message.
 </p>