Verification & trust
A listing carries one of three words, and each comes from a different party making a different promise. This page explains what each one claims and what none of them claims.
On this page(5 sections)
The three words a listing can carry
Every entry in a registry has a trust state. That editorial claim is asserted by pull request. In the official registry it is separate from the source-bound admission record that the automated workflow writes after both security checks pass.
| State | What it claims | What it doesn't |
|---|---|---|
listed | In the official registry, the exact source passed both automated admission checks. | No human source review is claimed. A third-party registry defines its own admission boundary. |
verified | Somebody here read the source at that exact commit. | A newer commit is a new listing, and is unverified until read again. |
blocked | Known-malicious or known-broken, with the reason recorded alongside. | The row stays in the file rather than being deleted. |
Listed is the honest default, and most rows will always be listed. Official discovery only enables a listed or verified extension while its securityReview matches the repository, commit, optional subdirectory, current policies and scanner version. An entry that states no trust level on a third-party registry still resolves to listed, but that does not imply it passed intentic's admission checks.
A blocked entry stays in the file. Removing the row would hide it from people browsing and tell the people who already installed it nothing, which is backwards: they are the ones at risk. Every blocked row carries its reason, so an advisory can quote it rather than saying "this was withdrawn" and leaving the reader to guess.
What the nightly scan checks
Separate from admission, a nightly job re-derives a handful of compatibility facts from your pinned commit, as a stranger holding nothing but the pointer. It answers the browser's narrower question, will this thing load?, and is why a gallery card can show a ✓ loads mark that nobody typed.
| Checked | What comes back |
|---|---|
manifest | The manifest at that commit parses, or the reason it doesn't, verbatim. |
bundle | The entry bundle exists and can load where it would be installed, or "none", for an extension that ships no UI. |
engines | The app version range the manifest declares. A raw fact, not a verdict: the scan doesn't know which version you run. |
Each answer is bound to the sha it was read from. Repoint your listing at a new commit and the checks disappear from the card until the next scan, rather than yesterday's verdict describing today's code. An absent check says nothing at all, which is the honest thing for it to say.
This is evidence, not endorsement. "It loads" and "somebody read it" are different claims made by different parties, and the gallery keeps them visually apart for that reason.
Five layers, and precisely what each guarantees
Trust in an extension is not one thing. Five separate mechanisms protect the person installing yours, they fail in different ways, and the reason to lay them out in a table is that the middle column is easy to over-read:
| Layer | What it guarantees | What it doesn't |
|---|---|---|
| Sha pinning | The approved code is the running code. Force-pushing your branch changes nothing on an installed sandbox. | That the code is good. |
| The manifest gate | Declared host integration. Undeclared registrations are refused and cooperative daemon calls are checked. | Browser or process confinement. Extension code can use capabilities outside the extension API. |
| Deterministic security scan | Trivy fails admission on known high or critical dependency flaws with fixes, committed secrets, and dangerous deployment configuration. | That unfamiliar behavior is benign, or that vulnerability data and detection rules are complete. |
| Adversarial agent audit | An intentic agent reads every executable surface and shipped artifact in the exact source; blocked or unjudged fails closed. | A proof of safety or runtime isolation. It is a fallible semantic review control. |
| Human verification | Somebody here independently read the source at that same commit. | An ongoing audit of later commits. |
The honest summary: installing an extension is trusting its author, the same way installing an editor plugin is. What intentic contributes is source-bound deterministic scanning and adversarial review, optional human verification, and a legible declaration of cooperative host access. Those reduce risk; they do not turn code sharing the app and sandbox into confined code.
Getting verified
Ask, in the pull request that lists you or one after it. Verification is somebody reading your source at the commit you pinned, so what makes it quick is what makes it possible to read: a small entry bundle you didn't minify beyond recognition, a manifest whose declared routes are the ones the code actually calls, and a description that matches the two.
Three things follow from it, and they're worth knowing before you decide it matters to you:
- The gallery ranks verified first, and sorts by stars within that. It is the one editorial thumb on the scale.
- It is a precondition for unattended updates. An owner may set an extension to update itself, but that policy only fires when four things hold at once, and a human-verified listing is the first of them.
- It expires at every new commit. Verified describes a commit, not a publisher. Ship a new sha and the listing is back to what a fresh reading of it would support, which is the only way the word can keep meaning anything.
When a listing goes bad
The same daily comparison that shows an owner "update available" also carries trust changes back to sandboxes that already installed you. Two of them do something:
- Blocked raises an advisory on the installed row, quoting the registry's recorded reason, and by default switches the extension off. That is the one automatic action the model permits: disabling runs no new code and reverses with a click.
- Security fix is the mirror image: a flag on your new entry saying its commit fixes a security problem in earlier ones. It promotes the update badge from ambient to loud, because there the old version is the dangerous one and waiting is the risky choice.
Both are asserted by pull request, exactly like trust, and are worth exactly that review. Neither can be set by the code being described.
Related pages
- Publish & registries: get the pointer listed in the first place.
- Install & manage extensions: what these words look like at the moment somebody clicks install.
- The gallery: the states above, rendered, on real listings.