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 <remko.po...@gmail.com> 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 <ralph.go...@dslextreme.com>
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ı <vol...@yazi.ci> 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 <remko.po...@gmail.com>
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
<https://issues.apache.org/jira/browse/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 <remko.po...@gmail.com>
wrote:

Shall we discuss this first please?

On Mon, Dec 13, 2021 at 5:10 AM Matt Sicker <boa...@gmail.com>
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ı <vol...@yazi.ci> wrote:

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

On Sun, Dec 12, 2021 at 9:01 PM Matt Sicker <boa...@gmail.com>
wrote:

Those were already disabled in 2.15.0.

Matt Sicker

On Dec 12, 2021, at 13:41, Volkan Yazıcı <vol...@yazi.ci>
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 <boa...@gmail.com>
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/









Reply via email to