fix(git): open absolute-path files via osfs root "/" (fixes "public key is not configured")#348
Merged
Merged
Conversation
smecsia
approved these changes
Jun 27, 2026
Cre-eD
approved these changes
Jun 27, 2026
Semgrep Scan ResultsRepository:
Scanned at 2026-06-28 07:43 UTC |
Security Scan ResultsRepository:
Scanned at 2026-06-28 07:43 UTC |
📊 Statement coverageMeasured on the documented included set (see
Baseline: |
163562c to
3b28c19
Compare
…eveal)
OpenFile delegated absolute paths to osfs.New("").OpenFile(...). Under go-billy
v5.9.0 the default ChrootOS resolves symlinks relative to its root via filepath.Rel;
with an empty root (which cleans to "."), filepath.Rel(".", "/abs/path") always errors,
so every absolute open returned "chroot boundary crossed".
This broke profile configs that reference keys by absolute/tilde path (e.g.
privateKeyPath: ~/.ssh/id_rsa). WithKeysFromScConfig loads the private key first, so the
failed open aborted the whole profile load. The error is swallowed by IgnoreConfigDirError
at command bootstrap, leaving the public key unset — surfacing later as the misleading
"public key is not configured" on `sc secrets reveal` / `add` / `allow`.
Root the OS filesystem at "/" for absolute paths so Rel("/", "/abs/path") is well-defined.
The relative-path fallback (wdFs) stays rooted at "" so it keeps resolving against cwd.
Updated the unit test that had codified the broken "chroot boundary" behavior to assert
absolute-path opens now succeed.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Ilya Sadykov <smecsia@gmail.com>
3b28c19 to
4095c51
Compare
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.
Problem
sc secrets reveal (and secrets add / secrets allow) fails with:
Error: public key is not configured
even when the profile is correctly configured and the key files exist. It reproduces with any profile that references keys by path, e.g. .sc/cfg.default.yaml:
projectName: my-project
privateKeyPath: ~/.ssh/id_rsa
publicKeyPath: ~/.ssh/id_rsa.pub
Root cause
git.repo.OpenFile delegates absolute paths to osfs.New("").OpenFile(...). Under go-billy v5.9.0, the default ChrootOS resolves symlinks relative to its root via filepath.Rel. With an empty
root (which cleans to "."), filepath.Rel(".", "/abs/path") always errors, so every absolute open returns chroot boundary crossed.
The failure cascades into the misleading error:
This was a latent regression introduced with the go-billy v5.9.0 upgrade — there was even a unit test that had codified the broken chroot boundary behavior as a "QUIRK."
Fix
Root the OS filesystem at "/" (not "") for absolute paths, so filepath.Rel("/", "/abs/path") is well-defined:
if path.IsAbs(rPath) {
return osfs.New("/").OpenFile(rPath, flag, perm)
}
The relative-path fallback (wdFs = osfs.New("") in initRepo) is intentionally left rooted at "" so it keeps resolving against the process cwd.
Updated the unit test that asserted the broken behavior to instead assert that absolute-path opens succeed and read content back.
Verification
Impact
Restores key-by-path / ~/.ssh-style profile configs for all secrets operations. No behavior change for inline-key profiles or relative-path resolution.