Assess SPDX inclusion for k8s release BOM implementation

[lukehinds]

Related to the following in k8s release SIG : kubernetes/release#1837 (comment)

Explore inclusion of SPDX manifests (XML 😦 ) , namely:

• What sort of values would be critical (place in the t-log) and what could go in ExtraData.
• What sort of signing system is used, how would we ensure non-repudiation.
• How would k8s release display entry and make it valuable, perhaps an inclusion URL pointing to the UUID?

[nishakm]

👋 I can help answer SPDX questions (XML is only one of the supported formats)

[lukehinds]

great, sounds good @nishakm , look forward to collaborating with you.

I guess a key question to kick off is if you do any sort of key signing(s) of either the SPDX manifest or the artifacts listed in the manifest, if so what is used (GPG, x509,..)?

[nishakm]

great, sounds good @nishakm , look forward to collaborating with you.

I guess a key question to kick off is if you do any sort of key signing(s) of either the SPDX manifest or the artifacts listed in the manifest, if so what is used (GPG, x509,..)?

You can sign a SPDX document/blob just like you would sign any artifact. At this time, the document itself doesn't support a "signature" metadata, but the community is working on adding it in SPDX 3.0.

[lukehinds]

@nishakm sent you slack invite if that's ok

[haydentherapper]

Closing as something we won't tackle due to keeping the API minimal and not increasing types - Hashedrekord should be used, ecosystems should determine how to canonicalize an artifact into a digest.