Christian, I was at least 3 years ahead of you on this one.This is precisely why in 3.x we extracted a LOT of stuff from log4j-core into their own modules. To be honest the main driver was JPMS - our goal for 3.x Is for log4j-core to only have a hard dependency on java.base and as few optional dependencies as possible. So when Log4Shell hit we moved all the JNDI stuff out of log4j-core AND require a property to be set to use it even if you include the jar containing the JNDI support. In addition, JNDI can now only access the java protocol or no protocol. So yes, it is very safe now.
Ralph > On Nov 1, 2023, at 12:22 PM, Christian Grobmeier <grobme...@apache.org> wrote: > > As some might know, I am writing a book and the publisher gathers a lot of > feedback. Also I talk to many people in my classrooms and also to many pros > at my clients side. > > What I hear is usually: > - is log4j really secure? > - can’t I disable certain features? > - are you sure you get jndi right this time? > > It always comes up why I don’t recommend some competition instead. > > We should not underestimate the impact log4shell had. Jndi was at the epi > center. Us, providing a giant jar including so much stuff with potential > security holes don’t do us a favor. > > If we think we have to maintain it, ok, but why can’t we extract it to its > own dependency? > > Btw, re your comment on -1: I do not plan to do anything against consensus. > Actually I seek consensus and try to understand better why we still have this > stuff and what we can do to improve perception . In general I feel the > atmosphere in this project has heated up more than it should. > > > On Wed, Nov 1, 2023, at 17:29, Matt Sicker wrote: >> I don’t see any reason why we shouldn’t publish the JNDI support in its >> own module as we’re planning in main already. Whether we eventually >> split out anything from the main repo is another story, but in 3.x, >> JNDI, like most of the optional features, will require downloading >> additional dependencies to explicitly opt in to using the feature (plus >> the JNDI stuff has an additional property you have to set to enable it, >> so you can’t end up with JNDI integration by accident even if the >> dependency is available). That seems fairly safe to me, and the >> naysayers at that point tend to be the same people who prefer >> printf-logging or using C because they’re elite programmers who never >> make mistakes and always design things perfectly decades ahead of time. >> >>> On Nov 1, 2023, at 7:18 AM, Apache <ralph.go...@dslextreme.com> wrote: >>> >>> >>> If you want separate logging config files in an EJB environment using JNDI >>> is pretty much required. The same would be true for any properties needed >>> in the configuration. >>> >>> In any case, despite Piotr saying this is a majority vote, it is not. I >>> will veto any attempt to remove JNDI components so one really needs to view >>> this vote in the light that any component receiving a -1 vote cannot be >>> removed as it will simply get a -1 when the PR/commit is attempted from >>> whomever gave the -1 vote. In other words, this is NOT a procedural vote >>> but a code modification vote that is taking place before the code is >>> modified. >>> >>> Ralph >>> >>>> On Nov 1, 2023, at 3:13 AM, Christian Grobmeier <grobme...@apache.org> >>>> wrote: >>>> >>>> On Wed, Nov 1, 2023, at 00:01, Ralph Goers wrote: >>>>> There is a difference between a JEE application that only uses servlets >>>>> vs one that uses EJBs. At a former employer we often used JBoss to run >>>>> servlets even though we had no EJBs. In an environment with EJBs I am >>>>> not sure how you can distinguish the various components from each other >>>>> without JNDI. >>>> >>>> I understand that in the EJB world you would need JNDI, but I fail to >>>> understand how your EJBs would use Log4j JNDI features? It appears to me >>>> that while EE world needs it, the Logging world does not necessary need it >>>> >>>>> >>>>> Ralph >>>>> >>>>>> On Oct 31, 2023, at 3:12 PM, Volkan Yazıcı <vol...@yazi.ci> wrote: >>>>>> Piotr, I think it is important to differentiate what is a requirement and >>>>>> what is just another way of achieving something. My employer has several >>>>>> Tomcat- and JBoss-based JEE applications (using Log4j) and we don't have >>>>>> a >>>>>> single JNDI usage I know of. >>>>>> I would like to hear "the functional need" that can't be done in a JEE >>>>>> application without JNDI. My emphasis is important, since "using JNDI" is >>>>>> not a functional need. >>>>>> On Tue, Oct 31, 2023 at 10:55 PM Piotr P. Karwasz >>>>>> <piotr.karw...@gmail.com> >>>>>> wrote: >>>>>>> Hi Christian, >>>>>>> On Tue, 31 Oct 2023 at 21:57, Christian Grobmeier <grobme...@apache.org> >>>>>>> wrote: >>>>>>>> I am surprised we still have JNDI in the code at all, but this made me >>>>>>> curious: >>>>>>>> why do JEE users need JNDI features for logging? Why can't they just >>>>>>>> use >>>>>>> the normal log mechanism? >>>>>>> JNDI is basically a bean container/factory that allows Java EE >>>>>>> applications to retrieve database connection pools, message queues or >>>>>>> mail sessions (and remote code as a bonus). >>>>>>> For the JMS appender, JNDI is essential. >>>>>>> For the JDBC appender there is an alternative: DBCP2 can provide a >>>>>>> database connection pool via a special connection string. >>>>>>> The SMTP appender does not use JNDI as far as I remember. >>>>>>> Of course there is an alternative to JNDI also in the Java EE world >>>>>>> (CDI), but it doesn't work with simple servlet containers like Tomcat. >>>>>>> Piotr >>>
