On Sat, Nov 5, 2022, 09:09 Elliotte Rusty Harold <elh...@ibiblio.org> wrote:
> After log4shell last year, I no longer have any patience for third > party logging libraries, full stop. > Uh? CVEs have occurred in all types of libraries, there is nothing about logging that makes it more CVE-prone. You might as well be talking about all third party libraries. Gary > IMO logging should be done through java.util.logging, nothing else. > This is fully functional since Java 1.4 twenty years ago. Log4j, > slf4j, plexus-logging, etc. are all efforts to solve a problem we > don't have any more. They are not needed and they introduce dependency > problems and security issues. > > For one example, Google has used java.util.logging exclusively in all > its internal Java code since at least 2008 and never needed anything > more. This is a matter of policy inside Google, and as a result of > this log4shell was close to a non-event for one of the largest Java > shops on the planet. It wasn't a complete non-event only because of > third party libraries that depended on log4j and open source projects > that weren't quite as strict about following Google rules. > > To the extent Maven and its plugins are currently dependent on SLF4J > and others, this should be fixed. We should not continue down this > path in any new or updated code. To be clear: > > 1. I am willing to do some of the work of ripping out old logging > calls and replacing them with j.u.l. > > 2. It is OK to have mixed logging during a transition period. > > 3. It is OK if some log messages are lost or appear when they're not > expected during a transition period. Logging is never critical > functionality. > > What I am not willing to accept are dependency management problems and > major security holes like log4shell due to optional, convenience > functionality. > > On Fri, Nov 4, 2022 at 10:57 AM Slawomir Jaranowski > <s.jaranow...@gmail.com> wrote: > > > > Hi, > > > > I want to start ( again :-) ) a discussion about logging in Maven > plugins. > > > > First I agree that plugin developers should use logging methods provided > by > > Plugin api. > > > > But we can not expect plugin developers to write everything from scratch. > > In many cases they may want to use an external library to do tasks needed > > by the plugin. > > > > We don't have any control over what logging framework is used in the > > external library used by plugin developers. > > > > We also maintain some libraries which can be used by plugin and also as > > standalone in another project. > > In such a case the question is - what logging we should use [1]? > > > > Last time I did a test, I use Java util logging from JDK in the Maven > > plugin. > > I see that Java util logging use default configuration, eg. we will have > > two lines for one log event. > > Even more options -q and -X have no effect for such a logger. > > > > One of the solution for such problem is using "Bridging" methods > supported > > by slf4j [2] > > Probably all of existing and future logging frameworks can not be > covered - > > but most of common using will be. > > > > I hope that, even if we will want to change the logging framework used > > internally in Maven, we can also use the same method. > > > > [1] https://github.com/apache/maven-dependency-analyzer/pull/71 > > [2] https://www.slf4j.org/legacy.html > > > > > > -- > > Sławomir Jaranowski > > > > -- > Elliotte Rusty Harold > elh...@ibiblio.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
