Symlinks: a render writes through a link, a check-then-use race, and a bad link blocking checkout
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
Start with crates/newgit-core/src/manager.rs around line 3109 and read the render write path, then compare it with the symlink refusal in capture and the behavior of tracker checkout/pull. The issue identifies four open safety and behavior decisions, including an O_NOFOLLOW approach for tracked-file reads. Done means resolving these cases and defining the expected behavior for checkout and symlinked directories.
Written by the indexing model from the issue text.
Description
#281 (for #258) stops capture from following symlinks. Left open, most important first:
- A render writes through a symlink. If a
[[render]] pathis a link, rendering writes into the link's target, which can be outside the workspace (crates/newgit-core/src/manager.rs, around the render write, ~line 3109). This is the write side of #258: anything that can put a link at a rendered path can make newgit rewrite an arbitrary file the user can write, with ports and exports substituted in. The render should refuse a link at its path, as capture now does, naming the path and target. - A check-then-use race remains. A regular file swapped for a link between the check and
git hash-objectwould still be followed. Closing it means reading tracked files in-process withO_NOFOLLOWinstead of handing paths to git. - A bad link now blocks
tracker checkout/pull. The safety capture before them refuses a link that leaves the workspace, so they fail until the link is removed by hand. The error says so. Should checkout be able to replace the link itself (the issue noted it used to), given the user asked for the lane's content? - A tracked path under a symlinked directory is always refused, even when the directory points inside the workspace, matching git's "beyond a symbolic link". Stricter than strictly needed; relax for the inside case?
- Dominant language
- Rust
- Stars
- 0
- Forks
- 0
- Avg merge
- 7h 20m
- Merged PRs (30d)
- 80
Getting set up
We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Spheroman/newgit
-
Port allocation order within a resource is unspecifiedPossibly taken A pull request linked to this issue is open or already merged. Opendocumentation good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Spheroman/newgit#59 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
Spheroman/newgit#289 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
Maintainers usually reply within 1 day
All issues in Spheroman/newgit
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
penso/herdr-gpui#934 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Y-ASLant/ElegantClipboard#178 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
linxiv-dev/linXiv#384 · 1 comment ·
Maintainers usually reply within 1 day
-
priority middle
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
KATO-Hiro/AtCoderClans#12945 ·
Maintainers usually reply within 1 day
-
bug drawings ui
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
userFRM/egui-charts#1595 ·
Maintainers usually reply within 1 day