Version bump for release.

[irker.git] / security.txt

diff --git a/security.txt b/security.txt
index 62bcee5bfafc75b3df28b4341e8dd6c9a8d258b3..4be95188d953d8416a1475f9094686cc221c0968 100644 (file)
--- a/security.txt
+++ b/security.txt
@@ -163,10 +163,6 @@ near resource limits.  An ordinary DoS attack would then be prevented
 from completely blocking all message traffic; the cost would be a
 whole lot of join/leave spam due to connection churn.
 
-We also use greenlets (Python coroutines imitating system threads)
-when they are available.  This reduces memory overhead due to
-threading substantially, making a thread-flooding DoS more dfficult.
-
 == Authentication/Integrity ==
 
 One way to help prevent DoS attacks would be in-band authentication -
@@ -184,18 +180,10 @@ 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.org>. 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
@@ -205,10 +193,11 @@ 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.
+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 ==
 
@@ -233,21 +222,6 @@ project.  The only other competitor to replace CIA known to us
 In the general case we cannot guarantee this property against
 groups A and F.
 
-== Why there is no support for passworded channels ==
-
-We've had support for password authentication to IRC requested, but it
-would be a rather bad fit for irkerd’s usage pattern. The problem
-isn’t that credentials would be difficult to pass to irkerd – an 
-optional password field wiuld ve easily enough added to the JSON. 
-
-No, the problem is that once irkerd were to acquire such a credential,
-it would have to do source-address IP checking to know (at a minimum)
-whether the source host of any given notification request is the same
-as one that has presented the password.
-
-It seems best not gong to go there; the potential for IRC access controls
-becoming leaky seems too high.
-
 == Risks relative to centralized services ==
 
 irker and irkerhook.py were written as a replacement for the