SPDX Gen Meeting Follow up- Mistake and Thanks
|
Phil Odence
All,
It hit me, out of the blue when I awoke this morning, that in Thursday’s General Meeting I neglected to mention and give thanks to May Wang for her contributions in serving on the Steering Committee. May is the IOT CTO of Palo Alto Networks and generously raised her hand to be one of two first Member Reps after we put the new Governance processes in place. She has been a consistent contributor to the Steering Committee and, I know, plans to stay active in our project for the future.
THANKS, May, and apologies for my spacing out. I’ve amended the Meeting Minutes accordingly.
Best, Phil
L. Philip Odence General Manager, Black Duck Audit Business Synopsys Software Integrity Group, Burlington, MA M (781) 258-9502 | phil.odence@... https://www.synopsys.com/audits
|
||||||||
|
|
||||||||
|
May Wang
Thank you, Phil, the members of the SPDX Steering Committee, and the SPDX Community. I am grateful for the fruitful year we have had working together. This year, we released the first loT SBOM product by Palo Alto Networks based on SPDX. Such a significant milestone couldn't have been possible without your support and leadership. I look forward to our continued collaboration to advance the adoption of SPDX and foster innovation in SBOM, especially in cybersecurity. May Wang, Ph.D. | CTO, IoT Security Palo Alto Networks | 3000 Tannery Way | Santa Clara, CA 95054 | USA Email: may@... | www.paloaltonetworks.com
The content of this message is the proprietary and confidential property of Palo Alto Networks, and should be treated as such. If you are not the intended recipient and have received this message in error, please delete this message from your computer system and notify me immediately by e-mail. Any unauthorized use or distribution of the content of this message is prohibited. |
||||||||
|
|
||||||||
|
Thanks May.
Two questions:
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
From: spdx@... <spdx@...> On Behalf Of May Wang via lists.spdx.org
Sent: Tuesday, April 11, 2023 12:05 AM To: Phil Odence <Phil.Odence@...> Cc: SPDX-general <spdx@...> Subject: Re: [spdx] SPDX Gen Meeting Follow up- Mistake and Thanks
Thank you, Phil, the members of the SPDX Steering Committee, and the SPDX Community.
I am grateful for the fruitful year we have had working together. This year, we released the first loT SBOM product by Palo Alto Networks based on SPDX. Such a significant milestone couldn't have been possible without your support and leadership. I look forward to our continued collaboration to advance the adoption of SPDX and foster innovation in SBOM, especially in cybersecurity.
-- May Wang, Ph.D. | CTO, IoT Security Palo Alto Networks | 3000 Tannery Way | Santa Clara, CA 95054 | USA Email: may@... | www.paloaltonetworks.com
The content of this message is the proprietary and confidential property of Palo Alto Networks, and should be treated as such. If you are not the intended recipient and have received this message in error, please delete this message from your computer system and notify me immediately by e-mail. Any unauthorized use or distribution of the content of this message is prohibited.
|
||||||||
|
|
||||||||
|
May Wang
Dick, Thank you for your questions. 1. Our spdx-based IoT SBOM is available to all our customers. I am not sure about the specific "testing purposes" you are referring to, happy to talk more details offline. 2. Good question. In addition to the SBOM info, we also provided links from SBOM to vulnerabilities, based on our own vulnerability database and some CVEs for now. We do plan to 1) expand to more vulnerability databases and CVEs. 2) expand to cover more devices. 3) the latest NIST VDR document provides good guidance but did not prescribe specific format, we will closely follow up any updates from NIST. Thank you, -- May Wang, Ph.D. | CTO, IoT Security Palo Alto Networks | 3000 Tannery Way | Santa Clara, CA 95054 | USA Email: may@... | www.paloaltonetworks.com
The content of this message is the proprietary and confidential property of Palo Alto Networks, and should be treated as such. If you are not the intended recipient and have received this message in error, please delete this message from your computer system and notify me immediately by e-mail. Any unauthorized use or distribution of the content of this message is prohibited. On Tue, Apr 11, 2023 at 5:10 AM Dick Brooks <dick@...> wrote:
|
||||||||
|
|
||||||||
|
May,
Thank you for the quick response.
With regard to testing; some of the spdx tool vendors conduct interoperability testing by sharing artifacts and reporting on any issues encountered. The DocFest is a formal version of this testing. Would Palo Alto Networks be willing to share their SPDX artifacts, confidentially, with spdx tool vendors for interoperability testing purposes only?
I agree with your findings on the NIST VDR; NIST identified the VDR data to be included, but not a specific format. There are two open source NIST VDR “interpretation” formats available, one from OWASP CycloneDX and the other from REA: Here’s an example of the open-source REA VDR format: https://raw.githubusercontent.com/rjb4standards/REA-Products/master/SBOMVDR_JSON/VDR_118.json
I also wrote an article describing the NIST SBOM VDR that ties back to the SP 800-161 standard and other NIST materials where VDR is referenced: https://energycentral.com/c/pip/what-nist-sbom-vulnerability-disclosure-report-vdr
FYI: REA has offered to withdraw it’s VDR format if the industry agrees to endorse the CycloneDX VDR format. Also, note, REA offered to freely transfer its open-source VDR format to the Linux Foundation, when it was first introduced; the offer was never acted on.
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
From: spdx@... <spdx@...> On Behalf Of May Wang via lists.spdx.org
Sent: Wednesday, April 12, 2023 2:59 AM To: spdx@... Cc: Phil Odence <Phil.Odence@...> Subject: Re: [spdx] SPDX Gen Meeting Follow up- Mistake and Thanks
Dick,
Thank you for your questions.
1. Our spdx-based IoT SBOM is available to all our customers. I am not sure about the specific "testing purposes" you are referring to, happy to talk more details offline.
2. Good question. In addition to the SBOM info, we also provided links from SBOM to vulnerabilities, based on our own vulnerability database and some CVEs for now. We do plan to 1) expand to more vulnerability databases and CVEs. 2) expand to cover more devices. 3) the latest NIST VDR document provides good guidance but did not prescribe specific format, we will closely follow up any updates from NIST.
Thank you, -- May Wang, Ph.D. | CTO, IoT Security Palo Alto Networks | 3000 Tannery Way | Santa Clara, CA 95054 | USA Email: may@... | www.paloaltonetworks.com
The content of this message is the proprietary and confidential property of Palo Alto Networks, and should be treated as such. If you are not the intended recipient and have received this message in error, please delete this message from your computer system and notify me immediately by e-mail. Any unauthorized use or distribution of the content of this message is prohibited.
On Tue, Apr 11, 2023 at 5:10 AM Dick Brooks <dick@...> wrote:
|
||||||||
|
|
||||||||
|
Joseph Silvia
Hello Dick,
You stated the REA has offered to withdraw it’s VDR format if the industry agrees to endorse the CycloneDX VDR format. Can you provide more details on the similarities and differences between the REA and CycloneDX VDR format?
Thanks, Joe
Joseph D. Silvia 1055 Thomas Jefferson St. NW, Suite 304 Washington, DC 20007 Office:732.906.6142 Mobile:781.526.5636 |
jsilvia@...
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
From: spdx@... <spdx@...> On Behalf Of
Dick Brooks
Sent: Wednesday, April 12, 2023 7:55 AM To: spdx@... Cc: 'Phil Odence' <Phil.Odence@...> Subject: Re: [spdx] SPDX Gen Meeting Follow up- Mistake and Thanks
May,
Thank you for the quick response.
With regard to testing; some of the spdx tool vendors conduct interoperability testing by sharing artifacts and reporting on any issues encountered. The DocFest is a formal version of this testing. Would Palo Alto Networks be willing to share their SPDX artifacts, confidentially, with spdx tool vendors for interoperability testing purposes only?
I agree with your findings on the NIST VDR; NIST identified the VDR data to be included, but not a specific format. There are two open source NIST VDR “interpretation” formats available, one from OWASP CycloneDX and the other from REA: Here’s an example of the open-source REA VDR format: https://raw.githubusercontent.com/rjb4standards/REA-Products/master/SBOMVDR_JSON/VDR_118.json
I also wrote an article describing the NIST SBOM VDR that ties back to the SP 800-161 standard and other NIST materials where VDR is referenced: https://energycentral.com/c/pip/what-nist-sbom-vulnerability-disclosure-report-vdr
FYI: REA has offered to withdraw it’s VDR format if the industry agrees to endorse the CycloneDX VDR format. Also, note, REA offered to freely transfer its open-source VDR format to the Linux Foundation, when it was first introduced; the offer was never acted on.
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
From: spdx@... <spdx@...>
On Behalf Of May Wang via
lists.spdx.org
Dick,
Thank you for your questions.
1. Our spdx-based IoT SBOM is available to all our customers. I am not sure about the specific "testing purposes" you are referring to, happy to talk more details offline.
2. Good question. In addition to the SBOM info, we also provided links from SBOM to vulnerabilities, based on our own vulnerability database and some CVEs for now. We do plan to 1) expand to more vulnerability databases and CVEs. 2) expand to cover more devices. 3) the latest NIST VDR document provides good guidance but did not prescribe specific format, we will closely follow up any updates from NIST.
Thank you, -- May Wang, Ph.D. | CTO, IoT Security Palo Alto Networks | 3000 Tannery Way | Santa Clara, CA 95054 | USA Email: may@... | www.paloaltonetworks.com
The content of this message is the proprietary and confidential property of Palo Alto Networks, and should be treated as such. If you are not the intended recipient and have received this message in error, please delete this message from your computer system and notify me immediately by e-mail. Any unauthorized use or distribution of the content of this message is prohibited.
On Tue, Apr 11, 2023 at 5:10 AM Dick Brooks <dick@...> wrote:
|
||||||||
|
|
||||||||
|
Hi Joe,
Both formats satisfy the NIST VDR data requirements identified in SP 800-161 RA-5, IMO.
REA uses an explicit model, listing each component and its vulnerability search status, including those with no vulnerabilities reported. It also supports SPDX and CycloneDX SBOM formats.
The CycloneDX VDR format uses an implicit model, listing only those components with reported vulnerabilities. I believe it can support both SPDX and CycloneDX SBOM formats, but I’ve not seen an SPDX representation.
The easiest way to see the differences is to view an example of each:
REA VDR: https://raw.githubusercontent.com/rjb4standards/REA-Products/master/SBOMVDR_JSON/VDR_118.json
CycloneDX VDR: https://raw.githubusercontent.com/rjb4standards/REA-Products/master/CDXVEX/CDX14.xml
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
From: spdx@... <spdx@...> On Behalf Of Joseph Silvia via lists.spdx.org
Sent: Wednesday, April 12, 2023 8:14 AM To: spdx@... Cc: 'Phil Odence' <Phil.Odence@...> Subject: Re: [spdx] SPDX Gen Meeting Follow up- Mistake and Thanks
Hello Dick,
You stated the REA has offered to withdraw it’s VDR format if the industry agrees to endorse the CycloneDX VDR format. Can you provide more details on the similarities and differences between the REA and CycloneDX VDR format?
Thanks, Joe
Joseph D. Silvia 1055 Thomas Jefferson St. NW, Suite 304 Washington, DC 20007 Office:732.906.6142 Mobile:781.526.5636 | jsilvia@...
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
From: spdx@... <spdx@...> On Behalf Of Dick Brooks
May,
Thank you for the quick response.
With regard to testing; some of the spdx tool vendors conduct interoperability testing by sharing artifacts and reporting on any issues encountered. The DocFest is a formal version of this testing. Would Palo Alto Networks be willing to share their SPDX artifacts, confidentially, with spdx tool vendors for interoperability testing purposes only?
I agree with your findings on the NIST VDR; NIST identified the VDR data to be included, but not a specific format. There are two open source NIST VDR “interpretation” formats available, one from OWASP CycloneDX and the other from REA: Here’s an example of the open-source REA VDR format: https://raw.githubusercontent.com/rjb4standards/REA-Products/master/SBOMVDR_JSON/VDR_118.json
I also wrote an article describing the NIST SBOM VDR that ties back to the SP 800-161 standard and other NIST materials where VDR is referenced: https://energycentral.com/c/pip/what-nist-sbom-vulnerability-disclosure-report-vdr
FYI: REA has offered to withdraw it’s VDR format if the industry agrees to endorse the CycloneDX VDR format. Also, note, REA offered to freely transfer its open-source VDR format to the Linux Foundation, when it was first introduced; the offer was never acted on.
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
From: spdx@... <spdx@...> On Behalf Of May Wang via lists.spdx.org
Dick,
Thank you for your questions.
1. Our spdx-based IoT SBOM is available to all our customers. I am not sure about the specific "testing purposes" you are referring to, happy to talk more details offline.
2. Good question. In addition to the SBOM info, we also provided links from SBOM to vulnerabilities, based on our own vulnerability database and some CVEs for now. We do plan to 1) expand to more vulnerability databases and CVEs. 2) expand to cover more devices. 3) the latest NIST VDR document provides good guidance but did not prescribe specific format, we will closely follow up any updates from NIST.
Thank you, -- May Wang, Ph.D. | CTO, IoT Security Palo Alto Networks | 3000 Tannery Way | Santa Clara, CA 95054 | USA Email: may@... | www.paloaltonetworks.com
The content of this message is the proprietary and confidential property of Palo Alto Networks, and should be treated as such. If you are not the intended recipient and have received this message in error, please delete this message from your computer system and notify me immediately by e-mail. Any unauthorized use or distribution of the content of this message is prohibited.
On Tue, Apr 11, 2023 at 5:10 AM Dick Brooks <dick@...> wrote:
|
||||||||
|
|
||||||||
|
Joseph Silvia
Hi Dick,
Thank you so much for the explanation. I have yet to see an SPDX representation as well and trying to wrap my head around some of these SBOM challenges in the Medical Device space where many MDMs are using a combination of FOSS, COTS and OTS in the development of their software not to mention who knows what contract manufacturers are using.
@May Do you know what the impact of all of this means in regard to IoMT and in particular, 62304 with the requirement to identify SOUP items?
Thanks, Joe
Joseph D. Silvia 1055 Thomas Jefferson St. NW, Suite 304 Washington, DC 20007 Office:732.906.6142 Mobile:781.526.5636 |
jsilvia@...
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
From: spdx@... <spdx@...> On Behalf Of
Dick Brooks
Sent: Wednesday, April 12, 2023 8:25 AM To: spdx@... Cc: 'Phil Odence' <Phil.Odence@...> Subject: Re: [spdx] SPDX Gen Meeting Follow up- Mistake and Thanks
Hi Joe,
Both formats satisfy the NIST VDR data requirements identified in SP 800-161 RA-5, IMO.
REA uses an explicit model, listing each component and its vulnerability search status, including those with no vulnerabilities reported. It also supports SPDX and CycloneDX SBOM formats.
The CycloneDX VDR format uses an implicit model, listing only those components with reported vulnerabilities. I believe it can support both SPDX and CycloneDX SBOM formats, but I’ve not seen an SPDX representation.
The easiest way to see the differences is to view an example of each:
REA VDR: https://raw.githubusercontent.com/rjb4standards/REA-Products/master/SBOMVDR_JSON/VDR_118.json
CycloneDX VDR: https://raw.githubusercontent.com/rjb4standards/REA-Products/master/CDXVEX/CDX14.xml
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
From: spdx@... <spdx@...>
On Behalf Of Joseph Silvia via
lists.spdx.org
Hello Dick,
You stated the REA has offered to withdraw it’s VDR format if the industry agrees to endorse the CycloneDX VDR format. Can you provide more details on the similarities and differences between the REA and CycloneDX VDR format?
Thanks, Joe
Joseph D. Silvia 1055 Thomas Jefferson St. NW, Suite 304 Washington, DC 20007 Office:732.906.6142 Mobile:781.526.5636 |
jsilvia@...
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
From: spdx@... <spdx@...>
On Behalf Of Dick Brooks
May,
Thank you for the quick response.
With regard to testing; some of the spdx tool vendors conduct interoperability testing by sharing artifacts and reporting on any issues encountered. The DocFest is a formal version of this testing. Would Palo Alto Networks be willing to share their SPDX artifacts, confidentially, with spdx tool vendors for interoperability testing purposes only?
I agree with your findings on the NIST VDR; NIST identified the VDR data to be included, but not a specific format. There are two open source NIST VDR “interpretation” formats available, one from OWASP CycloneDX and the other from REA: Here’s an example of the open-source REA VDR format: https://raw.githubusercontent.com/rjb4standards/REA-Products/master/SBOMVDR_JSON/VDR_118.json
I also wrote an article describing the NIST SBOM VDR that ties back to the SP 800-161 standard and other NIST materials where VDR is referenced: https://energycentral.com/c/pip/what-nist-sbom-vulnerability-disclosure-report-vdr
FYI: REA has offered to withdraw it’s VDR format if the industry agrees to endorse the CycloneDX VDR format. Also, note, REA offered to freely transfer its open-source VDR format to the Linux Foundation, when it was first introduced; the offer was never acted on.
Thanks,
Dick Brooks
Active Member of the CISA Critical Manufacturing Sector, Sector Coordinating Council – A Public-Private Partnership
Never trust software, always verify and report! ™ http://www.reliableenergyanalytics.com Email: dick@... Tel: +1 978-696-1788
From: spdx@... <spdx@...>
On Behalf Of May Wang via
lists.spdx.org
Dick,
Thank you for your questions.
1. Our spdx-based IoT SBOM is available to all our customers. I am not sure about the specific "testing purposes" you are referring to, happy to talk more details offline.
2. Good question. In addition to the SBOM info, we also provided links from SBOM to vulnerabilities, based on our own vulnerability database and some CVEs for now. We do plan to 1) expand to more vulnerability databases and CVEs. 2) expand to cover more devices. 3) the latest NIST VDR document provides good guidance but did not prescribe specific format, we will closely follow up any updates from NIST.
Thank you, -- May Wang, Ph.D. | CTO, IoT Security Palo Alto Networks | 3000 Tannery Way | Santa Clara, CA 95054 | USA Email: may@... | www.paloaltonetworks.com
The content of this message is the proprietary and confidential property of Palo Alto Networks, and should be treated as such. If you are not the intended recipient and have received this message in error, please delete this message from your computer system and notify me immediately by e-mail. Any unauthorized use or distribution of the content of this message is prohibited.
On Tue, Apr 11, 2023 at 5:10 AM Dick Brooks <dick@...> wrote:
|
||||||||
|
|
||||||||
|
May Wang
Joe, As you know well, medical device security is a big challenge. SBOM is probably needed most in healthcare as you pointed out. We have lots of healthcare customers asking for SBOM, but many MDMs don't provide it. That's why we released it in our product trying to help. With increasing regulation requirements, such as the recent one: FDA will refuse new medical devices for cybersecurity reasons on Oct. 1, hopefully more enforcement will be put on standards like IEC 62304 you mentioned. That will definitely push for more SBOM adoption. Dick, Thank you for your explanation and the additional info. We don't have APIs for testing purposes right now. We can try to put it on the roadmap, but that might take a while. :) Thanks! -- May Wang, Ph.D. | CTO, IoT Security Palo Alto Networks | 3000 Tannery Way | Santa Clara, CA 95054 | USA Email: may@... | www.paloaltonetworks.com
The content of this message is the proprietary and confidential property of Palo Alto Networks, and should be treated as such. If you are not the intended recipient and have received this message in error, please delete this message from your computer system and notify me immediately by e-mail. Any unauthorized use or distribution of the content of this message is prohibited.
|
||||||||
|
|
||||||||
|
Joe Bussell
The WDK that contains our SBOM and COSE tools is now available through the Windows Insider Program. I would appreciate any feedback on the tools or the delivery process.
Register to for the Windows Insider Program (Free) by following the instructions here: Get started with the Windows Insider Program - Windows Insider Program | Microsot Learn
Once registered go to the Windows Driver Kit Insider page here: Download Windows Insider Preview WDK (microsoft.com)
From this page download and install the SDK and the WDK.
Once installed the SBOM tools are located in <kitsRoots>\10\Tools\<versions>\x64\ · sbom-tool-win-x64.exe · CoseSignTool.exe
Using the tools: SBOM tool The SBOM tool is an open-source tool. See the project's GitHub repository for documentation that covers how to run and use the tool. GitHub - microsoft/sbom-tool: The SBOM tool is a highly scalable and enterprise ready tool to create SPDX 2.2 compatible SBOMs for any variety of artifacts.
· sbom-tool-win-x64.exe generate [<options>]
COSE Tool CoseSignTool.exe is a command-line tool that uses the following syntax: · CoseSignTool.exe [Sign|Validate|Get] [<options>] To see available options use /?
For signing, you must supply a private key certificate to sign with. Validate and Get operations require one or more public key certificates for the COSE signature to root to. In either case, the certificates may be supplied as files or as thumbprints of certificates in the Windows Certificate Store.
From: spdx@... <spdx@...> On Behalf Of
May Wang via lists.spdx.org
Sent: Wednesday, April 12, 2023 10:25 PM To: spdx@... Cc: May Wang via lists.spdx.org <maywang=paloaltonetworks.com@...>; Phil Odence <Phil.Odence@...> Subject: [EXTERNAL] Re: [spdx] SPDX Gen Meeting Follow up- Mistake and Thanks
Joe,
As you know well, medical device security is a big challenge. SBOM is probably needed most in healthcare as you pointed out. We have lots of healthcare customers asking for SBOM, but many MDMs don't provide it. That's why we released it in our product trying to help. With increasing regulation requirements, such as the recent one: FDA will refuse new medical devices for cybersecurity reasons on Oct. 1, hopefully more enforcement will be put on standards like IEC 62304 you mentioned. That will definitely push for more SBOM adoption.
Dick,
Thank you for your explanation and the additional info. We don't have APIs for testing purposes right now. We can try to put it on the roadmap, but that might take a while. :) Thanks!
-- May Wang, Ph.D. | CTO, IoT Security Palo Alto Networks | 3000 Tannery Way | Santa Clara, CA 95054 | USA Email: may@... | www.paloaltonetworks.com
The content of this message is the proprietary and confidential property of Palo Alto Networks, and should be treated as such. If you are not the intended recipient and have received this message in error, please delete this message from your computer system and notify me immediately by e-mail. Any unauthorized use or distribution of the content of this message is prohibited.
On Wed, Apr 12, 2023 at 6:08 AM Joseph Silvia via lists.spdx.org <jsilvia=orielstat.com@...> wrote:
|
||||||||
|
|
