-
Notifications
You must be signed in to change notification settings - Fork 142
Description
Is your feature request related to a problem? Please describe.
Our policy to deny packages based on licenses fails for packages without licenses, including our internal GitHub Actions and specific proprietary libraries of vendors. As a result, we'd have to specify many packages in the policy (>100) and continuously have to keep it up to date.
Describe the solution you'd like
Support wildcards for the purls in allow-dependencies-licenses, so we can specify:
allow-dependencies-licenses:
- pkg:githubactions/my-org/*
- pkg:maven/com.vendor.*
Instead of:
allow-dependencies-licenses:
- pkg:githubactions/my-org/my-action-a
- pkg:githubactions/my-org/my-action-b
- pkg:githubactions/my-org/my-action-c
- pkg:maven/com.vendor.group-a/package-1
- pkg:maven/com.vendor.group-a/package-2
- pkg:maven/com.vendor.group-b/package-1
- pkg:maven/com.vendor.group-b/package-2
Functionally, this comes down to:
- Using a wildcard for the name
- Using a wildcard in the namespace to match many packages, even if it concerns many specific namespaces.
Note that the purl spec is strict and only allows version ranges. This wildcard behavior would be specific to this dependency-review-action, although collaboration can be sought with the standard https://github.com/package-url/purl-spec
Describe alternatives you've considered
Alternatively GitHub could start supporting license curations, where licenses information can be ammended on a corporate level, so that LicenseRef-Vendor-Developer-License
can be assigned to certain packages, which can then be checked once with dependency-review-actions.
Additional context
Matching issue in purl spec package-url/purl-spec#600