A project we are working on requires us to generate software bill of materials from a set of components in fossil.

See cyclonedx.org for the standard and noting the existing tools we are considering a small TCL based tool which combines fossil version info and some elf analysis.

Would there any interest in this? The code for the project is a mix of licenses so bsd2 could be used and we would do the development but if there is anyone interested in looking at it is question 2 or has someone done this already.

This proposal would carry a lot more weight if it came from a registered users, especially a registered user using their real name rather than a handle or alias, and if it contained more detail about the proposed enhancement, as well as a list of advantages associated with supporting this feature. As it stands now, it has low probability of gaining any traction.

SBOM is more closely aligned with packaging and distribution, not development. Not until you have distributable binaries can you have the full SBOM.

If you want to tie Fossil into an SBOM system that works top-down from the committed source code — as opposed to the bottom-up binary method I've just advocated for — I think you'd be more productive selecting a suitably FOSS alternative from that list and then adding the ability to clone directly from Fossil and reference its commit IDs. Until someone does that, the prime probability is that each tool you look at will presume Git is the only DVCS in existence.

While Fossil has the ability to mirror to a Git repo, and that this can aid integration with such third-party tooling, it creates an impedance mismatch which may be problematic in light of the traceability requirements SBOM implies. When someone tells you to give them an auditable list of what went into the software, they will prefer that you point right at each referent, not point at the thing that points at the thing.

Richard,

Twas me who posted it from under a small tree in the tropics. I've signed a signed a contributor agreement long ago so apologies re: This proposal would carry a lot more weight if it came from a registered users, especially a registered user using their real name rather than a handle or alias,

The purpose was to answer:

1. Anyone (at all) interested in the whole SBOM thing with fossil. Answer: seems to be no which is fine, we just need to solve it anyways.
2. Prior works that may be interest noting I've done a fair bit of work reviewing the alternatives as mentioned by Warren.

and if it contained more detail about the proposed enhancement, as well as a list of advantages associated with supporting this feature.

I'll write up a summary of the scope of works for penance in a separate message, just in case anyone comes across and close the issue.

As it stands now, it has low probability of gaining any traction.

Ack.

Warren,

Thanks, I think I'm proposing what you describe in para 2, i.e. a top down and bottom up generation along with a merge using existing tools. I guess the main points are:

1. No suggestion of a change to fossil itself, just conventions.
2. A tool that generates a per component SBOM with references using a collection of fossil repos as the basis.
3. For the binary build use the existing toolsets as you say.

I'll write a summary in response for penance to the original post but pretty much lets consider it a non-problem.