Bug 227868 - www/apache24: 2.4.33 won't start anymore with LibreSSL
Summary: www/apache24: 2.4.33 won't start anymore with LibreSSL
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Bernard Spil
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-30 11:45 UTC by Jens K. Loewe
Modified: 2018-05-03 06:55 UTC (History)
8 users (show)

See Also:


Attachments
This fixes it for me (484 bytes, patch)
2018-05-02 13:08 UTC, Frank
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jens K. Loewe 2018-04-30 11:45:22 UTC
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.
Comment 1 M. Macha 2018-04-30 13:07:52 UTC
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"
Comment 2 mark.j.lysek 2018-04-30 16:12:15 UTC
(In reply to Jens K. Loewe from comment #0)
I also see the same problem.
Comment 3 Bernard Spil freebsd_committer 2018-04-30 18:02:38 UTC
(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.
Comment 4 Bernard Spil freebsd_committer 2018-04-30 18:13:46 UTC
Not an Apache bug, reassigning to me (libressl port maintainer)
Comment 5 M. Macha 2018-05-01 16:24:27 UTC
(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
Comment 6 Bernard Spil freebsd_committer 2018-05-01 17:25:31 UTC
(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.
Comment 7 M. Macha 2018-05-01 17:44:09 UTC
(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
Comment 8 B.J.Scharp 2018-05-01 19:32:09 UTC
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.
Comment 9 B.J.Scharp 2018-05-01 19:34:21 UTC
Another note: This problem obviously only exists if you have mod_ssl enabled. A blank config of Apache without ssl enabled will start fine.
Comment 10 M. Macha 2018-05-02 06:21:56 UTC
(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
Comment 11 Frank 2018-05-02 13:08:00 UTC
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.
Comment 12 Bernard Spil freebsd_committer 2018-05-02 18:22:26 UTC
OK, on it now. The patch I upstreamed for head was not fully backported in our port. Commit coming up after QA builds
Comment 13 commit-hook freebsd_committer 2018-05-02 19:03:38 UTC
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
Comment 14 Bernard Spil freebsd_committer 2018-05-02 19:08:53 UTC
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.
Comment 15 B.J.Scharp 2018-05-03 06:55:09 UTC
@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.