coreruleset / coreruleset/plugin-registry
Validate registry.yaml's license field against real SPDX identifiers
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 53
- Forks
- 12
- Avg merge
- 7h 30m
- Merged PRs (30d)
- 1
Description
Problem
registry-schema.json's license field only checks shape, not membership in the actual SPDX license list:
"pattern": "^[A-Za-z0-9][A-Za-z0-9.+-]*$"
This accepts any SPDX-looking string, including typos or made-up names (e.g. Apach-2.0), as long as the characters are alphanumeric plus ., +, -. It doesn't validate that the value is a real, known SPDX license identifier.
This isn't a security issue — the pattern already restricts to a safe character set, so unlike repository (#48) there's no injection risk. It's a data-quality gap. It's also one of the original requirements in #21: "SPDX license identifiers" was listed as a field CI should validate, and today it's only shape-validated.
Options considered
- Full SPDX list as an enum (~600+ identifiers via spdx/license-list-data): most complete, but enum bloat for a registry where every plugin today uses one of three licenses, and doesn't cover license expressions (
MIT OR Apache-2.0), which check-jsonschema can't validate without a small custom grammar. - Curated enum of licenses actually relevant here (recommended): the licenses already in use (
Apache-2.0,GPL-2.0,GPL-3.0) plus a handful of common OSS licenses. Keeps the same trust model the rest of the registry already has — adding a new license means a reviewed PR to the schema, not silent acceptance of an unvetted string. Smaller and easier to maintain than the full list.
One wrinkle either way: GitHub's own license detector reports our current GPL entries as GPL-2.0/GPL-3.0, which are deprecated-but-valid SPDX IDs (superseded by -only/-or-later variants). Whatever list we land on should include those as-is rather than force an unrelated migration.
Suggested next step
Add a curated enum to the license property in registry-schema.json, seeded with the licenses currently in registry.yaml, and document in docs/registry-schema.md that new licenses are added via schema PR.
Refs #21, #48.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the license property in registry-schema.json and compare it with the existing license values in registry.yaml, including GPL-2.0 and GPL-3.0. Add the curated enum described in the issue, then update docs/registry-schema.md to explain how new licenses are added through a schema PR and verify the current registry remains valid.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- json, markdown, yaml
- Domain
- documentation, tooling
- Issue type
- Feature
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 78/100