Modsecurity: Compiling from tarballs and conda-forge

[GustavoKatel]

TL;DR; Does compiling from tarballs have to require git?

Hi, I have been working in the python bindings of modsecurity (https://github.com/actions-security/pymodsecurity) for a couple of months now and I managed to get the lib to build inside conda-forge (https://github.com/conda-forge/modsecurity-feedstock). One can now install the lib in a conda environment using: conda install modsecurity and link with the bindings without needing to compile everything. I have been using it with no problems so far, despite minor compilation issue.

I am using the released tarballs to compile and got some git errors during setup. I managed to bypass with a patch over configure.ac (https://github.com/conda-forge/modsecurity-feedstock/blob/master/recipe/configure.ac.patch). I was wondering if this the best approach? I believe this is related to #1630

[victorhora]

Hey @GustavoKatel

Thanks a lot for your work on the bindings. We really appreciate it :)

As for:

Does compiling from tarballs have to require git?

In a sense it does due to configure.ac#L6 and configure.ac#L70, but that's it afaik.

Some of these buildscript errors on the buildscript might be related with the version of autoconf/automake.

Can you maybe share the errors logs you're getting?

[GustavoKatel]

Hi @victorhora

Here's the output if I build without the patch. https://pastebin.com/a8hGHChj

I got several messages like fatal: not a git repository (or any of the parent directories): .git

And no version definition in the logs

Got ModSecurity - for Linux

Expected: ModSecurity - v3.0.2 for Linux

I believe this happens because the tarballs are not a git repo per si (i.e. does not contain git information). So calling git commands in there are going to fail in fact.

[victorhora]

Hummm that makes sense indeed. Well your patch fixes the issue, but then it seems like the versions are all hardcoded :(

Maybe we could check with @zimmerle on moving those checks to the script that actually builds the release on the developers environment and changing configure.ac to not rely on a local Git repo but rather purely on the MAJOR / MINOR definitions.

But thinking again, maybe we could change those Git commands to not perform these checks locally but rather purely on a remote / upstream?

[zimmerle]

The idea is that the _./build.sh_ script is meant to run inside a git repository. In a development environment. As of the .tar.gz, we don't really expect development, but rather a user trying to compile the package, therefore it is safe to go straight to the _./configure_ script.

That is the main reason why the _./build.sh_ uses the git parameters while the rest won't.

You may want disable the _build.sh_ execution here:
https://github.com/conda-forge/modsecurity-feedstock/blob/dc46a86589f93db30c3536cc762a985649bb7877/recipe/build.sh#L3

Also, it worth to add a note on our build.sh, if the git repo is not found, it should print a useful and meaningful error message.

[GustavoKatel]

Oh nice! The build process did run successfully skipping the _build.sh_. I think I did miss that somewhere in the docs. I will update the package and remove the patch. Thanks @zimmerle @victorhora :)

[victorhora]

Also, it worth to add a note on our build.sh, if the git repo is not found, it should print a useful and meaningful error message.

Cool. Let's push a small change to that script prior to 3.0.3 release :)