Repository navigation
fix(cache): validate git version/ref values before rev-parse - #317
Merged
Merged
Conversation
Skill, plugin and hook entries pass def.version, def.ref (and repo
suffixes) to `git rev-parse --verify <ref>^{commit}`. Nothing checked
them first, so rev-parse's revision syntax (HEAD~2, main@{1}, :/text,
a..b) and option-like values reached git.
resolveRef, the only place these values reach git, now accepts only
plain tag/branch names and SHAs (letters, digits, . _ / + -, no leading
"-", no "..") and fails with a clear error otherwise. Lockfile pins
are checked the same way.
Closes #308
The capabilities-manager reference still described ${PLUGIN_DATA} as
~/.capa/plugin-data/<projectId>/<pluginId>/ that survives plugin updates.
Since #286 the folder is <slug>-<hash>, keyed by the declared source, and
it is removed when the plugin is no longer declared and by capa clean.
Match docs/README.md.
Closes #309
This was referenced Oct 14, 2026
The allowlist rejected tags git accepts, such as changesets/lerna
monorepo tags (@scope/pkg@1.2.3), "feature#12" or unicode names, which
installed fine before. Reject what git check-ref-format rejects instead
(control characters, space, ~ ^ : ? * [ \, "..", "@{", a leading
"-", "/" or ".", and similar), which still rules out rev-parse's
revision syntax and option-like values.
The offline snapshot fast path only checked that a lockfile pin was 40
characters long before using it as a path segment, so a tampered
resolvedRef could point at another local directory. It now requires 40
hex characters; anything else falls through to resolveRef, which
rejects it.
docs(skills): correct the PLUGIN_DATA path and lifetime
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
def.version,def.ref, repo suffixes and lockfile pins reachedgit rev-parse --verify <ref>^{commit}unchecked, so rev-parse's revision syntax and option-like values could get through. Closes #308.Stack 3/5: base #316, next #318.
What changed
resolveRefinmirror.tsis the only place these values reach git (skills, plugins and hooks all go through it). It now rejects whatgit check-ref-formatrejects:~ ^ : ? * [ \;..and@{;@;-,/or.;/or.;//and.lockcomponents;HEAD~1,main@{1},:/text,v1..v2) and option-like values (--output=...).@scope/pkg@1.2.3(an allowlist in the first version of this PR rejected those).snapshot.ts) now requires a lockfile pin to be 40 hex characters before using it as a path segment. A tamperedresolvedReflike../../...could otherwise point at another local directory. Anything else falls through toresolveRefand is rejected.Test plan
version,refand the pinned commit;v1.0.0still resolves;@scope/pkg@1.2.3,pkg@1.2.3,release/1.0,feature#12,caféandv1.0.0+build.1pass validation.bunx tsc --noEmitChecklist
bunx tsc --noEmitpasses🤖 Generated with Claude Code