[nextestudios]

Summary

• Wrong AES password is now reported as such. SharpCompress rejects a WinZip AES password through the 2-byte verifier with InvalidFormatException("bad password"); ErrorMapper mapped it to "wrong password or corrupt" (non-fatal, per entry). It now maps to WrongPassword, so the extraction stops before writing and the app asks for the password again, like ZipCrypto/RAR.
• Fixtures:
  • zip/Zip.deflate.WinzipAES.zip (AES-256, AE-2, password test) copied unchanged from SharpCompress b6cc95af (MIT, same provenance as the existing RAR/7z fixtures); extracted files are checked by SHA-256 against the originals.
  • AesZipFixtures (test support) writes AE-1/AE-2 archives per the public WinZip spec (PBKDF2-HMAC-SHA1, AES-CTR, HMAC-SHA1), used for AES-128 (AE-1, CRC checked) and AES-192 (AE-2, CRC 0 skipped).
• Tests: missing → PasswordRequired; wrong → WrongPassword, nothing left behind; correct → byte-identical content; a tampered AE-1 entry is refused by the CRC check and not placed (security boundary).
• docs/archive-support.md, fixture README and both changelogs updated with the observed results. Documented limitation: AE-2 stores CRC 0 and the engine doesn't verify the HMAC, so tampered AE-2 data is only noticed if decompression fails.

Tested in CI

• Windows runner: all new tests pass.

Manual checks

• None needed beyond the existing password keyboard flow.

Closes #64

🤖 Generated with Claude Code