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