Re: JNLP launched legacy app needs to override jdk.tls.disabledAlgorithms

Thanks. It's not what I wanted to hear, but is what I expected. It looks like java reflection might be the only solution for us in the short-term. I will dig into the code to see if I can figure out what's needed. Re: "stand alone installer" -- The support timeline for our legacy app is

Re: RFR 8201815: Use Mozilla Public Suffix List

> On May 23, 2018, at 4:21 AM, Magnus Ihse Bursie > wrote: > > ... but you should switch order on the chmod and the mv in the new gensrc > file, so the mv comes last. I thought it's safer to call CHMOD last so MV won't change file mode back. (I'm not saying

Re: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations

A couple updates: * Touched up the comments surrounding init/wrap/unwrap methods. None of these affect public javadocs. * Added an implementation for engineGetParameters.  This was something that just got forgotten from the initial development of the cipher when there were no

Re: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11 provider

Hi Valerie, Webrev 03 with changes to TestTLS12.java is here: * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.03 * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.03.zip The reason why we need a dependency to sun.security.pkcs11.SunPKCS11 is to instance

Re: RFR 8201815: Use Mozilla Public Suffix List

.. but you should switch order on the chmod and the mv in the new gensrc file, so the mv comes last. /Magnus > 22 maj 2018 kl. 17:44 skrev Erik Joelsson : > > Build changes look ok. > > /Erik > > >> On 2018-05-22 08:25, Weijun Wang wrote: >> Please take a review

Re: JNLP launched legacy app needs to override jdk.tls.disabledAlgorithms

You probably don’t want to hear that, but now is a good time to convert this JNLP App into a stand alone Installer (possibly with updater).that will not only allow you to ship a pre-configured and matching JRE, but it will also solve the problem that you do not get javaws updates starting on

Re: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations

Wow, good catch.  This is something that got left by the wayside, probably from one of the earliest revisions of the code when we didn't have an AlgorithmParameters implementation.  I'll get this fixed up today.  Shouldn't take too long to get this working.  I think it should return null if it

Re: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations

Question on engineGetParameters() in ChaCha20Cipher.java: 231 protected AlgorithmParameters engineGetParameters() { 232 return null; 233 } Shouldn't this return the params that are passed into engineInit()? Also, when null is passed in and the params are generated using

Re: RFR 8201815: Use Mozilla Public Suffix List

Build changes look ok. /Erik On 2018-05-22 08:25, Weijun Wang wrote: Please take a review at http://cr.openjdk.java.net/~weijun/8201815/webrev.00/ With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL

RFR 8201815: Use Mozilla Public Suffix List

Please take a review at http://cr.openjdk.java.net/~weijun/8201815/webrev.00/ With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL data was re-encoded as a zip file with entries for different TLDs. There

Re: JNLP launched legacy app needs to override jdk.tls.disabledAlgorithms

Clarification. When I said for option (1) "none had the desired effect", I mean at the start of main I confirmed with System.getProperty that the java.security.properties property isn't getting set thru the JNLP launch, so I doubt "==" will make any difference compared to "=". As far as