ZEISS / czicompress

Reduce the size of existing CZI-documents by converting them to zstd-compressed CZI documents
MIT License
18 stars 4 forks source link

Automate creation of THIRD_PARTY_LICENSES*.txt #7

Open m-ringler opened 1 year ago

m-ringler commented 1 year ago

We should add a github action that automates creation of THIRD_PARTY_LICENSES_ARTIFACT_DISTRIBUTION.txt by aggregating from

m-ringler commented 1 year ago

See https://github.com/microsoft/sbom-tool/blob/main/docs/setting-up-github-actions.md

However, there's the problem that the build complains when you do

$ dotnet build netczicompress.sln --output /path/to/czishrink-build-output`
MSBuild version 17.7.3+8ec440e68 for .NET
[...]
C:\Program Files\dotnet\sdk\7.0.402\Current\SolutionFile\ImportAfter\Microsoft.NET.Sdk.Solution.targets(36,5): warning NET
SDK1194: The "--output" option isn't supported when building a solution. Specifying a solution-level output path results i
n all projects copying outputs to the same directory, which can lead to inconsistent builds.`

Command line for sbom-tool path/to/sbom-tool-for-current-platform generate -b /path/to/czishrink-build-output -li true -bc . -pn CziShrink -ps CZICOMPRESS -V verbose -pv 1.0.0-alpha.46 -nsb https://github.com/ZEISS/czicompress/tree/main/czishrink

DaveyJonesBitPail commented 1 year ago

The build cmd could be adapted to be dotnet build --property:OutputPath=DESIRED_PATH. Since we are not multi-targeting we shouldn't run into issues here. Otherwise we can always bump down the SDK version used for building

FelixS90 commented 1 year ago

Memo (some things to consider when deriving a solution):

Most SCA tools do not support C/C++ - vcpkg if at all. BlackDuck is one of the more promising here.

More info: No support from dependabot: https://github.com/dependabot/dependabot-core/issues/2027 https://github.com/dependabot/dependabot-core/issues/7451

No support from MS sbom-tool (not sure though): https://github.com/microsoft/component-detection (only vcpkg in beta as of 2023-11-17) Strangely enough there is https://github.com/microsoft/sbom-tool/issues/81, which claims cmake support, but it does not say so on https://github.com/microsoft/component-detection

No support from ORT tool: https://github.com/oss-review-toolkit/ort/issues/2031

FelixS90 commented 1 year ago

@DaveyJonesBitPail

As discussed I suggest the following:

  1. Try to have the MS sbom-tool run on CMakeBuild (czicompress) Expectations: a) Dependencies currently statically stored in THIRD_PARTY_LICENSES_ARTIFACT_DISTRIBUTION.txt and THIRD_PARTY_LICENSES.txt are detected by the tool b) SBOM is uploaded together with the artifacts
  2. Make use of the SPDX Dependency Submission Action by uploading the results of Step 1 in SPDX and have this integrated with dependabot
  3. Following "Generating Software Bills of Materials (SBOMs) with SPDX at Microsoft | Validating our SBOMs at release", have a run of .NET Build (CziShrink) fail if the hash validation tool of the sbom-tool reports the NuGet package to not match the SBOM created in Step 1
  4. Create final SBOM for czishrink based on SBOM from Step 1 and SBOM from czishrink itself (either through sbom-tool as well or already existing dependabot [which would probably be the preferred option w.r.t. Step 2])