Allow timestamps in reproducible-marked SBOMs

[mathstuf]

In #70, there is no allowance for a timestamp when cdx:reproducible is set to true. Instead, I think that it should be allowed if the time is reproducible (e.g., by using a date derived from the sources to indicate "last edit" or something like SOURCE_DATE_EPOCH to pin a time for tooling to use during a build.

[jkowalleck]

relevant property: cdx:reproducible in https://github.com/CycloneDX/cyclonedx-property-taxonomy/blob/main/cdx.md

Boolean value are true or false. Case sensitive.

Property	Description
cdx:reproducible	Whether the CycloneDX document has been generated in a reproducible manner: if so, then time- or random-based values MUST be omitted, and elements order SHOULD be reproducible. Boolean value. May appear once.

[jkowalleck]

@mathstuf , could you

• tell which time-based information do you want to add, and tell which timestamp "fields" you want to populate in a CycloneDX document?
• explain why you think this is need? Do you know a tool that is planning to write the property to a CycloneDX document?

Please help me understand what the exact use cases should be, where they apply, and maybe how a technical implementation would look like.

The idea was: the absence of the cdx:reproducible property does not prevent any tool to generate CycloneDX documents in a self-proclaimed reproducible way. Instead, the existence of that property is for readers of a CycloneDX document, so they understand why time- and random-based information is missing in the document. This does not specify any field in particular, does not include nor exclude any field -- on purpose, because the generator of an SBOM decides which fields need to be written time-based. Some CycloneDX time field might not nahe time-based values but are based on other values, like an environment variable or such.

PS: if a tool fills certain fields based on any environment variables (like SOURCE_DATE_EPOCH, it does not fill them based on time. So the rules from cdx:reproducible would not even apply.

[mathstuf]

Oh, ok. If that is the purpose of the flag, then it seems fine to me.

FWIW, I came across this project from the Rust SBOM discussion not that I have any concrete plans for CycloneDX specifically at this time. I know colleagues are looking into SBOM details, but AFAIK have not decided on what form that takes in the end (we're mainly making sure our ducks are in a row and getting all the project/version/license info exposed properly right now).

[jkowalleck]

I see. thank you for the insights.

I will leave this open here, so further discussions may happen. maybe it is needed to document the implications of cdx:reproducible clearer. Any idea how this can be improved?

[mathstuf]

I think the issue is the "has been generated" wording here:

Whether the CycloneDX document has been generated in a reproducible manner.

If I am making a reproducible build with a stable timestamp (of whatever source), I should be able to include it. How about something along the lines of:

Whether the CycloneDX document has been generated with the expectation of representing a reproducible artifact. If so, then time- or random-based values MAY be missing in order to preserve reproducibility. All provided fields SHOULD be reproducible.

[jkowalleck]

Current description was agreed on by the maintainers of four different tools that already do reproducible SBOM generation.

If you want to have it changed so that another tool's principals are met, please tell me which tool. If this discussion is more of a thought-experiment, then please find proper cases and real-world-examples and link to them (show, don't tell) so that they can be analyzed.

---

I do understand your idea, @mathstuf, but your proposal misses the point of the whole feature as it was originally designed. There is no value to MAY be missing in a universe where all feature-relevant parts are already defined as optional, defined by CycloneDX document standard 1.0 to current 1.5. In fact, this feature's purpose is that feature-relevant parts MUST be missing. From a document generator's perspective, the feature-relevant parts MUST be omitted from the document. From a document ingester's perspective, all of a document's data is to be treated as reproducible (by the exact tools and env used to generate the document).

If I am making a reproducible build [...]

The cdx:reproducible feature does not say anything about build reproducibility. It is about the generation of the CycloneDX document in question. For example, if your build was not reproducible, you could still analyze the same build result twice and come to the exact same SBOM CycloneDX document, which would allow cdx:reproducible to be true.

But still, cdx:reproducible is optional, and even though a CycloneDX document might seem to be generated in a reproducible manner, the property may still be missing or omitted, or claim to be false.

[...] I should be able to include it. [...]

you already are, especially by the current description. What appears to be the problem?

---

@mathstuf , would you please state the "given"s that you assume, that make it necessary to discuss your change request? I suspect that we have different ideas what a "reproducible CycloneDX document" means, how it is generated, how it is digested, how it is enabled to be reproduced, or how it is prevented/hindered from reproducibility. From all what I've read from you before, you are referring to reproducible builds, not reproducible evidence analysis/reporting.

[jkowalleck]

will bring this topic to the attention during the next @CycloneDX/core-team meeting on 2023-09-04 to give it more attention and visibility.

[mathstuf]

Ah ha. Yes, it seems I jumped the gun on my assumptions of the scope of this flag. Since it is indeed for the CycloneDX document itself, then that seems much more in line. Sorry for the noise, just thought I saw something a bit off (but I was more peanut section than I thought I was).

[jkowalleck]

is all clear? can this issue be closed? @mathstuf

[mathstuf]

Yes, I think this is fine, thanks.