completely agree, Rohit. On Mon, Jan 31, 2022 at 8:01 AM Rohit Yadav <rohit.ya...@shapeblue.com> wrote:
> All, > > Given there are no objections or other thoughts discussed on the thread, I > propose the following: > > * Short-term: switch to reload4j which is a drop-in replacement and > has published a few releases since last two weeks (seems active), this will > require less effort for the benefit of updates/fixes that we'll get > immediately. > > * Long-term: refactor the logging usage across codebase with a utility > wrapper (in cloud-utils) where the logging library can be replaced with > something like logback (which seems more mature and maintained). The > long-term option can be discussed after we move to the drop-in replacement > and it turns out to be not maintained or has issues. > > I've started a WIP PR draft for the short-term solution > https://github.com/apache/cloudstack/pull/5878 > > > > Regards. > > ________________________________ > From: Daan Hoogland <daan.hoogl...@gmail.com> > Sent: Wednesday, January 19, 2022 18:23 > To: dev <dev@cloudstack.apache.org> > Cc: us...@cloudstack.apache.org <us...@cloudstack.apache.org> > Subject: Re: [DISCUSS] Log4j migration > > As I was involved it shouldn't come as a surprise to anyone that I agree > with Rohit on all he says here. > There was one consideration that we (both) abandoned quite early on; making > a pluggable framework for logging in which one can add their own preferred > library. We do not think it is worth the effort, but as a GSoC project or > if someone is willing to sponsor that it can still be put back on the > table. > I have a slight preference for the wrapper solution but am open to any > input from everyone. > > On Wed, Jan 19, 2022 at 1:17 PM Rohit Yadav <rohit.ya...@shapeblue.com> > wrote: > > > All, > > > > Following log4jshell advisory [1], I want to start a discussion thread > > around what next steps should we follow. > > > > Overview: The log4j 1.x has limited feature set and didn't have the same > > attack surface as log4j 2.x, this saved the ACS community from log4jshell > > [1]. In addition, our uber/fat jar build process since (last few years) > > only bundles classes from dependency jars that CloudStack management > server > > codebase requires; this may benefit that certain classes which could be > > exploit-able in 1.x weren't actually shadowed/bundled in the > > cloudstack-management uber/fat jar[2]. This strategy reduces the > CloudStack > > management uber/far jar's attack surface greatly. > > > > What is used in CloudStack: (details investigated with my colleague Daan) > > > > * Basic logging feature (console/file/rsyslog appenders, log levels, > > log4j config file) > > * Context-aware logging (this includes full/abbreviated class/package > > name, and sometimes specific context, > > > > LogContext and CallContext have some example use of MDC, NDC) > > > > * Stacktrace upon exception, a custom CglibThrowableRenderer class > > * Jar dependencies used: log4j v1.2.17, and apache-log4j-extras > v1.2.17 > > > > As the next step, I think it would be better to refactor the logging > usage > > to a new loggging utility in cloud-utils which can be used throughout the > > codebase, and this utility can in-turn wrap whatever logging library we > use > > and reduce our dependency on any logging library/version and swiftly > change > > logging library. The utility may also allow us to centrally add custom > > cloudstack feature (such as context-aware logging, manage stacktrace > output > > etc). > > > > I did some research to look at possible options for the community: > > > > 1. Status-Quo, stick with log4j 1.x: this is not ideal, as v1.2.17 was > > the last release in 1.x which has reach EOL [3]. > > 2. Migrate to 2.x: this is probably what is advised by the Apache > > Logging PMC [4] since 1.x has EOL, however: > > * 1.x pretty much sufficed our requirements of a logging library > > and 2.x has a large attack surface. > > * > > * Other Apache projects (such as hadoop, hive etc) are facing > while > > migrating their large codebases to log4j 2.x; the migration will require > > time, effort, and testing. The 2.x migration guide would require a lot of > > manual effort, there is no tooling to do this at scale. > > * On Twitter, some of the Logging PMC have advised that their v3 > > architecture will make log4j modular and lower attach surfaces. > > * My opinion: Logging library shouldn't try to do anything beyond > > logging, I'm less confident in migrating to 2.x after seeing how the CVE > > was handled by the Logging PMC and I didn't have a good interaction with > > them in a ML discussion thread. For an ASF TLP that is asked to adhere to > > the 'community over code' spirit, the user community isn't listend to and > > in a ML thread, it was deemed that any 1.x fork/maintenance would be > > considered "hostile" - this has led to interested sponsors and PMCs of > > other Apache projects joining forces with Ceki to continue log4j 1.x fork > > outside of ASF (see below). > > 3. Migrate to 1.x fork, drop-in replacement: Ceki (one of the > > developers of log4j 1.x, also behind sl4j and logback) has started a fork > > of 1.x under the name reload4j with which they continue 1.x support and > > address bugs/CVEs. They have already published v1.2.18 > > https://github.com/qos-ch/reload4j this is already finding a lot of > > support with a lot of users. > > 4. Migrate to logback: This is another project by Ceki/qos-ch, which > > aims to continue 1.x work while keeping logging library robust/small, > uses > > sl4j. https://logback.qos.ch/ > > > > Thoughts, what/where should we go, any other alternatives we should > > explore? > > > > [1] https://blogs.apache.org/cloudstack/entry/log4jshell > > > > [2] https://maven.apache.org/plugins/maven-shade-plugin/ > > > > [3] > > > https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces > > > > [4] https://logging.apache.org/log4j/2.x/ > > > > > > Regards. > > > > > > > > > > -- > Daan > > > > -- Daan
