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