Re: SBOM for Ant

On Fri, 21 Nov 2025 at 12:39, Stefan Bodewig <[email protected]> wrote:

> On 2025-11-16, Gintautas Grigelionis wrote:
>
> > Sorry for being unclear. I mean going back to PR 54 and taking another
> look
> > at it.
>
> Right now I am really only concerned with creating SBOMs and the changes
> to ivy.xml made in your PR would help if Ivy could create SBOMs. As long
> as Ivy doesn't (and as long as we don't enable it to) the change doesn't
> help getting there.
>
> > Then, Ivy needs a task that uses cyclonedx-core-java and/or
> > spdx-java-library.
>
> Right. Personally I'm not sure I have the time to create that and I'm
> pretty sure I don't won't have the time maintaining it to keep up with
> changes to CycloneDX or SPDX.
>

The changes to SBOM standards are handled in respective libraries
(e.g. there seem to be different libraries for SPDX 2 and 3). Their APIs
seem stable, though.
It looks like IvyDependencyTree could be a suitable starting point.


> I'd be very happy to defer dealing with the latest CISA policy changes
> to the people who are actively involved in following the formats and
> evolving the libraries we'd use.
>

It rather looks like there will be a push for harmonisation, in part thanks
to CRA.
We need to understand what the new minimum requirements will be, though.


> > If that's too much of a hassle, Maven can easily provide another
> > cop-out.  But I'd argue that dependency management ought to be done
> > properly in order to produce a proper SBOM.
>
> No argument with that, that's why all options I listed either dependend
> on our existing Maven POMs which provide that or state we need to extend
> the ivy.xml or come up with a one-off solution based on
> libraries.properties. That latter would be completely sufficient for our
> traditional tarball/zip releases as the artifact we'd be talking about
> is "all of Ant". The smaller things we push to the maven central are
> more complex IMHO.


PR 54 in its current form aims to eliminate fetch.xml
(except maybe for special logic around the ancient netrexx if that artifact
can no longer
be resolved -- pity JFrog sunset their repository service; it would bite us
in the back, though,
if we cannot represent it as pURL which is a requirement by SBOM ;-).
Can we drop netrexx or try a newer version? Pity I have no access to a
mainframe anymore :-(

I'd like to have a look at the release/upload part, there may be extra work.
Agreed on SBOM targeting "all of Ant".

Gintas