Better validation for input/output paths
Nobody has claimed this yet.
- Dominant language
- Shell
- Stars
- 5
- Forks
- 3
- Avg merge
- 2d 15h
- Merged PRs (30d)
- 1
Description
-
Doc Kit 0.5 now uses an additional regex
charclass_files_strictto try to avoid writing to out-of-scope output paths on the user's machine. However, it does not quite protect against enough cases.
../is caught at the beginning of the string but will not be caught, e.g. after a leading./or withinsome/path/../../../../../now/we/are/very/far/up.
There may be other issues I did not think about. -
For the input paths, we use
charclass_files_relaxedand that intentionally allows a leading../, however, even there, we still should not allow e.g.../../because then we're outside the repo and it does not make sense anymore.
Contributor guide
No contributing guide indexed for this repository
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.
Research direction
Locate the definitions and uses of charclass_files_strict and charclass_files_relaxed in the repository, then inspect how input and output paths are validated. Verify behavior for ../ after ./, traversal embedded in a path, and repeated ../ in input paths; done means out-of-scope output paths and input paths beyond the repository are rejected.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- shell
- Domain
- security
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100