Should the new methods describe how they will work in case of null params?
On 16/12/15 16:04, Yasumasa Suenaga wrote:
I adapted this enhancement after JDK-8145260:
http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.01/
Could you review it?
Thanks,
Yasumasa
On 2015/12/12 21:23, Yasumasa Suenaga wrote:
Hi Sherman,
Our proposal is affected by JDK-8142508.
We have to change ZipFile.java and and ZipFile.c .
Thus we will create a new webrev for current (after 8142508) jdk9/dev
repos.
Do you have any comments about current webrev?
http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/
If you have comments, we will fix them in new webrev.
Thanks,
Yasumasa
On 2015/12/03 16:51, KUBOTA Yuji wrote:
Hi Sherman,
Thanks for your quick response :)
I aimed to implement the "traditional" at this proposal by the below
reasons.
* We want to prepare API for encrypted zip files at first.
* Many people use the "traditional" in problem-free scope like a
temporary file.
* We do not know which implementation of the "stronger" is best for
openjdk.
* PKWare claims that they have patents about the "stronger" on
Zip[1].
* OTOH, WinZip have the alternative implementation of the
"stronger" [2][3].
* Instead, we prepared the extensibility by ZipCryption interface to
implement other encrypt engine, such as the AES based.
Thus, I think this PoC should support the "traditional" only.
In the future, anyone who want to implement the "stronger" can easily
add their code by virtue of this proposal.
[1] https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT
(1.4 Permitted Use & 7.0 Strong Encryption Specification)
[2]
https://en.wikipedia.org/wiki/Zip_(file_format)#Strong_encryption_controversy
[3] http://www.winzip.com/aes_info.htm
Thanks,
Yuji
2015-12-03 12:29 GMT+09:00 Xueming Shen <xueming.s...@oracle.com>:
Hi Yuji,
I will take a look at your PoC. Might need some time and even bring
in the
security guy
to evaluate the proposal. It seems like you are only interested in the
"traditional PKWare
decryption", which is, based on the wiki, "known to be seriously
flawed, and
in particular
is vulnerable to known-plaintext attacks":-) Any request to support
"stronger" encryption
mechanism, such as the AES based?
Regards,
Sherman
On 12/2/15 6:48 PM, KUBOTA Yuji wrote:
Hi all,
We need reviewer(s) for this PoC.
Could you please review this proposal and PoC ?
Thanks,
Yuji
2015-11-26 13:22 GMT+09:00 KUBOTA Yuji <kubota.y...@gmail.com>:
Hi all,
* Sorry for my mistake. I re-post this mail because I sent before get
a response of subscription confirmation of core-libs-dev.
Our customers have to handle password-protected zip files. However,
Java SE does not provide the APIs to handle it yet, so we must use
third party library so far.
Recently, we found JDK-4347142: "Need method to set Password
protection to Zip entries", and we tried to implement it.
The current zlib in JDK is completely unaffected by this proposal.
The
traditional zip encryption encrypts a data after it is has been
compressed by zlib.[1] So we do NOT need to change existing zlib
implementation.
We've created PoC and uploaded it as webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/
Test code is as below. This code will let you know how this PoC
works.
http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/Test.java
In NTT, a Japanese telecommunications company. We are providing many
enterprise systems to customers. Some of them, we need to
implement to
handle password-protected zip file. I guess that this proposal is
desired for many developers and users.
I'm working together with Yasumasa Suenaga, jdk9 committer
(ysuenaga).
We want to implement it if this proposal accepted.
[1]: https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT
(6.0 Traditional PKWARE Encryption)
Thanks,
Yuji
--
Best regards, Sergey.
