)]}'
{
  "commit": "798bcaa1eb01de7db9ff1881a3088603ad09b096",
  "tree": "877d3b898e970c180fea3c50e053a0791de2c1d0",
  "parents": [
    "85ec192ac4b000d4e47df6123b65eacbd1fdccfa"
  ],
  "author": {
    "name": "Carey Metcalfe",
    "email": "carey@cmetcalfe.ca",
    "time": "Tue May 16 07:43:44 2023"
  },
  "committer": {
    "name": "GitHub",
    "email": "noreply@github.com",
    "time": "Tue May 16 07:43:44 2023"
  },
  "message": "gh-103861: Fix Zip64 extensions not being properly applied in some cases (#103863)\n\nFix Zip64 extensions not being properly applied in some cases:\r\n\r\nFixes an issue where adding a small file to a `ZipFile`\r\nobject while forcing zip64 extensions causes an extra Zip64 record to be\r\nadded to the zip, but doesn\u0027t update the `min_version` or file sizes in\r\nthe primary central directory header.\r\n\r\nAlso fixed an edge case in checking if zip64 extensions are required:\r\n\r\nThis fixes an issue where if data requiring zip64 extensions was added\r\nto an unseekable stream without specifying `force_zip64\u003dTrue`, zip64\r\nextensions would not be used and a RuntimeError would not be raised when\r\nclosing the file (even though the size would be known at that point).\r\nThis would result in successfully writing corrupt zip files.\r\n\r\nDeciding if zip64 extensions are required outside of the `FileHeader`\r\nfunction means that both `FileHeader` and `_ZipWriteFile` will always be\r\nin sync. Previously, the `FileHeader` function could enable zip64\r\nextensions without propagating that decision to the `_ZipWriteFile`\r\nclass, which would then not correctly write the data descriptor record\r\nor check for errors on close.\r\n\r\nIf anyone is actually using `ZipInfo.FileHeader` as a public API without\r\nexplicitly passing True or False in for zip64, their own code may still be\r\nsusceptible to that kind of bug unless they make a similar change to\r\nwhere the zip64 decision happens.\r\n\r\nFixes #103861\r\n\r\n---------\r\n\r\nCo-authored-by: Gregory P. Smith \u003cgreg@krypto.org\u003e",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "73c6b0185a1a0e4ebb4dce40921e37324138dba0",
      "old_mode": 33188,
      "old_path": "Lib/test/test_zipfile/test_core.py",
      "new_id": "9960259c4cde0c7afbd0504d80abc6ea6cd316ae",
      "new_mode": 33188,
      "new_path": "Lib/test/test_zipfile/test_core.py"
    },
    {
      "type": "modify",
      "old_id": "116b939e55fe7055fd465be2c11979ceb34ecde5",
      "old_mode": 33188,
      "old_path": "Lib/zipfile/__init__.py",
      "new_id": "9fc1840ba1e5340658832ddc30c8394f4c1ccda8",
      "new_mode": 33188,
      "new_path": "Lib/zipfile/__init__.py"
    },
    {
      "type": "add",
      "old_id": "0000000000000000000000000000000000000000",
      "old_mode": 0,
      "old_path": "/dev/null",
      "new_id": "cc1c444449fe9361e5d33b1b600ab6f6ce616414",
      "new_mode": 33188,
      "new_path": "Misc/NEWS.d/next/Library/2023-04-25-19-58-13.gh-issue-103861.JeozgD.rst"
    }
  ]
}