This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/logging-site.git
The following commit(s) were added to refs/heads/asf-staging by this push:
new feca7006 Automatic Site Publish by Buildbot
feca7006 is described below
commit feca70069f6fdb34f1fa99652cb986e85bf9a032
Author: buildbot <[email protected]>
AuthorDate: Wed Aug 28 08:39:28 2024 +0000
Automatic Site Publish by Buildbot
---
content/feed.xml | 2 +-
content/security.html | 58 +++++++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/content/feed.xml b/content/feed.xml
index e1663f0c..092c52f5 100644
--- a/content/feed.xml
+++ b/content/feed.xml
@@ -1,4 +1,4 @@
-<?xml version="1.0" encoding="utf-8"?><feed
xmlns="http://www.w3.org/2005/Atom"; ><generator uri="https://jekyllrb.com/";
version="4.2.2">Jekyll</generator><link href="/feed.xml" rel="self"
type="application/atom+xml" /><link href="/" rel="alternate" type="text/html"
/><updated>2024-08-12T20:58:31+00:00</updated><id>/feed.xml</id><title
type="html">Apache Software Foundation - Logging
Services</title><subtitle>Write an awesome description for your new site here.
You can edit this line in _ [...]
+<?xml version="1.0" encoding="utf-8"?><feed
xmlns="http://www.w3.org/2005/Atom"; ><generator uri="https://jekyllrb.com/";
version="4.2.2">Jekyll</generator><link href="/feed.xml" rel="self"
type="application/atom+xml" /><link href="/" rel="alternate" type="text/html"
/><updated>2024-08-28T08:39:26+00:00</updated><id>/feed.xml</id><title
type="html">Apache Software Foundation - Logging
Services</title><subtitle>Write an awesome description for your new site here.
You can edit this line in _ [...]
<p>We were proud to be <a
href="/blog/2023/12/14/announcing-support-from-the-stf.html">supported by the
STF</a> last year.
This support helped us to fix many bugs, rewrite documentation, and improve
the overall quality of the codebase and security.</p>
diff --git a/content/security.html b/content/security.html
index f376a179..f8195924 100644
--- a/content/security.html
+++ b/content/security.html
@@ -154,8 +154,11 @@ Thus, GPG signatures should be validated in your build
process.</p>
<p>All configuration sources to an application must be trusted by the
programmer.
When loading a configuration file from disk (especially when a monitor
interval is configured to reload the file periodically), the location of the
configuration file must be kept safe from unauthorized modifications.
Similarly, when loading a configuration file over the network such as through
HTTP, this should be configured to use TLS or a secure connection in general
with strong authentication guarantees.
-This remote location must be kept safe from unauthorized modifications.
-When configurations are modified through JMX, the JMX server should be safely
configured to require authentication and a secure connection if being accessed
over the network.
+This remote location must be kept safe from unauthorized modifications.</p>
+</div>
+<div class="paragraph">
+<p>For Java-based projects supporting JNDI or JMX,
+when configurations are modified through JMX, the JMX server should be safely
configured to require authentication and a secure connection if being accessed
over the network.
When configurations are provided through JNDI, these should only use the
<code>java</code> scheme for sharing configurations in a Java EE or Jakarta EE
application service.
JNDI-sourced configurations should not use other JNDI providers such as LDAP,
DNS, or RMI, as all these providers are difficult to properly secure.</p>
</div>
@@ -240,6 +243,57 @@ The simplest way to avoid this problem is to never combine
compression with encr
</div>
</div>
</div>
+<div class="sect2">
+<h3 id="threat-log4net">Log4Net threat model</h3>
+<div class="paragraph">
+<p>Below we share the threat model specific to <a
href="/log4net">log4net</a>.</p>
+</div>
+<div class="sect3">
+<h4 id="threat-log4net-parametrized-logging">Parameterized logging</h4>
+<div class="paragraph">
+<p>When using a log message containing template parameters like
<code>{0}</code>, only the format string is evaluated for parameters to be
substituted.
+The message parameters themselves are not evaluated for parameters; they are
only included in the format string corresponding to their template position.
+The conversion of message parameters into a string is done on-demand depending
on the layout being used.
+When structure-preserving transformations of log data are required, a
structured layout (e.g., <code>XmlLayout</code>) should be used.
+Format strings should be compile-time constants, and under no circumstances
should format strings be built using user-controlled input data.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="threat-log4net-unstructured-logging">Unstructured logging</h4>
+<div class="paragraph">
+<p>When using an unstructured layout such as <code>PatternLayout</code>, no
guarantees can be made about the output format.
+This layout is mainly useful for development purposes and should not be relied
on in production applications.
+For example, if a log message contains new lines, these are not escaped or
encoded.
+As such, when using unstructured layouts, no user-controlled input should be
included in logs.
+It is strongly recommended that a structured layout (e.g.,
<code>XmlLayout</code>) is used instead for these situations.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="threat-log4net-structured-logging">Structured logging</h4>
+<div class="paragraph">
+<p>When using a structured layout (most layouts besides pattern layout), log
messages are encoded according to various output formats.
+These safely encode the various fields included in a log message.
+For example, the <code>XmlLayout</code> can be used to output log messages in
an XML structure where all log data is properly encoded into safely parseable
XML.
+This is the recommended mode of operation for use with log parsing and log
collection tools that rely on log files or arbitrary output streams.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="threat-log4net-log-masking">Log masking</h4>
+<div class="paragraph">
+<p>Log4Net, like any other generic logging library, cannot generically support
log masking of sensitive data.
+While custom plugins may be developed to attempt to mask various regular
expressions (such as a string that looks like a credit card number), the
general problem of log masking is equivalent to the halting problem in computer
science where sensitive data can always be obfuscated in such a way as to avoid
detection by log masking.
+As such, it is the responsibility of the developer to properly demarcate
sensitive data such that it can be consistently masked by log masking
plugins.</p>
+</div>
+</div>
+<div class="sect3">
+<h4 id="threat-log4net-availability">Availability</h4>
+<div class="paragraph">
+<p>Log4Net goes to great lengths to minimize performance overhead along with
options for minimizing latency or maximizing throughput.
+However, we cannot guarantee availability of the application if the appenders
cannot keep up with the logs being written.
+Logging can cause applications to block and wait for a log message to be
written.</p>
+</div>
+</div>
+</div>
</div>
</div>
<div class="sect1">
