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 <[email protected]> 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
