coreruleset / coreruleset/plugin-registry

Validate registry.yaml's license field against real SPDX identifiers

Open Beginner friendly
#49 0 comments 0 reactions 0 assignees View on GitHub

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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.