Comparing 3.1.48...3.1.49 · gitpython-developers/GitPython
Commits on Apr 28, 2026
-
reject control chars in written values in configuration
Reject CR, LF, and NUL in GitConfigParser values before writing them to git config files (which also is a deviation from Git which escapes them). GitConfigParser._write() serializes embedded newlines as indented continuation lines by replacing "\n" with "\n\t". Git itself skips leading whitespace before parsing config tokens, so an injected value such as: foo [core] hooksPath=/tmp/hooks is written in a form where the indented "[core]" line is still parsed by Git as a real section header. This lets attacker-controlled input passed to config_writer().set_value() poison repository config, including core.hooksPath, and redirect hook execution for later Git operations. Fail closed instead of stripping or normalizing these characters. Silent normalization can hide unsanitized caller input, and GitPython does not currently round-trip Git-style escaped values such as "\n" as embedded newlines. Apply the validation to set_value(), add_value(), and the public set() path so callers cannot bypass the safer helper API. Add regression tests for the advisory payload and for CR, LF, NUL, and bytes values. This preserves existing read behavior for config files that already contain multiline values while preventing GitPython from writing new unsafe values. Co-authored-by: Sebastian Thiel <sebastian.thiel@icloud.com>and Byron committed
Apr 28, 2026 -
Improve pure Python rev-parse coverage and behavior (#2135)
Port object-resolving revspec cases inspired by gix-revision into deterministic GitPython tests, without shelling out to Git or Gix at runtime. Refactor rev_parse handling around anchors, navigation, peeling, reflog selectors, path/index lookups, describe-style names, and commit-message searches. Document observed Git/Gix behavior differences and the GitPython choices made for user-facing compatibility. Co-authored-by: Sebastian Thiel <sebastian.thiel@icloud.com>
