GeezerVison

<!-- agent -->
GHSA-jm78-9fvv-mhgr reports that config option names containing Git
syntax can be serialized as unintended directives. A regression test showed
that set, set_value, and add_value accepted delimiter, comment, bracket, and
whitespace characters in option names.

Restrict written option names to GitPython's established safe character set of
letters, digits, hyphens, underscores, and dots. This blocks characters that
can change config syntax while preserving option names historically supported
by the writer and SectionConstraint.

A broader audit confirmed that every public option-creating config API and
SectionConstraint delegate reaches this validator; no separate config writer
sink was found. The behavior was checked against Git cf5497b14, and the full
config test module plus dotted-option regression pass.

Assisted-by: GPT 5.6
Co-authored-by: GPT 5.6 <[email protected]>

<!-- agent -->
GHSA-wvpp-8hx9-p66j reports that unsafe-option checks omitted the value
joined to a one-character option when split_single_char_options was false. A
regression test reproduced the mismatch: GitPython checked only -n even though
it emitted a joined -nVALUE token that Git parses as clustered short options.

Collect the exact joined token for unsplit one-character keyword arguments so
the existing clustered-short-option validation sees every option character.
The split form and long-option behavior remain unchanged.

A broader audit confirmed that all guarded keyword-forwarding APIs use
_option_candidates, including clone, ls-remote, fetch, pull, push, archive,
revision, diff, checkout-index, and tag paths. Git cf5497b14 confirms repeated
short-option parsing within a joined token. Focused candidate and unsafe-option
tests pass.

Assisted-by: GPT 5.6
Co-authored-by: GPT 5.6 <[email protected]>

<!-- agent -->
GHSA-4gmw-gg2m-w46p reports that caller-controlled treeish arguments could
be parsed by git read-tree as --index-output and select an arbitrary output
path. A regression test showed that from_tree reached Git instead of raising
UnsafeOptionError; the same unchecked path was reachable through reset and
both merge_tree treeish positions.

Add the project-standard unsafe-option guard and explicit opt-out to
from_tree, merge_tree, and reset. Check positional and keyword candidates so
abbreviations and alternate forwarding forms are covered before read-tree
runs.

A broader audit found only two read-tree sinks in the codebase; both are now
guarded, and reset delegates to the guarded from_tree path. The only remaining
index-output use is GitPython's controlled temporary index. Git cf5497b14
confirms read-tree parses this path-taking option before tree arguments.
Focused index tests and Ruff checks pass.

Assisted-by: GPT 5.6
Co-authored-by: GPT 5.6 <[email protected]>

<!-- agent -->
GHSA-9rj7-rf2p-w77r reports that Repo.init forwarded git-init
options without applying GitPython's unsafe-option policy. A regression
showed template and abbreviated option spellings reached Git without an
UnsafeOptionError and could create the destination before validation.

Add a git-init denylist for template installation and separate Git
directory redirection, check keyword options before any path or directory
mutation, and provide the standard explicit allow_unsafe_options escape
hatch. This preserves trusted uses while rejecting untrusted forwarding by
default.

An audit against Git cf5497b14c5a24f10c13f7e0ee85cb95af13ea6a
(v2.55.0.windows.3-16-gcf5497b14c) confirmed that init and clone are the
built-in commands that consume repository template directories. Clone,
clone_from, and submodule cloning already share the guarded clone helper;
the similarly named commit option only reads a commit-message template.

Validated with the focused init regression, the clone/init unsafe-option
suite, 185 config/Git/index/clone tests, Ruff, and basedpyright.

Assisted-by: GPT 5.6
Co-authored-by: GPT 5.6 <[email protected]>

<!-- agent -->
GHSA-hh9p-6wh2-4mfc reports that high-level rm and checkout wrappers
forwarded pathspec file options without GitPython's unsafe-option policy.
A regression showed that both commands surfaced multi-line pathspec data in
Git errors, while reset consumed the same caller-selected file without a
validation error. The audit also found that reset's positional commit could
carry the option before its argument separator.

Define one shared unsafe pathspec-file option list and apply it to
IndexFile.remove, Head.checkout, and HEAD.reset before invoking Git. Check
reset's positional commit as well as keyword options, retain the standard
allow_unsafe_options escape hatch for trusted callers, and cover abbreviated
long-option spellings.

An audit against Git cf5497b14c5a24f10c13f7e0ee85cb95af13ea6a
(v2.55.0.windows.3-16-gcf5497b14c) found pathspec-file support in add,
checkout/restore, commit, reset, rm, and stash. GitPython has no arbitrary
high-level option forwarding to the other commands, and git mv does not
support this option.

Validated with focused rejection and opt-in tests, 214 affected-module
regressions, Ruff, basedpyright, and git diff --check.

Assisted-by: GPT 5.6
Co-authored-by: GPT 5.6 <[email protected]>

Copilot AI left a comment