Raymond created CAMEL-25884:
-------------------------------
Summary: camel-zipfile: support password protection / encryption
(AES, ZipCrypto) in marshal and unmarshal
Key: CAMEL-25884
URL: https://issues.apache.org/jira/browse/CAMEL-25884
Project: Camel
Issue Type: New Feature
Components: camel-zipfile
Affects Versions: 4.23.0
Reporter: Raymond
h3. Description
The Zip File data format (camel-zipfile) can create and read ZIP files, but it
has no way to encrypt or password-protect the archive, or to read a
password-protected one. Users who exchange ZIP files containing sensitive data
(e.g. written to SFTP/FTP servers or sent by email) currently have to leave
Camel's data format and use a third-party library in a custom processor.
h3. Current state
* ZipFileDataFormat is built on commons-compress (ZipArchiveOutputStream /
ZipArchiveInputStream, 1.28.0 in camel-zipfile 4.23.0).
* Commons Compress does not support ZIP encryption (neither traditional nor
AES). Encrypted entries are reported as unreadable (canReadEntryData() ==
false), see [https://commons.apache.org/proper/commons-compress/zip.html]. So
this cannot be solved by upgrading or configuring commons-compress.
* Existing option set (usingIterator, allowEmptyDirectory,
preservePathElements, maxDecompressedSize) has no password/encryption options.
h3. Proposal
Add optional options to the zipFile data format:
||Option||Type||Default||Description||
|password|String|(none)|Password used to encrypt (marshal) or decrypt
(unmarshal). When not set, behaviour is unchanged.|
|encryptionMethod|enum|AES|NONE, ZIP_STANDARD (ZipCrypto, legacy), AES. Only
used when password is set.|
|aesKeyStrength|enum|256|128 or 256 (marshal only; AES-192 can additionally be
read).|
Optionally allow overriding the password per exchange through a header (e.g.
CamelZipFilePassword), so it can be supplied from a secret/vault at runtime.
h3. Implementation suggestion
* Use Zip4j (net.lingala.zip4j:zip4j, Apache License 2.0), which supports
AES-128/256 and standard ZIP encryption, and has a stream API (ZipOutputStream
/ ZipInputStream) since 2.x.
* Use Zip4j only when a password is configured; the existing commons-compress
code path stays untouched, so existing users see no change in behaviour or
performance.
* Keep support for usingIterator (streaming split of multi-entry archives) and
maxDecompressedSize when decrypting.
* Alternatively, if the project prefers not to add a dependency to
camel-zipfile, provide this as a separate data format/component.
* Implementing WinZip AE-1/AE-2 directly on top of commons-compress was
considered, but means maintaining security-sensitive crypto code in Camel, so
it is not recommended.
h3. Notes
* ZipCrypto has known weaknesses and should be documented as legacy; AES
should be the default.
* Interoperability: AES-encrypted ZIPs are readable by 7-Zip and WinZip, but
not by Info-Zip unzip 6.0. Document this in the component docs.
* Wrong password and corrupt data should produce a clear exception (not silent
empty output); see the related error-handling fixes CAMEL-14748 and CAMEL-16410.
* Passwords must not be logged and should work with RAW() / property
placeholders.
h3. Acceptance criteria
* marshal().zipFile() with password produces an AES-256 encrypted ZIP that
opens in 7-Zip with that password.
* unmarshal().zipFile() with password reads AES and ZipCrypto encrypted
archives, including with usingIterator=true.
* Wrong password results in a clear exception.
* Without a password, behaviour is identical to today.
* Docs (data format page, Spring Boot starter properties, YAML/XML DSL
examples) updated.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
