Re: [DISCUSS] replacing Log4j1 as default logging backend

[Istvan Toth <st...@apache.org>]

I've gone ahead with Andrew's suggestion, and opened PHOENIX-6637 with a PR.

Please review and comment/approve.
I plan to do the same on all branches and on the PQS and Connectors repo as
well.
I haven't checked OMID yet.

On Mon, Jan 17, 2022 at 1:48 PM Istvan Toth <st...@apache.org> wrote:

> Thanks Andrew!
>
> While I think we should eventually move to one of the more up-to-date
> solutions I listed,
> this looks like a great short-term solution.
> The fact that it is maintained by the original log4j author lends it extra
> credibility.
>
> Istvan
>
> On Sat, Jan 15, 2022 at 5:27 AM Andrew Purtell <ap...@apache.org>
> wrote:
>
>> Reload4J might be an acceptable solution if you need a CVE free logging
>> back end with log4j1 compatibility.
>>
>> On Wed, Jan 12, 2022 at 6:16 AM Istvan Toth <st...@apache.org> wrote:
>>
>> > Hi!
>> >
>> > While we have avoided the worst of the recent Log4j2 vulnerabilities,
>> due
>> > to using the long abandoned Log4j1 libraries, we should consider
>> replacing
>> > the default logging implementation.
>> >
>> >  Log4j1 als has a number open CVEs, and even if none of them as
>> critical as
>> > the main Log4j2 was, including abandoned code in the distribution is
>> not a
>> > good practice.
>> >
>> > Luckily, we have already migrated all logging to slf4j, so any backend
>> > changes require minimal to none (java) code changes, we mostly need to
>> > update the startup scripts, config files, and binary assemblies.
>> >
>> > The phoenix-server binary does not include a logging backend, and will
>> use
>> > whatever the HBase installation uses.
>> >
>> > The recommended phoenix-client-embedded JDBC driver/client doesn't
>> include
>> > logging backed either, so it's up to end user to add one.
>> >
>> > The only places where we add a logging backend is sqlline, which
>> currently
>> > uses phoenix-client-embedded, and adds the logging backend JAR
>> separately,
>> > the legacy phoenix-client JAR, and the PQS server JAR. (IIRC we the OMID
>> > TSO is not shaded, and the backend is added from a /lib directory)
>> >
>> > I would personally also prefer to remove the legacy phoenix-client.jar
>> from
>> > 5.2/4.16 onwards.
>> >
>> > So basically we are talking about the logging implementation used by the
>> > sqlline.py,
>> > Phoenix Query Server, and the OMID TSO daemon.
>> >
>> > Some options:
>> >
>> > * Keep log4j1
>> > + No work
>> > + supports Java 7
>> > - Unmaitained
>> > - Users are increasingly (and rightfully) paranoid about out of support
>> > packages with open CVEs
>> >
>> > * Switch to logback
>> > + Similar config to log4j1
>> > + Smallish codebase (~400k)
>> > + Supports Java 7
>> > - Hbase 3 uses log4j2
>> >
>> > * Switch to slf4j2
>> > + Hbase 3 uses log4j2
>> > - Entirely new config format
>> > - Bigger codebase (~1800k for log4j2-core)
>> > - Latest version does not support Java 7
>> >
>> > * Switch to Java.util.logging
>> > + included in the JDK/JRE
>> > + No need to update / track CVEs separately
>> > - New config format
>> > - Less powerful than the others, which is especially problematic for
>> PQS /
>> > OMID TSO, which need "real" logging
>> >
>> > We could theoretically also mix and match these, for example use j.u.l
>> for
>> > sqlline.py , and logback or slf4j2 for PQS and Omid TSO, which already
>> > require Java 8 anyway.
>> >
>> > Please share your thoughts
>> > * Are you OK with dropping phoenix-client in the next minor release, and
>> > making phoenix-client-embedded the only option ?
>> > * Which backend do you prefer ? If we choose log4j2 do we leave 4.x on
>> > log4j1 ?
>> > * How important is alignment with the HBase logging backend ? (and is
>> the
>> > HBase decision to go with log4j2 final ?)
>> > * When should we switch ?
>> > * Any killer feature that one bakcend has the others don't ?
>> > * Anything that comes to your mind
>> >
>> > regards
>> > Istvan
>> >
>> --
>> Best regards,
>> Andrew
>>
>> Words like orphans lost among the crosstalk, meaning torn from truth's
>> decrepit hands
>>    - A23, Crosstalk
>>
>