While I can perfectly compile Apache with SSL enabled, trying to start it results in a nasty error: > Cannot load libexec/apache24/mod_ssl.so into server: /usr/local/libexec/apache24/mod_ssl.so: Undefined symbonl "OPENSSL_malloc_init" Seems like LibreSSL broke it again.
Hi, same here. Had to reinstall libressl 2.6.4 by pkg and recompile every port which is related to libressl with "make clan && make deinstall && make && make install"
(In reply to Jens K. Loewe from comment #0) I also see the same problem.
(In reply to Jens K. Loewe from comment #0) (In reply to M. Macha from comment #1) (In reply to mark.j.lysek from comment #2) Hi all, Can you please let me know how you updated (poudriere/portmaster/portupdate/"make") and what order you used when updating? Did you read UPDATING before building? I currently believe that using portmaster/portupgrade _only_ works when 1. Update ports tree (and thus LibreSSL to 2.7) 2. Run `portmaster -r libressl` 3. Run `portmaster -a` Any other method will lead to non-functional environment. I'm sorry for the issues this causes. It's undoable to bump all portrevisions (about half the ports tree). I've yet to receive reports of issues when using poudriere, you are **strongly** recommended to stop using portmaster/portupgrade which are basically unsupported.
Not an Apache bug, reassigning to me (libressl port maintainer)
(In reply to Bernard Spil from comment #3) Hi Bernard, thnaks for your reply, I did the following to update to libressl 2.7.2 # cd /usr/ports # portsnap fetch && portsnaup update && pkg version |grep "<" # portmaster -Bd -r libressl # portmaster -aBd # service apache24 restart This was leading to a broken environment. I truly have read the UPDATING File before updating. Kind regards, Matthias
(In reply to M. Macha from comment #5) Hi Michael, Thanks for the response. It is all too common for people to not read it, yet that does not exclude the possibility that people do! So far, there is no evidence that these issues arise for users of poudriere. Did the `portmaster -Bd -r libressl` or `portmaster -aBd` actually rebuild/reinstall/package www/apache24? I myself stumbled over not doing the portmaster -r before everything else on an old box I maintain. Luckily, I build&package everything in a build jail there so I can fix the issue before I break my system with `pkg update`. Cheers, Bernard.
(In reply to Bernard Spil from comment #6) Hi Bernard, yes www/apache24 has been rebuild by executing portmaster -Bd -r libressl". In addition I did a addition build which succeeded, even if I don't know if there was an compile warning the build seems to work fine. To revert to libressl 2.6.4 I had to create symlinks for libcrypto and libssl. Greetings, Matthias
I have the same problem. FreeBSD version is 11.1-RELEASE-p9 LibreSSL version is libressl-2.7.2_1 Apache version is apache24-2.4.33 Everything is build from ports. When the problem first occurred after updating, I uninstalled EVERY port on the system, and rebuild them from scratch. Problem still persists. No build errors in either case, but Apache doesn't start, showing the "Undefined symbol "OPENSSL_malloc_init"" error. I tried downgrading libressl using ports-mgmt/portdowngrade, but when I try to rebuild Apache after that, it tries to install libressl 2.7 again, and fails if I use the -x flag on portmaster. So right now I'm in a bit of a bind, as I have no webserver, and the only option I can think of is going back to OpenSSL. If anyone has a workaround other than that (or disabling SSL), I'd be happy to hear it.
Another note: This problem obviously only exists if you have mod_ssl enabled. A blank config of Apache without ssl enabled will start fine.
(In reply to B.J.Scharp from comment #8) Hi, just to the following. Install libressl 2.6.4 via pkg or ports-mgmt/portdowngrade and create the following symlinks: /usr/local/lib/libcrypto.so.42 /usr/local/lib/libcrypto.so.43 /usr/local/lib/libssl.so.44 /usr/local/lib/libssl.so.45 Than rebuild apache24 and apr1 that should temporary fix it for you. Please keep in mind to unlink libcrypto.so.43 and libssl.so.45 before you try to update to libressl 2.7.2. Kind regards, Matthias
Created attachment 192994 [details] This fixes it for me I had exactly the same problem (using portmaster). Since I found no solution using Google I dug through the Apache code, found the reference to OPENSSL_malloc_init and saw, that it's special 1.1 API code. I looked through LibreSSLs code and could not find OPENSSL_malloc_init at all, but found the "old" CRYPTO_malloc_init. No clue what went wrong here. I removed the conditional code from apaches source (see attached patch), compiled it and now apache starts and serves over HTTPS just fine.
OK, on it now. The patch I upstreamed for head was not fully backported in our port. Commit coming up after QA builds
A commit references this bug: Author: brnrd Date: Wed May 2 19:03:19 UTC 2018 New revision: 468867 URL: https://svnweb.freebsd.org/changeset/ports/468867 Log: www/apache24: Fix runtime failure with LibreSSL 2.7 - Fix LOG_FORENSIC in plist while here PR: 227868 Reported by: Jens K. Loewe <mozilla tuxproject de> Approved by: hat (apache@) Changes: head/www/apache24/Makefile head/www/apache24/files/patch-modules_ssl_mod__ssl.c head/www/apache24/files/patch-modules_ssl_ssl__engine__init.c head/www/apache24/pkg-plist
Hi All, My apologies for the delay in fixing this. I was focussing on the use of portmaster builds and hadn't verified the reported error. Ultimately boils down to me not backporting the LibreSSL 2.7 fixes I upstreamed to Apache, which are already integrated into 2.5/trunk branch. I'll make sure I get te backported fixes in upstream too. Thanks for your patience! Bernard.
@Matthias: Thanks. I'd found the crypto one, that solved the build problem. The ssl one isn't needed for build, but I've added it for good measure. Honest question: why does Apache (and most other ports) reference the libcrypto.so.4X file (which is in itself a symlink, not the 'real' file), and not the libcrypto.so symlink? (the one without any version references) That would solve these build issues once and for all.