Re: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files

2020-08-28 Thread Hai-May Chao
JarSigner.java #953: The output debug message can be removed from the code. JavaUtilZipFileAccess.java #44: Change posixPerms to extraAttrs. ZipFile.java #661: Suggest to keep the comment and update it with the additional 4 bits for symlink. The rest of code changes and CSR look good. Thanks,

Re: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files

2020-08-28 Thread Weijun Wang
Everything looks fine to me. I’ve added myself as the CSR reviewer. In the Solution section, it probably should me “The existing warning introduced in JDK-8218021 is expanded to include symlink”. It is not a new warning. Thanks, Max > On Aug 28, 2020, at 12:05 PM, Seán Coffey wrote: > > >

Re: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files

2020-08-28 Thread Seán Coffey
On 28/08/2020 16:18, Weijun Wang wrote: 1. Add a comment on how to generate ZIPBYTES in the test. Not the byte[] declaration but how the original ZIP file is generated. I'll add a comment block to the test:     /* * Created using the createByteArray utility method. * The zipfile

Re: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files

2020-08-28 Thread Weijun Wang
1. Add a comment on how to generate ZIPBYTES in the test. Not the byte[] declaration but how the original ZIP file is generated. 2. Does this require a CSR? The POSIX permission one had one. Thanks, Max > On Aug 28, 2020, at 10:17 AM, Seán Coffey wrote: > > I've been poking around the zip

Re: RFR: 8250968: Symlinks attributes not preserved when using jarsigner on zip files

2020-08-28 Thread Seán Coffey
I've been poking around the zip internals and am now able to locate the 16 bits of interest. The position of these actual bits does appear to move around from one test run to another. For now, I guess it's sufficient to look for the pattern of interest in the signed zip file. New testcase

Re: RFC8410 (in)compatibility

2020-08-28 Thread Anders Rundgren
On 2020-08-28 15:58, Weijun Wang wrote: Is “Ed25519” what you need? It’s not available in JDK 11. See https://bugs.openjdk.java.net/browse/JDK-8199231. I know, that's why I wrote that I currently use BC (BouncyCastle). My question is thus applicable to JDK 15. BC apparently rejects X25519

Re: RFC8410 (in)compatibility

2020-08-28 Thread Weijun Wang
Is “Ed25519” what you need? It’s not available in JDK 11. See https://bugs.openjdk.java.net/browse/JDK-8199231. —Max > On Aug 28, 2020, at 9:55 AM, Anders Rundgren > wrote: > > On 2020-08-28 15:41, Weijun Wang wrote: >> What version of java are you using and what’s your command to generate

Re: RFC8410 (in)compatibility

2020-08-28 Thread Anders Rundgren
On 2020-08-28 15:41, Weijun Wang wrote: What version of java are you using and what’s your command to generate the key pair? Hi Max, While waiting for JDK 15, I'm currently using JDK11 and BC but the question is really about the Signature object specification. KeyPairGenerator kpg =

Re: RFC8410 (in)compatibility

2020-08-28 Thread Weijun Wang
What version of java are you using and what’s your command to generate the key pair? Thanks, Max > On Aug 28, 2020, at 7:03 AM, Anders Rundgren > wrote: > > Hi Crypto Experts, > > Please pardon my ignorance regarding curve25519, but I ran into problems [*] > trying to recreate the sample

RFC8410 (in)compatibility

2020-08-28 Thread Anders Rundgren
Hi Crypto Experts, Please pardon my ignorance regarding curve25519, but I ran into problems [*] trying to recreate the sample certificate: https://tools.ietf.org/html/rfc8410#section-10.2 It seems that the certificate is signed with a key intended for ECDH. Question: is Java's "Signature"