Security
How the ClarkCant Marketplace handles package trust: the security boundary, what verified, listed and featured mean, and how to report a vulnerability.
Draft — requires legal review before production launch. This text describes how the service works today. It is not final legal terms, and placeholders marked TO BE CONFIRMED still need an owner's decision.
The boundary
- The marketplace discovers and curates. It indexes package metadata from npm, records automated checks and shows curation decisions.
- npm distributes. Package tarballs, versions and integrity digests come from npm. The marketplace never hosts or serves package code.
- ClarkCant executes. ClarkCant downloads the exact version from npm, re-verifies its integrity, shows the permissions the manifest requests, asks for your consent and runs the package in its declared isolation lane.
Nothing on the marketplace grants a package any permission, and the marketplace never runs community code, not even to render a preview: previews are images, video and metadata only.
What the words mean
| Term | Meaning | What it does not mean |
|---|---|---|
| Listed | The package passed automated checks when indexed: a valid ClarkCant manifest and a tarball that matched npm's sha512 integrity digest | A person has reviewed the code, or the code is safe |
| Featured | Marketplace curators chose to highlight the package | A security audit |
| Hidden / rejected | Curators removed the package from public pages and APIs | Anything about other versions or other registries |
| Verified publisher | The publisher proved control of a web domain with a DNS TXT record | That the publisher's packages are safe or reviewed |
| Tarball integrity | The tarball we downloaded matched the sha512 digest npm publishes | That the code is benign; ClarkCant checks integrity again itself |
| Provenance recorded | npm lists a provenance attestation; we store its reference | A verified signature: the marketplace does not verify attestations yet |
Package listing data is untrusted input written by package authors. READMEs and descriptions are sanitised before display and scripts in them never run.
How the site protects you
- A strict Content Security Policy, no third-party scripts, and framing only by the site itself.
- Rate limits on sign-in, the APIs, search and package submission.
- Every admin and curator change is validated against schemas, needs a scoped credential and is written to an audit log. Agents and tools use scoped tokens; nothing gets direct database access.
Reporting a vulnerability
Please report vulnerabilities privately to [TO BE CONFIRMED: security contact email] and allow us time to fix them before disclosure. Do not test against other people's accounts or data.