Re: Log4j mitigation

[Alain Hebert <ahebert () pubnix net>]

    Well,

    In my experience, it is a really widely used library.  It has been 
pretty much the de-facto standard for logging for a long while.


IMHO

    So anything Java (and exposed obviously) need a review...


Best Practices

    As a standard we always tent to push our customers to more 
light-weight logging library with less magic.


PS: And it is not the first time Log4j ended causing headaches... For 
those wondering.  I remember back in 2017 when everyone was angrily 
saying they'll change for something else...

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=log4j

-----
Alain Hebertahebert () pubnix net    
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770     Beaconsfield, Quebec     H9W 6G7
Tel: 514-990-5911http://www.pubnix.net     Fax: 514-990-9443

On 12/13/21 14:24, Owen DeLong via NANOG wrote:
> The bigger problem seems to be the ever growing list of products you may be using which depend on it potentially 
> without your knowledge.
>
> Owen
>
>
> > On Dec 11, 2021, at 03:41 , Jared Mauch<jared () puck nether net>  wrote:
> >
> > This is largely a patching exercise for people that use the software. If you use it, please patch.
> >
> > Sent via RFC1925 complaint device
> >
> > > On Dec 10, 2021, at 10:59 PM, Andy Ringsmuth<andy () andyring com>  wrote:
> > >
> > > The intricacies of Java are over my head, but I’ve been reading about this Log4j issue that sounds pretty bad.
> > >
> > > What do we know about this? What, if anything, can a network operator do to help mitigate this? Or even an end user?
> > >
> > > ----
> > > Andy Ringsmuth
> > > 5609 Harding Drive
> > > Lincoln, NE 68521-5831
> > > (402) 304-0083
> > > andy () andyring com