What is our preferred option for archive manifests? Because of the perversities of the java.util.zip API, it is easiest to unpack a whole file at once, and then cache on disk (encrypted). AFAICS ZipFile needs a plaintext file to operate on. Therefore I propose: - Use ZipInputStream, and unpack the whole file into an encrypted (and padded) cache directory when we first meet it. - Keep a cache of a user-controlled size of unpacked ZIP manifest files. IMHO a reasonable default would be 32MB. These files are individually LRU'd, are encrypted with ephemeral keys, and are padded. The cache is wiped on startup.
This means that tar.gz and tar.bz2 support would be rather easy, using the Jakarta Commons Compress API. That is, assuming that its license (ASL 2.0) is compatible with the GPL. http://jakarta.apache.org/commons/sandbox/compress/ -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20051021/ca25cdb2/attachment.pgp>
