The previous change prevents the transformer from writing a file outside of
the working directory.
However it still produced an entry for an errant file when producing just contents,
and not writing to the file system. However, the errant path would be added to the
message and might be used by subsequent components to write to the file system.
This situation is present in the `UnZip2FileTests`.
While this vulnerability is not directly exposed by the framework, user applications
could be affected by it.
When the file name holds path traversal file names it gets
concatenated to the target extraction directory,
the final path ends up outside of the target folder.
Fixes GH-164 (https://github.com/spring-projects/spring-integration-extensions/issues/164)
* Move `deleteFile` logic to the end of of `ZipTransformer#doZipTransform()`
* Add `deleteFile = true` for the `ZipTransformerTests`
* Add `<request-handler-advice-chain>` to the transformers XSD definitions
* Upgrade to Gradle 3.0
* Upgrade dependencies
Move delete logic before reply message creation
* Upgrade to Gradle-2.5, SI-4.2.4
* Remove redundant dependencies
* Add `slf4j-log4j12` to avoid log noise during testing
* Add `settings.gradle` to allow Artifactory Release Management
* Move XSD stuff to the proper place - `org\springframework\integration\zip\config`
* Get rid of manual `enum` transformation in the `Parser`:
- we can't do that there because `property-placeholder` and SpEL are processed later
- no reason to do that at all - `enum`s are properly converted by the SF during bean population phase
* Fix `UnZipTransformer` to `delete()` file in the `finally` block after closing the `InputStream` on file
