Re: [VOTE] Release Log4j 2.15.1-rc1

[Mikael Ståldal]

I agree too. I was just worried that we wouldn't remove Message Lookups 
until 3.x. Removing them in the next minor release (2.16.0) is reasonable.



On 2021-12-13 10:12, Volkan Yazıcı wrote:

I agree with both of your points Remko.

On Mon, Dec 13, 2021 at 2:40 AM Remko Popma  wrote:


I am also okay with removing Message Lookups from 2.x.
A release with that change should be called 2.16.0 though, not 2.15.1 or
2.15.2.

Also it makes sense to *only* have that security change (removing Message
Lookups) in such a 2.16.0 release and not add other features.
This will reduce the testing burden for people looking to upgrade.



On Mon, Dec 13, 2021 at 8:12 Ralph Goers 
wrote:


Volkan,

While ASF rules say a -1 vote is not a veto for all practical purposes

the

release manager is going to consider it a blocker.

A release that removes JNDI will prevent people from inadvertently using
the JNDI Lookup, JMS, or JndiContextSelector
without understanding the security risk using them. Message Lookups are a
different problem. We are not disabling JNDI
so people can re-enable message lookups. That would be crazy. We are
disabling JNDI because, despite all the fixes we
have made, I still don’t trust it.

We have all agreed Message Lookups need to be killed in master. If we are
all in agreement to kill them now in 2.x I’m
fine with that but the two are separate issues.

If you are OK with the release than your vote should be anything but -1.
If you really feel it needs a -1 then we need to see
if we are all ok completely removing the option to re-enable message
lookups. I would completely understand if that is what
you want and I would support that so please don’t feel pressured to give
in.

Ralph



On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:

You don't need my vote. As far as I count, you already have more than

3.


I can imagine Ralph and the rest have worked sleeplessly for days.

Hence

if

they think disabling JNDI buys us a benefit, so be it.

If not millions, tens of thousands of people tried to upgrade Log4j to
2.15.0 recently. A release where JNDI lookup disabled will only adress
people who still (astonishingly!) want to use "message lookups" –

correct

me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring

more

confusion than benefit to the general audience. I think the fix to the
vulnerability is to disable message lookups, not patches to the JNDI
lookup. I want to believe that users get this fact right and have

already

disabled it. We need to be really careful with our next release. We

can't

expect people to upgrade once a week. Putting aside the damage it does

to

the reputation of the project.

On Sun, Dec 12, 2021 at 9:47 PM Remko Popma 

wrote:



First, is this really a blocker for 2.15.1?
I think it is prudent to do urgent releases soon.
This JNDI change (LOG4J2-3208
) feels urgent

enough

to
warrant another shortened vote window.
A larger change like removing message lookups should not be rushed out

like

this, it needs review time.

Second, do we really want to do this? Are we not overreacting?
Would it not be better to remove lookups in message parameters only?
(In implementation terms, resolve all lookups *before* interpolating

the

message parameters?)

Also, let me state the obvious, lookups *in configuration* are

tremendously

useful and should not be removed.
This may be obvious to some of us, but I just want to make sure there

is no

confusion about that (because I personally was confused about this at

some

point). :-)

Finally, if we decide to do this, should a change like this be in a
point/bugfix release (2.15.1) or should it be a separate minor release

like

2.16.0?



On Mon, Dec 13, 2021 at 5:10 AM Remko Popma 

wrote:



Shall we discuss this first please?

On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker 

wrote:



If you can handle that change, I can roll a new release candidate.

Matt Sicker


On Dec 12, 2021, at 14:07, Volkan Yazıcı  wrote:

I know. I want them to be removed, not disabled.


On Sun, Dec 12, 2021 at 9:01 PM Matt Sicker 

wrote:


Those were already disabled in 2.15.0.

Matt Sicker


On Dec 12, 2021, at 13:41, Volkan Yazıcı 

wrote:


I very well recognize your heroic effort on tackling this issue

and

I am

very thankful for that.
I vote -1, because I want message (not configuration!) lookups to

be

removed.

Message lookups create a vast attack surface. Anything they offer

can

simply be implemented by the user.


On Sun, Dec 12, 2021 at 4:48 AM 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. A

Re: [VOTE] Release Log4j 2.15.1-rc1

[Gary Gregory]

JNDI is commonly used to configure JMS and JDBC.

Gary

On Mon, Dec 13, 2021 at 4:12 AM Volkan Yazıcı  wrote:

> Thanks so much for your understanding Ralph, it is very important for me.
>
> For one, message lookups are nothing but a plethora of vulnerabilities. I
> think everybody agrees on this. We shouldn't try to make it secure, we
> _must_ ditch it off.
>
> Second, I think, again, we shouldn't even be trying to incorporate any
> fixes on the JNDI. This approach unfortunately was already proven to be
> futile. We should rather have exposed everywhere how dangerous it is and
> disabled (actually, preferably, removed) it. The entire internet is buzzing
> with JNDI, but I have yet to hear a use case for it. If it would be up to
> me, I would even rollback JndiManager checks introduced in 2.15.0. (I am
> not suggesting this.) All in all, I guess disabling JNDI by default appears
> to be the most sensible next step.
>
> Putting aside all technical details of the next release, we should really
> work on the "human" aspect of things. We should come up with a change set
> to prove the quality of Log4j and win all broken hearts back. This change
> set should shout out loud "we have heard you and thanks for working with
> us!" I don't think we are in a hurry with the next release, let's put some
> diligent effort into what to ship next.
>
> On Mon, Dec 13, 2021 at 12:12 AM Ralph Goers 
> wrote:
>
> > Volkan,
> >
> > While ASF rules say a -1 vote is not a veto for all practical purposes
> the
> > release manager is going to consider it a blocker.
> >
> > A release that removes JNDI will prevent people from inadvertently using
> > the JNDI Lookup, JMS, or JndiContextSelector
> > without understanding the security risk using them. Message Lookups are a
> > different problem. We are not disabling JNDI
> > so people can re-enable message lookups. That would be crazy. We are
> > disabling JNDI because, despite all the fixes we
> > have made, I still don’t trust it.
> >
> > We have all agreed Message Lookups need to be killed in master. If we are
> > all in agreement to kill them now in 2.x I’m
> > fine with that but the two are separate issues.
> >
> > If you are OK with the release than your vote should be anything but -1.
> > If you really feel it needs a -1 then we need to see
> > if we are all ok completely removing the option to re-enable message
> > lookups. I would completely understand if that is what
> > you want and I would support that so please don’t feel pressured to give
> > in.
> >
> > Ralph
> >
> >
> > > On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:
> > >
> > > You don't need my vote. As far as I count, you already have more than
> 3.
> > >
> > > I can imagine Ralph and the rest have worked sleeplessly for days.
> Hence
> > if
> > > they think disabling JNDI buys us a benefit, so be it.
> > >
> > > If not millions, tens of thousands of people tried to upgrade Log4j to
> > > 2.15.0 recently. A release where JNDI lookup disabled will only adress
> > > people who still (astonishingly!) want to use "message lookups" –
> correct
> > > me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring
> > more
> > > confusion than benefit to the general audience. I think the fix to the
> > > vulnerability is to disable message lookups, not patches to the JNDI
> > > lookup. I want to believe that users get this fact right and have
> already
> > > disabled it. We need to be really careful with our next release. We
> can't
> > > expect people to upgrade once a week. Putting aside the damage it does
> to
> > > the reputation of the project.
> > >
> > > On Sun, Dec 12, 2021 at 9:47 PM Remko Popma 
> > wrote:
> > >
> > >> First, is this really a blocker for 2.15.1?
> > >> I think it is prudent to do urgent releases soon.
> > >> This JNDI change (LOG4J2-3208
> > >> ) feels urgent
> > enough
> > >> to
> > >> warrant another shortened vote window.
> > >> A larger change like removing message lookups should not be rushed out
> > like
> > >> this, it needs review time.
> > >>
> > >> Second, do we really want to do this? Are we not overreacting?
> > >> Would it not be better to remove lookups in message parameters only?
> > >> (In implementation terms, resolve all lookups *before* interpolating
> the
> > >> message parameters?)
> > >>
> > >> Also, let me state the obvious, lookups *in configuration* are
> > tremendously
> > >> useful and should not be removed.
> > >> This may be obvious to some of us, but I just want to make sure there
> > is no
> > >> confusion about that (because I personally was confused about this at
> > some
> > >> point). :-)
> > >>
> > >> Finally, if we decide to do this, should a change like this be in a
> > >> point/bugfix release (2.15.1) or should it be a separate minor release
> > like
> > >> 2.16.0?
> > >>
> > >>
> > >>
> > >> On Mon, Dec 13, 2021 at 5:10 AM Remko Popma 
> > wrote:
> > >>
> > >>> Shall we discuss this first please?

Re: [VOTE] Release Log4j 2.15.1-rc1

[Volkan Yazıcı]

I agree with both of your points Remko.

On Mon, Dec 13, 2021 at 2:40 AM Remko Popma  wrote:

> I am also okay with removing Message Lookups from 2.x.
> A release with that change should be called 2.16.0 though, not 2.15.1 or
> 2.15.2.
>
> Also it makes sense to *only* have that security change (removing Message
> Lookups) in such a 2.16.0 release and not add other features.
> This will reduce the testing burden for people looking to upgrade.
>
>
>
> On Mon, Dec 13, 2021 at 8:12 Ralph Goers 
> wrote:
>
> > Volkan,
> >
> > While ASF rules say a -1 vote is not a veto for all practical purposes
> the
> > release manager is going to consider it a blocker.
> >
> > A release that removes JNDI will prevent people from inadvertently using
> > the JNDI Lookup, JMS, or JndiContextSelector
> > without understanding the security risk using them. Message Lookups are a
> > different problem. We are not disabling JNDI
> > so people can re-enable message lookups. That would be crazy. We are
> > disabling JNDI because, despite all the fixes we
> > have made, I still don’t trust it.
> >
> > We have all agreed Message Lookups need to be killed in master. If we are
> > all in agreement to kill them now in 2.x I’m
> > fine with that but the two are separate issues.
> >
> > If you are OK with the release than your vote should be anything but -1.
> > If you really feel it needs a -1 then we need to see
> > if we are all ok completely removing the option to re-enable message
> > lookups. I would completely understand if that is what
> > you want and I would support that so please don’t feel pressured to give
> > in.
> >
> > Ralph
> >
> >
> > > On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:
> > >
> > > You don't need my vote. As far as I count, you already have more than
> 3.
> > >
> > > I can imagine Ralph and the rest have worked sleeplessly for days.
> Hence
> > if
> > > they think disabling JNDI buys us a benefit, so be it.
> > >
> > > If not millions, tens of thousands of people tried to upgrade Log4j to
> > > 2.15.0 recently. A release where JNDI lookup disabled will only adress
> > > people who still (astonishingly!) want to use "message lookups" –
> correct
> > > me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring
> > more
> > > confusion than benefit to the general audience. I think the fix to the
> > > vulnerability is to disable message lookups, not patches to the JNDI
> > > lookup. I want to believe that users get this fact right and have
> already
> > > disabled it. We need to be really careful with our next release. We
> can't
> > > expect people to upgrade once a week. Putting aside the damage it does
> to
> > > the reputation of the project.
> > >
> > > On Sun, Dec 12, 2021 at 9:47 PM Remko Popma 
> > wrote:
> > >
> > >> First, is this really a blocker for 2.15.1?
> > >> I think it is prudent to do urgent releases soon.
> > >> This JNDI change (LOG4J2-3208
> > >> ) feels urgent
> > enough
> > >> to
> > >> warrant another shortened vote window.
> > >> A larger change like removing message lookups should not be rushed out
> > like
> > >> this, it needs review time.
> > >>
> > >> Second, do we really want to do this? Are we not overreacting?
> > >> Would it not be better to remove lookups in message parameters only?
> > >> (In implementation terms, resolve all lookups *before* interpolating
> the
> > >> message parameters?)
> > >>
> > >> Also, let me state the obvious, lookups *in configuration* are
> > tremendously
> > >> useful and should not be removed.
> > >> This may be obvious to some of us, but I just want to make sure there
> > is no
> > >> confusion about that (because I personally was confused about this at
> > some
> > >> point). :-)
> > >>
> > >> Finally, if we decide to do this, should a change like this be in a
> > >> point/bugfix release (2.15.1) or should it be a separate minor release
> > like
> > >> 2.16.0?
> > >>
> > >>
> > >>
> > >> On Mon, Dec 13, 2021 at 5:10 AM Remko Popma 
> > wrote:
> > >>
> > >>> Shall we discuss this first please?
> > >>>
> > >>> On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker 
> wrote:
> > >>>
> >  If you can handle that change, I can roll a new release candidate.
> > 
> >  Matt Sicker
> > 
> > > On Dec 12, 2021, at 14:07, Volkan Yazıcı  wrote:
> > >
> > > I know. I want them to be removed, not disabled.
> > >
> > >> On Sun, Dec 12, 2021 at 9:01 PM Matt Sicker 
> > >> wrote:
> > >>
> > >> Those were already disabled in 2.15.0.
> > >>
> > >> Matt Sicker
> > >>
> >  On Dec 12, 2021, at 13:41, Volkan Yazıcı 
> wrote:
> > >>>
> > >>> I very well recognize your heroic effort on tackling this issue
> > and
> >  I am
> > >>> very thankful for that.
> > >>> I vote -1, because I want message (not configuration!) lookups to
> > be
> > >>> removed.
> > >>>
> > >>> Message lookups create a vast attack surface. Anything t

Re: [VOTE] Release Log4j 2.15.1-rc1

[Volkan Yazıcı]

Thanks so much for your understanding Ralph, it is very important for me.

For one, message lookups are nothing but a plethora of vulnerabilities. I
think everybody agrees on this. We shouldn't try to make it secure, we
_must_ ditch it off.

Second, I think, again, we shouldn't even be trying to incorporate any
fixes on the JNDI. This approach unfortunately was already proven to be
futile. We should rather have exposed everywhere how dangerous it is and
disabled (actually, preferably, removed) it. The entire internet is buzzing
with JNDI, but I have yet to hear a use case for it. If it would be up to
me, I would even rollback JndiManager checks introduced in 2.15.0. (I am
not suggesting this.) All in all, I guess disabling JNDI by default appears
to be the most sensible next step.

Putting aside all technical details of the next release, we should really
work on the "human" aspect of things. We should come up with a change set
to prove the quality of Log4j and win all broken hearts back. This change
set should shout out loud "we have heard you and thanks for working with
us!" I don't think we are in a hurry with the next release, let's put some
diligent effort into what to ship next.

On Mon, Dec 13, 2021 at 12:12 AM Ralph Goers 
wrote:

> Volkan,
>
> While ASF rules say a -1 vote is not a veto for all practical purposes the
> release manager is going to consider it a blocker.
>
> A release that removes JNDI will prevent people from inadvertently using
> the JNDI Lookup, JMS, or JndiContextSelector
> without understanding the security risk using them. Message Lookups are a
> different problem. We are not disabling JNDI
> so people can re-enable message lookups. That would be crazy. We are
> disabling JNDI because, despite all the fixes we
> have made, I still don’t trust it.
>
> We have all agreed Message Lookups need to be killed in master. If we are
> all in agreement to kill them now in 2.x I’m
> fine with that but the two are separate issues.
>
> If you are OK with the release than your vote should be anything but -1.
> If you really feel it needs a -1 then we need to see
> if we are all ok completely removing the option to re-enable message
> lookups. I would completely understand if that is what
> you want and I would support that so please don’t feel pressured to give
> in.
>
> Ralph
>
>
> > On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:
> >
> > You don't need my vote. As far as I count, you already have more than 3.
> >
> > I can imagine Ralph and the rest have worked sleeplessly for days. Hence
> if
> > they think disabling JNDI buys us a benefit, so be it.
> >
> > If not millions, tens of thousands of people tried to upgrade Log4j to
> > 2.15.0 recently. A release where JNDI lookup disabled will only adress
> > people who still (astonishingly!) want to use "message lookups" – correct
> > me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring
> more
> > confusion than benefit to the general audience. I think the fix to the
> > vulnerability is to disable message lookups, not patches to the JNDI
> > lookup. I want to believe that users get this fact right and have already
> > disabled it. We need to be really careful with our next release. We can't
> > expect people to upgrade once a week. Putting aside the damage it does to
> > the reputation of the project.
> >
> > On Sun, Dec 12, 2021 at 9:47 PM Remko Popma 
> wrote:
> >
> >> First, is this really a blocker for 2.15.1?
> >> I think it is prudent to do urgent releases soon.
> >> This JNDI change (LOG4J2-3208
> >> ) feels urgent
> enough
> >> to
> >> warrant another shortened vote window.
> >> A larger change like removing message lookups should not be rushed out
> like
> >> this, it needs review time.
> >>
> >> Second, do we really want to do this? Are we not overreacting?
> >> Would it not be better to remove lookups in message parameters only?
> >> (In implementation terms, resolve all lookups *before* interpolating the
> >> message parameters?)
> >>
> >> Also, let me state the obvious, lookups *in configuration* are
> tremendously
> >> useful and should not be removed.
> >> This may be obvious to some of us, but I just want to make sure there
> is no
> >> confusion about that (because I personally was confused about this at
> some
> >> point). :-)
> >>
> >> Finally, if we decide to do this, should a change like this be in a
> >> point/bugfix release (2.15.1) or should it be a separate minor release
> like
> >> 2.16.0?
> >>
> >>
> >>
> >> On Mon, Dec 13, 2021 at 5:10 AM Remko Popma 
> wrote:
> >>
> >>> Shall we discuss this first please?
> >>>
> >>> On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker  wrote:
> >>>
>  If you can handle that change, I can roll a new release candidate.
> 
>  Matt Sicker
> 
> > On Dec 12, 2021, at 14:07, Volkan Yazıcı  wrote:
> >
> > I know. I want them to be removed, not disabled.
> >
> >> On Sun, Dec 12, 2021 at 9:

Re: [VOTE] Release Log4j 2.15.1-rc1

[Ralph Goers]

Done, except I made it an info message.I can change it to info if you really 
think it is appropriate. 

Ralph

> On Dec 12, 2021, at 8:48 PM, Matt Sicker  wrote:
> 
> I’m canceling this vote and will start a new one for the updates in progress.
> 
>> On Dec 12, 2021, at 21:41, Remko Popma  wrote:
>> 
>> Okay. Would it be a good idea to retain support for the %m{nolookups} 
>> configuration format?
>> (Silently accept and ignore it.)
> 
> Yes, I think it would be a good idea.
> 
> 

Re: [VOTE] Release Log4j 2.15.1-rc1

[Matt Sicker]

I’m canceling this vote and will start a new one for the updates in progress.

> On Dec 12, 2021, at 21:41, Remko Popma  wrote:
> 
> Okay. Would it be a good idea to retain support for the %m{nolookups} 
> configuration format?
> (Silently accept and ignore it.)

Yes, I think it would be a good idea.

Re: [VOTE] Release Log4j 2.15.1-rc1

[Remko Popma]

Okay. Would it be a good idea to retain support for the %m{nolookups} 
configuration format?
(Silently accept and ignore it.)

When the configuration contains  %m{lookups}, it may be good to print a WARN 
message to the status logger that this setting will be ignored. 



> On Dec 13, 2021, at 12:24, Ralph Goers  wrote:
> I have just put up a PR. Please review it. Either Matt or I can cut a 
> 2.16.0. I don’t see the point of 2.15.1 if we are going to do this.
> 
> Ralph
> 
>> On Dec 12, 2021, at 7:49 PM, Gary Gregory  wrote:
>> 
>> I like RERO but 3 releases in a week is a lot even for me :-)
>> 
>> Gary
>> 
>>> On Sun, Dec 12, 2021 at 9:41 PM Remko Popma  wrote:
>>> It seems that Ralph has already started to work on a PR to remove message
>>> lookups altogether from 2.x.
>>> I have come around to Volkan’s point that we don’t want to ask users to
>>> upgrade Log4j every week.
>>> So it maybe better to cancel the 2.15.1 release and have a dedicated
>>> security release 2.16.0 with just the JNDI change and removing message
>>> lookups altogether.
>>> Does anyone have a strong desire to release 2.15.1 with just the JNDI
>>> change?
 On Dec 13, 2021, at 11:06, Gary Gregory  wrote:
 Should we proceed with 2.15.1 or cancel it and go to 2.16.0 straight
>>> away?
 Gary
> On Sun, Dec 12, 2021, 20:40 Remko Popma  wrote:
> I am also okay with removing Message Lookups from 2.x.
> A release with that change should be called 2.16.0 though, not 2.15.1 or
> 2.15.2.
> Also it makes sense to *only* have that security change (removing
>>> Message
> Lookups) in such a 2.16.0 release and not add other features.
> This will reduce the testing burden for people looking to upgrade.
> On Mon, Dec 13, 2021 at 8:12 Ralph Goers 
> wrote:
>> Volkan,
>> While ASF rules say a -1 vote is not a veto for all practical purposes
> the
>> release manager is going to consider it a blocker.
>> A release that removes JNDI will prevent people from inadvertently
>>> using
>> the JNDI Lookup, JMS, or JndiContextSelector
>> without understanding the security risk using them. Message Lookups
>>> are a
>> different problem. We are not disabling JNDI
>> so people can re-enable message lookups. That would be crazy. We are
>> disabling JNDI because, despite all the fixes we
>> have made, I still don’t trust it.
>> We have all agreed Message Lookups need to be killed in master. If we
>>> are
>> all in agreement to kill them now in 2.x I’m
>> fine with that but the two are separate issues.
>> If you are OK with the release than your vote should be anything but
>>> -1.
>> If you really feel it needs a -1 then we need to see
>> if we are all ok completely removing the option to re-enable message
>> lookups. I would completely understand if that is what
>> you want and I would support that so please don’t feel pressured to
>>> give
>> in.
>> Ralph
>>> On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:
>>> You don't need my vote. As far as I count, you already have more than
> 3.
>>> I can imagine Ralph and the rest have worked sleeplessly for days.
> Hence
>> if
>>> they think disabling JNDI buys us a benefit, so be it.
>>> If not millions, tens of thousands of people tried to upgrade Log4j to
>>> 2.15.0 recently. A release where JNDI lookup disabled will only adress
>>> people who still (astonishingly!) want to use "message lookups" –
> correct
>>> me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring
>> more
>>> confusion than benefit to the general audience. I think the fix to the
>>> vulnerability is to disable message lookups, not patches to the JNDI
>>> lookup. I want to believe that users get this fact right and have
> already
>>> disabled it. We need to be really careful with our next release. We
> can't
>>> expect people to upgrade once a week. Putting aside the damage it does
> to
>>> the reputation of the project.
>>> On Sun, Dec 12, 2021 at 9:47 PM Remko Popma 
>> wrote:
 First, is this really a blocker for 2.15.1?
 I think it is prudent to do urgent releases soon.
 This JNDI change (LOG4J2-3208
 ) feels urgent
>> enough
 to
 warrant another shortened vote window.
 A larger change like removing message lookups should not be rushed
>>> out
>> like
 this, it needs review time.
 Second, do we really want to do this? Are we not overreacting?
 Would it not be better to remove lookups in message parameters only?
 (In implementation terms, resolve all lookups *before* interpolating
> the
 message parameters?)
 Also, let me state the obvious, lookups *in configuration* are
>> tremendously
 useful and should not be removed.
 This

Re: [VOTE] Release Log4j 2.15.1-rc1

[Ralph Goers]

I have just put up a PR. Please review it. Either Matt or I can cut a 2.16.0. I 
don’t see the point of 2.15.1 if we are going to do this.

Ralph

> On Dec 12, 2021, at 7:49 PM, Gary Gregory  wrote:
> 
> I like RERO but 3 releases in a week is a lot even for me :-)
> 
> Gary
> 
> On Sun, Dec 12, 2021 at 9:41 PM Remko Popma  wrote:
> 
>> It seems that Ralph has already started to work on a PR to remove message
>> lookups altogether from 2.x.
>> 
>> I have come around to Volkan’s point that we don’t want to ask users to
>> upgrade Log4j every week.
>> 
>> So it maybe better to cancel the 2.15.1 release and have a dedicated
>> security release 2.16.0 with just the JNDI change and removing message
>> lookups altogether.
>> 
>> Does anyone have a strong desire to release 2.15.1 with just the JNDI
>> change?
>> 
>> 
>>> On Dec 13, 2021, at 11:06, Gary Gregory  wrote:
>>> 
>>> Should we proceed with 2.15.1 or cancel it and go to 2.16.0 straight
>> away?
>>> 
>>> Gary
>>> 
 On Sun, Dec 12, 2021, 20:40 Remko Popma  wrote:
 
 I am also okay with removing Message Lookups from 2.x.
 A release with that change should be called 2.16.0 though, not 2.15.1 or
 2.15.2.
 
 Also it makes sense to *only* have that security change (removing
>> Message
 Lookups) in such a 2.16.0 release and not add other features.
 This will reduce the testing burden for people looking to upgrade.
 
 
 
 On Mon, Dec 13, 2021 at 8:12 Ralph Goers 
 wrote:
 
> Volkan,
> 
> While ASF rules say a -1 vote is not a veto for all practical purposes
 the
> release manager is going to consider it a blocker.
> 
> A release that removes JNDI will prevent people from inadvertently
>> using
> the JNDI Lookup, JMS, or JndiContextSelector
> without understanding the security risk using them. Message Lookups
>> are a
> different problem. We are not disabling JNDI
> so people can re-enable message lookups. That would be crazy. We are
> disabling JNDI because, despite all the fixes we
> have made, I still don’t trust it.
> 
> We have all agreed Message Lookups need to be killed in master. If we
>> are
> all in agreement to kill them now in 2.x I’m
> fine with that but the two are separate issues.
> 
> If you are OK with the release than your vote should be anything but
>> -1.
> If you really feel it needs a -1 then we need to see
> if we are all ok completely removing the option to re-enable message
> lookups. I would completely understand if that is what
> you want and I would support that so please don’t feel pressured to
>> give
> in.
> 
> Ralph
> 
> 
>> On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:
>> 
>> You don't need my vote. As far as I count, you already have more than
 3.
>> 
>> I can imagine Ralph and the rest have worked sleeplessly for days.
 Hence
> if
>> they think disabling JNDI buys us a benefit, so be it.
>> 
>> If not millions, tens of thousands of people tried to upgrade Log4j to
>> 2.15.0 recently. A release where JNDI lookup disabled will only adress
>> people who still (astonishingly!) want to use "message lookups" –
 correct
>> me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring
> more
>> confusion than benefit to the general audience. I think the fix to the
>> vulnerability is to disable message lookups, not patches to the JNDI
>> lookup. I want to believe that users get this fact right and have
 already
>> disabled it. We need to be really careful with our next release. We
 can't
>> expect people to upgrade once a week. Putting aside the damage it does
 to
>> the reputation of the project.
>> 
>> On Sun, Dec 12, 2021 at 9:47 PM Remko Popma 
> wrote:
>> 
>>> First, is this really a blocker for 2.15.1?
>>> I think it is prudent to do urgent releases soon.
>>> This JNDI change (LOG4J2-3208
>>> ) feels urgent
> enough
>>> to
>>> warrant another shortened vote window.
>>> A larger change like removing message lookups should not be rushed
>> out
> like
>>> this, it needs review time.
>>> 
>>> Second, do we really want to do this? Are we not overreacting?
>>> Would it not be better to remove lookups in message parameters only?
>>> (In implementation terms, resolve all lookups *before* interpolating
 the
>>> message parameters?)
>>> 
>>> Also, let me state the obvious, lookups *in configuration* are
> tremendously
>>> useful and should not be removed.
>>> This may be obvious to some of us, but I just want to make sure there
> is no
>>> confusion about that (because I personally was confused about this at
> some
>>> point). :-)
>>> 
>>> Finally, if we decide to do this, should a change

Re: [VOTE] Release Log4j 2.15.1-rc1

[Gary Gregory]

I like RERO but 3 releases in a week is a lot even for me :-)

Gary

On Sun, Dec 12, 2021 at 9:41 PM Remko Popma  wrote:

> It seems that Ralph has already started to work on a PR to remove message
> lookups altogether from 2.x.
>
> I have come around to Volkan’s point that we don’t want to ask users to
> upgrade Log4j every week.
>
> So it maybe better to cancel the 2.15.1 release and have a dedicated
> security release 2.16.0 with just the JNDI change and removing message
> lookups altogether.
>
> Does anyone have a strong desire to release 2.15.1 with just the JNDI
> change?
>
>
> > On Dec 13, 2021, at 11:06, Gary Gregory  wrote:
> >
> > Should we proceed with 2.15.1 or cancel it and go to 2.16.0 straight
> away?
> >
> > Gary
> >
> >> On Sun, Dec 12, 2021, 20:40 Remko Popma  wrote:
> >>
> >> I am also okay with removing Message Lookups from 2.x.
> >> A release with that change should be called 2.16.0 though, not 2.15.1 or
> >> 2.15.2.
> >>
> >> Also it makes sense to *only* have that security change (removing
> Message
> >> Lookups) in such a 2.16.0 release and not add other features.
> >> This will reduce the testing burden for people looking to upgrade.
> >>
> >>
> >>
> >> On Mon, Dec 13, 2021 at 8:12 Ralph Goers 
> >> wrote:
> >>
> >>> Volkan,
> >>>
> >>> While ASF rules say a -1 vote is not a veto for all practical purposes
> >> the
> >>> release manager is going to consider it a blocker.
> >>>
> >>> A release that removes JNDI will prevent people from inadvertently
> using
> >>> the JNDI Lookup, JMS, or JndiContextSelector
> >>> without understanding the security risk using them. Message Lookups
> are a
> >>> different problem. We are not disabling JNDI
> >>> so people can re-enable message lookups. That would be crazy. We are
> >>> disabling JNDI because, despite all the fixes we
> >>> have made, I still don’t trust it.
> >>>
> >>> We have all agreed Message Lookups need to be killed in master. If we
> are
> >>> all in agreement to kill them now in 2.x I’m
> >>> fine with that but the two are separate issues.
> >>>
> >>> If you are OK with the release than your vote should be anything but
> -1.
> >>> If you really feel it needs a -1 then we need to see
> >>> if we are all ok completely removing the option to re-enable message
> >>> lookups. I would completely understand if that is what
> >>> you want and I would support that so please don’t feel pressured to
> give
> >>> in.
> >>>
> >>> Ralph
> >>>
> >>>
>  On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:
> 
>  You don't need my vote. As far as I count, you already have more than
> >> 3.
> 
>  I can imagine Ralph and the rest have worked sleeplessly for days.
> >> Hence
> >>> if
>  they think disabling JNDI buys us a benefit, so be it.
> 
>  If not millions, tens of thousands of people tried to upgrade Log4j to
>  2.15.0 recently. A release where JNDI lookup disabled will only adress
>  people who still (astonishingly!) want to use "message lookups" –
> >> correct
>  me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring
> >>> more
>  confusion than benefit to the general audience. I think the fix to the
>  vulnerability is to disable message lookups, not patches to the JNDI
>  lookup. I want to believe that users get this fact right and have
> >> already
>  disabled it. We need to be really careful with our next release. We
> >> can't
>  expect people to upgrade once a week. Putting aside the damage it does
> >> to
>  the reputation of the project.
> 
>  On Sun, Dec 12, 2021 at 9:47 PM Remko Popma 
> >>> wrote:
> 
> > First, is this really a blocker for 2.15.1?
> > I think it is prudent to do urgent releases soon.
> > This JNDI change (LOG4J2-3208
> > ) feels urgent
> >>> enough
> > to
> > warrant another shortened vote window.
> > A larger change like removing message lookups should not be rushed
> out
> >>> like
> > this, it needs review time.
> >
> > Second, do we really want to do this? Are we not overreacting?
> > Would it not be better to remove lookups in message parameters only?
> > (In implementation terms, resolve all lookups *before* interpolating
> >> the
> > message parameters?)
> >
> > Also, let me state the obvious, lookups *in configuration* are
> >>> tremendously
> > useful and should not be removed.
> > This may be obvious to some of us, but I just want to make sure there
> >>> is no
> > confusion about that (because I personally was confused about this at
> >>> some
> > point). :-)
> >
> > Finally, if we decide to do this, should a change like this be in a
> > point/bugfix release (2.15.1) or should it be a separate minor
> release
> >>> like
> > 2.16.0?
> >
> >
> >
> > On Mon, Dec 13, 2021 at 5:10 AM Remko Popma 
> >>> wrote:
> >
> >> Shall we discuss this first ple

Re: [VOTE] Release Log4j 2.15.1-rc1

[Remko Popma]

It seems that Ralph has already started to work on a PR to remove message 
lookups altogether from 2.x. 

I have come around to Volkan’s point that we don’t want to ask users to upgrade 
Log4j every week. 

So it maybe better to cancel the 2.15.1 release and have a dedicated security 
release 2.16.0 with just the JNDI change and removing message lookups 
altogether. 

Does anyone have a strong desire to release 2.15.1 with just the JNDI change?


> On Dec 13, 2021, at 11:06, Gary Gregory  wrote:
> 
> Should we proceed with 2.15.1 or cancel it and go to 2.16.0 straight away?
> 
> Gary
> 
>> On Sun, Dec 12, 2021, 20:40 Remko Popma  wrote:
>> 
>> I am also okay with removing Message Lookups from 2.x.
>> A release with that change should be called 2.16.0 though, not 2.15.1 or
>> 2.15.2.
>> 
>> Also it makes sense to *only* have that security change (removing Message
>> Lookups) in such a 2.16.0 release and not add other features.
>> This will reduce the testing burden for people looking to upgrade.
>> 
>> 
>> 
>> On Mon, Dec 13, 2021 at 8:12 Ralph Goers 
>> wrote:
>> 
>>> Volkan,
>>> 
>>> While ASF rules say a -1 vote is not a veto for all practical purposes
>> the
>>> release manager is going to consider it a blocker.
>>> 
>>> A release that removes JNDI will prevent people from inadvertently using
>>> the JNDI Lookup, JMS, or JndiContextSelector
>>> without understanding the security risk using them. Message Lookups are a
>>> different problem. We are not disabling JNDI
>>> so people can re-enable message lookups. That would be crazy. We are
>>> disabling JNDI because, despite all the fixes we
>>> have made, I still don’t trust it.
>>> 
>>> We have all agreed Message Lookups need to be killed in master. If we are
>>> all in agreement to kill them now in 2.x I’m
>>> fine with that but the two are separate issues.
>>> 
>>> If you are OK with the release than your vote should be anything but -1.
>>> If you really feel it needs a -1 then we need to see
>>> if we are all ok completely removing the option to re-enable message
>>> lookups. I would completely understand if that is what
>>> you want and I would support that so please don’t feel pressured to give
>>> in.
>>> 
>>> Ralph
>>> 
>>> 
 On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:
 
 You don't need my vote. As far as I count, you already have more than
>> 3.
 
 I can imagine Ralph and the rest have worked sleeplessly for days.
>> Hence
>>> if
 they think disabling JNDI buys us a benefit, so be it.
 
 If not millions, tens of thousands of people tried to upgrade Log4j to
 2.15.0 recently. A release where JNDI lookup disabled will only adress
 people who still (astonishingly!) want to use "message lookups" –
>> correct
 me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring
>>> more
 confusion than benefit to the general audience. I think the fix to the
 vulnerability is to disable message lookups, not patches to the JNDI
 lookup. I want to believe that users get this fact right and have
>> already
 disabled it. We need to be really careful with our next release. We
>> can't
 expect people to upgrade once a week. Putting aside the damage it does
>> to
 the reputation of the project.
 
 On Sun, Dec 12, 2021 at 9:47 PM Remko Popma 
>>> wrote:
 
> First, is this really a blocker for 2.15.1?
> I think it is prudent to do urgent releases soon.
> This JNDI change (LOG4J2-3208
> ) feels urgent
>>> enough
> to
> warrant another shortened vote window.
> A larger change like removing message lookups should not be rushed out
>>> like
> this, it needs review time.
> 
> Second, do we really want to do this? Are we not overreacting?
> Would it not be better to remove lookups in message parameters only?
> (In implementation terms, resolve all lookups *before* interpolating
>> the
> message parameters?)
> 
> Also, let me state the obvious, lookups *in configuration* are
>>> tremendously
> useful and should not be removed.
> This may be obvious to some of us, but I just want to make sure there
>>> is no
> confusion about that (because I personally was confused about this at
>>> some
> point). :-)
> 
> Finally, if we decide to do this, should a change like this be in a
> point/bugfix release (2.15.1) or should it be a separate minor release
>>> like
> 2.16.0?
> 
> 
> 
> On Mon, Dec 13, 2021 at 5:10 AM Remko Popma 
>>> wrote:
> 
>> Shall we discuss this first please?
>> 
>> On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker 
>> wrote:
>> 
>>> If you can handle that change, I can roll a new release candidate.
>>> 
>>> Matt Sicker
>>> 
 On Dec 12, 2021, at 14:07, Volkan Yazıcı  wrote:
 
 I know. I want them to be removed, not disabled.
 
> On Sun, Dec 12,

Re: [VOTE] Release Log4j 2.15.1-rc1

[Gary Gregory]

Should we proceed with 2.15.1 or cancel it and go to 2.16.0 straight away?

Gary

On Sun, Dec 12, 2021, 20:40 Remko Popma  wrote:

> I am also okay with removing Message Lookups from 2.x.
> A release with that change should be called 2.16.0 though, not 2.15.1 or
> 2.15.2.
>
> Also it makes sense to *only* have that security change (removing Message
> Lookups) in such a 2.16.0 release and not add other features.
> This will reduce the testing burden for people looking to upgrade.
>
>
>
> On Mon, Dec 13, 2021 at 8:12 Ralph Goers 
> wrote:
>
> > Volkan,
> >
> > While ASF rules say a -1 vote is not a veto for all practical purposes
> the
> > release manager is going to consider it a blocker.
> >
> > A release that removes JNDI will prevent people from inadvertently using
> > the JNDI Lookup, JMS, or JndiContextSelector
> > without understanding the security risk using them. Message Lookups are a
> > different problem. We are not disabling JNDI
> > so people can re-enable message lookups. That would be crazy. We are
> > disabling JNDI because, despite all the fixes we
> > have made, I still don’t trust it.
> >
> > We have all agreed Message Lookups need to be killed in master. If we are
> > all in agreement to kill them now in 2.x I’m
> > fine with that but the two are separate issues.
> >
> > If you are OK with the release than your vote should be anything but -1.
> > If you really feel it needs a -1 then we need to see
> > if we are all ok completely removing the option to re-enable message
> > lookups. I would completely understand if that is what
> > you want and I would support that so please don’t feel pressured to give
> > in.
> >
> > Ralph
> >
> >
> > > On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:
> > >
> > > You don't need my vote. As far as I count, you already have more than
> 3.
> > >
> > > I can imagine Ralph and the rest have worked sleeplessly for days.
> Hence
> > if
> > > they think disabling JNDI buys us a benefit, so be it.
> > >
> > > If not millions, tens of thousands of people tried to upgrade Log4j to
> > > 2.15.0 recently. A release where JNDI lookup disabled will only adress
> > > people who still (astonishingly!) want to use "message lookups" –
> correct
> > > me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring
> > more
> > > confusion than benefit to the general audience. I think the fix to the
> > > vulnerability is to disable message lookups, not patches to the JNDI
> > > lookup. I want to believe that users get this fact right and have
> already
> > > disabled it. We need to be really careful with our next release. We
> can't
> > > expect people to upgrade once a week. Putting aside the damage it does
> to
> > > the reputation of the project.
> > >
> > > On Sun, Dec 12, 2021 at 9:47 PM Remko Popma 
> > wrote:
> > >
> > >> First, is this really a blocker for 2.15.1?
> > >> I think it is prudent to do urgent releases soon.
> > >> This JNDI change (LOG4J2-3208
> > >> ) feels urgent
> > enough
> > >> to
> > >> warrant another shortened vote window.
> > >> A larger change like removing message lookups should not be rushed out
> > like
> > >> this, it needs review time.
> > >>
> > >> Second, do we really want to do this? Are we not overreacting?
> > >> Would it not be better to remove lookups in message parameters only?
> > >> (In implementation terms, resolve all lookups *before* interpolating
> the
> > >> message parameters?)
> > >>
> > >> Also, let me state the obvious, lookups *in configuration* are
> > tremendously
> > >> useful and should not be removed.
> > >> This may be obvious to some of us, but I just want to make sure there
> > is no
> > >> confusion about that (because I personally was confused about this at
> > some
> > >> point). :-)
> > >>
> > >> Finally, if we decide to do this, should a change like this be in a
> > >> point/bugfix release (2.15.1) or should it be a separate minor release
> > like
> > >> 2.16.0?
> > >>
> > >>
> > >>
> > >> On Mon, Dec 13, 2021 at 5:10 AM Remko Popma 
> > wrote:
> > >>
> > >>> Shall we discuss this first please?
> > >>>
> > >>> On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker 
> wrote:
> > >>>
> >  If you can handle that change, I can roll a new release candidate.
> > 
> >  Matt Sicker
> > 
> > > On Dec 12, 2021, at 14:07, Volkan Yazıcı  wrote:
> > >
> > > I know. I want them to be removed, not disabled.
> > >
> > >> On Sun, Dec 12, 2021 at 9:01 PM Matt Sicker 
> > >> wrote:
> > >>
> > >> Those were already disabled in 2.15.0.
> > >>
> > >> Matt Sicker
> > >>
> >  On Dec 12, 2021, at 13:41, Volkan Yazıcı 
> wrote:
> > >>>
> > >>> I very well recognize your heroic effort on tackling this issue
> > and
> >  I am
> > >>> very thankful for that.
> > >>> I vote -1, because I want message (not configuration!) lookups to
> > be
> > >>> removed.
> > >>>
> > >>> Message lookups cre

Re: [VOTE] Release Log4j 2.15.1-rc1

[Remko Popma]

I am also okay with removing Message Lookups from 2.x.
A release with that change should be called 2.16.0 though, not 2.15.1 or
2.15.2.

Also it makes sense to *only* have that security change (removing Message
Lookups) in such a 2.16.0 release and not add other features.
This will reduce the testing burden for people looking to upgrade.



On Mon, Dec 13, 2021 at 8:12 Ralph Goers  wrote:

> Volkan,
>
> While ASF rules say a -1 vote is not a veto for all practical purposes the
> release manager is going to consider it a blocker.
>
> A release that removes JNDI will prevent people from inadvertently using
> the JNDI Lookup, JMS, or JndiContextSelector
> without understanding the security risk using them. Message Lookups are a
> different problem. We are not disabling JNDI
> so people can re-enable message lookups. That would be crazy. We are
> disabling JNDI because, despite all the fixes we
> have made, I still don’t trust it.
>
> We have all agreed Message Lookups need to be killed in master. If we are
> all in agreement to kill them now in 2.x I’m
> fine with that but the two are separate issues.
>
> If you are OK with the release than your vote should be anything but -1.
> If you really feel it needs a -1 then we need to see
> if we are all ok completely removing the option to re-enable message
> lookups. I would completely understand if that is what
> you want and I would support that so please don’t feel pressured to give
> in.
>
> Ralph
>
>
> > On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:
> >
> > You don't need my vote. As far as I count, you already have more than 3.
> >
> > I can imagine Ralph and the rest have worked sleeplessly for days. Hence
> if
> > they think disabling JNDI buys us a benefit, so be it.
> >
> > If not millions, tens of thousands of people tried to upgrade Log4j to
> > 2.15.0 recently. A release where JNDI lookup disabled will only adress
> > people who still (astonishingly!) want to use "message lookups" – correct
> > me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring
> more
> > confusion than benefit to the general audience. I think the fix to the
> > vulnerability is to disable message lookups, not patches to the JNDI
> > lookup. I want to believe that users get this fact right and have already
> > disabled it. We need to be really careful with our next release. We can't
> > expect people to upgrade once a week. Putting aside the damage it does to
> > the reputation of the project.
> >
> > On Sun, Dec 12, 2021 at 9:47 PM Remko Popma 
> wrote:
> >
> >> First, is this really a blocker for 2.15.1?
> >> I think it is prudent to do urgent releases soon.
> >> This JNDI change (LOG4J2-3208
> >> ) feels urgent
> enough
> >> to
> >> warrant another shortened vote window.
> >> A larger change like removing message lookups should not be rushed out
> like
> >> this, it needs review time.
> >>
> >> Second, do we really want to do this? Are we not overreacting?
> >> Would it not be better to remove lookups in message parameters only?
> >> (In implementation terms, resolve all lookups *before* interpolating the
> >> message parameters?)
> >>
> >> Also, let me state the obvious, lookups *in configuration* are
> tremendously
> >> useful and should not be removed.
> >> This may be obvious to some of us, but I just want to make sure there
> is no
> >> confusion about that (because I personally was confused about this at
> some
> >> point). :-)
> >>
> >> Finally, if we decide to do this, should a change like this be in a
> >> point/bugfix release (2.15.1) or should it be a separate minor release
> like
> >> 2.16.0?
> >>
> >>
> >>
> >> On Mon, Dec 13, 2021 at 5:10 AM Remko Popma 
> wrote:
> >>
> >>> Shall we discuss this first please?
> >>>
> >>> On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker  wrote:
> >>>
>  If you can handle that change, I can roll a new release candidate.
> 
>  Matt Sicker
> 
> > On Dec 12, 2021, at 14:07, Volkan Yazıcı  wrote:
> >
> > I know. I want them to be removed, not disabled.
> >
> >> On Sun, Dec 12, 2021 at 9:01 PM Matt Sicker 
> >> wrote:
> >>
> >> Those were already disabled in 2.15.0.
> >>
> >> Matt Sicker
> >>
>  On Dec 12, 2021, at 13:41, Volkan Yazıcı  wrote:
> >>>
> >>> I very well recognize your heroic effort on tackling this issue
> and
>  I am
> >>> very thankful for that.
> >>> I vote -1, because I want message (not configuration!) lookups to
> be
> >>> removed.
> >>>
> >>> Message lookups create a vast attack surface. Anything they offer
> >> can
> >>> simply be implemented by the user.
> >>>
>  On Sun, Dec 12, 2021 at 4:48 AM 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

Re: [VOTE] Release Log4j 2.15.1-rc1

[Ralph Goers]

Volkan,

While ASF rules say a -1 vote is not a veto for all practical purposes the 
release manager is going to consider it a blocker.

A release that removes JNDI will prevent people from inadvertently using the 
JNDI Lookup, JMS, or JndiContextSelector 
without understanding the security risk using them. Message Lookups are a 
different problem. We are not disabling JNDI 
so people can re-enable message lookups. That would be crazy. We are disabling 
JNDI because, despite all the fixes we 
have made, I still don’t trust it.

We have all agreed Message Lookups need to be killed in master. If we are all 
in agreement to kill them now in 2.x I’m 
fine with that but the two are separate issues. 

If you are OK with the release than your vote should be anything but -1. If you 
really feel it needs a -1 then we need to see 
if we are all ok completely removing the option to re-enable message lookups. I 
would completely understand if that is what 
you want and I would support that so please don’t feel pressured to give in.

Ralph


> On Dec 12, 2021, at 2:08 PM, Volkan Yazıcı  wrote:
> 
> You don't need my vote. As far as I count, you already have more than 3.
> 
> I can imagine Ralph and the rest have worked sleeplessly for days. Hence if
> they think disabling JNDI buys us a benefit, so be it.
> 
> If not millions, tens of thousands of people tried to upgrade Log4j to
> 2.15.0 recently. A release where JNDI lookup disabled will only adress
> people who still (astonishingly!) want to use "message lookups" – correct
> me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring more
> confusion than benefit to the general audience. I think the fix to the
> vulnerability is to disable message lookups, not patches to the JNDI
> lookup. I want to believe that users get this fact right and have already
> disabled it. We need to be really careful with our next release. We can't
> expect people to upgrade once a week. Putting aside the damage it does to
> the reputation of the project.
> 
> On Sun, Dec 12, 2021 at 9:47 PM Remko Popma  wrote:
> 
>> First, is this really a blocker for 2.15.1?
>> I think it is prudent to do urgent releases soon.
>> This JNDI change (LOG4J2-3208
>> ) feels urgent enough
>> to
>> warrant another shortened vote window.
>> A larger change like removing message lookups should not be rushed out like
>> this, it needs review time.
>> 
>> Second, do we really want to do this? Are we not overreacting?
>> Would it not be better to remove lookups in message parameters only?
>> (In implementation terms, resolve all lookups *before* interpolating the
>> message parameters?)
>> 
>> Also, let me state the obvious, lookups *in configuration* are tremendously
>> useful and should not be removed.
>> This may be obvious to some of us, but I just want to make sure there is no
>> confusion about that (because I personally was confused about this at some
>> point). :-)
>> 
>> Finally, if we decide to do this, should a change like this be in a
>> point/bugfix release (2.15.1) or should it be a separate minor release like
>> 2.16.0?
>> 
>> 
>> 
>> On Mon, Dec 13, 2021 at 5:10 AM Remko Popma  wrote:
>> 
>>> Shall we discuss this first please?
>>> 
>>> On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker  wrote:
>>> 
 If you can handle that change, I can roll a new release candidate.
 
 Matt Sicker
 
> On Dec 12, 2021, at 14:07, Volkan Yazıcı  wrote:
> 
> I know. I want them to be removed, not disabled.
> 
>> On Sun, Dec 12, 2021 at 9:01 PM Matt Sicker 
>> wrote:
>> 
>> Those were already disabled in 2.15.0.
>> 
>> Matt Sicker
>> 
 On Dec 12, 2021, at 13:41, Volkan Yazıcı  wrote:
>>> 
>>> I very well recognize your heroic effort on tackling this issue and
 I am
>>> very thankful for that.
>>> I vote -1, because I want message (not configuration!) lookups to be
>>> removed.
>>> 
>>> Message lookups create a vast attack surface. Anything they offer
>> can
>>> simply be implemented by the user.
>>> 
 On Sun, Dec 12, 2021 at 4:48 AM 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
>

Re: [VOTE] Release Log4j 2.15.1-rc1

[Volkan Yazıcı]

You don't need my vote. As far as I count, you already have more than 3.

I can imagine Ralph and the rest have worked sleeplessly for days. Hence if
they think disabling JNDI buys us a benefit, so be it.

If not millions, tens of thousands of people tried to upgrade Log4j to
2.15.0 recently. A release where JNDI lookup disabled will only adress
people who still (astonishingly!) want to use "message lookups" – correct
me if I'm wrong. Hence, I think in its current form, 2.15.1 will bring more
confusion than benefit to the general audience. I think the fix to the
vulnerability is to disable message lookups, not patches to the JNDI
lookup. I want to believe that users get this fact right and have already
disabled it. We need to be really careful with our next release. We can't
expect people to upgrade once a week. Putting aside the damage it does to
the reputation of the project.

On Sun, Dec 12, 2021 at 9:47 PM Remko Popma  wrote:

> First, is this really a blocker for 2.15.1?
> I think it is prudent to do urgent releases soon.
> This JNDI change (LOG4J2-3208
> ) feels urgent enough
> to
> warrant another shortened vote window.
> A larger change like removing message lookups should not be rushed out like
> this, it needs review time.
>
> Second, do we really want to do this? Are we not overreacting?
> Would it not be better to remove lookups in message parameters only?
> (In implementation terms, resolve all lookups *before* interpolating the
> message parameters?)
>
> Also, let me state the obvious, lookups *in configuration* are tremendously
> useful and should not be removed.
> This may be obvious to some of us, but I just want to make sure there is no
> confusion about that (because I personally was confused about this at some
> point). :-)
>
> Finally, if we decide to do this, should a change like this be in a
> point/bugfix release (2.15.1) or should it be a separate minor release like
> 2.16.0?
>
>
>
> On Mon, Dec 13, 2021 at 5:10 AM Remko Popma  wrote:
>
> > Shall we discuss this first please?
> >
> > On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker  wrote:
> >
> >> If you can handle that change, I can roll a new release candidate.
> >>
> >> Matt Sicker
> >>
> >> > On Dec 12, 2021, at 14:07, Volkan Yazıcı  wrote:
> >> >
> >> > I know. I want them to be removed, not disabled.
> >> >
> >> >> On Sun, Dec 12, 2021 at 9:01 PM Matt Sicker 
> wrote:
> >> >>
> >> >> Those were already disabled in 2.15.0.
> >> >>
> >> >> Matt Sicker
> >> >>
> >>  On Dec 12, 2021, at 13:41, Volkan Yazıcı  wrote:
> >> >>>
> >> >>> I very well recognize your heroic effort on tackling this issue and
> >> I am
> >> >>> very thankful for that.
> >> >>> I vote -1, because I want message (not configuration!) lookups to be
> >> >>> removed.
> >> >>>
> >> >>> Message lookups create a vast attack surface. Anything they offer
> can
> >> >>> simply be implemented by the user.
> >> >>>
> >>  On Sun, Dec 12, 2021 at 4:48 AM 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 <
> >>  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 <
> >>  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
> <
> >>  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/ <
> >>  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-

Re: [VOTE] Release Log4j 2.15.1-rc1

[Remko Popma]

On Mon, Dec 13, 2021 at 5:47 AM Remko Popma  wrote:

> First, is this really a blocker for 2.15.1?
> I think it is prudent to do urgent releases soon.
> This JNDI change (LOG4J2-3208
> ) feels urgent enough
> to warrant another shortened vote window.
> A larger change like removing message lookups should not be rushed out
> like this, it needs review time.
>
> Second, do we really want to do this? Are we not overreacting?
> Would it not be better to remove lookups in message parameters only?
> (In implementation terms, resolve all lookups *before* interpolating the
> message parameters?)
>
> Also, let me state the obvious, lookups *in configuration* are
> tremendously useful and should not be removed.
> This may be obvious to some of us, but I just want to make sure there is
> no confusion about that (because I personally was confused about this at
> some point). :-)
>
> Finally, if we decide to do this, should a change like this be in a
> point/bugfix release (2.15.x) or should it be a separate minor release like
> 2.16.0?
>

Personally, my preference would be to go ahead with the 2.15.1 release as
it stands (containing only LOG4J2-3208
).
Further improvements can be done incrementally in future releases.


>
>
> On Mon, Dec 13, 2021 at 5:10 AM Remko Popma  wrote:
>
>> Shall we discuss this first please?
>>
>> On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker  wrote:
>>
>>> If you can handle that change, I can roll a new release candidate.
>>>
>>> Matt Sicker
>>>
>>> > On Dec 12, 2021, at 14:07, Volkan Yazıcı  wrote:
>>> >
>>> > I know. I want them to be removed, not disabled.
>>> >
>>> >> On Sun, Dec 12, 2021 at 9:01 PM Matt Sicker  wrote:
>>> >>
>>> >> Those were already disabled in 2.15.0.
>>> >>
>>> >> Matt Sicker
>>> >>
>>>  On Dec 12, 2021, at 13:41, Volkan Yazıcı  wrote:
>>> >>>
>>> >>> I very well recognize your heroic effort on tackling this issue and
>>> I am
>>> >>> very thankful for that.
>>> >>> I vote -1, because I want message (not configuration!) lookups to be
>>> >>> removed.
>>> >>>
>>> >>> Message lookups create a vast attack surface. Anything they offer can
>>> >>> simply be implemented by the user.
>>> >>>
>>>  On Sun, Dec 12, 2021 at 4:48 AM 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 <
>>>  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 <
>>>  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 <
>>>  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/ <
>>>  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

[Remko Popma]

First, is this really a blocker for 2.15.1?
I think it is prudent to do urgent releases soon.
This JNDI change (LOG4J2-3208
) feels urgent enough to
warrant another shortened vote window.
A larger change like removing message lookups should not be rushed out like
this, it needs review time.

Second, do we really want to do this? Are we not overreacting?
Would it not be better to remove lookups in message parameters only?
(In implementation terms, resolve all lookups *before* interpolating the
message parameters?)

Also, let me state the obvious, lookups *in configuration* are tremendously
useful and should not be removed.
This may be obvious to some of us, but I just want to make sure there is no
confusion about that (because I personally was confused about this at some
point). :-)

Finally, if we decide to do this, should a change like this be in a
point/bugfix release (2.15.1) or should it be a separate minor release like
2.16.0?



On Mon, Dec 13, 2021 at 5:10 AM Remko Popma  wrote:

> Shall we discuss this first please?
>
> On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker  wrote:
>
>> If you can handle that change, I can roll a new release candidate.
>>
>> Matt Sicker
>>
>> > On Dec 12, 2021, at 14:07, Volkan Yazıcı  wrote:
>> >
>> > I know. I want them to be removed, not disabled.
>> >
>> >> On Sun, Dec 12, 2021 at 9:01 PM Matt Sicker  wrote:
>> >>
>> >> Those were already disabled in 2.15.0.
>> >>
>> >> Matt Sicker
>> >>
>>  On Dec 12, 2021, at 13:41, Volkan Yazıcı  wrote:
>> >>>
>> >>> I very well recognize your heroic effort on tackling this issue and
>> I am
>> >>> very thankful for that.
>> >>> I vote -1, because I want message (not configuration!) lookups to be
>> >>> removed.
>> >>>
>> >>> Message lookups create a vast attack surface. Anything they offer can
>> >>> simply be implemented by the user.
>> >>>
>>  On Sun, Dec 12, 2021 at 4:48 AM 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 <
>>  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 <
>>  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 <
>>  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/ <
>>  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

[Remko Popma]

Shall we discuss this first please?

On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker  wrote:

> If you can handle that change, I can roll a new release candidate.
>
> Matt Sicker
>
> > On Dec 12, 2021, at 14:07, Volkan Yazıcı  wrote:
> >
> > I know. I want them to be removed, not disabled.
> >
> >> On Sun, Dec 12, 2021 at 9:01 PM Matt Sicker  wrote:
> >>
> >> Those were already disabled in 2.15.0.
> >>
> >> Matt Sicker
> >>
>  On Dec 12, 2021, at 13:41, Volkan Yazıcı  wrote:
> >>>
> >>> I very well recognize your heroic effort on tackling this issue and I
> am
> >>> very thankful for that.
> >>> I vote -1, because I want message (not configuration!) lookups to be
> >>> removed.
> >>>
> >>> Message lookups create a vast attack surface. Anything they offer can
> >>> simply be implemented by the user.
> >>>
>  On Sun, Dec 12, 2021 at 4:48 AM 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 <
>  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 <
>  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 <
>  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/ <
>  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 you can handle that change, I can roll a new release candidate.

Matt Sicker

> On Dec 12, 2021, at 14:07, Volkan Yazıcı  wrote:
> 
> I know. I want them to be removed, not disabled.
> 
>> On Sun, Dec 12, 2021 at 9:01 PM Matt Sicker  wrote:
>> 
>> Those were already disabled in 2.15.0.
>> 
>> Matt Sicker
>> 
 On Dec 12, 2021, at 13:41, Volkan Yazıcı  wrote:
>>> 
>>> I very well recognize your heroic effort on tackling this issue and I am
>>> very thankful for that.
>>> I vote -1, because I want message (not configuration!) lookups to be
>>> removed.
>>> 
>>> Message lookups create a vast attack surface. Anything they offer can
>>> simply be implemented by the user.
>>> 
 On Sun, Dec 12, 2021 at 4:48 AM 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 <
 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 <
 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 <
 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/ <
 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

[Volkan Yazıcı]

I know. I want them to be removed, not disabled.

On Sun, Dec 12, 2021 at 9:01 PM Matt Sicker  wrote:

> Those were already disabled in 2.15.0.
>
> Matt Sicker
>
> > On Dec 12, 2021, at 13:41, Volkan Yazıcı  wrote:
> >
> > I very well recognize your heroic effort on tackling this issue and I am
> > very thankful for that.
> > I vote -1, because I want message (not configuration!) lookups to be
> > removed.
> >
> > Message lookups create a vast attack surface. Anything they offer can
> > simply be implemented by the user.
> >
> >> On Sun, Dec 12, 2021 at 4:48 AM 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 <
> >> 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 <
> >> 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 <
> >> 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/ <
> >> 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]

Those were already disabled in 2.15.0.

Matt Sicker

> On Dec 12, 2021, at 13:41, Volkan Yazıcı  wrote:
> 
> I very well recognize your heroic effort on tackling this issue and I am
> very thankful for that.
> I vote -1, because I want message (not configuration!) lookups to be
> removed.
> 
> Message lookups create a vast attack surface. Anything they offer can
> simply be implemented by the user.
> 
>> On Sun, Dec 12, 2021 at 4:48 AM 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 <
>> 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 <
>> 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 <
>> 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/ <
>> 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

[Volkan Yazıcı]

I very well recognize your heroic effort on tackling this issue and I am
very thankful for that.
I vote -1, because I want message (not configuration!) lookups to be
removed.

Message lookups create a vast attack surface. Anything they offer can
simply be implemented by the user.

On Sun, Dec 12, 2021 at 4:48 AM 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 <
> 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 <
> 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 <
> 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/ <
> 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]

This is what I see on the console and printing the exception from the
debugger:

13:42:06,505 |-INFO in ch.qos.logback.classic.LoggerContext[default] -
Found resource [logback-test.xml] at
[file:/C:/d3vsrc/git/apache/logging-log4j2-2.x/log4j-core/target/test-classes/logback-test.xml]
13:42:06,763 |-INFO in
ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute
not set
13:42:06,773 |-INFO in ch.qos.logback.core.joran.action.AppenderAction -
About to instantiate appender of type [ch.qos.logback.core.FileAppender]
13:42:06,801 |-INFO in ch.qos.logback.core.joran.action.AppenderAction -
Naming appender as [TestLogfile]
13:42:06,829 |-INFO in
ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default
type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder]
property
13:42:06,833 |-WARN in
ch.qos.logback.classic.encoder.PatternLayoutEncoder@61df66b6 - As of
version 1.2.0 "immediateFlush" property should be set within the enclosing
Appender.
13:42:06,833 |-WARN in
ch.qos.logback.classic.encoder.PatternLayoutEncoder@61df66b6 - Please move
"immediateFlush" property into the enclosing appender.
13:42:06,978 |-WARN in
ch.qos.logback.classic.encoder.PatternLayoutEncoder@61df66b6 - Setting the
"immediateFlush" property of the enclosing appender to false
13:42:06,978 |-INFO in ch.qos.logback.core.FileAppender[TestLogfile] - File
property is set to [target/testlogback.log]
13:42:06,985 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction
- Setting level of ROOT logger to DEBUG
13:42:06,985 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction -
Attaching appender named [TestLogfile] to Logger[ROOT]
13:42:06,987 |-INFO in
ch.qos.logback.classic.joran.action.ConfigurationAction - End of
configuration.
13:42:06,989 |-INFO in
ch.qos.logback.classic.joran.JoranConfigurator@50eac852 - Registering
current configuration as safe fallback point

*javax.naming.NameNotFoundException: DNS name not found [response code 3];
remaining name 'apache.org '*
at com.sun.jndi.dns.DnsClient.checkResponseCode(DnsClient.java:660)
at com.sun.jndi.dns.DnsClient.isMatchResponse(DnsClient.java:578)
at com.sun.jndi.dns.DnsClient.doUdpQuery(DnsClient.java:426)
at com.sun.jndi.dns.DnsClient.query(DnsClient.java:211)
at com.sun.jndi.dns.Resolver.query(Resolver.java:81)
at com.sun.jndi.dns.DnsContext.c_lookup(DnsContext.java:290)
at
com.sun.jndi.toolkit.ctx.ComponentContext.p_lookup(ComponentContext.java:542)
at
com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:177)
at
com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:205)
at javax.naming.InitialContext.lookup(InitialContext.java:417)
at
org.apache.logging.log4j.core.net.JndiManager.lookup(JndiManager.java:273)
at
org.apache.logging.log4j.core.lookup.JndiLookup.lookup(JndiLookup.java:56)
at
org.apache.logging.log4j.core.lookup.AbstractLookup.lookup(AbstractLookup.java:33)
at
org.apache.logging.log4j.core.lookup.JndiRestrictedLookupTest.testDnsLookup(JndiRestrictedLookupTest.java:152)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.zapodot.junit.ldap.internal.EmbeddedLdapRuleImpl$1.evaluate(EmbeddedLdapRuleImpl.java:154)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(For

Re: [VOTE] Release Log4j 2.15.1-rc1

[Ralph Goers]

I’ve verified the 512 SHAs are ok and run the build ok. After getting Matt to 
update the KEYS file his signature now verifies properly.

+1

Ralph



> On Dec 12, 2021, at 10:26 AM, Ralph Goers  wrote:
> 
> I don’t. But of course I wrote that test. It verifies that if you add dns as 
> a supported protocol that it can find apache.org. Running 
> it under the debugger it returns a DnsContext for me, which JndiLookup 
> converts to a String which frankly isn’t very useful.
> 
> com.sun.jndi.dns.DnsContext@4bdcaf36
> 
> Can you run it under the debugger and see what happens inside JndiManager? I 
> would expect you are getting an exception.
> 
> I should probably consider creating a bogus JNDI protocol and registering it 
> for that test instead of doing something real.
> 
> Ralph
> 
>> On Dec 12, 2021, at 8:51 AM, Gary Gregory  wrote:
>> 
>> Also, on Windows 10 and Java 8:
>> 
>> [ERROR] Failures:
>> [ERROR]   JndiRestrictedLookupTest.testDnsLookup:154 No DNS data returned
>> [INFO]
>> [ERROR] Tests run: 2244, Failures: 1, Errors: 0, Skipped: 11
>> [INFO]
>> 
>> Does anyone else get that?
>> 
>> Gary
>> 
>> 
>> On Sun, Dec 12, 2021 at 9:07 AM Gary Gregory  wrote:
>> 
>>> +1
>>> 
>>> *- I cannot get revapi:check to work on the log4j-api module due to some
>>> weird maven dependency issue I cannot resolve, may someone confirm that
>>> this check passes?*
>>> 
>>> - Apache RAT check OK
>>> - mvn clean package
>>> 
>>> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
>>> Maven home: /usr/local/Cellar/maven/3.8.4/libexec
>>> Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
>>> /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
>>> Default locale: en_US, platform encoding: UTF-8
>>> OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
>>> 
>>> Darwin *** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT
>>> 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64
>>> 
>>> On Sat, Dec 11, 2021 at 10:48 PM 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 <
 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 <
 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 <
 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/ <
 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

[Carter Kozak]

+1

mvn clean && mvn install
rat passes
$ mvn -v
Apache Maven 3.6.3
Maven home: /usr/share/maven
Java version: 1.8.0_282, vendor: Azul Systems, Inc., runtime: 
/home/ckozak/.tools/jdk/zulu8.52.0.23-ca-jdk8.0.282-linux_x64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.13.0-22-generic", arch: "amd64", family: "unix"

On Sat, Dec 11, 2021, at 22: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

[Ron Grabowski]

 +1 for Log4j 2.15.1-rc1, I accidently replied to the wrong thread earlier.
mvn clean install -t toolchains-sample-win.xmlmvn apache-rat:checkmvn 
revapi:check -pl log4j-api
Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)Maven home: 
C:\projects\apache-maven-3.8.4Java version: 1.8.0_181, vendor: Oracle 
Corporation, runtime: C:\Program Files\Java\jdk1.8.0_181\jreDefault locale: 
en_US, platform encoding: Cp1252OS name: "windows 10", version: "10.0", arch: 
"amd64", family: "windows"

On Sunday, December 12, 2021, 09:07:52 AM EST, Gary Gregory 
 wrote:  
 
 +1

*- I cannot get revapi:check to work on the log4j-api module due to some
weird maven dependency issue I cannot resolve, may someone confirm that
this check passes?*

- Apache RAT check OK
- mvn clean package

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /usr/local/Cellar/maven/3.8.4/libexec
Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"

Darwin *** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT
2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64

On Sat, Dec 11, 2021 at 10:48 PM 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 <
> 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 <
> 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 <
> 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/ <
> 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]

I don’t. But of course I wrote that test. It verifies that if you add dns as a 
supported protocol that it can find apache.org. Running 
it under the debugger it returns a DnsContext for me, which JndiLookup converts 
to a String which frankly isn’t very useful.

com.sun.jndi.dns.DnsContext@4bdcaf36

Can you run it under the debugger and see what happens inside JndiManager? I 
would expect you are getting an exception.

I should probably consider creating a bogus JNDI protocol and registering it 
for that test instead of doing something real.

Ralph

> On Dec 12, 2021, at 8:51 AM, Gary Gregory  wrote:
> 
> Also, on Windows 10 and Java 8:
> 
> [ERROR] Failures:
> [ERROR]   JndiRestrictedLookupTest.testDnsLookup:154 No DNS data returned
> [INFO]
> [ERROR] Tests run: 2244, Failures: 1, Errors: 0, Skipped: 11
> [INFO]
> 
> Does anyone else get that?
> 
> Gary
> 
> 
> On Sun, Dec 12, 2021 at 9:07 AM Gary Gregory  wrote:
> 
>> +1
>> 
>> *- I cannot get revapi:check to work on the log4j-api module due to some
>> weird maven dependency issue I cannot resolve, may someone confirm that
>> this check passes?*
>> 
>> - Apache RAT check OK
>> - mvn clean package
>> 
>> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
>> Maven home: /usr/local/Cellar/maven/3.8.4/libexec
>> Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
>> /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
>> Default locale: en_US, platform encoding: UTF-8
>> OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
>> 
>> Darwin *** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT
>> 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64
>> 
>> On Sat, Dec 11, 2021 at 10:48 PM 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 <
>>> 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 <
>>> 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 <
>>> 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/ <
>>> 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]

Also, on Windows 10 and Java 8:

[ERROR] Failures:
[ERROR]   JndiRestrictedLookupTest.testDnsLookup:154 No DNS data returned
[INFO]
[ERROR] Tests run: 2244, Failures: 1, Errors: 0, Skipped: 11
[INFO]

Does anyone else get that?

Gary


On Sun, Dec 12, 2021 at 9:07 AM Gary Gregory  wrote:

> +1
>
> *- I cannot get revapi:check to work on the log4j-api module due to some
> weird maven dependency issue I cannot resolve, may someone confirm that
> this check passes?*
>
> - Apache RAT check OK
> - mvn clean package
>
> Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
> Maven home: /usr/local/Cellar/maven/3.8.4/libexec
> Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
> /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"
>
> Darwin *** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT
> 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64
>
> On Sat, Dec 11, 2021 at 10:48 PM 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 <
>> 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 <
>> 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 <
>> 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/ <
>> 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]

+1

*- I cannot get revapi:check to work on the log4j-api module due to some
weird maven dependency issue I cannot resolve, may someone confirm that
this check passes?*

- Apache RAT check OK
- mvn clean package

Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537)
Maven home: /usr/local/Cellar/maven/3.8.4/libexec
Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime:
/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac"

Darwin *** 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT
2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64

On Sat, Dec 11, 2021 at 10:48 PM 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 <
> 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 <
> 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 <
> 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/ <
> 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

[Remko Popma]

+1
build succeeds, all tests pass

Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117;
2019-08-28T00:06:16+09:00)
Maven home: C:\apps\apache-maven-3.6.2\bin\..
Java version: 1.8.0_202, vendor: Oracle Corporation, runtime:
C:\apps\jdk1.8.0_202\jre
Default locale: en_GB, platform encoding: MS932
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"



On Sun, Dec 12, 2021 at 1:39 PM Gary Gregory  wrote:

> 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/
> >
>

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/
>

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

[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/