> ## Blocked pending the release of go-git v6 > > `phase::blocked` as of 2026-08-24. **Do not file this yet.** > > `v6.0.0-alpha.5` already fixes the substantive half (an in-tree `.git` symlink > opens, and the handle works). Filing against v5 while v6 is in alpha asks > maintainers to spend time on a line that may be closed to fixes anyway, and > the honest report changes shape depending on what v6 ships as stable. > > **The condition that unblocks this:** go-git v6 reaches a stable release. > Check with one line: > > ```bash > go list -m -versions github.com/go-git/go-git/v6 | tr ' ' '\n' | tail -5 > ``` > > When it does, re-measure both rows of the version table against the stable > tag, then decide. If v6 stable still refuses an out-of-tree `.git` symlink, > question 2 below is the whole report and question 1 becomes "is v5 getting > backports at all". If v6 stable fixes both, this ticket closes unfiled. > > `ready-for-human` was removed while this is blocked, so a queue filtered on it > does not surface something nobody should act on. Put it back when v6 ships. > ## Human-owned — not for agent action > > This ticket exists to be picked up **by a person**, deliberately. It asks for > an issue to be filed on a third-party public tracker, under a personal > identity, on a project this estate does not control. That is not something to > automate: the artefact is public, attributed, and not undoable. > > An agent may update this ticket, but must not file the upstream report. Found while implementing [#6](https://gitlab.com/phpboyscout/go/repo/-/work_items/6) (spec 0004), where fifteen `.git` shapes were measured against `OpenLocal`. This one is not #6 and is not ours to fix. **We are not exposed.** `OpenLocal` reports this error rather than papering over it, `TestOpenLocal_GitDirRedirects` covers the symlink case as a must-keep-reporting row, and `docs/explanation/limitations.md` documents it. Nothing here breaks. **Update, 2026-08-24: v6 already fixes the substantive half.** The first draft of this report was written against v5 only. Checking the v6 alpha line before filing changed what is worth reporting, and shrank it considerably. Read the version table below before writing anything upstream. Not urgent either way. A `.git` symlink is uncommon, though it is a shape real git supports and some people rely on (a git directory on a different volume, or a checkout assembled by a sync tool). --- ## `go-git/go-git` **Where:** https://github.com/go-git/go-git/issues **Versions checked**, both measured rather than inferred: | Version | `.git` symlink → target **inside** the working tree | → target **outside** | |---|---|---| | `v5.19.2` (go-billy `v5.9.1`) | `chroot boundary crossed` | `chroot boundary crossed` | | `v6.0.0-alpha.5` (go-billy `v6.0.0-alpha.2`) | **opens, and the handle is usable** | `path escapes from parent: ".git"` | The v6 handle was verified rather than assumed to work: `PlainOpen` returns a nil error, `Head()` resolves, and `CommitObject` reads the seeded commit back. A nil error and a usable handle are not the same thing, which is a lesson this module learned the hard way in #5. So **v6 fixes the case that made this a defect** and gives the remaining refusal an accurate message. What is left to ask upstream is much smaller than "here is a bug". ### Suggested title > v5: `.git` symlink fails with "chroot boundary crossed" even for an in-tree target (fixed on v6 — backport wanted?) ### Body On the v5 line, `PlainOpen` cannot open a repository whose `.git` is a symlink, and it fails the same way whatever the link points at. A target that is a **sibling directory inside the same working tree** fails exactly as one pointing outside does, so this is not the boundary check refusing an escape. `dotGitToOSFilesystems` (`repository.go:341`) stats `.git`, which follows the symlink and reports a directory, and then chroots onto the symlink **itself**: ```go fi, err = fs.Stat(GitDirName) // ... if fi.IsDir() { dot, err = fs.Chroot(GitDirName) // repository.go:389 — roots at the link, not its target return dot, fs, err } ``` `PlainOpenWithOptions` then calls `dot.Stat("")` (`repository.go:316`). Resolving that root means resolving the symlink and expressing its target relative to the root, and the root *is* the symlink, so the target is always outside it. `ChrootHelper.resolveFollowedRoot` → `linkTargetRel` → `relativeToRoot` therefore returns `billy.ErrCrossedBoundary` unconditionally. **Reproduction on v5** — go-billy only, no repository and no go-git: ```go func TestChrootOntoSymlink(t *testing.T) { dir := t.TempDir() os.Mkdir(filepath.Join(dir, "realgit"), 0o755) os.Symlink("realgit", filepath.Join(dir, ".git")) // target is INSIDE dir fs := osfs.New(dir) fi, err := fs.Stat(".git") fmt.Println("Stat(.git):", err, "isDir:", fi.IsDir()) // <nil> true dot, err := fs.Chroot(".git") fmt.Println("Chroot(.git):", err) // <nil> _, err = dot.Stat("") fmt.Println(`dot.Stat(""):`, err) // chroot boundary crossed } ``` `osfs.New(dir).Stat(".git")` on its own resolves the same symlink correctly, so the chroot helper is not generally broken. It is specifically a chroot whose own root is a symlink. **On `v6.0.0-alpha.5` the in-tree case opens and works**, and an out-of-tree target is refused with `path escapes from parent: ".git"`, which describes what actually happened rather than reporting a boundary crossing that did not. **So the questions are:** 1. Is a v5 backport wanted, or is v5 effectively in maintenance and this simply the reason to move to v6? Either answer is useful to write down, because the v5 error message points a reader at a security problem they do not have. 2. On v6, is refusing an out-of-tree `.git` symlink intentional? Real git follows it. If it is deliberate sandboxing that is worth saying in the docs, since it is a real difference in behaviour from the git CLI. Happy to open a PR for a v5 backport if that is wanted.