> On Oct 29, 2025, at 4:33 PM, sebb <[email protected]> wrote:
>
> On Wed, 29 Oct 2025 at 18:34, Vladimir Sitnikov
> <[email protected]> wrote:
>>
>>> commit introduced from merging a user-provided patch. It went through the
>> entire review process
>>
>> As far as I understand, log4shell was effectively caused by "all features
>> in a single jar" design.
>> If log4j had multiple jar files, then the users could depend only on the
>> features they
>> use, so the impact of the CVE would be much less.
>>
>> At the same time, the patch of "allow jndi resolution" could land on its
>> own jar, so it would impact a subset of the users only.
>> Code review could catch the issue of adding too many features to the single
>> jar.
>>
>> ---
>>
>> Here's the similar case in commons-lang:
>> A recent CVE-2025-48924 relates to ClassUtils while commons-lang is
>> often used for its StringUtils only.
>>
>> If commons-lang was modular like commons-stringutils, commons-classutils,
>> and so on,
>> then it would be much more secure for the end-users.
>>
>> Here's a question: what do you think of releasing commons-stringutils.jar
>> with StringUtils and Strings clases only?
>>
>> Frankly, many projects use only StringUtils, yet they suffer from
>> accidental CVEs in one of the classes they never use.
>
> Surely if they don't use the classes, then they cannot be affected by
> a CVE that applies to such a class?
>
+1, peanuts. Will consider LocaleUtils, And maybe AudioUtils, and maybe
SystemUtils….direction unclear.
Cheers,
CRTIII
>> Vladimir
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
