Re: [DISCUSS] Log4j migration

[Daan Hoogland <da...@gmail.com>]

completely agree, Rohit.

On Mon, Jan 31, 2022 at 8:01 AM Rohit Yadav <ro...@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 <da...@gmail.com>
> Sent: Wednesday, January 19, 2022 18:23
> To: dev <de...@cloudstack.apache.org>
> Cc: users@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 <ro...@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