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 <[email protected]> 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: [email protected]
> > > For additional commands, e-mail: [email protected]
> > >
> > >
> >
> > 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: [email protected]
> > For additional commands, e-mail: [email protected]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
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: [email protected]
For additional commands, e-mail: [email protected]
