Hi all,
PING: Could you review new implementation for ZIP encryption?
http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.04/
http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.04/Test.java
Thanks,
Yasumasa
On 2016/02/10 23:36, Yasumasa Suenaga wrote:
I've uploaded
I've uploaded testcase here:
http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.04/Test.java
Yasumasa
On 2016/02/10 23:34, Yasumasa Suenaga wrote:
Hi Sherman,
I've refactored a patch for this enhancement:
http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.04/
1. I
Hi Sherman,
I've refactored a patch for this enhancement:
http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.04/
1. I changed ZipCryption and implementation class to package private.
2. Encryption / Decryption key is allowed passphrase string.
3. I added passphrase and validation
Hi Sherman and all,
Could you please let know your thought and the past case about AES?
Thanks,
Yuji
2016-01-08 0:01 GMT+09:00 KUBOTA Yuji :
> Hi Sherman,
>
> Thank you for sharing!
>
> 2016-01-07 4:04 GMT+09:00 Xueming Shen :
>> The reason that
Hi Sherman,
Thank you for sharing!
2016-01-07 4:04 GMT+09:00 Xueming Shen :
> The reason that I'm not convinced that we really need a public interface of
> ZipCryption here
> is I don't know how useful/helpful/likely it would be going forward that
> someone might really
Just to note that I once needed this and even commented on Stack Overflow
about it:
http://stackoverflow.com/questions/166340/write-a-password-protected-zip-file-in-java
I'd just note that setting the password on each entry is a bit painful, as
you'd normally expect to just set the password once.
Hi Sherman,
Thank you for your feedback!
At first, I'd like to confirm your thought about ZipCryption to
prevent misunderstand.
By following reasons, we should remove (or modified) ZipCryption to
not have any "encryption" related field/method in DeflaterOutputStream
/ InflaterInputStream.
1.
Hi Stephen,
Thank you for your note. After discussion about the design, we will
re-implement API. Please check it, and give feedback us when the time
comes :)
Thanks,
Yuji
2016-01-06 19:27 GMT+09:00 Stephen Colebourne :
> Just to note that I once needed this and even
On 1/6/16 5:25 AM, KUBOTA Yuji wrote:
Hi Sherman,
Thank you for your feedback!
At first, I'd like to confirm your thought about ZipCryption to
prevent misunderstand.
By following reasons, we should remove (or modified) ZipCryption to
not have any "encryption" related field/method in
Yuji,
I'm not convinced that the ZipCryption is a public interface we'd like to
expose,
at least for now, given the proprietary nature of the "strong encryption"
defined
by PKWARE.
As I said in my previous email, it might be desired to hide the
"passwd/encryption"
support for the
Hi Sherman,
2015-12-20 16:35 GMT+09:00 Xueming Shen :
> It is no longer necessary to touch the native code (zip_util.c/h) after the
> native ZipFile implementation has been moved up to the java level. Those
> native code are for vm access only now, which I dont think care
You Yasumasa,
It is no longer necessary to touch the native code (zip_util.c/h) after the
native ZipFile implementation has been moved up to the java level. Those
native code are for vm access only now, which I dont think care about the
password support at all.
But before getting into the
Hi Jason,
Thank you for your comment.
I've fixed it in new webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.03/
Thanks,
Yasumasa
On 2015/12/17 0:33, Jason Mehrens wrote:
The null check of 'entry' at line 351 of ZipFile.getInputStream is in conflict
with line 350 and 348.
(Not an OpenJDK reviewer)
Hi,
I was wondering if the CRC32 implementation in TraditionalZipCryption could
be replaced with java.util.zip.CRC32 class.
Though I note that in this case TraditionalZipCryption#updateKeys(int c)
will require CRC32#update(int crc, int b) method which is currently
Hi Anirvan,
j.u.z.CRC32 supports 8-bits value and byte array.
update(int, int) which you suggested will calculate lower 8-bits value:
http://docs.oracle.com/javase/8/docs/api/java/util/zip/CRC32.html#update-int
-
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,
Hi Sergey,
Thank you for your comment.
I added that description in new webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.02/
Thanks,
Yasumasa
On 2015/12/16 22:19, Sergey Bylokhov wrote:
Should the new methods describe how they will work in case of null params?
On 16/12/15
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
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
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
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 :
> Hi all,
>
> * Sorry for my mistake. I re-post this mail because I sent before get
> a response of subscription confirmation of
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
22 matches
Mail list logo