You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by pq...@apache.org on 2005/11/07 00:13:02 UTC
svn commit: r331159 - /apr/site/trunk/xdocs/security_report.xml
Author: pquerna
Date: Sun Nov 6 15:13:01 2005
New Revision: 331159
URL: http://svn.apache.org/viewcvs?rev=331159&view=rev
Log:
Add a basic security document, mostly copied from http://httpd.apache.org/security_report.html
Added:
apr/site/trunk/xdocs/security_report.xml
Added: apr/site/trunk/xdocs/security_report.xml
URL: http://svn.apache.org/viewcvs/apr/site/trunk/xdocs/security_report.xml?rev=331159&view=auto
==============================================================================
--- apr/site/trunk/xdocs/security_report.xml (added)
+++ apr/site/trunk/xdocs/security_report.xml Sun Nov 6 15:13:01 2005
@@ -0,0 +1,38 @@
+<?xml version="1.0"?>
+<document>
+ <properties>
+ <author email="dev@apr.apache.org">APR Developers</author>
+ <title>Reporting Security Problems with APR</title>
+ </properties>
+<body>
+
+<section id="reporting">
+<title>Reporting New Security Problems with APR</title>
+<p>The Apache Software Foundation takes a very active stance in eliminating
+security problems and denial of service attacks against the
+Apache Portable Runtime.</p>
+
+<p>We strongly encourage folks to report such problems to our private
+security mailing list first, before disclosing them in a public forum.</p>
+
+<p><strong>We cannot accept regular bug reports or other queries at
+this address, we ask that you use our <a
+href="http://issues.apache.org/bugzilla/enter_bug.cgi?product=APR">bugzilla
+page</a> for those. <font color="red">All mail sent to this
+address that does not relate to security problems in the APR source
+code will be ignored.</font></strong></p>
+
+<p>The mailing address is:
+<code>security@apache.org</code>
+</p>
+
+<p>Note that all networked servers are subject to denial of service
+attacks, and we cannot promise magic workarounds to generic problems
+(such as a client streaming lots of data to your server, or re-requesting
+the same URL repeatedly). In general our philosophy is to avoid any
+attacks which can cause the server to consume resources in a non-linear
+relationship to the size of inputs.</p>
+
+</section>
+</body>
+</document>