Karl Eichwalder &lt;ke(a)gnu.franken.de&gt; writes: FYI: This annoying bug is still visible :-( -- | ,__o | _-\_<, http://www.gnu.franken.de/ke/ | (*)/'(*)

On Sun, 25 Jul 2004, Jens Frank wrote: Using firefox 0.9 as an anonymous user I don't see any of those <p><br /></p> in the page source. Is this some kind of mozilla bug? Alfio

On Wed, Jul 14, 2004 at 10:58:20PM +0200, Emmanuel Engelhart wrote: If article [[X]] includes [[Template:A]] which includes [[Template:B]], which again includes [[Template:A]], this would result in a memory bomb using only two different templates. Caching templates is a good idea when keeping track of the used memory. Before we do so, the number of templates used must currently be restricted to avoid endless loops. Regards, JeLuF

On Wed, Jul 14, 2004 at 05:53:41PM -0400, Bill Clark wrote: Emmanuel and I have tested it: It is vulnerable to this approach. Regards, JeLuF

Bill Clark wrote: That's what we already do. MAX_INCLUDE_REPEAT is a maximum for inclusions of a given template, there's no limit on the number of different templates included. So if A included B and B included A, you'd get 5 copies of each: A->B->A->B->A->B->A->B->A->B->link to A. This is unacceptable because people want to use templates for things which are included many times in a single page, like superscript "Le" on fr, or fancy bullet points. -- Tim Starling

On Thu, 15 Jul 2004 15:50:53 +1000, Tim Starling &lt;ts4294967296(a)hotmail.com&gt; wrote: How about a MAX_INCLUDE_DEPTH then, instead? -Bill Clark

On Thu, 15 Jul 2004 16:11:16 +1000, Tim Starling &lt;ts4294967296(a)hotmail.com&gt; wrote: Hmm.. the problem would seem insurmountable then (barring some sort of checking on the size of includes, which seems like more trouble than its worth). Oh well. -Bill Clark

On Thu, 15 Jul 2004 16:50:12 +1000, Tim Starling &lt;ts4294967296(a)hotmail.com&gt; wrote: When I read Emmanuel's first post, I thought MAX_INCLUDE_REPEAT limit was set solely in order to prevent infinite loops in inclusions. Then you informed me that it was also intended to prevent attacks based on including a large number of large files (or more accurately, including a limited number of large files multiple times). I didn't see any way to prevent that kind of attack without either: 1) Checking the size before inclusion. 2) Limiting the number of inclusions (or at least making it more difficult by limiting the number of times the same file can be included, thus forcing attackers to create multiple large templates, which is easier to track and/or prevent). I didn't think (1) was feasible (but see below) so that meant we're stuck with (2), which also prevents the inclusion of a large number of small files (such as the fancy bullets you mentioned). That's why I thought the problem was insurmountable; it seemed to be intrinsically tied to the number of repeated includes. Block repeated includes for large files, and you also have to block them for small files. Maybe the type of approach in (1) isn't as bad as I thought though, since we could just keep a running total of how much data has been included, and block further inclusions once a limit has been reached. MAX_CUMULATIVE_INCLUDE_SIZE? Actually, that might not be a half bad idea, since it would solve the infinite inclusion problem as well (though MAX_INCLUDE_DEPTH might still be a better way to handle that problem, since it might take too long for small looping templates to build up to the size limit). -Bill Clark

Selon Bill Clark &lt;wclarkxoom(a)gmail.com&gt;om>: I'm coding a patch in this way, which prevents the inclusion of more than MAX_TEMPLATE_INCLUSION_CHAR. My opinion, is simply to prevent endless recursive templates (by storing the recursion path). With, what I already code, the template parsing should be faster, and with less painful limitations. Emmanuel Engelhart