EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Log4Shell approaches
From: "Carriveau, Anthony via Tech-talk" <tech-talk at aps.anl.gov>
To: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Tue, 14 Dec 2021 14:43:09 +0000

Hi Murali,

 

I have always been a fan of slf4j, as it’s an abstraction layer between application code and the logging implementation you choose.  I switched to using slf4j+logback in applications long ago, but local installations should be able to select whatever logging implementation (presuming it’s supported, and most major ones are) for their logging needs.

 

it does appear that this community is switching to log4j2, and Spring Boot itself will be switching to that as the default logging implemetation in the near future.  Those two endorsements alone are probably enough reason to make a decision of log4j2 as a default logging solution.

 

I would still recommend considering using slf4j though, and I recently rediscovered that my last project used slf4j+log4j2, so I know from personal experience that it works fine.  The real power is that sites can select whatever logging implementation they desire by dropping in the necessary libraries, recompiling, and testing.

 

Thanks

Anthony

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Matt Clarke via Tech-talk
Sent: Tuesday, December 14, 2021 1:42 AM
To: tech-talk at aps.anl.gov
Subject: Re: Log4Shell approaches

 

[EXTERNAL] This email originated from outside of FRIB

Hi.

 

As far as I understand, the security issue has been fixed so updating should be sufficient.

 

From the Logback page: “Fortunately, logback is unrelated to log4j 2.x and does not share its vulnerabilities.”

If I was cynical I might read that as “it probably has its own unique vulnerabilities which haven’t been found yet” ;)

 

Ultimately, like a lot of OSS, both projects seem to be maintained by a handful of core developers.

 

Cheers,

 

Matt

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of "Shankar, Murali via Tech-talk" <tech-talk at aps.anl.gov>
Reply-To: "Shankar, Murali" <mshankar at slac.stanford.edu>
Date: Monday, 13 December 2021 at 18:58
To: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Subject: Log4Shell approaches

 

We were wondering if others had any recommendations on this. That is, should we continue using/migrating to log4j2 ( and hope the security issues are fixed ) or should we consider alternatives like logback etc. Any thoughts are appreciated.

 

Regards,

Murali

 


References:
Log4Shell approaches Shankar, Murali via Tech-talk
Re: Log4Shell approaches Matt Clarke via Tech-talk

Navigate by Date:
Prev: EPICS_DB_INCLUDE_PATH Alfio Rizzo via Tech-talk
Next: Re: Photonic Science X-ray FDS camera Mark Rivers via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
Navigate by Thread:
Prev: Re: Log4Shell approaches Jörn Dreyer via Tech-talk
Next: arv-tools not detecting USB3 camera Gofron, Kazimierz via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
ANJ, 14 Dec 2021 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·