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