[Starlingx-discuss] Is there Log4j security vulnerability in Starlingx 5.0?
Hi Team, You might have heard about log4j library security vulnerability. I would like to know if this security flaw is also in STX 5.0 or not? If so, then is there any solution. Mit freundlichen Grüßen/ with best regards, Yatindra Shashi IoTG DE- Intel Corporation Munich, Germany Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
On 2022-01-05 11:08:13 +0000 (+0000), Shashi, Yatindra wrote:
You might have heard about log4j library security vulnerability. I would like to know if this security flaw is also in STX 5.0 or not? If so, then is there any solution.
While it's just a part of StarlingX so not at all a complete answer, I started a discussion within the OpenStack Security SIG on the same topic: https://lists.openstack.org/pipermail/openstack-discuss/2022-January/026490.... None of OpenStack is directly affected since it's written in Python, not Java, but some things people often install alongside it may be impacted (OpenDaylight, Elasticsearch, et cetera). Hope that helps. I too am curious to know the complete answer as pertains to the whole of the StarlingX distribution. -- Jeremy Stanley
StarlingX is NOT impacted by log4j library security vulnerability. Greg. From: Shashi, Yatindra <yatindra.shashi@intel.com> Sent: Wednesday, January 5, 2022 6:08 AM To: starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] Is there Log4j security vulnerability in Starlingx 5.0? [Please note: This e-mail is from an EXTERNAL e-mail address] Hi Team, You might have heard about log4j library security vulnerability. I would like to know if this security flaw is also in STX 5.0 or not? If so, then is there any solution. Mit freundlichen Grüßen/ with best regards, Yatindra Shashi IoTG DE- Intel Corporation Munich, Germany Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de<https://urldefense.com/v3/__http:/www.intel.de__;!!AjveYdw8EvQ!IWnwqm2n8XwvL8YV8B7cEJsB4Q2pfbKDtAEDMl-VQKVTY2nqiFfcVB1ZWclHRhpGeBk$> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
On 2022-01-05 15:16:54 +0000 (+0000), Waines, Greg wrote:
StarlingX is NOT impacted by log4j library security vulnerability. [...]
Is that because an installation of StarlingX results in no Java-based software on the systems, or that the Java-based software installed does not use the Log4j library, or uses it but does not use vulnerable versions, or for some other reason? Thanks for the details! -- Jeremy Stanley
Correct. -----Original Message----- From: Jeremy Stanley <fungi@yuggoth.org> Sent: Wednesday, January 5, 2022 10:26 AM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Is there Log4j security vulnerability in Starlingx 5.0? [Please note: This e-mail is from an EXTERNAL e-mail address] On 2022-01-05 15:16:54 +0000 (+0000), Waines, Greg wrote:
StarlingX is NOT impacted by log4j library security vulnerability. [...]
Is that because an installation of StarlingX results in no Java-based software on the systems, or that the Java-based software installed does not use the Log4j library, or uses it but does not use vulnerable versions, or for some other reason? Thanks for the details! -- Jeremy Stanley
Hi Jeremy, Just to clarify, there is no java used in StarlingX. Regards, Ghada -----Original Message----- From: Waines, Greg <Greg.Waines@windriver.com> Sent: Thursday, January 06, 2022 1:56 PM To: Jeremy Stanley <fungi@yuggoth.org>; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Is there Log4j security vulnerability in Starlingx 5.0? Correct. -----Original Message----- From: Jeremy Stanley <fungi@yuggoth.org> Sent: Wednesday, January 5, 2022 10:26 AM To: starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Is there Log4j security vulnerability in Starlingx 5.0? [Please note: This e-mail is from an EXTERNAL e-mail address] On 2022-01-05 15:16:54 +0000 (+0000), Waines, Greg wrote:
StarlingX is NOT impacted by log4j library security vulnerability. [...]
Is that because an installation of StarlingX results in no Java-based software on the systems, or that the Java-based software installed does not use the Log4j library, or uses it but does not use vulnerable versions, or for some other reason? Thanks for the details! -- Jeremy Stanley _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On 2022-01-11 14:37:51 +0000 (+0000), Khalil, Ghada wrote:
Just to clarify, there is no java used in StarlingX. [...]
That's not quite the same as saying that an installation of StarlingX will result in no Java on the systems, but I assume it's what you meant. The investigation in OpenStack is starting to turn up more corner cases than just Neutron's support for the Java-based OpenDaylight service. It's come to light that Kolla will install Elasticsearch if centralized logging is configured, while Monasca and CloudKitty can both use Elasticsearch as their storage backend. From your statement, it sounds like StarlingX deployments make use of none of those components, so should be unaffected. Thanks again for all the info! -- Jeremy Stanley
On 2022-01-11 14:37:51 +0000 (+0000), Khalil, Ghada wrote:
Just to clarify, there is no java used in StarlingX. [...]
That's not quite the same as saying that an installation of StarlingX will result in no Java on the systems, but I assume it's what you meant.
[[GK]] Yes that's what I meant. Apologies for not being clear. [...]
participants (4)
-
Jeremy Stanley
-
Khalil, Ghada
-
Shashi, Yatindra
-
Waines, Greg