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
