Build on macOS with Apple silicon (arm64)

[eduar-hte]

what

Support building libModSecurity on macOS with Apple silicon (arm64)

why

Apple has been moving the macOS platform to Apple silicon (arm64) over the last few years (as of June 2023, the entire Mac lineup uses Apple silicon chips).

This PR fixes build configuration issues in pcre & yajl that prevented the library from compiling on newer versions of macOS (which probably apply to the x86_64 version of the OS too).

Additionally, it updates the GitHub quality assurance workflow to run now on macOS 14, which is an Apple silicon (arm64) runner image (see here).

[eduar-hte]

This PR fixes build configuration issues in pcre & yajl that prevented the library from compiling on newer versions of macOS (which probably apply to the x86_64 version of the OS too).

The configure step of the build on macOS 14 with Apple silicon would trigger the following error:

checking for libpcre config script... no
configure: error: pcre library is required
configure: *** pcre library not found.

Having address the pcre issue, the build would still fail with the following error:

Error: transaction.cc:19:10: fatal error: 'yajl/yajl_tree.h' file not found
#include <yajl/yajl_tree.h>
         ^~~~~~~~~~~~~~~~~~
1 error generated.
make[3]: *** [libmodsecurity_la-transaction.lo] Error 1

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[eduar-hte]

Additionally, it updates the GitHub quality assurance workflow to run now on macOS 14, which is an Apple silicon (arm64) runner image (see here).

I replaced the macos-12 (x86_64) runner with the macos-14 (arm64) instead of just adding it in order not to multiply the number of configurations to build in the workflow.

NOTE: This doesn't imply dropping support for x86_64 on macOS though, but rather have visibility on the more representative architecture on the platform now.

[airween]

LGTM

[airween]

Thanks again @eduar-hte.

[eduar-hte]

airween@, I'm seeing builds today failing on the new macos-14 runner image.

I found about it while working on another PR and experiencing failures on the mac builds, which I initially thought were related to those changes, but it seems they were unrelated.

It's always the same regression tests:

(   2/  2/   4): test/test-cases/regression/config-secremoterules.json

but the configuration changes (for example macOS (wo ssdeep) or macOS (wo libxml)). However, the same configuration then builds on a follow up build, so it doesn't appear to be specific to one of them.

For example:

but then:

I think I saw you experience this yourself working on the CHANGES PR today, right? (this build) shows the same issue, but a follow up build run successfully.

[eduar-hte]

It's always the same regression tests:

(   2/  2/   4): test/test-cases/regression/config-secremoterules.json

The strangest thing is that if I'm not reading things wrong, the test file only has three tests, and when the builds fail, they show that four were executed.

If you take a look at the CHANGES PR build that failed that I mentioned before, the macOS (wo ssdeep) configuration triggers the error and shows the listing above.

However, in the same build (and I would expect regression test .json file because all are built using the same repository commit) the macOS (wo libxml) configuration, which ran the tests successfully, shows:

(   3/  0/   3): test/test-cases/regression/config-secremoterules.json

[airween]

Hi @eduar-hte,

yes, this is a very weird behavior and I'm not sure I understand what I see.

It's weird because when you sent the PR, all checks passed successfully. When I merge the PR, tests run again. In this case, the tests on macOS were failed. Then I re-run them again by hand, and all of them finished successfully.

And yes, there is a pending PR where I collect merged PR's for CHANGES, and after each commit the macOS tests were failed too.

It is very annoying that the failed tests are not consistent: every time a different test fails.

@theseion, @fzipi do you have any ideas what happens here?

[airween]

It's always the same regression tests:

(   2/  2/   4): test/test-cases/regression/config-secremoterules.json

yes, I noticed that.

The strangest thing is that if I'm not reading things wrong, the test file only has three tests, and when the builds fail, they show that four were executed.

yes, you're right.

If you take a look at the CHANGES PR build that failed that I mentioned before, the macOS (wo ssdeep) configuration triggers the error and shows the listing above.

Maybe, I didn't noticed that. But now I looked up few other jobs and found this one:

Here you can see that the macOS (wo geoip) was the success test, and macOS (with pcre2) was the first failed build.

This was a job after merging your PR.

However, in the same build (and I would expect regression test .json file because all are built using the same repository commit) the macOS (wo libxml) configuration, which ran the tests successfully, shows:

(   3/  0/   3): test/test-cases/regression/config-secremoterules.json

Look at this

(   0/  0/   3): test/test-cases/regression/config-secremoterules.json

I think we definitely need to investigate this.

Do you have any macOS-14 environment?

[eduar-hte]

If you take a look at the CHANGES PR build that failed that I mentioned before, the macOS (wo ssdeep) configuration triggers the error and shows the listing above.

Maybe, I didn't noticed that. But now I looked up few other jobs and found this one:
(...)

Yes, my point was that it's clearly related to macOS 14, but not the PR that I was currently working on (which I ended up spending a couple of hours trying to think how my changes could have broken those regression tests).

I think we definitely need to investigate this.

This is strange and started happening just today so I think it's related to a change in environment.

I went back to see all the actions executed in my fork for the macos-apple-silicon branch, and I noticed that all of them that run successfully (other than the in development changes in the branch, of course) were running macOS 14.5 (see here from 4 days ago) and 14..4.1 (see here from 3 months ago (!) when I worked on this).

And as far as I can see, all of the builds that fail are running on macOS 14.6, a GitHub runner image which was released yesterday and is currently being deployed, see here.

Do you have any macOS-14 environment?

Yes, I have a macOS mini that is running macOS 14.5, and all the tests run successfully there after cloning the repository and building v3/master.

I'll try to see if I can update it to macOS 14.6 and see if I can reproduce it there.

[eduar-hte]

And as far as I can see, all of the builds that fail are running on macOS 14.6, a GitHub runner image which was released yesterday and is currently being deployed, see here.

The CHANGES PR build that failed (see here) ran on this new runner image (macOS 14.6):

Current runner version: '2.317.0'
Operating System
  macOS
  14.6
  23G80
Runner Image
  Image: macos-14-arm64
  Version: 20240805.3

while the one that run successfully two hours later (see here) ran on the older one (macOS 14.5):

Current runner version: '2.317.0'
Operating System
  macOS
  14.5
  23F79
Runner Image
  Image: macos-14-arm64
  Version: 20240728.1

[eduar-hte]

I'll try to see if I can update it to macOS 14.6 and see if I can reproduce it there.

I've updated my mac mini and found that the test Include remote rules - failed download (Abort) fails:

Test name: Include remote rules - failed download (Abort).
Reason: 
failed!
Expected a parser error.
Expected: Failed to download: HTTP response code said error
Produced: Rules error. File: https://gist.githubusercontent.com/zimmerle/a4c1ec028999f7df71d0cc80f4f271ca/raw/4c74363bf4eae974180f1a82007196e58729dd16/modsecurity-regression-test-secremoterules-bonga.txt. Line: 1. Column: 0. 
 - Failed to download: Failure when receiving data from the peer

The test configuration depends on a specific error message from curl/OS (HTTP response code said error), which seems to have changed (Failure when receiving data from the peer).

I'll create a new quick PR to simplify the test configuration and look just for Failed to download, which is the prefix added by the libModSecurity parser when logging the parser error.

PS: Someone should take a look at why custom-test-driver & test-suite.sh mix up their total tests count (probably when a test fail).

[eduar-hte]

I'll create a new quick PR to simplify the test configuration and look just for Failed to download, which is the prefix added by the libModSecurity parser when logging the parser error.

A build with this change running on macOS 16 shows that this change solves the issue, see here.

I had to trigger the build a couple of times because the first two ones were assigned a macOS 14.5 runner image, which would not have proven that the change addressed the issue.