Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v2]
On Sat, 16 Jan 2021 00:48:43 GMT, Naoto Sato wrote:
>> Actually I was correcting the L217, changed {) -> {}. But 2 days ago,
>> Jonathan Gibbons fixed it in another commit 6bb6093. I found his fix after
>> running the merge. Looks both of us forgot to update the copyright year. Any
>> suggestion?
>> doclet.help.systemProperties.body=\
>> The {0} page lists references to system properties.
>
> I believe your PR still contains the fix to add the newline at the end of the
> file (at L518). So I think you can simply change the copyright year in
> `standard.properties` file.
Thx! Fixed the copyright year for this file.
-
PR: https://git.openjdk.java.net/jdk16/pull/123
Re: [jdk16] RFR: JDK-8259732: JDK 16 L10n resource file update - msg drop 10 [v3]
> This is the changes for JDK 16 msg drop 10. Leo Jiang has updated the pull request incrementally with one additional commit since the last revision: fix the missing copyright year for standard.properties - Changes: - all: https://git.openjdk.java.net/jdk16/pull/123/files - new: https://git.openjdk.java.net/jdk16/pull/123/files/d72f444a..9c7574e2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16=123=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk16=123=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/123.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/123/head:pull/123 PR: https://git.openjdk.java.net/jdk16/pull/123
Integrated: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1
On Tue, 15 Dec 2020 20:29:08 GMT, Valerie Peng wrote: > Can someone help review this? > > This change enhances RSA KeyFactory impl of SunRsaSign and SunPKCS11 > providers to accept RSA keys in PKCS#1 format and encoding and translate them > to provider-specific RSA keys. Updated the relevant tests with a sample > PKCS#1 encoded key pair. > > Thanks, > Valerie This pull request has now been integrated. Changeset: 68cf65d2 Author:Valerie Peng URL: https://git.openjdk.java.net/jdk/commit/68cf65d2 Stats: 462 lines in 6 files changed: 303 ins; 55 del; 104 mod 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 Reviewed-by: weijun - PR: https://git.openjdk.java.net/jdk/pull/1787
Re: RFR: 8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1 [v3]
On Fri, 15 Jan 2021 01:45:07 GMT, Valerie Peng wrote: >> Marked as reviewed by weijun (Reviewer). > >> >> >> _Mailing list message from [Michael StJohns](mailto:mstjo...@comcast.net) on >> [security-dev](mailto:security-dev@openjdk.java.net):_ >> >> Sorry - I'm coming to this a bit late. >> >> Any chance of adding the logic for generatePublic() from a PKCS8 RSA >> private key??? RFC3477 has the PKCS1 RSAPrivateKey ASN1 which includes >> the modulus and publicExponent - so it should be a pretty straight >> forward add to generate a public key. >> >> PKCS11 2.40 started requiring that the publicExponent be stored with the >> private key to allow for the public key to be regenerated from a private >> key object.?? Going forward,? it might be a good idea to modify the >> RSAPrivate(Crt)KeyImpl class to store the publicExponent if provided. >> >> Mike > > You are correct that for RSA private CRT keys the necessary values are there > for figuring out its corresponding public keys. > > This change is about adding support for PKCS#1 encoded RSA keys and be able > to translate them into PKCS#8 encoded keys and/or extract various key specs > out of them. If you already have PKCS#8 RSAPrivateCrtKey obj from SunRsaSign > provider, you can call its getPublicExponent() method and use that to create > a RSAPublicKeySpec and generate RSA public key with it. If you are using 3rd > party impl which does not return the public exponent value somehow, then you > can translate it using the RSA key factory impl from SunRsaSign provider and > then repeat the fore-mentioned step. Will this address your need? If not, > could you elaborate the usage that you have in mind? Not sure if you are > suggesting a new KeyFactory.generatePublic() method which take a PrivateKey > or else. Mike, We can continue your feedback with a separate RFE since this RFE is just about adding support for PKCS#1 encoding. I need to wrap this up before my upcoming trip this Wed, hope that's ok with you. Thanks! Valerie - PR: https://git.openjdk.java.net/jdk/pull/1787
Java and the NTFS Path weakness
Hello, you might have seen the media coverage on a Microsoft Windows 10 and Windows Server problem where a certain NTFS internal path causes the Windows driver to claim corruption and mark the filesystem dirty. (Some even reported actual corruption of their filesystems). The java.nio Path seems to be resistance against that, as it detects an illegal path itself: | Welcome to JShell -- Version 11.0.9.1 | For an introduction type: /help intro jshell> var bad = "C:\\:$i30:$bitmap"; bad ==> "C:\\:$i30:$bitmap" jshell> new File(bad).toPath() | Exception java.nio.file.InvalidPathException: Illegal char <:> at index 3: C:\:$i30:$bitmap |at WindowsPathParser.normalize (WindowsPathParser.java:182) |at WindowsPathParser.parse (WindowsPathParser.java:153) |at WindowsPathParser.parse (WindowsPathParser.java:77) |at WindowsPath.parse (WindowsPath.java:92) |at WindowsFileSystem.getPath (WindowsFileSystem.java:229) |at File.toPath (File.java:2292) |at (#6:1) jshell> Paths.get(bad) | Exception java.nio.file.InvalidPathException: Illegal char <:> at index 3: C:\:$i30:$bitmap |at WindowsPathParser.normalize (WindowsPathParser.java:182) |at WindowsPathParser.parse (WindowsPathParser.java:153) |at WindowsPathParser.parse (WindowsPathParser.java:77) |at WindowsPath.parse (WindowsPath.java:92) |at WindowsFileSystem.getPath (WindowsFileSystem.java:229) |at Path.of (Path.java:147) |at Paths.get (Paths.java:69) |at (#7:1) jshell> Path.of(bad) | Exception java.nio.file.InvalidPathException: Illegal char <:> at index 3: C:\:$i30:$bitmap |at WindowsPathParser.normalize (WindowsPathParser.java:182) |at WindowsPathParser.parse (WindowsPathParser.java:153) |at WindowsPathParser.parse (WindowsPathParser.java:77) |at WindowsPath.parse (WindowsPath.java:92) |at WindowsFileSystem.getPath (WindowsFileSystem.java:229) |at Path.of (Path.java:147) |at (#8:1) (not sure if there is a way to construct a path without that normalization). Unfortunally, however, the java.io.File and its IO functions to not provide this protection, when you call jshell> new File(bad).exists() $9 ==> false (or some other methods accessing the file) you will see the crash message in the event log. I am not sure if Java should or could filter that (however since java.nio already does it might be an option, not sure however if Microsoft would be faster and fixing that problem). But I thought I mention this here in case you have Java server applications which derive file names from untrusted user input (including uncompressing ZIP files). Gruss Bernd
