date:20220120

Re: [logging-log4j2] 01/02: Add PropertiesLookup#getProperties().

2022-01-20 Thread Gary Gregory

Hi Carter,

I have several needs I am trying to satisfy. I have a lot of customizations
I have to support and implement in Log4j 1 and 2 (the Log4j 1 code is being
migrated to Log4j 2, but we still need to use the bridge to support Log4j 1
in 3rd party dependencies and transitive dependencies). We have new apps,
we have legacy apps, we have a lot of code. We do a lot of what I would
call in-flight manipulation of Log4j 1 and 2 in these apps, and some plain
old [re]configurations using the Configurator APIs, which are the easy use
cases to implement and support. Users (devs and admins really) can change
the Log4j configuration file and have Log4j monitor the file and that's
fine, but that's the advanced case because people can too easily muck up
these configuration files. Instead of mucking with files, these app servers
come up, stay up, and need to be configured and reconfigured through a set
of (REST) admin APIs. Some of these admin tasks do all sorts of
introspections and reconfigurations and that is where this kind of API
comes in. I want to be able to start from something like an Interpolator
(in all these code bases, we use the Log4j Interpolator, Commons Lang,
Common Text, you name it, it's in some code base somewhere), find this or
that StrLookup and returns pieces of it to client, so a UI can say "You're
got this config setting, would you like to change it?". Depending on the
use case, the app, and the server combo, sometimes changing a setting,
means the UI generates a new config file and sends it over, sometimes to
translates to calling a specific Configurator API like one of the
setLevel() APIs, and some other time we query and/or edit objects directly
in Log4j and elsewhere. Sorry for the long write up!

Gary

On Wed, Jan 19, 2022 at 6:32 PM Carter Kozak  wrote:

> Any chance you could help me understand the rationale for this feature? I
> opted not to implement a method akin to MapLookup.getMap because that
> wasn't used, avoiding unnecessary API constraints allows us to refactor
> more easily in the future. If the values are required elsewhere, it may be
> reasonable, but I have another change in flight that may impact such
> consumers.
>
> Thanks!
> -ck
>
> On Sat, Jan 15, 2022, at 18:45, ggreg...@apache.org wrote:
>
> This is an automated email from the ASF dual-hosted git repository.
>
> ggregory pushed a commit to branch release-2.x
> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
>
> commit d402f360fbad18bc3c0902a65e8e53a1202e57d5
> Author: Gary Gregory 
> AuthorDate: Sat Jan 15 18:45:37 2022 -0500
>
> Add PropertiesLookup#getProperties().
>
> Commit 1/2 for cherry-picking to master.
> ---
> .../logging/log4j/core/lookup/PropertiesLookup.java   | 19
> ---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
> index 995a71b..3066792 100644
> ---
> a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
> +++
> b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
> @@ -34,16 +34,28 @@ public final class PropertiesLookup implements
> StrLookup {
>   */
>  private final Map properties;
>
> +/**
> + * Constructs a new instance for the given map.
> + *
> + * @param properties map these.
> + */
>  public PropertiesLookup(final Map properties) {
>  this.properties = properties == null
>  ? Collections.emptyMap()
>  : properties;
>  }
>
> +/**
> + * Gets the property map.
> + *
> + * @return the property map.
> + */
> +public Map getProperties() {
> +return properties;
> +}
> +
>  @Override
> -public String lookup(
> -@SuppressWarnings("ignored") final LogEvent event,
> -final String key) {
> +public String lookup(@SuppressWarnings("ignored") final LogEvent
> event, final String key) {
>  return lookup(key);
>  }
>
> @@ -65,4 +77,5 @@ public final class PropertiesLookup implements StrLookup
> {
>  public String toString() {
>  return "PropertiesLookup{properties=" + properties + '}';
>  }
> +
> }
>
>
>

[GitHub] [logging-log4j1] lsimons commented on pull request #18: Refine build scripts

2022-01-20 Thread GitBox



lsimons commented on pull request #18:
URL: https://github.com/apache/logging-log4j1/pull/18#issuecomment-1017489683


   This PR should be closed.
   
   See https://github.com/apache/logging-log4j1/blob/main/README.md for 
rationale.
   
   See
   * https://reload4j.qos.ch/
   * https://github.com/qos-ch/reload4j
   for a maintained/released fork of similar improvements/fixes.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [logging-log4j1] lsimons commented on pull request #15: vulnerability for Version 1.x. CVE-2021-4104

2022-01-20 Thread GitBox



lsimons commented on pull request #15:
URL: https://github.com/apache/logging-log4j1/pull/15#issuecomment-1017490489


   This PR should be closed.
   
   See https://github.com/apache/logging-log4j1/blob/main/README.md for 
rationale.
   
   See
   * https://reload4j.qos.ch/
   * https://github.com/qos-ch/reload4j
   
   for a maintained/released fork with security fixes.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [logging-log4j1] lsimons commented on pull request #16: Cleaned-up log4j 1.2 that disables scary networking (trunk, binary-incompatible)

2022-01-20 Thread GitBox



lsimons commented on pull request #16:
URL: https://github.com/apache/logging-log4j1/pull/16#issuecomment-1017491119


   See
   * https://reload4j.qos.ch/
   * https://github.com/qos-ch/reload4j
   
   for a maintained/released fork with similar security fixes.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [logging-log4j1] lsimons commented on pull request #17: Cleaned-up log4j 1.2 that disables scary networking (base=1.2.17, fully binary compatible)

2022-01-20 Thread GitBox



lsimons commented on pull request #17:
URL: https://github.com/apache/logging-log4j1/pull/17#issuecomment-1017491386


   See
   * https://reload4j.qos.ch/
   * https://github.com/qos-ch/reload4j
   
   for a maintained/released fork with similar security fixes.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@logging.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Is log4j 2.12.4

2022-01-20 Thread anchit parmar

Dear Team,

 

Please confim if 2.12.4 is vuln to following CVE's

1)   
CVE-2021-45105

2)   
CVE-2021-45046

3)   
CVE-2021-44228

 

Also, 

As per https://endoflife.date/log4jlog4j version 2.12.x has reached its
EOL. The Log4j team no longer supports Java 7. 

 

Please confirm if above statement is true or not. 

 

 

Warm Regards,

Anchit Parmar

Team Lead - Vulnerability Management & Penetration Testing Practice

Information Security Department  

IDBI Intech Limited , IDBI Bank Building, Plot No. 39-41, Sector-11, 

CBD Belapur, Navi Mumbai - 400 614 .

Cell- 8779522843

 


Disclaimer: This e-mail contains privileged information or information 
belonging to IDBI Intech Ltd and is intended solely for the addressee/s. Access 
to this email by anyone else is unauthorized. Any copying (whole or partial) or 
further distribution beyond the original recipient is not intended, and may be 
unlawful. The recipient acknowledges that IDBI Intech Ltd is unable to exercise 
control or ensure or guarantee the integrity of the contents of the information 
contained in e-mail transmissions and further acknowledges that any views 
expressed in this message are those of the individual sender and are not 
binding on IDBI Intech Ltd. E-mails are susceptible to alteration and their 
integrity cannot be guaranteed. IDBI Intech Ltd does not accept any liability 
for any damages caused on account of this e-mail. If you have received this 
email in error, please contact the sender and delete the material from your 
computer.

Re: Is log4j 2.12.4

2022-01-20 Thread Ralph Goers

I believe I already answered this off-list.

Ralph

> On Jan 20, 2022, at 7:17 AM, anchit parmar 
>  wrote:
> 
> Dear Team,
> 
> 
> 
> Please confim if 2.12.4 is vuln to following CVE's
> 
> 1)   
> CVE-2021-45105
> 
> 2)   
> CVE-2021-45046
> 
> 3)   
> CVE-2021-44228
> 
> 
> 
> Also, 
> 
> As per https://endoflife.date/log4jlog4j version 2.12.x has reached its
> EOL. The Log4j team no longer supports Java 7. 
> 
> 
> 
> Please confirm if above statement is true or not. 
> 
> 
> 
> 
> 
> Warm Regards,
> 
> Anchit Parmar
> 
> Team Lead - Vulnerability Management & Penetration Testing Practice
> 
> Information Security Department  
> 
> IDBI Intech Limited , IDBI Bank Building, Plot No. 39-41, Sector-11, 
> 
> CBD Belapur, Navi Mumbai - 400 614 .
> 
> Cell- 8779522843
> 
> 
> 
> 
> Disclaimer: This e-mail contains privileged information or information 
> belonging to IDBI Intech Ltd and is intended solely for the addressee/s. 
> Access to this email by anyone else is unauthorized. Any copying (whole or 
> partial) or further distribution beyond the original recipient is not 
> intended, and may be unlawful. The recipient acknowledges that IDBI Intech 
> Ltd is unable to exercise control or ensure or guarantee the integrity of the 
> contents of the information contained in e-mail transmissions and further 
> acknowledges that any views expressed in this message are those of the 
> individual sender and are not binding on IDBI Intech Ltd. E-mails are 
> susceptible to alteration and their integrity cannot be guaranteed. IDBI 
> Intech Ltd does not accept any liability for any damages caused on account of 
> this e-mail. If you have received this email in error, please contact the 
> sender and delete the material from your computer.

Re: [logging-log4j2] 01/02: Add PropertiesLookup#getProperties().

2022-01-20 Thread Ralph Goers

It still isn’t clear to me why the existing lookups aren’t sufficient. I 
thought we already have a lookup that does the same thing.

Ralph

> On Jan 20, 2022, at 5:48 AM, Gary Gregory  wrote:
> 
> Hi Carter,
> 
> I have several needs I am trying to satisfy. I have a lot of customizations
> I have to support and implement in Log4j 1 and 2 (the Log4j 1 code is being
> migrated to Log4j 2, but we still need to use the bridge to support Log4j 1
> in 3rd party dependencies and transitive dependencies). We have new apps,
> we have legacy apps, we have a lot of code. We do a lot of what I would
> call in-flight manipulation of Log4j 1 and 2 in these apps, and some plain
> old [re]configurations using the Configurator APIs, which are the easy use
> cases to implement and support. Users (devs and admins really) can change
> the Log4j configuration file and have Log4j monitor the file and that's
> fine, but that's the advanced case because people can too easily muck up
> these configuration files. Instead of mucking with files, these app servers
> come up, stay up, and need to be configured and reconfigured through a set
> of (REST) admin APIs. Some of these admin tasks do all sorts of
> introspections and reconfigurations and that is where this kind of API
> comes in. I want to be able to start from something like an Interpolator
> (in all these code bases, we use the Log4j Interpolator, Commons Lang,
> Common Text, you name it, it's in some code base somewhere), find this or
> that StrLookup and returns pieces of it to client, so a UI can say "You're
> got this config setting, would you like to change it?". Depending on the
> use case, the app, and the server combo, sometimes changing a setting,
> means the UI generates a new config file and sends it over, sometimes to
> translates to calling a specific Configurator API like one of the
> setLevel() APIs, and some other time we query and/or edit objects directly
> in Log4j and elsewhere. Sorry for the long write up!
> 
> Gary
> 
>> On Wed, Jan 19, 2022 at 6:32 PM Carter Kozak  wrote:
>> 
>> Any chance you could help me understand the rationale for this feature? I
>> opted not to implement a method akin to MapLookup.getMap because that
>> wasn't used, avoiding unnecessary API constraints allows us to refactor
>> more easily in the future. If the values are required elsewhere, it may be
>> reasonable, but I have another change in flight that may impact such
>> consumers.
>> 
>> Thanks!
>> -ck
>> 
>> On Sat, Jan 15, 2022, at 18:45, ggreg...@apache.org wrote:
>> 
>> This is an automated email from the ASF dual-hosted git repository.
>> 
>> ggregory pushed a commit to branch release-2.x
>> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
>> 
>> commit d402f360fbad18bc3c0902a65e8e53a1202e57d5
>> Author: Gary Gregory 
>> AuthorDate: Sat Jan 15 18:45:37 2022 -0500
>> 
>>Add PropertiesLookup#getProperties().
>> 
>>Commit 1/2 for cherry-picking to master.
>> ---
>> .../logging/log4j/core/lookup/PropertiesLookup.java   | 19
>> ---
>> 1 file changed, 16 insertions(+), 3 deletions(-)
>> 
>> diff --git
>> a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
>> index 995a71b..3066792 100644
>> ---
>> a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
>> +++
>> b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
>> @@ -34,16 +34,28 @@ public final class PropertiesLookup implements
>> StrLookup {
>>  */
>> private final Map properties;
>> 
>> +/**
>> + * Constructs a new instance for the given map.
>> + *
>> + * @param properties map these.
>> + */
>> public PropertiesLookup(final Map properties) {
>> this.properties = properties == null
>> ? Collections.emptyMap()
>> : properties;
>> }
>> 
>> +/**
>> + * Gets the property map.
>> + *
>> + * @return the property map.
>> + */
>> +public Map getProperties() {
>> +return properties;
>> +}
>> +
>> @Override
>> -public String lookup(
>> -@SuppressWarnings("ignored") final LogEvent event,
>> -final String key) {
>> +public String lookup(@SuppressWarnings("ignored") final LogEvent
>> event, final String key) {
>> return lookup(key);
>> }
>> 
>> @@ -65,4 +77,5 @@ public final class PropertiesLookup implements StrLookup
>> {
>> public String toString() {
>> return "PropertiesLookup{properties=" + properties + '}';
>> }
>> +
>> }
>> 
>> 
>>

Re: [logging-log4j2] 01/02: Add PropertiesLookup#getProperties().

2022-01-20 Thread Carter Kozak

Thanks Gary, I appreciate the context, though I admit I still don't understand 
how it relates directly to the new getter method.

Ralph, I think your question is about the distinction between MapLookup and the 
new PropertiesLookup that I added recently.
The story begins here: https://github.com/apache/logging-log4j2/pull/646 A 
reasonable request, it should be possible to load a field from a map-message 
using '${map:myField}' even if there's a 'value' defined in the configuration. Previously we 
would read the properties map first, then map messages. However, if we simply 
made that change as is, the default lookup (no prefix) would also have 
preferred map-message data, potentially from user-input, over the properties 
that they referenced. Similar issues existed for the subtypes of MapLookup, of 
which there were a few.
By using a different kind of lookup which isn't aware of MapMessages as the 
default resolved, we avoid this class of issues, thus the new type. Added here: 
https://github.com/apache/logging-log4j2/pull/647



On Thu, Jan 20, 2022, at 09:22, Ralph Goers wrote:
> It still isn’t clear to me why the existing lookups aren’t sufficient. I 
> thought we already have a lookup that does the same thing.
> 
> Ralph
> 
> > On Jan 20, 2022, at 5:48 AM, Gary Gregory  wrote:
> > 
> > Hi Carter,
> > 
> > I have several needs I am trying to satisfy. I have a lot of customizations
> > I have to support and implement in Log4j 1 and 2 (the Log4j 1 code is being
> > migrated to Log4j 2, but we still need to use the bridge to support Log4j 1
> > in 3rd party dependencies and transitive dependencies). We have new apps,
> > we have legacy apps, we have a lot of code. We do a lot of what I would
> > call in-flight manipulation of Log4j 1 and 2 in these apps, and some plain
> > old [re]configurations using the Configurator APIs, which are the easy use
> > cases to implement and support. Users (devs and admins really) can change
> > the Log4j configuration file and have Log4j monitor the file and that's
> > fine, but that's the advanced case because people can too easily muck up
> > these configuration files. Instead of mucking with files, these app servers
> > come up, stay up, and need to be configured and reconfigured through a set
> > of (REST) admin APIs. Some of these admin tasks do all sorts of
> > introspections and reconfigurations and that is where this kind of API
> > comes in. I want to be able to start from something like an Interpolator
> > (in all these code bases, we use the Log4j Interpolator, Commons Lang,
> > Common Text, you name it, it's in some code base somewhere), find this or
> > that StrLookup and returns pieces of it to client, so a UI can say "You're
> > got this config setting, would you like to change it?". Depending on the
> > use case, the app, and the server combo, sometimes changing a setting,
> > means the UI generates a new config file and sends it over, sometimes to
> > translates to calling a specific Configurator API like one of the
> > setLevel() APIs, and some other time we query and/or edit objects directly
> > in Log4j and elsewhere. Sorry for the long write up!
> > 
> > Gary
> > 
> >> On Wed, Jan 19, 2022 at 6:32 PM Carter Kozak  wrote:
> >> 
> >> Any chance you could help me understand the rationale for this feature? I
> >> opted not to implement a method akin to MapLookup.getMap because that
> >> wasn't used, avoiding unnecessary API constraints allows us to refactor
> >> more easily in the future. If the values are required elsewhere, it may be
> >> reasonable, but I have another change in flight that may impact such
> >> consumers.
> >> 
> >> Thanks!
> >> -ck
> >> 
> >> On Sat, Jan 15, 2022, at 18:45, ggreg...@apache.org wrote:
> >> 
> >> This is an automated email from the ASF dual-hosted git repository.
> >> 
> >> ggregory pushed a commit to branch release-2.x
> >> in repository https://gitbox.apache.org/repos/asf/logging-log4j2.git
> >> 
> >> commit d402f360fbad18bc3c0902a65e8e53a1202e57d5
> >> Author: Gary Gregory 
> >> AuthorDate: Sat Jan 15 18:45:37 2022 -0500
> >> 
> >>Add PropertiesLookup#getProperties().
> >> 
> >>Commit 1/2 for cherry-picking to master.
> >> ---
> >> .../logging/log4j/core/lookup/PropertiesLookup.java   | 19
> >> ---
> >> 1 file changed, 16 insertions(+), 3 deletions(-)
> >> 
> >> diff --git
> >> a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
> >> b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
> >> index 995a71b..3066792 100644
> >> ---
> >> a/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
> >> +++
> >> b/log4j-core/src/main/java/org/apache/logging/log4j/core/lookup/PropertiesLookup.java
> >> @@ -34,16 +34,28 @@ public final class PropertiesLookup implements
> >> StrLookup {
> >>  */
> >> private final Map properties;
> >> 
> >> +/**
> >> + * Constructs a new instance for the given m

Re: Is log4j 2.12.4

2022-01-20 Thread Gary Gregory

Hello Anchit,

The only reliable source of information is our security page here
https://logging.apache.org/log4j/2.x/security.html where you will answers
to your questions.

We do not control what other sites say, nor would I want to review the
whole internet; -)

Gary

On Thu, Jan 20, 2022, 09:17 anchit parmar
 wrote:

> Dear Team,
>
>
>
> Please confim if 2.12.4 is vuln to following CVE's
>
> 1)   
> CVE-2021-45105
>
> 2)   
> CVE-2021-45046
>
> 3)   
> CVE-2021-44228
>
>
>
> Also,
>
> As per https://endoflife.date/log4jlog4j version 2.12.x has reached
> its
> EOL. The Log4j team no longer supports Java 7.
>
>
>
> Please confirm if above statement is true or not.
>
>
>
>
>
> Warm Regards,
>
> Anchit Parmar
>
> Team Lead - Vulnerability Management & Penetration Testing Practice
>
> Information Security Department
>
> IDBI Intech Limited , IDBI Bank Building, Plot No. 39-41, Sector-11,
>
> CBD Belapur, Navi Mumbai - 400 614 .
>
> Cell- 8779522843
>
>
>
>
> Disclaimer: This e-mail contains privileged information or information
> belonging to IDBI Intech Ltd and is intended solely for the addressee/s.
> Access to this email by anyone else is unauthorized. Any copying (whole or
> partial) or further distribution beyond the original recipient is not
> intended, and may be unlawful. The recipient acknowledges that IDBI Intech
> Ltd is unable to exercise control or ensure or guarantee the integrity of
> the contents of the information contained in e-mail transmissions and
> further acknowledges that any views expressed in this message are those of
> the individual sender and are not binding on IDBI Intech Ltd. E-mails are
> susceptible to alteration and their integrity cannot be guaranteed. IDBI
> Intech Ltd does not accept any liability for any damages caused on account
> of this e-mail. If you have received this email in error, please contact
> the sender and delete the material from your computer.
>

Re: [logging-log4j2] 01/02: Add PropertiesLookup#getProperties().

[GitHub] [logging-log4j1] lsimons commented on pull request #18: Refine build scripts

[GitHub] [logging-log4j1] lsimons commented on pull request #15: vulnerability for Version 1.x. CVE-2021-4104

[GitHub] [logging-log4j1] lsimons commented on pull request #16: Cleaned-up log4j 1.2 that disables scary networking (trunk, binary-incompatible)

[GitHub] [logging-log4j1] lsimons commented on pull request #17: Cleaned-up log4j 1.2 that disables scary networking (base=1.2.17, fully binary compatible)

Is log4j 2.12.4

Re: Is log4j 2.12.4

Re: [logging-log4j2] 01/02: Add PropertiesLookup#getProperties().

Re: [logging-log4j2] 01/02: Add PropertiesLookup#getProperties().

Re: Is log4j 2.12.4

10 matches

Site Navigation

Mail list logo

Footer information