Log4j mitigation

Mon Dec 13 20:01:06 UTC 2021

     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 at 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 at 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 at 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 at andyring.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20211213/0b283694/attachment.html>