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 main environment variables:

• SYFT_DOTNET_SEARCH_LOCAL_LICENSES
  • 'true' | 'false'
  • Search for NuGet packages in all known local cache directories.
• SYFT_DOTNET_LOCAL_CACHE_PATHS
  • Expects a comma-separated lists of local cache directories for NuGet packages to use when searching for local NuGet packages / licenses.
  • Defaults to all known local NuGet repository cache directories as retrieved from the dotnet SDK-tool if undefined.
• 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)
• 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 as retrieved from the dotnet SDK-tool if undefined.

NuGet package provider credentials:

These are only ever used, if a NuGet package repository returns the status code 401 Unauthorized when trying to retrieve a remote NuGet package.

• SYFT_DOTNET_PACKAGE_PROVIDER_CREDENTIALS_USERNAME
  • Username for a credential for remote NuGet package repositories to use when searching for remote NuGet packages / licenses in a package repository requiring authentication.
• SYFT_DOTNET_PACKAGE_PROVIDER_CREDENTIALS_PASSWORD
  • Password for a credential for remote NuGet package repositories to use when searching for remote NuGet packages / licenses in a package repository requiring authentication.

N.B.:

• Credentials are only accepted if both username and password are given.

[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]

After tackling all review conversations up to now, 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.

[kzantow]

Thanks for the latest updates; I found a few other things after a finer tooth comb. Other than what's mentioned here, it's looking really good -- very appreciated!

[HeyeOpenSource]

In a sense, the localNuGetCacheResolvers are source content:
These are the folders ('sources') from where the external NuGet dependencies are linked...

Hence, I would currently refrain from changing from the file.Resolver implementation to an fs package implementation.

@kzantow : What do you say?

[HeyeOpenSource]

Thanks for the clarification about the decisions taken.
At the moment I am not quite sure, how I'd go about performing the switch towards the fs package...

Then again:
In a sense, the localNuGetCacheResolvers are source content:
These are the folders ('sources') from where the external NuGet dependencies are linked... 🤷‍♂️

@kzantow : What do you say?