search

ZEISS / czicompress

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

Automate creation of THIRD_PARTY_LICENSES*.txt #7

Open m-ringler opened 10 months ago

m-ringler commented 10 months ago

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

m-ringler commented 10 months 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 10 months 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 10 months 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 10 months 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])