irkerd: Replace 'password' global with local Connection.password

[irker.git] / security.txt

diff --git a/security.txt b/security.txt
index 01b0132c01a4bf31fc82301078752f9990639d00..e217720979ea47b9a70d1e22255a9b96635842c3 100644 (file)
--- a/security.txt
+++ b/security.txt
@@ -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,14 +180,14 @@ 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.
 
 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
 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
+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.
 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.


@@ -196,10 +196,10 @@ 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
 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.
+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.

 
 === Future directions ===
 
 
 === Future directions ===