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