On Thu, Nov 2, 2023, at 02:12, Ralph Goers wrote:
> Christian, I was at least 3 years ahead of you on this one.This is
Sorry I was not active for a while. Good you were here.
> precisely why in 3.x we extracted a LOT of stuff from log4j-core into
> their own modules.
Why not 2.x?
> 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.
I understand, Jpms support was added to 2.x recently. Can we do the same thing
for 2.x?
> 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.
In this case we need to improve our communication a lot. The main website is
still showing all cves and I didn’t find the information easily that I just
asked for.
As you mentioned, this issue is history for three years but the website still
looks like all hell is loose.
I believe you it is safe (always did after all the countless reviews), but
people still don’t.
With all that said splitting the repos for2.x still feels right.
Christian
> 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
>>>>
