Add new PURL type: 'firefox-extension'

[annextuckner]

This PR registers a new PURL type for Firefox Browser Extensions (add-ons), as distributed via addons.mozilla.org (AMO). It follows the structure and review feedback of the recently merged chrome-extension type (#522), and answers the questions from the Register new PURL type template below.

• Why is this new PURL type needed?
• What are the PURL component level definitions?
• What input do you have from the relevant package ecosystem/community?
• Are there any open questions or concerns about this new PURL type?

Why is this new PURL type needed?

Browser extensions are installable, versioned software packages and an increasingly important software supply chain surface (SBOMs, malware and vulnerability advisories, policy/inventory tooling all need to reference them). The chrome-extension type was registered in #522; Firefox is the other major independent extension ecosystem, with its own store (AMO), its own extension ID format, and — unlike Chrome — a documented public API with downloadable version history. There is currently no standard way to identify a Firefox add-on and version.

What are the PURL component level definitions?

Full definition in types/firefox-extension-definition.json, with generated docs and test cases included in this PR.

Component	Definition
type	firefox-extension (descriptive <browser>-extension naming per #522 / #673 feedback)
namespace	Prohibited — there is no namespace
name	Required. The extension ID from the browser_specific_settings.gecko.id manifest key: either an email-like string of 80 chars or less (e.g. uBlock0@raymondhill.net) or a GUID in curly braces (e.g. {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}). Case sensitive. permitted_characters: `^([a-zA-Z0-9-.]*@[a-zA-Z0-9-.]+
version	Optional (omitted = latest). 1–4 dot-separated numbers per the WebExtension manifest version key, enforced by AMO for new submissions. permitted_characters: ^\d+(\.\d+){0,3}$
qualifiers / subpath	None defined
repository	https://addons.mozilla.org — add-ons are queryable by extension ID via the documented AMO API, and previous versions are listed and downloadable.

Example PURLs (all real, verified against the AMO v5 API):

• pkg:firefox-extension/uBlock0%40raymondhill.net@1.72.2
• pkg:firefox-extension/%40testpilot-containers@8.3.8
• pkg:firefox-extension/%7Bd10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d%7D@4.41.1
• pkg:firefox-extension/uBlock0%40raymondhill.net (latest)

What input do you have from the relevant package ecosystem/community?

• In Add new PURL type: 'chrome-extension' #522, @patrickkettner (Chrome extensions team) reviewed the browser-extension PURL approach and noted the "mozilla add-on store would share identical logic to what you created" — i.e. stable store extension ID as name, optional 1–4 segment version.
• The name and version formats here are taken directly from Mozilla's official documentation (browser_specific_settings.gecko.id, manifest version) and the AMO addons-server API docs; the extension ID is the key Mozilla itself uses in its API and blocklist.
• No direct review from Mozilla staff yet — happy to seek input from the AMO/add-ons team if maintainers want vendor sign-off as was done for Add new PURL type: 'chrome-extension' #522.

Are there any open questions or concerns about this new PURL type?

• Extension ID vs. AMO slug as the name. The mutable, AMO-only listing slug (e.g. ublock-origin) was deliberately rejected in favor of the immutable extension ID, consistent with the Add new PURL type: 'chrome-extension' #522 feedback favoring collision-free primary keys — and because Firefox also supports signed self-distributed extensions that have no AMO listing or slug. The trade-off is percent-encoding (%40, %7B, %7D) in every PURL. An expected-failure test guards against slugs being used as names.
• Case sensitivity: extension IDs preserve case (uBlock0@raymondhill.net), so the name is defined as case sensitive to avoid mangling the canonical ID; AMO lookups are tolerant in practice.
• Legacy versions: a small number of pre-2022 add-on versions use the older "toolkit" version format (letters, e.g. 1.0b3) and would not match the version pattern; the definition notes this and follows the format AMO enforces today.

Checks

Docs and purl-types-index.json regenerated with make gendocs; make checkjson passes; roundtrip canonicalization of all valid test cases verified with packageurl-python.

A sibling PR (#928) adds edge-extension for the Microsoft Edge Add-ons store.

🤖 Generated with Claude Code

[mjherzog]

@annextuckner Thank you for the PR and adapting the "Register new PURL type" template for the PR. We especially appreciate that you provided some failing tests.
We do not require a formal sign-off from Firefox but it would be helpful if you could contact someone at the Firefox team who can review the proposal and document that there are no objections (i.e. lazy consensus).

[mixmix]

Is the second part (the more UUID shaped bit) really case sensitive?

oh... I sampled the database and yes! {5C46D283-ABDE-4dce-B83C-08881401921C}