Re: [wildfly-dev] HTTP/2 out of the box in Wildfly 10.1

I think that would actually end up being more complex. Stuart On Mon, Jun 6, 2016 at 12:45 PM, Jason T. Greene <jason.greene(a)redhat.com&gt; wrote: > Another option could be a post boot task. So it's still eager but don't > block completed start. We'd still need to block Tls ports though. So maybe > this does not help > > On Jun 5, 2016, at 9:31 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com&gt; > wrote: > > 2048 bits adds close to a second to first boot on my machine (obviously > subsequent boots are unaffected). > > This is probably a bit much, I will work on getting a POC for the lazy > loading approach implemented. > > Stuart > > On Mon, Jun 6, 2016 at 12:27 PM, Jason T. Greene <jason.greene(a)redhat.com > > wrote: > >> We should really be generating 2048 bit keys. >> >> I don't like adding to our boot time, we have already seen it grow and >> this would be yet another case. >> >> On Jun 5, 2016, at 8:57 PM, Stuart Douglas <stuart.w.douglas(a)gmail.com&gt; >> wrote: >> >> So I just did up a very quick prototype that generates self signed >> certificates on startup and it looks like the difference in startup time is >> negligible (at least when generating 1024 bit RSA keys). Even if the >> difference is measurable it only affects the very first startup. >> >> I think that in order to simplify the implementation of this it may be >> better to simply generate the key of first startup, instead of attempting >> to do it lazily. >> >> Stuart >> >> On Sat, Jun 4, 2016 at 12:09 AM, Jason T. Greene < >> jason.greene(a)redhat.com&gt; wrote: >> >>> >>> What will be default keysize? It has to be probably choosen to work >>>> also without "Java Cryptography Extension (JCE) Unlimited Strength >>>> Jurisdiction Policy" >>>> >>> >>> Probably the largest that is supported without JCE. It does not matter >>> that much, self signed certs are inherently insecure, this is a developer >>> usability feature, not something that can be used in production. >>> >>> >>> IIRC there is actually no limit on RSA key size, it's only symmetric >>> algs that are limited, so we could use a standard 2048 bit key without >>> issue. >>> >>> >>> >>> Stuart >>> >>> >>>> >>>> >>>> >>>> On Thu, Jun 2, 2016 at 10:01 PM, Stuart Douglas < >>>> stuart.w.douglas(a)gmail.com&gt; wrote: >>>> >>>>> So I guess we should talk about how this should actually work. >>>>> >>>>> In terms of auto generating the key I was thinking we would need to >>>>> add a new attribute to the 'keystore' element under the security realm, >>>>> something like 'auto-generate-cert-host="localhost"'. I am not sure what >>>>> other options we would need, or how configurable we should make it, but as >>>>> this is for testing/development purposes I don't think we need to expose >>>>> full control over the certificate generation process. >>>>> >>>>> In terms of the implementation we could just implement an SSLContext >>>>> wrapper, that can do the generation and then create a 'real' SSLContext the >>>>> first time it is asked to create and SSLEngine. >>>>> >>>>> Stuart >>>>> >>>>> On Fri, Jun 3, 2016 at 3:19 AM, Jason Greene <jason.greene(a)redhat.com >>>>> > wrote: >>>>> >>>>>> >>>>>> > On Jun 2, 2016, at 11:29 AM, Harold Campbell <hcamp(a)muerte.net&gt; >>>>>> wrote: >>>>>> > >>>>>> > On Thu, 2016-06-02 at 09:22 +1000, Stuart Douglas wrote: >>>>>> >> Hi All, >>>>>> >> >>>>>> >> I would like to propose that we add support for HTTP/2 out of the >>>>>> box >>>>>> >> in Wildfly 10.1. >>>>>> >> >>>>>> > >>>>>> > This lowly user desperately wants a release containing the fix to >>>>>> WFLY- >>>>>> > 6283 sooner rather than later. I'm sure other people have other pet >>>>>> > bugs awaiting release. >>>>>> > >>>>>> > I have no opinion on HTTP/2 being added other than to ask that >>>>>> pent up >>>>>> > bug fixes be kept in mind. >>>>>> >>>>>> >>>>>> Hi Harold, >>>>>> >>>>>> That fix is already in master, so it will be included in 10.1. >>>>>> >>>>>> -- >>>>>> Jason T. Greene >>>>>> WildFly Lead / JBoss EAP Platform Architect >>>>>> JBoss, a division of Red Hat >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> wildfly-dev mailing list >>>>> wildfly-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>>> >>>> _______________________________________________ >>> wildfly-dev mailing list >>> wildfly-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>> >>> >> >