Properly \n-terminate each send.

[irker.git] / security.txt

diff --git a/security.txt b/security.txt
index 9a72dafc3c8ff8da766c218e766e7bde0b059b4a..2638a92f1995988a55a1e7c56e51950b2102023d 100644 (file)
--- a/security.txt
+++ b/security.txt
@@ -9,8 +9,9 @@ it derives from a code audit and report by Daniel Franke.
 We begin by stating some assumptions about how irker will be deployed,
 and articulating a set of security goals.
 
-Communication flow in an irker deployment will looks like this:
+Communication flow in an irker deployment will look like this:
 
+-----------------------------------------------------------------------------
              Committers
                  |
                  |
@@ -24,6 +25,7 @@ Communication flow in an irker deployment will looks like this:
                  |
                  |
              IRC servers
+-----------------------------------------------------------------------------
 
 Here are our assumptions:
 
@@ -87,11 +89,15 @@ Our security goals for irker can be enumerated as follows:
 == Control Issues ===
 
 We have audited the irker and irkerhook.py code for exploitable 
-vulnerabilities.  We have not found any in the code itself, but the
-fact that irkerhook.py relies on external binaries to mine data ought
-of its repository opens up a well-known set of vulnerabilities if a
-malicious user is able to insert binaries in a carelessly-set 
-execution path.  Normal precautions against this should be taken.
+vulnerabilities.  We have not found any in the code itself, and the
+use of Python gives us confidence in the absence of large classes of errors
+(such as buffer overruns) that afflict C programs.
+
+However, the fact that irkerhook.py relies on external binaries to
+mine data out of its repository opens up a well-known set of
+vulnerabilities if a malicious user is able to insert binaries in a
+carelessly-set execution path.  Normal precautions against this should
+be taken.
 
 == Availability ==
 
@@ -157,7 +163,7 @@ 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.
 
-= Authentication/Integrity =
+== Authentication/Integrity ==
 
 One way to help prevent DoS attacks would be in-band authentication -
 requiring irkerd submitters to present a credential along with each
@@ -186,6 +192,15 @@ 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
@@ -226,8 +241,8 @@ The principal advantages of CIA from a security point of view were (a)
 it provided a single point at which spam filtering and source blocking
 could be done with benefit to all projects using the service, and (b)
 since it had to have a database anyway for routing messages to project
-channels, the incremental overhead for an authentication feature will
-be relatively low.
+channels, the incremental overhead for an authentication feature would
+have been relatively low.
 
 As a matter of fact rather than theory CIA never fully exploited
 either possibility.  Anyone could create a CIA project entry with