Re: [log4cxx] ABI stability

[Thorsten Schöning]

Guten Tag Robert Middleton,
am Montag, 29. November 2021 um 04:53 schrieben Sie:

> At this point, I believe that I have converted all of the important
> classes to be ABI-stable.[...]

Not that it's too representative, but things properly build and test
for my pretty current VS 17.02 as well.

> As per the LocationInfo, in the future we should probably make more
> use of std::string_view(C++17) or the equivalent boost::string_view.

+1

> I'll merge this into a new branch(log4cxx-next?) shortly[...]

Not too important, but as there's already some "latest_stable",
"next_stable" might make sense as well. "latest|next|old_stable" has
been used for the old website.

> * Remove any APR references in the header files.

+1. The less dependencies the better and preferring BOOST over APR
seems to make sense for some C++ app.

Mit freundlichen Grüßen

Thorsten Schöning

-- 
AM-SoFT IT-Service - Bitstore Hameln GmbH
Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK

E-Mail: thorsten.schoen...@am-soft.de
Web:http://www.AM-SoFT.de/

Tel:   05151-  9468- 0
Tel:   05151-  9468-55
Fax:   05151-  9468-88
Mobil:  0178-8 9468-04

AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska

Re: Removing message lookups in master

[Mikael Ståldal]

I would say that log messages and log message parameter are as much (or 
as little) controlled by the application. I don't think it make sense to 
see them differently from a security perspective.


Just as some code might do:
  logger.info("some message {}", userInput);

Other code might do:
  logger.info("some message " + userInput);

And if you use the Scala API, parameters get merged into the log message 
since you would use Scala string interpolation:

https://logging.apache.org/log4j/scala/index.html

(There might also exist 3rd-party language bindings or other wrappers of 
Log4j where parameters are merged into into the log message before 
passed to Log4j.)


I think that lookups should be removed from both log message and log 
message parameters.



On 2021-12-10 11:50, Remko Popma wrote:

I would say no. Lookups are very powerful and useful.
We could consider removing JNDI lookups.

The biggest problem however is that the lookups are applied to the logging
message *parameters*.
The logging message is controlled by the application, so any lookups there
should be fine or at least any problems can be found during review/audit.

I cannot imagine a scenario where doing lookups against the message
parameters is useful.
There could be such a scenario, but then the application should do this
explicitly, with something like

logger.info("some message {}", doExplicitLookup(param));

I haven't looked at the fix in enough detail, but removing lookups in
logging message parameters sounds reasonable.
Not sure how easy it would be to implement this though.


On Fri, Dec 10, 2021 at 7:31 PM Volkan Yazıcı  wrote:


Shall we completely remove message lookups (which are only used by
PatternLayout) in master?

Re: Removing message lookups in master

[Carter Kozak]

Agreed that the feature should be purged entirely. I turned it off by default 
with no global enablement on release-2.x (shipped in 2.15).

-ck

> On Dec 11, 2021, at 09:13, Mikael Ståldal  wrote:
> 
> I would say that log messages and log message parameter are as much (or as 
> little) controlled by the application. I don't think it make sense to see 
> them differently from a security perspective.
> 
> Just as some code might do:
>  logger.info("some message {}", userInput);
> 
> Other code might do:
>  logger.info("some message " + userInput);
> 
> And if you use the Scala API, parameters get merged into the log message 
> since you would use Scala string interpolation:
> https://logging.apache.org/log4j/scala/index.html
> 
> (There might also exist 3rd-party language bindings or other wrappers of 
> Log4j where parameters are merged into into the log message before passed to 
> Log4j.)
> 
> I think that lookups should be removed from both log message and log message 
> parameters.
> 
> 
>> On 2021-12-10 11:50, Remko Popma wrote:
>> I would say no. Lookups are very powerful and useful.
>> We could consider removing JNDI lookups.
>> The biggest problem however is that the lookups are applied to the logging
>> message *parameters*.
>> The logging message is controlled by the application, so any lookups there
>> should be fine or at least any problems can be found during review/audit.
>> I cannot imagine a scenario where doing lookups against the message
>> parameters is useful.
>> There could be such a scenario, but then the application should do this
>> explicitly, with something like
>> logger.info("some message {}", doExplicitLookup(param));
>> I haven't looked at the fix in enough detail, but removing lookups in
>> logging message parameters sounds reasonable.
>> Not sure how easy it would be to implement this though.
>>> On Fri, Dec 10, 2021 at 7:31 PM Volkan Yazıcı  wrote:
>>> Shall we completely remove message lookups (which are only used by
>>> PatternLayout) in master?
>>> 

Re: Removing message lookups in master

[Ralph Goers]

I agree. Remove it from master.

Ralph

> On Dec 11, 2021, at 7:42 AM, Carter Kozak  wrote:
> 
> Agreed that the feature should be purged entirely. I turned it off by default 
> with no global enablement on release-2.x (shipped in 2.15).
> 
> -ck
> 
>> On Dec 11, 2021, at 09:13, Mikael Ståldal  wrote:
>> 
>> I would say that log messages and log message parameter are as much (or as 
>> little) controlled by the application. I don't think it make sense to see 
>> them differently from a security perspective.
>> 
>> Just as some code might do:
>> logger.info("some message {}", userInput);
>> 
>> Other code might do:
>> logger.info("some message " + userInput);
>> 
>> And if you use the Scala API, parameters get merged into the log message 
>> since you would use Scala string interpolation:
>> https://logging.apache.org/log4j/scala/index.html
>> 
>> (There might also exist 3rd-party language bindings or other wrappers of 
>> Log4j where parameters are merged into into the log message before passed to 
>> Log4j.)
>> 
>> I think that lookups should be removed from both log message and log message 
>> parameters.
>> 
>> 
>>> On 2021-12-10 11:50, Remko Popma wrote:
>>> I would say no. Lookups are very powerful and useful.
>>> We could consider removing JNDI lookups.
>>> The biggest problem however is that the lookups are applied to the logging
>>> message *parameters*.
>>> The logging message is controlled by the application, so any lookups there
>>> should be fine or at least any problems can be found during review/audit.
>>> I cannot imagine a scenario where doing lookups against the message
>>> parameters is useful.
>>> There could be such a scenario, but then the application should do this
>>> explicitly, with something like
>>> logger.info("some message {}", doExplicitLookup(param));
>>> I haven't looked at the fix in enough detail, but removing lookups in
>>> logging message parameters sounds reasonable.
>>> Not sure how easy it would be to implement this though.
 On Fri, Dec 10, 2021 at 7:31 PM Volkan Yazıcı  wrote:
 Shall we completely remove message lookups (which are only used by
 PatternLayout) in master?
 
> 
> 

Re: Removing message lookups in master

[Matt Sicker]

Agreed. I didn’t realize this feature existed like that until recently, and 
it’s not worth salvaging.

Matt Sicker

> On Dec 11, 2021, at 09:25, Ralph Goers  wrote:
> 
> I agree. Remove it from master.
> 
> Ralph
> 
>> On Dec 11, 2021, at 7:42 AM, Carter Kozak  wrote:
>> 
>> Agreed that the feature should be purged entirely. I turned it off by 
>> default with no global enablement on release-2.x (shipped in 2.15).
>> 
>> -ck
>> 
 On Dec 11, 2021, at 09:13, Mikael Ståldal  wrote:
>>> 
>>> I would say that log messages and log message parameter are as much (or as 
>>> little) controlled by the application. I don't think it make sense to see 
>>> them differently from a security perspective.
>>> 
>>> Just as some code might do:
>>> logger.info("some message {}", userInput);
>>> 
>>> Other code might do:
>>> logger.info("some message " + userInput);
>>> 
>>> And if you use the Scala API, parameters get merged into the log message 
>>> since you would use Scala string interpolation:
>>> https://logging.apache.org/log4j/scala/index.html
>>> 
>>> (There might also exist 3rd-party language bindings or other wrappers of 
>>> Log4j where parameters are merged into into the log message before passed 
>>> to Log4j.)
>>> 
>>> I think that lookups should be removed from both log message and log 
>>> message parameters.
>>> 
>>> 
 On 2021-12-10 11:50, Remko Popma wrote:
 I would say no. Lookups are very powerful and useful.
 We could consider removing JNDI lookups.
 The biggest problem however is that the lookups are applied to the logging
 message *parameters*.
 The logging message is controlled by the application, so any lookups there
 should be fine or at least any problems can be found during review/audit.
 I cannot imagine a scenario where doing lookups against the message
 parameters is useful.
 There could be such a scenario, but then the application should do this
 explicitly, with something like
 logger.info("some message {}", doExplicitLookup(param));
 I haven't looked at the fix in enough detail, but removing lookups in
 logging message parameters sounds reasonable.
 Not sure how easy it would be to implement this though.
> On Fri, Dec 10, 2021 at 7:31 PM Volkan Yazıcı  wrote:
> Shall we completely remove message lookups (which are only used by
> PatternLayout) in master?
> 
>> 
>> 
> 
> 

[VOTE] Release Log4j 2.15.1-rc1

[Matt Sicker]

This is a vote to release Log4j 2.15.1, the next version of the Log4j 2 project.

Please download, test, and cast your votes on the log4j developers list.
[] +1, release the artifacts
[] -1, don't release because...

The vote will remain open for 72 hours (or more if required). All votes are 
welcome and we encourage everyone to test the release, but only Logging PMC 
votes are “officially” counted. As always, at least 3 +1 votes and more 
positive than negative votes are required.

Changes in this release include:

Fixed Bugs

* LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to be set to 
true to allow JNDI.

Tag: 
a)  for a new copy do "git clone https://github.com/apache/logging-log4j2.git 
" and then "git checkout 
tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1 
https://github.com/apache/logging-log4j2.git 
"
b) for an existing working copy to “git pull” and then “git checkout 
tags/log4j-2.15.1-rc1”

Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html 
.

Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachelogging-1067/

Distribution archives: https://dist.apache.org/repos/dist/dev/logging/log4j/ 
 

You may download all the Maven artifacts by executing:
wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate 
https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/

Re: [VOTE] Release Log4j 2.15.1-rc1

[Matt Sicker]

If possible, let’s try to get this vote done over the next 24 hours.

Matt Sicker

> On Dec 11, 2021, at 21:48, Matt Sicker  wrote:
> 
> This is a vote to release Log4j 2.15.1, the next version of the Log4j 2 
> project.
> 
> Please download, test, and cast your votes on the log4j developers list.
> [] +1, release the artifacts
> [] -1, don't release because...
> 
> The vote will remain open for 72 hours (or more if required). All votes are 
> welcome and we encourage everyone to test the release, but only Logging PMC 
> votes are “officially” counted. As always, at least 3 +1 votes and more 
> positive than negative votes are required.
> 
> Changes in this release include:
> 
> Fixed Bugs
> 
> * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to be set 
> to true to allow JNDI.
> 
> Tag: 
> a)  for a new copy do "git clone 
> https://github.com/apache/logging-log4j2.git"; and then "git checkout 
> tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1 
> https://github.com/apache/logging-log4j2.git";
> b) for an existing working copy to “git pull” and then “git checkout 
> tags/log4j-2.15.1-rc1”
> 
> Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html.
> 
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachelogging-1067/
> 
> Distribution archives: https://dist.apache.org/repos/dist/dev/logging/log4j/ 
> 
> You may download all the Maven artifacts by executing:
> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate 
> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/

Re: [VOTE] Release Log4j 2.15.1-rc1

[Ralph Goers]

Or less. While it is not an essential release I believe it will be appreciated.

Ralph

> On Dec 11, 2021, at 9:01 PM, Matt Sicker  wrote:
> 
> If possible, let’s try to get this vote done over the next 24 hours.
> 
> Matt Sicker
> 
>> On Dec 11, 2021, at 21:48, Matt Sicker  wrote:
>> 
>> This is a vote to release Log4j 2.15.1, the next version of the Log4j 2 
>> project.
>> 
>> Please download, test, and cast your votes on the log4j developers list.
>> [] +1, release the artifacts
>> [] -1, don't release because...
>> 
>> The vote will remain open for 72 hours (or more if required). All votes are 
>> welcome and we encourage everyone to test the release, but only Logging PMC 
>> votes are “officially” counted. As always, at least 3 +1 votes and more 
>> positive than negative votes are required.
>> 
>> Changes in this release include:
>> 
>> Fixed Bugs
>> 
>> * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to be set 
>> to true to allow JNDI.
>> 
>> Tag: 
>> a)  for a new copy do "git clone 
>> https://github.com/apache/logging-log4j2.git"; and then "git checkout 
>> tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1 
>> https://github.com/apache/logging-log4j2.git";
>> b) for an existing working copy to “git pull” and then “git checkout 
>> tags/log4j-2.15.1-rc1”
>> 
>> Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html.
>> 
>> Maven Artifacts: 
>> https://repository.apache.org/content/repositories/orgapachelogging-1067/
>> 
>> Distribution archives: https://dist.apache.org/repos/dist/dev/logging/log4j/ 
>> 
>> You may download all the Maven artifacts by executing:
>> wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate 
>> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/

Re: [VOTE] Release Log4j 2.15.1-rc1

[Gary Gregory]

I'll review in the morning (EST).

Gary

On Sat, Dec 11, 2021, 23:02 Matt Sicker  wrote:

> If possible, let’s try to get this vote done over the next 24 hours.
>
> Matt Sicker
>
> > On Dec 11, 2021, at 21:48, Matt Sicker  wrote:
> >
> > This is a vote to release Log4j 2.15.1, the next version of the Log4j 2
> project.
> >
> > Please download, test, and cast your votes on the log4j developers list.
> > [] +1, release the artifacts
> > [] -1, don't release because...
> >
> > The vote will remain open for 72 hours (or more if required). All votes
> are welcome and we encourage everyone to test the release, but only Logging
> PMC votes are “officially” counted. As always, at least 3 +1 votes and more
> positive than negative votes are required.
> >
> > Changes in this release include:
> >
> > Fixed Bugs
> >
> > * LOG4J2-3208: Disable JNDI by default. Require log4j2.enableJndi to be
> set to true to allow JNDI.
> >
> > Tag:
> > a)  for a new copy do "git clone
> https://github.com/apache/logging-log4j2.git"; and then "git checkout
> tags/log4j-2.15.1-rc1”  or just "git clone -b log4j-2.15.1-rc1
> https://github.com/apache/logging-log4j2.git";
> > b) for an existing working copy to “git pull” and then “git checkout
> tags/log4j-2.15.1-rc1”
> >
> > Web Site:  https://logging.staged.apache.org/log4j/2.x/index.html.
> >
> > Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachelogging-1067/
> >
> > Distribution archives:
> https://dist.apache.org/repos/dist/dev/logging/log4j/
> >
> > You may download all the Maven artifacts by executing:
> > wget -e robots=off --cut-dirs=7 -nH -r -p -np --no-check-certificate
> https://repository.apache.org/content/repositories/orgapachelogging-1067/org/apache/logging/log4j/
>