Re: Re: [fileupload] Have a FileUpload release (after 3.5 years)
Yeah, there is code that looks odd for 2022, like a custom Closeable interface instead of reusing the JRE's. I'll take a look. Gary On Sun, Jul 17, 2022 at 2:32 PM Matt Juntunen wrote: > > Sounds good. Do you know of anything else that needs to be done? I'm > guessing we can hold off on a full 1.x migration guide until the full > 2.0.0 version. > > -Matt J > > On Sun, Jul 17, 2022 at 2:13 PM Gary Gregory wrote: > > > > We should at least remove deprecated elements. > > > > Gary > > > > On Sun, Jul 17, 2022 at 10:49 AM Matt Juntunen > > wrote: > > > > > > I am going to put the 2.0.0-beta1 release on my TODO list. I am > > > currently working toward a release of commons-text, so I can't be sure > > > on a timeline. If anyone has questions or time to pick this up, please > > > let me know. > > > > > > Regards, > > > Matt J > > > > > > On Fri, Jul 15, 2022 at 12:35 PM Matt Juntunen > > > wrote: > > > > > > > > It sounds like we've agreed on creating a 2.0.0-beta1 release. Does > > > > anyone have availability to lead the release? > > > > > > > > Regards, > > > > Matt J > > > > > > > > On Wed, Jul 13, 2022 at 9:35 AM sebb wrote: > > > > > > > > > > It looks like Commons does not have the concept of Alpha releases. > > > > > > > > > > https://commons.apache.org/releases/versioning.html > > > > > > > > > > Sorry, I must have been thinking of a different project. > > > > > > > > > > Sebb > > > > > > > > > > On Wed, 13 Jul 2022 at 01:36, Gary Gregory > > > > > wrote: > > > > > > > > > > > > A beta is a good idea IMO. > > > > > > > > > > > > Gary > > > > > > > > > > > > On Tue, Jul 12, 2022, 17:19 Matt Juntunen > > > > > > wrote: > > > > > > > > > > > > > Based on what I'm hearing, I'm thinking a beta release might be > > > > > > > appropriate. That would give consumers a chance to move away from > > > > > > > the > > > > > > > previous version while giving us a chance to test and fine-tune > > > > > > > the > > > > > > > API. Thoughts? > > > > > > > > > > > > > > Regards, > > > > > > > Matt J > > > > > > > > > > > > > > On Tue, Jul 12, 2022 at 4:15 PM Christoph Grüninger > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > Publishing a first release candidate might help. Currently > > > > > > > > there is no > > > > > > > > indication for anybody to invest in testing FileUpload. > > > > > > > > > > > > > > > > In doubt: release early, release often. People are using > > > > > > > > FileUpload > > > > > > > > together with vulnerable dependencies! > > > > > > > > > > > > > > > > Bye > > > > > > > > Christoph > > > > > > > > > > > > > > > > - > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Re: [fileupload] Have a FileUpload release (after 3.5 years)
Sounds good. Do you know of anything else that needs to be done? I'm guessing we can hold off on a full 1.x migration guide until the full 2.0.0 version. -Matt J On Sun, Jul 17, 2022 at 2:13 PM Gary Gregory wrote: > > We should at least remove deprecated elements. > > Gary > > On Sun, Jul 17, 2022 at 10:49 AM Matt Juntunen > wrote: > > > > I am going to put the 2.0.0-beta1 release on my TODO list. I am > > currently working toward a release of commons-text, so I can't be sure > > on a timeline. If anyone has questions or time to pick this up, please > > let me know. > > > > Regards, > > Matt J > > > > On Fri, Jul 15, 2022 at 12:35 PM Matt Juntunen > > wrote: > > > > > > It sounds like we've agreed on creating a 2.0.0-beta1 release. Does > > > anyone have availability to lead the release? > > > > > > Regards, > > > Matt J > > > > > > On Wed, Jul 13, 2022 at 9:35 AM sebb wrote: > > > > > > > > It looks like Commons does not have the concept of Alpha releases. > > > > > > > > https://commons.apache.org/releases/versioning.html > > > > > > > > Sorry, I must have been thinking of a different project. > > > > > > > > Sebb > > > > > > > > On Wed, 13 Jul 2022 at 01:36, Gary Gregory > > > > wrote: > > > > > > > > > > A beta is a good idea IMO. > > > > > > > > > > Gary > > > > > > > > > > On Tue, Jul 12, 2022, 17:19 Matt Juntunen > > > > > wrote: > > > > > > > > > > > Based on what I'm hearing, I'm thinking a beta release might be > > > > > > appropriate. That would give consumers a chance to move away from > > > > > > the > > > > > > previous version while giving us a chance to test and fine-tune the > > > > > > API. Thoughts? > > > > > > > > > > > > Regards, > > > > > > Matt J > > > > > > > > > > > > On Tue, Jul 12, 2022 at 4:15 PM Christoph Grüninger > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > Publishing a first release candidate might help. Currently there > > > > > > > is no > > > > > > > indication for anybody to invest in testing FileUpload. > > > > > > > > > > > > > > In doubt: release early, release often. People are using > > > > > > > FileUpload > > > > > > > together with vulnerable dependencies! > > > > > > > > > > > > > > Bye > > > > > > > Christoph > > > > > > > > > > > > > > - > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > - > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Re: [fileupload] Have a FileUpload release (after 3.5 years)
We should at least remove deprecated elements. Gary On Sun, Jul 17, 2022 at 10:49 AM Matt Juntunen wrote: > > I am going to put the 2.0.0-beta1 release on my TODO list. I am > currently working toward a release of commons-text, so I can't be sure > on a timeline. If anyone has questions or time to pick this up, please > let me know. > > Regards, > Matt J > > On Fri, Jul 15, 2022 at 12:35 PM Matt Juntunen > wrote: > > > > It sounds like we've agreed on creating a 2.0.0-beta1 release. Does > > anyone have availability to lead the release? > > > > Regards, > > Matt J > > > > On Wed, Jul 13, 2022 at 9:35 AM sebb wrote: > > > > > > It looks like Commons does not have the concept of Alpha releases. > > > > > > https://commons.apache.org/releases/versioning.html > > > > > > Sorry, I must have been thinking of a different project. > > > > > > Sebb > > > > > > On Wed, 13 Jul 2022 at 01:36, Gary Gregory wrote: > > > > > > > > A beta is a good idea IMO. > > > > > > > > Gary > > > > > > > > On Tue, Jul 12, 2022, 17:19 Matt Juntunen > > > > wrote: > > > > > > > > > Based on what I'm hearing, I'm thinking a beta release might be > > > > > appropriate. That would give consumers a chance to move away from the > > > > > previous version while giving us a chance to test and fine-tune the > > > > > API. Thoughts? > > > > > > > > > > Regards, > > > > > Matt J > > > > > > > > > > On Tue, Jul 12, 2022 at 4:15 PM Christoph Grüninger > > > > > > > > > > wrote: > > > > > > > > > > > > Publishing a first release candidate might help. Currently there is > > > > > > no > > > > > > indication for anybody to invest in testing FileUpload. > > > > > > > > > > > > In doubt: release early, release often. People are using FileUpload > > > > > > together with vulnerable dependencies! > > > > > > > > > > > > Bye > > > > > > Christoph > > > > > > > > > > > > - > > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > - > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] SBOM Generation
Matt, I am a member of a few other open source Java libs and I am interested in what you come up with to follow your lead and add SBOM to them as well. The more pervasive we can make it the better for the whole Java ecosystem overall! Melloware @melloware on GitHub > On Jul 17, 2022, at 12:16 PM, Matt Juntunen wrote: > > Sounds good. I've moved the discussion to the > security-disc...@community.apache.org mailist list [1]. > > Regards, > Matt J > > [1] https://lists.apache.org/thread/l8661o0t1r8498bhy01wdwg1s2kkhogy > >> On Sun, Jul 17, 2022 at 11:11 AM Gary Gregory wrote: >> >>> On Sun, Jul 17, 2022 at 11:00 AM sebb wrote: >>> >>> On Sun, 17 Jul 2022 at 15:45, Matt Juntunen >>> wrote: Hello all, Steve Springett recently created a PR [1] for commons-parent that introduces the generation of software bill of materials (SBOM) artifacts into the build process. First of all, thank you, Steve. Secondly, I believe this is an important topic that should be addressed by our community. SBOMs contain metadata that can be used in application security contexts and software supply chain analysis. They seem to be becoming increasingly important as the software industry places a greater emphasis on cybersecurity. I have a small amount of experience with these types of files from my day job. My team will soon begin generating them for all of our projects in order to allow automated tools to better track CVEs and report to our customers on the security of our applications. The questions I believe we need to answer as a community are: 1. Do we want to include SBOMs in our Maven build artifacts? 2. If so, what format do we want to use? In regard to the first question, I believe that we would need a good reason to *not* include these (or similar) artifacts. It's a simple service we can provide to help our users maintain good cybersecurity practices. As the provider of a number of hugely popular open-source libraries, I would love to see us take the lead on ensuring the security of the Java ecosystem. For question two, there are a few SBOM standards out there, notably SPDX [2] and CycloneDX [3] (which is what Steve included in his PR). I am not well versed in the exact differences between the formats, but CycloneDX seems to have better Java support and a large number of useful tools, such as the Maven plugin used in Steve's PR. If we can agree on answers to the two questions above, then we can move forward and start discussing details. Thank you all for your time. >>> >>> SBOMs presumably apply to all ASF software, so it seems to me it would >>> be sensible to address this at ASF level. >>> It would be silly for each project to generate the data differently, >>> even if only slightly. >>> Once a format is settled upon, I would expect it to be implemented via >>> the Apache POM, rather than by every Maven Java project. >>> >>> I think the mailing list for this is probably >>> security-disc...@community.apache.org: >>> https://lists.apache.org/list.html?security-disc...@community.apache.org >> >> I agree with Sebb. >> >> Note that the CycloneDX plugin does not work correctly for >> multi-module Maven projects. See the PR for my results. >> >> Gary >> >>> Regards, Matt J [1] https://github.com/apache/commons-parent/pull/122 [2] https://spdx.dev/ [3] https://cyclonedx.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] SBOM Generation
Sounds good. I've moved the discussion to the security-disc...@community.apache.org mailist list [1]. Regards, Matt J [1] https://lists.apache.org/thread/l8661o0t1r8498bhy01wdwg1s2kkhogy On Sun, Jul 17, 2022 at 11:11 AM Gary Gregory wrote: > > On Sun, Jul 17, 2022 at 11:00 AM sebb wrote: > > > > On Sun, 17 Jul 2022 at 15:45, Matt Juntunen > > wrote: > > > > > > Hello all, > > > > > > Steve Springett recently created a PR [1] for commons-parent that > > > introduces the generation of software bill of materials (SBOM) > > > artifacts into the build process. First of all, thank you, Steve. > > > Secondly, I believe this is an important topic that should be > > > addressed by our community. SBOMs contain metadata that can be used in > > > application security contexts and software supply chain analysis. They > > > seem to be becoming increasingly important as the software industry > > > places a greater emphasis on cybersecurity. I have a small amount of > > > experience with these types of files from my day job. My team will > > > soon begin generating them for all of our projects in order to allow > > > automated tools to better track CVEs and report to our customers on > > > the security of our applications. The questions I believe we need to > > > answer as a community are: > > > > > > 1. Do we want to include SBOMs in our Maven build artifacts? > > > 2. If so, what format do we want to use? > > > > > > In regard to the first question, I believe that we would need a good > > > reason to *not* include these (or similar) artifacts. It's a simple > > > service we can provide to help our users maintain good cybersecurity > > > practices. As the provider of a number of hugely popular open-source > > > libraries, I would love to see us take the lead on ensuring the > > > security of the Java ecosystem. > > > > > > For question two, there are a few SBOM standards out there, notably > > > SPDX [2] and CycloneDX [3] (which is what Steve included in his PR). I > > > am not well versed in the exact differences between the formats, but > > > CycloneDX seems to have better Java support and a large number of > > > useful tools, such as the Maven plugin used in Steve's PR. > > > > > > If we can agree on answers to the two questions above, then we can > > > move forward and start discussing details. Thank you all for your > > > time. > > > > SBOMs presumably apply to all ASF software, so it seems to me it would > > be sensible to address this at ASF level. > > It would be silly for each project to generate the data differently, > > even if only slightly. > > Once a format is settled upon, I would expect it to be implemented via > > the Apache POM, rather than by every Maven Java project. > > > > I think the mailing list for this is probably > > security-disc...@community.apache.org: > > https://lists.apache.org/list.html?security-disc...@community.apache.org > > I agree with Sebb. > > Note that the CycloneDX plugin does not work correctly for > multi-module Maven projects. See the PR for my results. > > Gary > > > > > > Regards, > > > Matt J > > > > > > [1] https://github.com/apache/commons-parent/pull/122 > > > [2] https://spdx.dev/ > > > [3] https://cyclonedx.org/ > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] SBOM Generation
On Sun, Jul 17, 2022 at 11:00 AM sebb wrote: > > On Sun, 17 Jul 2022 at 15:45, Matt Juntunen wrote: > > > > Hello all, > > > > Steve Springett recently created a PR [1] for commons-parent that > > introduces the generation of software bill of materials (SBOM) > > artifacts into the build process. First of all, thank you, Steve. > > Secondly, I believe this is an important topic that should be > > addressed by our community. SBOMs contain metadata that can be used in > > application security contexts and software supply chain analysis. They > > seem to be becoming increasingly important as the software industry > > places a greater emphasis on cybersecurity. I have a small amount of > > experience with these types of files from my day job. My team will > > soon begin generating them for all of our projects in order to allow > > automated tools to better track CVEs and report to our customers on > > the security of our applications. The questions I believe we need to > > answer as a community are: > > > > 1. Do we want to include SBOMs in our Maven build artifacts? > > 2. If so, what format do we want to use? > > > > In regard to the first question, I believe that we would need a good > > reason to *not* include these (or similar) artifacts. It's a simple > > service we can provide to help our users maintain good cybersecurity > > practices. As the provider of a number of hugely popular open-source > > libraries, I would love to see us take the lead on ensuring the > > security of the Java ecosystem. > > > > For question two, there are a few SBOM standards out there, notably > > SPDX [2] and CycloneDX [3] (which is what Steve included in his PR). I > > am not well versed in the exact differences between the formats, but > > CycloneDX seems to have better Java support and a large number of > > useful tools, such as the Maven plugin used in Steve's PR. > > > > If we can agree on answers to the two questions above, then we can > > move forward and start discussing details. Thank you all for your > > time. > > SBOMs presumably apply to all ASF software, so it seems to me it would > be sensible to address this at ASF level. > It would be silly for each project to generate the data differently, > even if only slightly. > Once a format is settled upon, I would expect it to be implemented via > the Apache POM, rather than by every Maven Java project. > > I think the mailing list for this is probably > security-disc...@community.apache.org: > https://lists.apache.org/list.html?security-disc...@community.apache.org I agree with Sebb. Note that the CycloneDX plugin does not work correctly for multi-module Maven projects. See the PR for my results. Gary > > > Regards, > > Matt J > > > > [1] https://github.com/apache/commons-parent/pull/122 > > [2] https://spdx.dev/ > > [3] https://cyclonedx.org/ > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] SBOM Generation
On Sun, 17 Jul 2022 at 15:45, Matt Juntunen wrote: > > Hello all, > > Steve Springett recently created a PR [1] for commons-parent that > introduces the generation of software bill of materials (SBOM) > artifacts into the build process. First of all, thank you, Steve. > Secondly, I believe this is an important topic that should be > addressed by our community. SBOMs contain metadata that can be used in > application security contexts and software supply chain analysis. They > seem to be becoming increasingly important as the software industry > places a greater emphasis on cybersecurity. I have a small amount of > experience with these types of files from my day job. My team will > soon begin generating them for all of our projects in order to allow > automated tools to better track CVEs and report to our customers on > the security of our applications. The questions I believe we need to > answer as a community are: > > 1. Do we want to include SBOMs in our Maven build artifacts? > 2. If so, what format do we want to use? > > In regard to the first question, I believe that we would need a good > reason to *not* include these (or similar) artifacts. It's a simple > service we can provide to help our users maintain good cybersecurity > practices. As the provider of a number of hugely popular open-source > libraries, I would love to see us take the lead on ensuring the > security of the Java ecosystem. > > For question two, there are a few SBOM standards out there, notably > SPDX [2] and CycloneDX [3] (which is what Steve included in his PR). I > am not well versed in the exact differences between the formats, but > CycloneDX seems to have better Java support and a large number of > useful tools, such as the Maven plugin used in Steve's PR. > > If we can agree on answers to the two questions above, then we can > move forward and start discussing details. Thank you all for your > time. SBOMs presumably apply to all ASF software, so it seems to me it would be sensible to address this at ASF level. It would be silly for each project to generate the data differently, even if only slightly. Once a format is settled upon, I would expect it to be implemented via the Apache POM, rather than by every Maven Java project. I think the mailing list for this is probably security-disc...@community.apache.org: https://lists.apache.org/list.html?security-disc...@community.apache.org > Regards, > Matt J > > [1] https://github.com/apache/commons-parent/pull/122 > [2] https://spdx.dev/ > [3] https://cyclonedx.org/ > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Re: [fileupload] Have a FileUpload release (after 3.5 years)
I am going to put the 2.0.0-beta1 release on my TODO list. I am currently working toward a release of commons-text, so I can't be sure on a timeline. If anyone has questions or time to pick this up, please let me know. Regards, Matt J On Fri, Jul 15, 2022 at 12:35 PM Matt Juntunen wrote: > > It sounds like we've agreed on creating a 2.0.0-beta1 release. Does > anyone have availability to lead the release? > > Regards, > Matt J > > On Wed, Jul 13, 2022 at 9:35 AM sebb wrote: > > > > It looks like Commons does not have the concept of Alpha releases. > > > > https://commons.apache.org/releases/versioning.html > > > > Sorry, I must have been thinking of a different project. > > > > Sebb > > > > On Wed, 13 Jul 2022 at 01:36, Gary Gregory wrote: > > > > > > A beta is a good idea IMO. > > > > > > Gary > > > > > > On Tue, Jul 12, 2022, 17:19 Matt Juntunen > > > wrote: > > > > > > > Based on what I'm hearing, I'm thinking a beta release might be > > > > appropriate. That would give consumers a chance to move away from the > > > > previous version while giving us a chance to test and fine-tune the > > > > API. Thoughts? > > > > > > > > Regards, > > > > Matt J > > > > > > > > On Tue, Jul 12, 2022 at 4:15 PM Christoph Grüninger > > > > wrote: > > > > > > > > > > Publishing a first release candidate might help. Currently there is no > > > > > indication for anybody to invest in testing FileUpload. > > > > > > > > > > In doubt: release early, release often. People are using FileUpload > > > > > together with vulnerable dependencies! > > > > > > > > > > Bye > > > > > Christoph > > > > > > > > > > - > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[all] SBOM Generation
Hello all, Steve Springett recently created a PR [1] for commons-parent that introduces the generation of software bill of materials (SBOM) artifacts into the build process. First of all, thank you, Steve. Secondly, I believe this is an important topic that should be addressed by our community. SBOMs contain metadata that can be used in application security contexts and software supply chain analysis. They seem to be becoming increasingly important as the software industry places a greater emphasis on cybersecurity. I have a small amount of experience with these types of files from my day job. My team will soon begin generating them for all of our projects in order to allow automated tools to better track CVEs and report to our customers on the security of our applications. The questions I believe we need to answer as a community are: 1. Do we want to include SBOMs in our Maven build artifacts? 2. If so, what format do we want to use? In regard to the first question, I believe that we would need a good reason to *not* include these (or similar) artifacts. It's a simple service we can provide to help our users maintain good cybersecurity practices. As the provider of a number of hugely popular open-source libraries, I would love to see us take the lead on ensuring the security of the Java ecosystem. For question two, there are a few SBOM standards out there, notably SPDX [2] and CycloneDX [3] (which is what Steve included in his PR). I am not well versed in the exact differences between the formats, but CycloneDX seems to have better Java support and a large number of useful tools, such as the Maven plugin used in Steve's PR. If we can agree on answers to the two questions above, then we can move forward and start discussing details. Thank you all for your time. Regards, Matt J [1] https://github.com/apache/commons-parent/pull/122 [2] https://spdx.dev/ [3] https://cyclonedx.org/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
