[jira] [Commented] (LOG4J2-2077) Update from Jackson 2.9.1 to 2.9.2
[ https://issues.apache.org/jira/browse/LOG4J2-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239939#comment-16239939 ] ASF subversion and git services commented on LOG4J2-2077: - Commit 14165e2980dd0979ac85a9b11aecd5de87829eb7 in logging-log4j2's branch refs/heads/master from [~garydgregory] [ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=14165e2 ] [LOG4J2-2077] Update from Jackson 2.9.1 to 2.9.2. > Update from Jackson 2.9.1 to 2.9.2 > -- > > Key: LOG4J2-2077 > URL: https://issues.apache.org/jira/browse/LOG4J2-2077 > Project: Log4j 2 > Issue Type: Improvement > Components: Core >Affects Versions: 2.9.1 >Reporter: Gary Gregory >Assignee: Gary Gregory > > Update from Jackson 2.9.1 to 2.9.2. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (LOG4J2-2100) LevelMixIn class for Jackson is coded incorrectly
[
https://issues.apache.org/jira/browse/LOG4J2-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed LOG4J2-2100.
Resolution: Fixed
Fix Version/s: 2.10.0
Fixed in git master.
> LevelMixIn class for Jackson is coded incorrectly
> -
>
> Key: LOG4J2-2100
> URL: https://issues.apache.org/jira/browse/LOG4J2-2100
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.9.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.10.0
>
>
> While it works, the {{LevelMixIn}} class for Jackson is coded incorrectly and
> a problem shows up as
> https://github.com/FasterXML/jackson-databind/issues/1809 if you updated
> Jackson from 2.9.1 to 2.9.2. While I would argue this is a regression in
> Jackson, Jackson contributor think it was lucky this worked at all.
> This ticket will apply changes suggested by Jackson and a separate ticket
> will update to Jackson 2.9.2.
> See also my original report to Jackson here
> https://github.com/FasterXML/jackson-databind/issues/1795
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-2100) LevelMixIn class for Jackson is coded incorrectly
[
https://issues.apache.org/jira/browse/LOG4J2-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239884#comment-16239884
]
ASF subversion and git services commented on LOG4J2-2100:
-
Commit bfb7a3d83922cb2be23acef76e6aefaa074aa6d4 in logging-log4j2's branch
refs/heads/master from [~garydgregory]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=bfb7a3d ]
[LOG4J2-2100] LevelMixIn class for Jackson is coded incorrectly.
> LevelMixIn class for Jackson is coded incorrectly
> -
>
> Key: LOG4J2-2100
> URL: https://issues.apache.org/jira/browse/LOG4J2-2100
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.9.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> While it works, the {{LevelMixIn}} class for Jackson is coded incorrectly and
> a problem shows up as
> https://github.com/FasterXML/jackson-databind/issues/1809 if you updated
> Jackson from 2.9.1 to 2.9.2. While I would argue this is a regression in
> Jackson, Jackson contributor think it was lucky this worked at all.
> This ticket will apply changes suggested by Jackson and a separate ticket
> will update to Jackson 2.9.2.
> See also my original report to Jackson here
> https://github.com/FasterXML/jackson-databind/issues/1795
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (LOG4J2-2100) LevelMixIn class for Jackson is coded incorrectly
[
https://issues.apache.org/jira/browse/LOG4J2-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-2100:
-
Description:
While it works, the {{LevelMixIn}} class for Jackson is coded incorrectly and a
problem shows up as https://github.com/FasterXML/jackson-databind/issues/1809
if you updated Jackson from 2.9.1 to 2.9.2. While I would argue this is a
regression in Jackson, Jackson contributor think it was lucky this worked at
all.
This ticket will apply changes suggested by Jackson and a separate ticket will
update to Jackson 2.9.2.
See also my original report to Jackson here
https://github.com/FasterXML/jackson-databind/issues/1795
was:
While it works, the {{LevelMixIn}} class for Jackson is coded incorrectly and a
problem shows up as https://github.com/FasterXML/jackson-databind/issues/1809
if you updated Jackson from 2.9.1 to 2.9.2. While I would argue this is a
regression in Jackson, Jackson contributor think it was lucky this worked at
all.
This ticket will apply changes suggested by Jackson and a separate ticket will
update to Jackson 2.9.2.
> LevelMixIn class for Jackson is coded incorrectly
> -
>
> Key: LOG4J2-2100
> URL: https://issues.apache.org/jira/browse/LOG4J2-2100
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.9.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> While it works, the {{LevelMixIn}} class for Jackson is coded incorrectly and
> a problem shows up as
> https://github.com/FasterXML/jackson-databind/issues/1809 if you updated
> Jackson from 2.9.1 to 2.9.2. While I would argue this is a regression in
> Jackson, Jackson contributor think it was lucky this worked at all.
> This ticket will apply changes suggested by Jackson and a separate ticket
> will update to Jackson 2.9.2.
> See also my original report to Jackson here
> https://github.com/FasterXML/jackson-databind/issues/1795
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (LOG4J2-2100) LevelMixIn class for Jackson is coded incorrectly
[
https://issues.apache.org/jira/browse/LOG4J2-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-2100:
-
Description:
While it works, the {{LevelMixIn}} class for Jackson is coded incorrectly and a
problem shows up as https://github.com/FasterXML/jackson-databind/issues/1809
if you updated Jackson from 2.9.1 to 2.9.2. While I would argue this is a
regression in Jackson, Jackson contributor think it was lucky this worked at
all.
This ticket will apply changes suggested by Jackson and a separate ticket will
update to Jackson 2.9.2.
was:
While it works, LevelMixIn class for Jackson is coded incorrectly and a problem
shows up as https://github.com/FasterXML/jackson-databind/issues/1809 if you
updated Jackson from 2.9.1 to 2.9.2. While I would argue this is a regression
in Jackson, Jackson contributor think it was lucky this worked at all.
This ticket will apply changes suggested by Jackson and a separate ticket will
update to Jackson 2.9.2.
> LevelMixIn class for Jackson is coded incorrectly
> -
>
> Key: LOG4J2-2100
> URL: https://issues.apache.org/jira/browse/LOG4J2-2100
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.9.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> While it works, the {{LevelMixIn}} class for Jackson is coded incorrectly and
> a problem shows up as
> https://github.com/FasterXML/jackson-databind/issues/1809 if you updated
> Jackson from 2.9.1 to 2.9.2. While I would argue this is a regression in
> Jackson, Jackson contributor think it was lucky this worked at all.
> This ticket will apply changes suggested by Jackson and a separate ticket
> will update to Jackson 2.9.2.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (LOG4J2-2100) LevelMixIn class for Jackson is coded incorrectly
Gary Gregory created LOG4J2-2100: Summary: LevelMixIn class for Jackson is coded incorrectly Key: LOG4J2-2100 URL: https://issues.apache.org/jira/browse/LOG4J2-2100 Project: Log4j 2 Issue Type: Bug Components: Core Affects Versions: 2.9.1 Reporter: Gary Gregory Assignee: Gary Gregory While it works, LevelMixIn class for Jackson is coded incorrectly and a problem shows up as https://github.com/FasterXML/jackson-databind/issues/1809 if you updated Jackson from 2.9.1 to 2.9.2. While I would argue this is a regression in Jackson, Jackson contributor think it was lucky this worked at all. This ticket will apply changes suggested by Jackson and a separate ticket will update to Jackson 2.9.2. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] logging-log4j2 pull request #123: Modify MapMessage constructor
GitHub user JackLee1993 opened a pull request: https://github.com/apache/logging-log4j2/pull/123 Modify MapMessage constructor The MapMessage constructor is not unified. the 'this' should be add You can merge this pull request into a Git repository by running: $ git pull https://github.com/JackLee1993/logging-log4j2 req Alternatively you can review and apply these changes as the patch at: https://github.com/apache/logging-log4j2/pull/123.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #123 commit 799d20ad91a4df187ab4cb25da7b16a188fb319c Author: liyao01 Date: 2017-11-06T02:38:45Z Modify MapMessage constructor ---
[jira] [Commented] (LOG4J2-1203) Allow filtering of line breaks in layout pattern
[
https://issues.apache.org/jira/browse/LOG4J2-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239576#comment-16239576
]
Mikael Ståldal commented on LOG4J2-1203:
However, I would say that to be really safe against injection attacks, I would
recommend using JsonLayout or GelfLayout.
> Allow filtering of line breaks in layout pattern
>
>
> Key: LOG4J2-1203
> URL: https://issues.apache.org/jira/browse/LOG4J2-1203
> Project: Log4j 2
> Issue Type: New Feature
> Components: Pattern Converters
>Affects Versions: 2.4.1
>Reporter: Mitth'raw'nuruodo
>Assignee: Mikael Ståldal
>Priority: Minor
> Fix For: 2.10.0
>
> Attachments:
> 0001-LOG4J2-1203-Added-Pattern-encoding-for-CRLF-only.patch
>
>
> Unless specific steps are taken to filter log inputs, there may be a risk of
> CRLF injection, allowing an attacker to forge log entries:
> https://cwe.mitre.org/data/definitions/93.html
> This is not a critical vulnerability, but manually
> escaping/encoding/sanitising every instance of logging in a large application
> is impractical. Most applications have no need to output un-filtered line
> breaks, so they would benefit from a global option.
> Could the list of pattern converters be extended to include a modifier to say
> that whitespace should be normalised (as per Commons Lang
> {{StringUtils.normaliseSpace}})? Eg {{%_m}}
> Alternatively, it would be simple to implement a wrapper that would apply
> normalisation to the output of another layout, but it would be more difficult
> to configure such a wrapper in XML, and it would affect the entire log
> output, effectively obliterating all padding modifiers.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (LOG4J2-1203) Allow filtering of line breaks in layout pattern
[
https://issues.apache.org/jira/browse/LOG4J2-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal resolved LOG4J2-1203.
Resolution: Fixed
Fix Version/s: (was: 2.0-rc2)
2.10.0
In Git master, please verify and close.
> Allow filtering of line breaks in layout pattern
>
>
> Key: LOG4J2-1203
> URL: https://issues.apache.org/jira/browse/LOG4J2-1203
> Project: Log4j 2
> Issue Type: New Feature
> Components: Pattern Converters
>Affects Versions: 2.4.1
>Reporter: Mitth'raw'nuruodo
>Assignee: Mikael Ståldal
>Priority: Minor
> Fix For: 2.10.0
>
> Attachments:
> 0001-LOG4J2-1203-Added-Pattern-encoding-for-CRLF-only.patch
>
>
> Unless specific steps are taken to filter log inputs, there may be a risk of
> CRLF injection, allowing an attacker to forge log entries:
> https://cwe.mitre.org/data/definitions/93.html
> This is not a critical vulnerability, but manually
> escaping/encoding/sanitising every instance of logging in a large application
> is impractical. Most applications have no need to output un-filtered line
> breaks, so they would benefit from a global option.
> Could the list of pattern converters be extended to include a modifier to say
> that whitespace should be normalised (as per Commons Lang
> {{StringUtils.normaliseSpace}})? Eg {{%_m}}
> Alternatively, it would be simple to implement a wrapper that would apply
> normalisation to the output of another layout, but it would be more difficult
> to configure such a wrapper in XML, and it would affect the entire log
> output, effectively obliterating all padding modifiers.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-1203) Allow filtering of line breaks in layout pattern
[
https://issues.apache.org/jira/browse/LOG4J2-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239573#comment-16239573
]
ASF subversion and git services commented on LOG4J2-1203:
-
Commit 6b41f589781e8cdcaee0fac72ff4b75f538d89a6 in logging-log4j2's branch
refs/heads/master from [~rtur...@e-djuster.com]
[ https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;h=6b41f58 ]
LOG4J2-1203 Added Pattern encoding for CRLF only
Added a Pattern encoding format limited to just CRLF for use cases
where you do not want full HTML or JSON encoding, but do want to
protected against CR and/or LF injection attacks in logs.
> Allow filtering of line breaks in layout pattern
>
>
> Key: LOG4J2-1203
> URL: https://issues.apache.org/jira/browse/LOG4J2-1203
> Project: Log4j 2
> Issue Type: New Feature
> Components: Pattern Converters
>Affects Versions: 2.4.1
>Reporter: Mitth'raw'nuruodo
>Assignee: Mikael Ståldal
>Priority: Minor
> Fix For: 2.0-rc2
>
> Attachments:
> 0001-LOG4J2-1203-Added-Pattern-encoding-for-CRLF-only.patch
>
>
> Unless specific steps are taken to filter log inputs, there may be a risk of
> CRLF injection, allowing an attacker to forge log entries:
> https://cwe.mitre.org/data/definitions/93.html
> This is not a critical vulnerability, but manually
> escaping/encoding/sanitising every instance of logging in a large application
> is impractical. Most applications have no need to output un-filtered line
> breaks, so they would benefit from a global option.
> Could the list of pattern converters be extended to include a modifier to say
> that whitespace should be normalised (as per Commons Lang
> {{StringUtils.normaliseSpace}})? Eg {{%_m}}
> Alternatively, it would be simple to implement a wrapper that would apply
> normalisation to the output of another layout, but it would be more difficult
> to configure such a wrapper in XML, and it would affect the entire log
> output, effectively obliterating all padding modifiers.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LOG4J2-1203) Allow filtering of line breaks in layout pattern
[
https://issues.apache.org/jira/browse/LOG4J2-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16239574#comment-16239574
]
ASF GitHub Bot commented on LOG4J2-1203:
Github user asfgit closed the pull request at:
https://github.com/apache/logging-log4j2/pull/122
> Allow filtering of line breaks in layout pattern
>
>
> Key: LOG4J2-1203
> URL: https://issues.apache.org/jira/browse/LOG4J2-1203
> Project: Log4j 2
> Issue Type: New Feature
> Components: Pattern Converters
>Affects Versions: 2.4.1
>Reporter: Mitth'raw'nuruodo
>Assignee: Mikael Ståldal
>Priority: Minor
> Fix For: 2.0-rc2
>
> Attachments:
> 0001-LOG4J2-1203-Added-Pattern-encoding-for-CRLF-only.patch
>
>
> Unless specific steps are taken to filter log inputs, there may be a risk of
> CRLF injection, allowing an attacker to forge log entries:
> https://cwe.mitre.org/data/definitions/93.html
> This is not a critical vulnerability, but manually
> escaping/encoding/sanitising every instance of logging in a large application
> is impractical. Most applications have no need to output un-filtered line
> breaks, so they would benefit from a global option.
> Could the list of pattern converters be extended to include a modifier to say
> that whitespace should be normalised (as per Commons Lang
> {{StringUtils.normaliseSpace}})? Eg {{%_m}}
> Alternatively, it would be simple to implement a wrapper that would apply
> normalisation to the output of another layout, but it would be more difficult
> to configure such a wrapper in XML, and it would affect the entire log
> output, effectively obliterating all padding modifiers.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] logging-log4j2 pull request #122: LOG4J2-1203 Added Pattern encoding for CRL...
Github user asfgit closed the pull request at: https://github.com/apache/logging-log4j2/pull/122 ---
[jira] [Work started] (LOG4J2-1203) Allow filtering of line breaks in layout pattern
[
https://issues.apache.org/jira/browse/LOG4J2-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on LOG4J2-1203 started by Mikael Ståldal.
--
> Allow filtering of line breaks in layout pattern
>
>
> Key: LOG4J2-1203
> URL: https://issues.apache.org/jira/browse/LOG4J2-1203
> Project: Log4j 2
> Issue Type: New Feature
> Components: Pattern Converters
>Affects Versions: 2.4.1
>Reporter: Mitth'raw'nuruodo
>Assignee: Mikael Ståldal
>Priority: Minor
> Fix For: 2.0-rc2
>
> Attachments:
> 0001-LOG4J2-1203-Added-Pattern-encoding-for-CRLF-only.patch
>
>
> Unless specific steps are taken to filter log inputs, there may be a risk of
> CRLF injection, allowing an attacker to forge log entries:
> https://cwe.mitre.org/data/definitions/93.html
> This is not a critical vulnerability, but manually
> escaping/encoding/sanitising every instance of logging in a large application
> is impractical. Most applications have no need to output un-filtered line
> breaks, so they would benefit from a global option.
> Could the list of pattern converters be extended to include a modifier to say
> that whitespace should be normalised (as per Commons Lang
> {{StringUtils.normaliseSpace}})? Eg {{%_m}}
> Alternatively, it would be simple to implement a wrapper that would apply
> normalisation to the output of another layout, but it would be more difficult
> to configure such a wrapper in XML, and it would affect the entire log
> output, effectively obliterating all padding modifiers.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (LOG4J2-1203) Allow filtering of line breaks in layout pattern
[
https://issues.apache.org/jira/browse/LOG4J2-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikael Ståldal reopened LOG4J2-1203:
Assignee: Mikael Ståldal
> Allow filtering of line breaks in layout pattern
>
>
> Key: LOG4J2-1203
> URL: https://issues.apache.org/jira/browse/LOG4J2-1203
> Project: Log4j 2
> Issue Type: New Feature
> Components: Pattern Converters
>Affects Versions: 2.4.1
>Reporter: Mitth'raw'nuruodo
>Assignee: Mikael Ståldal
>Priority: Minor
> Fix For: 2.0-rc2
>
> Attachments:
> 0001-LOG4J2-1203-Added-Pattern-encoding-for-CRLF-only.patch
>
>
> Unless specific steps are taken to filter log inputs, there may be a risk of
> CRLF injection, allowing an attacker to forge log entries:
> https://cwe.mitre.org/data/definitions/93.html
> This is not a critical vulnerability, but manually
> escaping/encoding/sanitising every instance of logging in a large application
> is impractical. Most applications have no need to output un-filtered line
> breaks, so they would benefit from a global option.
> Could the list of pattern converters be extended to include a modifier to say
> that whitespace should be normalised (as per Commons Lang
> {{StringUtils.normaliseSpace}})? Eg {{%_m}}
> Alternatively, it would be simple to implement a wrapper that would apply
> normalisation to the output of another layout, but it would be more difficult
> to configure such a wrapper in XML, and it would affect the entire log
> output, effectively obliterating all padding modifiers.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] logging-log4j2 issue #121: (doc) Remove wrong xml tag ""
Github user mikaelstaldal commented on the issue: https://github.com/apache/logging-log4j2/pull/121 @dr0i I would suggest you post to the [log4j-user mailing list](http://logging.apache.org/log4j/2.x/mail-lists.html) for support. Do you have a configuration with a Log4j1XmlLayout in it? If so you need to have log4j-1.2-api on your classpath, since that layout is there (not in log4j-core as most other layouts). ---
