The latest tagged release. rgit has no long-lived release branches, so a
fix ships in the next tag rather than being backported.
Use GitHub's private vulnerability reporting on this repository (Security → Report a vulnerability). It stays private until a fix ships.
Please do not open a public issue for a suspected vulnerability first.
rgit stages and commits on a caller's behalf, so the interesting failures
are ones where it writes something the caller did not name:
- A symbol anchor that stages bytes outside its own extent, or a path outside the repository.
- A crafted source file that makes the resolver stage content from an unrelated declaration.
- Anything that causes
rgitto run a command the caller did not ask for, beyond thegitinvocations it documents.
- Hooks running arbitrary code.
rgitruns git's hooks exactly asgit commitdoes, and deliberately does not police them (docs/USAGE.md). A malicious hook in a repository you have already checked out is outside this boundary — as it is forgititself. - Language servers and the tree-sitter CLI. Both are optional external
programs you install;
rgitshells out to them and trusts them the way any editor does. That trust does not extend to the pathrgitreachesgopls's daemon socket at: a predictable name in a world-writable temp directory could be pre-created by another user on a multi-user host. So before every dial or spawnrgitcreates or re-verifies a private, UID-scoped,0700subdirectory,Lstats it to reject a planted symlink rather than follow it, and confirms the current user still owns it; any check failing degrades to[ts-only](internal/lsp/dial.go'sprivateSocketDir). Windows has no UID to scope by (os.Getuidreturns-1, naming the directoryrgit--1) and needs no ownership check: its per-user temp directory is already ACL-restricted by the platform. A caller-supplied$RGIT_LSP_SOCKETis exempt — it is the caller's path to manage, not onergitvouches for. - A wrong extent that stages too little. That is a correctness bug — please file it as an ordinary issue.