Version bump for release.

[irker.git] / security.txt

diff --git a/security.txt b/security.txt
index 2638a92f1995988a55a1e7c56e51950b2102023d..4be95188d953d8416a1475f9094686cc221c0968 100644 (file)
--- a/security.txt
+++ b/security.txt
@@ -71,7 +71,7 @@ Our security goals for irker can be enumerated as follows:
 * Availability: Only group A should be able to to deny or degrade
   irkerd's ability to receive commit messages and relay them to the
   IRC server. We recognize and accept as inevitable that MITMs (groups
-  4 and 5) can do this too (by ARP spoofing, cable-cutting, etc.).
+  E and F) can do this too (by ARP spoofing, cable-cutting, etc.).
   But, in particular, we would like irker-mediated services to be
   resilient against DoS (denial of service) attacks.
 
@@ -86,7 +86,7 @@ Our security goals for irker can be enumerated as follows:
 * Auditability: If people abuse irkerd, we want to be able to identify
   the abusive account or IP address.
 
-== Control Issues ===
+== Control Issues ==
 
 We have audited the irker and irkerhook.py code for exploitable 
 vulnerabilities.  We have not found any in the code itself, and the
@@ -144,7 +144,7 @@ ineffective - just sets a target for the DoS attack.
 
 3. Limit the number of requests that can be queued by source IP address.
 This might be worth doing; it would stymie a single-source DoS attack through
-a publicly-exposed irkerd, though not a DDoS by a bitnet.  But there isn't
+a publicly-exposed irkerd, though not a DDoS by a botnet.  But there isn't
 a lot of win here for a properly installed irker (e.g. behind a firewall), 
 which is typically going to get all its requests from a single repo host
 anyway.
@@ -180,31 +180,24 @@ for a godawful amount of code bloat.
 The deployment advice in the installation instructions assumes that 
 irkerd submitters are "authenticated" by being inside a firewall - that is,
 mesages are issued from an intranet and it can be trusted that anyone 
-issuing messages from within a given intrenet is authorized to do so.
+issuing messages from within a given intranet is authorized to do so.
 This fits the assumption that irker instances will run on forge sites
 receiving requests from instances of irkerhook.py.
 
-If this is *not* the case (e.g. the network between a hook and irkerd
-has to be considered hostile) we could hide irkerd behind an instance
-of spiped <http://www.tarsnap.com/spiped.html> or an instance of
-stunnel <http://www.stunnel.orgproxy>. These would be far superior to
-in-band authentication in that they would leave the job to specialist
-code not in any way coupled to irkerd's internals, minimizing
-global complexity and failure modes.
-
 One larger issue (not unique to irker) is that because of the
 insecured nature of IRC it is essentially impossible to secure
 #commits against commit notifications that are either garbled by
 software errors and misconfigurations or maliciously crafted to
-confuse anyone attempting to gather statistics from that.  The lesson
-here is that IRC monitoring isn't a good method for that purpose;
-going direct to the repositories via a toolkit such as Ohloh is
-a far better idea.
-
-=== Future directions ===
-
-There is presently no direct support for spipe or stunnel in
-irkerhook.py.  We'd take patches for this.
+confuse anyone attempting to gather statistics from that channel.  The
+lesson here is that IRC monitoring isn't a good method for that
+purpose; going direct to the repositories via a toolkit such as Ohloh
+is a far better idea.
+
+When this analysis was originally written, we recommended using spiped
+or stunnel to solve the problem of passing notifications from irkerd
+to IRC servers over a potentially hostile network that might interfere
+with them.  Later, SSL/TLS support proved easy to add and is now in
+irkerd itself.
 
 == Secrecy ==