Issue #1227 - Get licenses for NuGet packages

[HeyeOpenSource]

Description

• Fixes Get licenses for NuGet packages #1227

Type of change

• New feature (non-breaking change which adds functionality)

Checklist:

• I have added unit tests that cover changed behavior
• I have tested my code in common scenarios and confirmed there are no regressions
• I have added comments to my code, particularly in hard-to-understand sections

[HeyeOpenSource]

Just for the record:
I oriented myself at the golang cataloger.

The configuration can also be influenced by the following four environment variables:

• NUGET_SEARCH_LOCAL_LICENSES or SYFT_DOTNET_SEARCH_LOCAL_LICENSES
  • 'true' | 'false'
  • Search for NuGet packages in all known local cache directories.
• NUGET_SEARCH_REMOTE_LICENSES or SYFT_DOTNET_SEARCH_REMOTE_LICENSES
  • 'true' | 'false'
  • Search for NuGet packages in all enabled known remote NuGet package repositories eg. https://api.nuget.org/v3-flatcontainer/ as retrieved from https://api.nuget.org/v3/index.json (unless the NuGet package providers setting is overridden)
• NUGET_PACKAGE_PROVIDERS or SYFT_DOTNET_PACKAGE_PROVIDERS
  • Expects a comma-separated lists of the URLs of remote NuGet package repositories to use when searching for remote NuGet packages / licenses.
  • Defaults to all enabled known remote NuGet repositories if undefined.
• NUGET_PACKAGE_PROVIDER_CREDENTIALS or SYFT_DOTNET_PACKAGE_PROVIDER_CREDENTIALS
  • Expects a comma-separated lists of the credentials (<username>:<password>) for remote NuGet package repositories to use when searching for remote NuGet packages / licenses in a package repository requiring authentication.

[HeyeOpenSource]

FYI:
The feature for defining credentials should mostly be applicable to commercial CI/CD environments,
where access restriction is required by appropriate data security requirements.

Gitea for example allows to create such code- and NuGet package repositories.

[HeyeOpenSource]

Switched back to draft due to commit by @wagoodman
Create single license scanner for all catalogers (#3348)

[HeyeOpenSource]

Since make test did not throw any errors, I feel free to return this pull request back to Ready for review. 😄

[HeyeOpenSource]

The Validations workflow finally throws no more errors at me. 👍
cf. Validations #17

[kzantow]

Hey @HeyeOpenSource, thanks very much for this PR! Generally speaking, it looks like you've followed the same patterns used elsewhere and this change looks really good. There are a couple specific things I'd like to note:

• instead of adding a bunch of binary files for the tests (including unneeded images and such), could we build these to a test docker image? for example Java runs some builds for test artifacts
• it looks as though there are a number of things reliant on the dotnet executable; can we get this information without it? if we could, this will definitely help move this PR forward more quickly
• environment variable usage should be cleaned up as noted in more specific comments

[HeyeOpenSource]

After tackling all review conversations, the Validations action is all green once more:
Validations #27

• instead of adding a bunch of binary files for the tests (including unneeded images and such), could we build these to a test docker image? for example Java runs some builds for test artifacts

I have removed any artifacts, which are not strictly neccessary.
As you correctly stated it does not really make sense to have obsolete images and binaries clogging up the repo.