{"version":"2.1.247","anchor":"git-metadata-files-are-read-with-a-size-cap-instead-of-being","canonical_anchor":"git-metadata-files-are-read-with-a-size-cap-instead-of-being","heading":"Git metadata files are read with a size cap instead of being slurped whole","tier":"notice","area":"Git Safety","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.247\/e\/git-metadata-files-are-read-with-a-size-cap-instead-of-being","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.247","markdown":"### Git metadata files are read with a size cap instead of being slurped whole\n\nA giant git config file can no longer be slurped whole into memory; reads cap at a megabyte.\n\n**What**\n\nReading a repository's `config` now reads at most 1,000,000 bytes and, when more remains, discards the trailing partial line before parsing, so a pathologically large config cannot pull an unbounded amount into memory.\n\n**Details**\n\n- The `.git` file and `commondir` readers moved to the same capped reader, using `sniffEncoding: !0, withBytes: !0`.\n- Those two return null when the read was truncated, so a truncated prefix is treated as no answer rather than parsed as a path.\n\n**Evidence**\n\n`sniffEncoding`\n\n- Area: Git Safety\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 2\/5"}