You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by Eric Pugh <ep...@apache.org> on 2026/10/14 15:02:59 UTC
SBOM's in our Release artifacts?
Hey all,
Chatting with Piotr at C/C Glasgow about his SBOM contribution for Solr, and I wanted to take the temperature of the community on adding this artifact to our releases. What he is proposing in https://github.com/apache/solr/pull/4690 is to provide as part of our release a file that describes exactly what dependencies are in the binary archive.
Adding SBOM's to releases would be a somewhat new thing for an Apache project. Apache Camel and PLC4X both ship SBOMs, and they have a lot of dependenices like us. Ivy and Ant as well as Log4j are other examples of project doing this.
SBOM's might be the data structure that we could use to publish our dependency updates from release to release, instead of doing it via Changelog entries. We had a bit of disucssion in https://lists.apache.org/thread.html/1lbnk8ch6s92hlkh91bq2vzf738gppr0. It would also replace the current dependency mapping file in the solr-site used to track vex file ranges: https://github.com/apache/solr-site/blob/main/plugins/vex/solr-dependency-versions.json for any release that had it.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: SBOM's in our Release artifacts?
Posted by Eric Pugh <ep...@apache.org>.
On 2026/10/26 11:31:12 Jason Gerlowski wrote:
> Yeah, my understanding is that, in general, this is something folks
> see value in.
>
> Whether it's a separate release artifact vs. "just" a file part of our
> distribution tgz, I don't have strong feelings about. It sounds like
> you're leaning towards the "release artifact" approach? Are there
> particular advantages of that plan you're aware of?
>
> (I'm not asking out of skepticism, but ignorance. I'm not that
> familiar with how these things are typically handled.)
>
> Best,
>
> Jason
>
> On Thu, Oct 15, 2026 at 6:30 AM Eric Pugh <ep...@apache.org> wrote:
> >
> >
> >
> > On 2026-10-14 15:02 UTC Eric Pugh wrote:
> > > Hey all,
> > >
> > > Chatting with Piotr at C/C Glasgow about his SBOM contribution for Solr, and I wanted to take the temperature of the community on adding this artifact to our releases. What he is proposing in https://github.com/apache/solr/pull/4690 is to provide as part of our release a file that describes exactly what dependencies are in the binary archive.
> > >
> > > Adding SBOM's to releases would be a somewhat new thing for an Apache project. Apache Camel and PLC4X both ship SBOMs, and they have a lot of dependenices like us. Ivy and Ant as well as Log4j are other examples of project doing this.
> > >
> > > SBOM's might be the data structure that we could use to publish our dependency updates from release to release, instead of doing it via Changelog entries. We had a bit of disucssion in https://lists.apache.org/thread.html/1lbnk8ch6s92hlkh91bq2vzf738gppr0. It would also replace the current dependency mapping file in the solr-site used to track vex file ranges: https://github.com/apache/solr-site/blob/main/plugins/vex/solr-dependency-versions.json for any release that had it.
> > >
> > > Thoughts?
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: dev-help@solr.apache.org
> > >
> > >
> >
> > It looks like the idea of SBOM's for Solr has actually been around for a few years. We have a number of JIRAs that are open:
> >
> > https://issues.apache.org/jira/browse/SOLR-17328: Publish SBOMs for Solr binary artifacts
> > https://issues.apache.org/jira/browse/SOLR-16796: Publish an SBOM for Solr maven artifacts
> >
> > And a related:
> >
> > https://issues.apache.org/jira/browse/SOLR-17602: Maintain final JAR dependencies in source control to track changes
> > https://issues.apache.org/jira/browse/SOLR-15929: Clean up NOTICE and LICENSE files for Solr
> >
> >
> > Finding SOLR-18328 and SOLR-16796 shifts me more in the direction of "yes, this is something we want to do as a community"...
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Yeah, I think it's still a wild and wooly frontier a bit. I had a chat with one of the folks from https://openssf.org/ and they said that we're still in a time of competing standards. More than one way of describing an SBOM.
We saw this same patternw ith VEX files as well. So, I think the important thing is to pick something that other Apache projects do, and move forward.
I'm going to take this as positive sign to get that for 10.2...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: SBOM's in our Release artifacts?
Posted by "Piotr P. Karwasz" <pk...@apache.org>.
Hi Eric,
On 29.10.2026 11:40, Eric Pugh wrote:
> Piotr, why does the file have two names?
> It appears to be <foo>.cdx.json if it's not in solr and <foo>.bom inside of Solr?
There's no deep reason behind it. I just followed the file name patterns
that CycloneDX recognizes [1]: tools are expected to detect an SBOM if
it is named `bom.json` or `*.cdx.json`. Whatever names we pick, they
should stay within that convention.
## Detached SBOM
For the SBOM published next to the release artifacts, Apache Trusted
Releases already has a convention: append `.cdx.json` to the artifact's
file name. Under that convention, the SBOM for `solr-10.1.0.tgz` is
`solr-10.1.0.tgz.cdx.json`.
We can discuss whether that's the best choice. Dropping the archive
extension (`solr-10.1.0.cdx.json`) would also make sense, since a single
SBOM could then cover the same release in several archive formats:
- solr-10.1.0.tgz
- solr-10.1.0.zip
- solr-10.1.0.tar.xz
## Embedded SBOM
For the SBOM inside the archive, I'm not aware of any general
convention, but there are some precedents:
- PEP 770 puts SBOMs under `.dist-info/sboms/`.
- Spring Boot puts them under `META-INF/sbom/<name>.cdx.json`.
Following those, `sbom/solr-10.1.0.cdx.json` (or something under
`sboms/`) might be a better choice than the current name.
I also looked at how Ant handles this, but Ant's SBOM has one entry per
file in the archive, which makes it *huge*: about as large as the
archive itself. Needless to say, Ant doesn't embed it in the archive.
Piotr
[1] https://cyclonedx.org/specification/overview/#recognized-file-patterns
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: SBOM's in our Release artifacts?
Posted by Eric Pugh <ep...@apache.org>.
On 2026/10/26 20:26:27 Piotr P. Karwasz wrote:
> Hi Jason,
>
> On 26.10.2026 12:31, Jason Gerlowski wrote:
> > Whether it's a separate release artifact vs. "just" a file part of our
> > distribution tgz, I don't have strong feelings about. It sounds like
> > you're leaning towards the "release artifact" approach? Are there
> > particular advantages of that plan you're aware of?
>
>
> My PR implements both, this way:
>
> - You can check the SBOM *before* downloading Solr.
> - Users don't lose the SBOM if the unpackage the binary release.
>
> If you make a release using ATR (even by manually uploading the
> artifacts), ATR will recognize any file named <foo>.cdx.json as SBOM of
> the corresponding <foo> file and do some analysis.
>
> Piotr
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Piotr, why does the file have two names?
It appears to be <foo>.cdx.json if it's not in solr and <foo>.bom inside of Solr?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: SBOM's in our Release artifacts?
Posted by "Piotr P. Karwasz" <pi...@mailing.copernik.eu>.
Hi Jason,
On 26.10.2026 12:31, Jason Gerlowski wrote:
> Whether it's a separate release artifact vs. "just" a file part of our
> distribution tgz, I don't have strong feelings about. It sounds like
> you're leaning towards the "release artifact" approach? Are there
> particular advantages of that plan you're aware of?
My PR implements both, this way:
- You can check the SBOM *before* downloading Solr.
- Users don't lose the SBOM if the unpackage the binary release.
If you make a release using ATR (even by manually uploading the
artifacts), ATR will recognize any file named <foo>.cdx.json as SBOM of
the corresponding <foo> file and do some analysis.
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: SBOM's in our Release artifacts?
Posted by Jason Gerlowski <ge...@gmail.com>.
Yeah, my understanding is that, in general, this is something folks
see value in.
Whether it's a separate release artifact vs. "just" a file part of our
distribution tgz, I don't have strong feelings about. It sounds like
you're leaning towards the "release artifact" approach? Are there
particular advantages of that plan you're aware of?
(I'm not asking out of skepticism, but ignorance. I'm not that
familiar with how these things are typically handled.)
Best,
Jason
On Thu, Oct 15, 2026 at 6:30 AM Eric Pugh <ep...@apache.org> wrote:
>
>
>
> On 2026-10-14 15:02 UTC Eric Pugh wrote:
> > Hey all,
> >
> > Chatting with Piotr at C/C Glasgow about his SBOM contribution for Solr, and I wanted to take the temperature of the community on adding this artifact to our releases. What he is proposing in https://github.com/apache/solr/pull/4690 is to provide as part of our release a file that describes exactly what dependencies are in the binary archive.
> >
> > Adding SBOM's to releases would be a somewhat new thing for an Apache project. Apache Camel and PLC4X both ship SBOMs, and they have a lot of dependenices like us. Ivy and Ant as well as Log4j are other examples of project doing this.
> >
> > SBOM's might be the data structure that we could use to publish our dependency updates from release to release, instead of doing it via Changelog entries. We had a bit of disucssion in https://lists.apache.org/thread.html/1lbnk8ch6s92hlkh91bq2vzf738gppr0. It would also replace the current dependency mapping file in the solr-site used to track vex file ranges: https://github.com/apache/solr-site/blob/main/plugins/vex/solr-dependency-versions.json for any release that had it.
> >
> > Thoughts?
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >
>
> It looks like the idea of SBOM's for Solr has actually been around for a few years. We have a number of JIRAs that are open:
>
> https://issues.apache.org/jira/browse/SOLR-17328: Publish SBOMs for Solr binary artifacts
> https://issues.apache.org/jira/browse/SOLR-16796: Publish an SBOM for Solr maven artifacts
>
> And a related:
>
> https://issues.apache.org/jira/browse/SOLR-17602: Maintain final JAR dependencies in source control to track changes
> https://issues.apache.org/jira/browse/SOLR-15929: Clean up NOTICE and LICENSE files for Solr
>
>
> Finding SOLR-18328 and SOLR-16796 shifts me more in the direction of "yes, this is something we want to do as a community"...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: SBOM's in our Release artifacts?
Posted by Eric Pugh <ep...@apache.org>.
On 2026-10-14 15:02 UTC Eric Pugh wrote:
> Hey all,
>
> Chatting with Piotr at C/C Glasgow about his SBOM contribution for Solr, and I wanted to take the temperature of the community on adding this artifact to our releases. What he is proposing in https://github.com/apache/solr/pull/4690 is to provide as part of our release a file that describes exactly what dependencies are in the binary archive.
>
> Adding SBOM's to releases would be a somewhat new thing for an Apache project. Apache Camel and PLC4X both ship SBOMs, and they have a lot of dependenices like us. Ivy and Ant as well as Log4j are other examples of project doing this.
>
> SBOM's might be the data structure that we could use to publish our dependency updates from release to release, instead of doing it via Changelog entries. We had a bit of disucssion in https://lists.apache.org/thread.html/1lbnk8ch6s92hlkh91bq2vzf738gppr0. It would also replace the current dependency mapping file in the solr-site used to track vex file ranges: https://github.com/apache/solr-site/blob/main/plugins/vex/solr-dependency-versions.json for any release that had it.
>
> Thoughts?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
It looks like the idea of SBOM's for Solr has actually been around for a few years. We have a number of JIRAs that are open:
https://issues.apache.org/jira/browse/SOLR-17328: Publish SBOMs for Solr binary artifacts
https://issues.apache.org/jira/browse/SOLR-16796: Publish an SBOM for Solr maven artifacts
And a related:
https://issues.apache.org/jira/browse/SOLR-17602: Maintain final JAR dependencies in source control to track changes
https://issues.apache.org/jira/browse/SOLR-15929: Clean up NOTICE and LICENSE files for Solr
Finding SOLR-18328 and SOLR-16796 shifts me more in the direction of "yes, this is something we want to do as a community"...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org