joewitt opened a new pull request, #11636: URL: https://github.com/apache/nifi/pull/11636
## Summary - UnpackContent now verifies CRC-32 for every ZIP entry that provides a checksum, including entries skipped by File Filter and directory entries. - On mismatch, any FlowFiles already created for earlier entries are removed and only the original archive is routed to `failure`. The error is logged without a stack trace. - Encrypted ZIP handling (Password configured) is unchanged: zip4j does not expose the uncompressed checksum, so CRC validation is not applied there. This is a behavior change for corrupt ZIP FlowFiles that previously unpacked without error (NIFI-15718). A mismatched CRC means the archive is untrustworthy, so there is no property to ignore it. ## Test plan - [x] Generated STORED and DEFLATED ZIPs with valid CRC route extracted entries to success and the original to original - [x] Generated ZIPs with a bad CRC (single-entry and last entry of a multi-entry archive) route only the original to failure - [x] File Filter still extracts matching entries when all CRCs are valid - [x] File Filter does not extract a skipped entry, but a bad CRC on that skipped entry still fails the archive - [x] Directory plus nested file with valid CRCs unpacks the file - [x] Existing encrypted ZIP tests still pass - [x] CRC mismatch is logged without a throwable/stack trace - [x] Local NiFi: drop `nifi-standard-nar` and confirm a two-entry ZIP with a bad CRC on the second file fails cleanly -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
