On 22.04.2015 10:52, Stefan Eissing wrote: > I made two small patches based on the feedback from Kaspar. One for > the code and one for the documentation.
Thanks. In the patch for ssl_private.h, the complete NPN block should actually be dropped - the same block is are already part of ssl_private.h, just 10 lines above. > However there are a lot of openssl 1.0.1 installations out there > where httpd 2.4 is deployed which already talk NPN "a lot of... which already talk NPN"? I have a bit a hard time in following this argument: since mod_ssl in 2.4 doesn't have NPN, this suggests that these installations currently rely on custom patches in any case - so I wouldn't expect there to be "a lot of" (or I might be missing the real point). > and it might take some time for getting ALPN support from the > distros. Which would mean more people building and deploying their > own SSL libraries/patching mod_ssl and having no auto update, if they > want to use SPDY or HTTP/2. I don't find this reasoning very convincing... if we look at distributions with long term support (which is the sort of thing to consider for running a production HTTP server), then we see that they are now at 2.4.6 (RHEL), 2.4.7 (Ubuntu), 2.4.10 (SLES) or similar. And they usually stay with these versions for the whole OS release lifetime, only security fixes are backported (new features only in exceptional cases). I.e., it's highly unlikely that admins could rely on the vendor-supplied httpd package to get NPN in the next, say, 12 months. "auto update" typically means "security fixes only". OTOH, if a distributor is really going from 2.4.x to 2.4-latest this or next year, then I'd say that chances are quite high that he also upgrades to OpenSSL 1.0.2 at the same time (in particular given the increased pace for new OpenSSL releases and the faster EOL timelines, see https://www.openssl.org/about/releasestrat.html). For me the time seems right to rip NPN out of trunk and only backport the ALPN code to 2.4. Kaspar
