Created attachment 32309 [details] Patch for apache24 to build cleanly with LibreSSL Apache 2.4 (and 2.2) can not be built when LibreSSL is used as SSL library. LibreSSL has (amongst others) - removed RAND_egd - removed CHIL engine - added SSL_CTX_use_certificate_chain this leads to build failures for missing and redefining functions. This patch fixes these errors by - adding a check for RAND_egd and SSL_CTX_use_certificate_chain - using an already available define for CHIL - using defines for the added checks Patch attached, this applies without issue to a cleanly extracted httpd-2.4.10 tree. This has also been submitted as a report at FreeBSD, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196139
Rewording the summary to more accurately capture the topic of this bug. I'm not really supportive of this idea, to be frank. mod_ssl is effectively mod_openssl these days. It used to have (and in 2.2.x still does) an ssl_toolkit_compat layer which allowed support for multiple toolkits, in theory, but as discussed in these two threads, the consensus in 2010/2011 was to deliberately drop support for non-OpenSSL toolkits: https://mail-archives.apache.org/mod_mbox/httpd-dev/201005.mbox/%3C20100525124551.GA11177%40redhat.com%3E https://mail-archives.apache.org/mod_mbox/httpd-dev/201107.mbox/%3C4E35065D.30104%40velox.ch%3E (see r1154683 and and r1154687) While the changes for supporting LibreSSL might seem small right now, it would definitely mean that mod_ssl maintenance becomes [again] more complex, assuming a scenario of LibreSSL deviating more substantially from OpenSSL in the future (consider http://www.openbsd.org/cgi-bin/man.cgi?query=tls_init&sektion=3 e.g.). Maintaining mod_ssl compatibility with all OpenSSL versions still floating around (0.9.7/0.9.8/1.0.0/1.0.1) is already quite burdensome, and I wouldn't want to make things more complicated by adding another toolkit to the mix (otherwise, next on the table would be BoringSSL, I guess). Let's draw a clear line right now, and not silently morph mod_[open]ssl into something like mod_{libre,boring,...}ssl.
*** Bug 57395 has been marked as a duplicate of this bug. ***
I can see why you don't want to support that many versions/libraries... However, recently (Okt and Dec 2014) the OpenSSL project has released both a new version of the Roadmap and a new Release Strategy https://www.openssl.org/about/roadmap.html https://www.openssl.org/about/releasestrat.html indicating that some bigger change is required that will impact API etc. The number of supported OpenSSL versions will be greatly reduced. Both 0.9.8 and 1.0.0 will be end-of-support by end of this year, and 1.0.1 is planned to be end-of-support 24 months from now. Without a doubt OpenBSD's (and if my patches are committed) FreeBSD's ports will make it possible to compile Apache with LibreSSL. Going forward the effort to make that work will increase and other TLS libraries will start emerging (ressl/libtls). Is a strategy with regards to other TLS libraries already formulated? And if so, where can we find it?
Comment on attachment 32309 [details] Patch for apache24 to build cleanly with LibreSSL Marking as obsolete - the SSL_CTX_use_certificate_chain changes are no longer necessary (see https://mail-archives.apache.org/mod_mbox/httpd-dev/201504.mbox/%3C20150415163613.GC15209%40fintan.stsp.name%3E). ENGINE_CTRL_CHIL_SET_FORKCHECK: committed with r1673455 RAND_egd: committed with r1674542 and r1675410
Also, ENGINE_CTRL_CHIL_SET_FORKCHECK change already backported to 2.4.x with r1673900.
Hi Kaspar, Happy that this is now fixed. Must say I'm pretty annoyed with the process. I do believe I've submitted a proper patch using the process as desired by the project (BugZilla). I basically get told off and that this would require a separate module since the difference between LibreSSL and OpenSSL is perceived to be to big. Then 4 months later people drop patches in via the Mailing-List (is that the proper way of supplying patches to Apache httpd?). There's no communication on this PR that there's things are changing until 4 patch-sets are being committed fixing all of the issues with LibreSSL. The patches committed are identical to the ones I committed yet there's no attribution, thanks or apologies on the process that was followed by the project. Perhaps things improve once I can mail from a @freebsd.org account? Hope to hear from you regarding the change of policy with regards to non-OpenSSL toolkits. With kindest though miffed regards and many thanks for a fine product, Bernard Spil.
Bugzilla isn't the right place for complaining, or discussing general questions about toolkit support. And don't Cc me unsolicitedly, please. I was not involved in launching the mid-April effort on LibreSSL compatibility (see https://mail-archives.apache.org/mod_mbox/httpd-dev/201504.mbox/%3C20150414135312.GA15703%40fintan.stsp.name%3E), so you're asking the wrong person. I merely updated the information in this bug to make sure that whoever looks at this issue sees relatively up-to-date information. My opinion re: adding LibreSSL to the list of supported mod_ssl toolkits (comment 1) hasn't changed, but then I'm not the only httpd dev who has a say on this, either.
> Then 4 months later people drop patches in via the Mailing-List (is that the > proper way of supplying patches to Apache httpd?). Either/both is appropriate. I don't think 'PatchAvailable' would have helped, but I personally stay more on top of email then the list of open bugs unless they stay active [which means they stay active in my mail client] > There's no communication > on this PR that there's things are changing until 4 patch-sets are being > committed fixing all of the issues with LibreSSL. For whatever reason, this PR didn't gather much attention, so there was no (immediate) followup here. > The patches committed are > identical to the ones I committed yet there's no attribution, thanks or > apologies on the process that was followed by the project. I will investigate to see if they were developed independently or if they were via your freebsd bugzilla patches and not properly attributed. > Perhaps things improve once I can mail from a @freebsd.org account? I don't think that is much of a factor. Stefan posted from his apache.org account where he earned his karma on a related project and is a member of the foundation looking to improve httpd. He also posted shortly after another community member asking about the same CHIL_engine issue fixed in the first patch. So for better or for worse, I think those things got his thread a little more attention. > Hope to hear from you regarding the change of policy with regards to > non-OpenSSL toolkits. There is no policy, just the opinion whoever has time to respond, work on, and maintain things. Sorry for your bad experience, but it is largely due to volunteer resources stretched thin.
Hi Eric, Kaspar, My apologies. Reacted from the gut. The patches are probably not even mine to begin with and may originate from OpenBSD ports or Gentoo-libressl... Thanks for a fine product!
Commits relative to RAND_egd (r1674542, r1675410, and r1676842, with updated credit), proposed for backport to 2.4.x (in r1676844). Thanks Bernard.
(In reply to Bernard Spil from comment #9) > Hi Eric, Kaspar, > > My apologies. Reacted from the gut. > > The patches are probably not even mine to begin with and may originate from > OpenBSD ports or Gentoo-libressl... > > Thanks for a fine product! No worries, and apologies for the patches languishing and the resulting confusion.
Backported to 2.4.13 with r1679199, released with 2.4.16.
Meanwhile this can be further simplified. LibreSSL 2.2.0 added an additional define so the autoconf kludge is no longer needed. The naming is in line with the OpenSSL naming of removed features #ifdef HAVE_RAND_EGD change to #ifndef OPENSSL_NO_EGD Remove autoconf test for RAND_egd