CycloneDX SBOM for databroker and databroker-cli #756
Conversation
SebastianSchildt
force-pushed
the
feature/databroker-bom-cyclonedx
branch
11 times, most recently
from
ee72423 to
582e6a8
Compare
SebastianSchildt
changed the title
SebastianSchildt
force-pushed
the
feature/databroker-bom-cyclonedx
branch
from
582e6a8 to
8b488f6
Compare
| run: | | ||
| cargo install cargo-license | ||
| python3 createbom.py --dash ${{github.workspace}}/dash-databroker-deps ../databroker | ||
| cargo tree -e normal --prefix none --no-dedupe --target all --all-features > ${{github.workspace}}/cargodeps |
There was a problem hiding this comment.
Just to make sure that I understand things right - as of now we get the same result for both databroker and databroker-cli, right? I.e. we do not try to be smart and just include what is actually used?
There was a problem hiding this comment.
Yes it does.
So I think the difference is, the SBOM (not this snippet) we ship in a container, tries to capture more or less precisely what is in the container, i.e. we only copy databroker bin dependencies, i.e. in the buildall shell script
cp ./databroker/databroker_bin.cdx.json ../dist/$target_docker/sbom.json
The BOM creation before does not really care "what" is in the BOM, it collect the fact it sees
The DASH think is more a "project-level Eclipse thing", where we check if the licenses in our dependencies are compatible, and whether we "believe what is written on the box", as such the "correct way" to do them might be for all dependencies (also python, go etc.) whenever something is merged. I did not want to refactor that here, as we are still splitting things out here anyway. Also even if this finds things that do not belong to cli but in fact are dabtroker only, doesn't change the fact, that we do need Eclipse Dash clearing. Only issue is, we are currently maybe checking some things double. Options
- keep like as is
- refactor to do this only once for all Rust code in the repo
- be a bit more narrow in th workflows for databroker and databroker-cli build with cargo tree
I prefer 1 or 3 for now, let me check 3
There was a problem hiding this comment.
Ok I tried 3. now. Probably should have done this before writing that wall of text :)
|
Should we possibly as part of this PR delete the third party section in https://github.com/eclipse/kuksa.val/blob/master/NOTICE.md#third-party-content ? It is anyway out of date, right? |
Creates a CycloneDX Software Bill of Materials (SBOM) for the databroker. Refactor createbom so it can collect licenses from any CycloneDX input file, so it may be reused for other parts of the project as well. Signed-off-by: Sebastian Schildt <[email protected]>
SebastianSchildt
force-pushed
the
feature/databroker-bom-cyclonedx
branch
from
8b488f6 to
c6a758e
Compare
Signed-off-by: Sebastian Schildt <[email protected]>
|
Wrt to NOTICE:I agree. I removed all outdated/weird content from Notice. I left the third party content section, trying to explain how you would get such informaton |
There was a problem hiding this comment.
Looks good to me, but I am no Rust expert. Do we want @lukasmittag or @argerus to have a chance to comment as well?
|
I think it does not even "touch" Rust much. I suggest, if no further feedback to merge Monday |
|
Adding @argerus as reviewer - we need to decide when we want to have "code freeze" on Databroker in this repo, and/or when we want to "remove" Databroker from this repo. If we merge it here we need to make sure that it is integrated to the new repo. |
|
Databroker has been migrated to https://github.com/eclipse-kuksa/kuksa-databroker. |
|
Replaced by eclipse-kuksa/kuksa-databroker#24 |
Creates a CycloneDX Software Bill of Materials (SBOM) for the databroker. Refactor createbom so it can collect licenses from a CycloneDX input file, so it may be reused for other parts of the project as well.
This PR
Smaller fixes
Notes
I read quite a bit about SBOM generation in the RUST ecosystem and decided to go for https://crates.io/crates/cargo-cyclonedx , as this seems the most promising way. "Built-in" support in cargo may be a couple of years off, and cargo development is quite slow these days. Similarly I think we should not try to do this "ourself" by hand. By using that crate we profit from developments in that area. I verified that currently we did not loose any information compared to the "old" way.
In the future the "collectlicensefromcyclonedx.py" might be refactored to live pip-installable in kuksa-common, as it might also be used for other components, i.e. Python based ones - as long as a Cyclone SBOM is available. Not part of this PR though