Hi folks, Uwe After upgrading to Conscrypt 1.4.1. I still failure on https://jenkins.thetaphi.de/job/Lucene-Solr-http2-Linux/7/consoleText. I kinda feel that this SSL is big pain but can be solved easily in Java 9. Should it is possible for us to not supporting SSL in HTTP2 (anyone want to run SSL can use any HTTP2 proxy like nginx as a gate keeper).
Thanks! On Wed, Nov 28, 2018 at 10:55 AM Uwe Schindler <[email protected]> wrote: > Hi, > > > > About the bundling of conscrypt.jar in the binary distribution of Apache > Solr, I opened LEGAL-425: > > https://issues.apache.org/jira/browse/LEGAL-425 > > > > Uwe > > > > ----- > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > http://www.thetaphi.de > > eMail: [email protected] > > > > *From:* Uwe Schindler <[email protected]> > *Sent:* Wednesday, November 28, 2018 11:38 AM > *To:* [email protected] > *Subject:* RE: Poll: Merge jira/http2 to master branch > > > > Hi Dat, hi Shawn, > > > > Thanks for the confirmation! This is what I had in mind (missing ALPN > support). > > > > IMHO, we should not yet switch away from Java 8 as minimum requirement. > With multi-release JARs we are at the moment perfectly able to handle users > with newer Java versions, but we should still support Java 8 (as its still > widely deployed), although EOL is close. As Redhat, AdoptOpenJDK, and > several Linux distributions still provide support for Java 8 at least for 2 > or 3 more years, I think it’s to early to switch. With recent changes, the > support by Oracle is no longer the way to go, as there are many > alternatives. > > > > My proposal would be to wait until master is branched to “branch_8x” > (stays on Java 8 + MR-JAR support), then change “master” to have Java 11 as > minimum requirement. > > > > About HTTP2: I have no problem with bundling conscrypt (is it needed for > both Jetty Server and Jetty Client)?, but disable it by default and only > register it in the Java TLS SPI, if Java 8 is used. On Java 9 and later use > the shipped HTTP2 support. My proposal would be to do it with a > Multirelease JAR (this is currently enabled in Lucene already). > > > > If there are license problems, we can do the following: Disable HTTP2 on > Java 8 completely but provide documentation in the Solr Ref Guide how to > enable it (something like: download conscrypt-uber.jar from maven and save > in solr/lib directory). We can enable it automatically, if class.forName() > does not throw CNFE). Maybe add a sysprop, but that’s not needed. I think > enabling conscrypt is easy with reflection only, or do we need to compile > hard against it. From what I figured out, it’s only used at a few places. > > > > SolrJ should by default ship without conscyrpt (make it “optional” maven > dependency). If it’s in classpath, enable it. > > > > Uwe > > > > ----- > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > http://www.thetaphi.de > > eMail: [email protected] > > > > *From:* Đạt Cao Mạnh <[email protected]> > *Sent:* Wednesday, November 28, 2018 11:01 AM > *To:* Solr/Lucene Dev <[email protected]> > *Subject:* Re: Poll: Merge jira/http2 to master branch > > > > Hi, > > > > I will try to summary all the options here > > 1. No support for HTTP/2 + SSL at all, if users want to run SSL they must > stick with HTTP/1.1 > > 2. Set Java requirement to 9 and use ALPN implementation of JDK 9 > > 3. If users want to use HTTP/2, we will notice about license problem then > download and use Conscrypt library. Of course that we still test the > Conscrypt implementation in tests. > > > > > > On Wed, Nov 28, 2018 at 1:06 AM Shawn Heisey <[email protected]> wrote: > > On 11/27/2018 3:32 AM, Uwe Schindler wrote: > > I'd like to bring one thing into attention: This library conscrypt is > ASF2-licensed, but the JAR files contain binary versions of an OpenSSL fork > named BoringSSL. I'd recommend to check the licensing, because OpenSSL > licenses are a bit strange (some BSD fork, also ASF2, but some code is > still outdated - I am not sure what the fork actually uses). I have the > feeling we should include ASF legal department. > > > > Nevertheless, I am not 100% sure if conscrypt should really be inclued > by default in SolrJ. As SolrJ is a client library for Solr and can be used > by external projects, there is the problem of incompatibilities with the > native C code included. E.g., if one uses SolrJ with IBM J9 or other Java > versions different from openjdk. So I'd be careful. My question is: Do we > really need that library. To me it looks like it improves speed only, or is > there something that requires its use? > > As you might know ... full and proper http/2 support with Java 8 > requires the conscrypt library. With Java 9 or higher, the > functionality is provided natively by Java. If I remember right, what > conscrypt provides that Java 8 lacks is ALPN. > > If there are license issues with conscrypt, perhaps it might make sense > to require a newer major version of Java instead ... but I think that > upgrading the project's Java requirement to 9, 10, or 11 probably > requires a wider discussion. Lucene probably has no burning need for it > right now. I have no idea whether there are language features in Java > 9+ that we as a group are wanting to use. Another point for > consideration is that the effective EOL for Java 8 is fast approaching, > and EOL dates have already come and gone for 9 and 10. > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > > > -- > > *Best regards,* > > *Cao Mạnh Đạt* > > > > *D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: [email protected] > <[email protected]>* > -- *Best regards,* *Cao Mạnh Đạt* *D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: [email protected] <[email protected]>*
