Hi Uwe, To enable Conscrypt we have include several related Jetty libraries, the same thing will need to be done if we uses Java 9 ALPN. So support both security providers and testing them is kinda painful in my point of view.
On Wed, Nov 28, 2018 at 4:16 PM Đạt Cao Mạnh <caomanhdat...@gmail.com> wrote: > 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 <u...@thetaphi.de> 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: u...@thetaphi.de >> >> >> >> *From:* Uwe Schindler <u...@thetaphi.de> >> *Sent:* Wednesday, November 28, 2018 11:38 AM >> *To:* dev@lucene.apache.org >> *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: u...@thetaphi.de >> >> >> >> *From:* Đạt Cao Mạnh <caomanhdat...@gmail.com> >> *Sent:* Wednesday, November 28, 2018 11:01 AM >> *To:* Solr/Lucene Dev <dev@lucene.apache.org> >> *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 <apa...@elyograg.org> 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: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> >> >> -- >> >> *Best regards,* >> >> *Cao Mạnh Đạt* >> >> >> >> *D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com >> <caomanhdat...@gmail.com>* >> > > > -- > *Best regards,* > *Cao Mạnh Đạt* > > > *D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com > <caomanhdat...@gmail.com>* > -- *Best regards,* *Cao Mạnh Đạt* *D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com <caomanhdat...@gmail.com>*
