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
 * 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.
 
   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.
 
 * 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
 
 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
 
 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.
 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 
 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.
 
 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
 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 ==
 
 
 == Secrecy ==