GHSA-rrfc-2x66-j7xh: 
Rust vulnerability analysis and mitigation

The duplicate check compares names with to_lowercase, but filesystems fold differently, so two entries of a crafted archive can land on one file. The run ends with exit status 0 and the archive gone, and one file's data is lost. On macOS on default APFS, with main at b2bc6c29: python3 - <<'PY' import zipfile with zipfile.ZipFile("ss.zip", "w") as z: z.writestr("straße.txt", b"first file\n") for i in range(600): z.writestr(f"f{i}.txt", b"x") z.writestr("STRASSE.txt", b"second file\n") PY hatchzip extract ss.zip -y -o out --keep-free 0 It prints Extraction complete: 602 entries, exits 0 and removes the archive, and out holds 601 files. The filler puts the two names in different batches; without it the run stops with "already exists". The same happens with s and ſ, σ and ς, fi and fi, and with the NFC and NFD forms of a name, which you mentioned on #50. By reading the kernel's casefold code, ext4 and f2fs casefold should behave alike, but I haven't run those, or Windows. A related path needs no crafted archive. A resume treats whatever is at an entry's path as its own, and only compares names exactly. If first.zip has extracted Makefile into a folder, and second.tar with makefile is killed after one commit and resumed with that folder on a filesystem that folds case, Makefile is deleted and the run exits 0. Fix ideas: compare with a real case fold after normalization where the destination folds case, or refuse names outside ASCII there, and before a resume deletes or replaces something, compare its spelling on disk with the entry's bytes. Not fixed by the case-only PR for #50, which only changes destinations known to keep names apart.