Release builds doesn't contain the libs or dlls

[ElevationsRPG]

I would really appreciate if LibModSecurity contained both 32-bit and 64-bit libs and dlls in release builds so that i can get straight to using the library with core owasp crs ruleset.

[airween]

Hi @ElevationsRPG,

I would really appreciate if LibModSecurity contained both 32-bit and 64-bit libs and dlls in release builds

That's not as simple. libmodsecurity3 is a library with several optional features, eg. you can choose which storage type you want to use for transaction's data (LMDB, in-memory), which regex engine you want to use (pcre2, old pcre), do you want to use XML or not, want to use JSON or not, etc...

With which features should we publish the compiled library/dll?

i can get straight to using the library with core owasp crs ruleset.

Sorry, I don't understand this. You can use libmodsecurity3 with Nginx through a connector, then you can use a rule set (eg. CRS). But I don't see the point here, how do you want to use straight the library with CRS...

[ElevationsRPG]

Hi @ElevationsRPG,

I would really appreciate if LibModSecurity contained both 32-bit and 64-bit libs and dlls in release builds

That's not as simple. libmodsecurity3 is a library with several optional features, eg. you can choose which storage type you want to use for transaction's data (LMDB, in-memory), which regex engine you want to use (pcre2, old pcre), do you want to use XML or not, want to use JSON or not, etc...

With which features should we publish the compiled library/dll?

i can get straight to using the library with core owasp crs ruleset.

Sorry, I don't understand this. You can use libmodsecurity3 with Nginx through a connector, then you can use a rule set (eg. CRS). But I don't see the point here, how do you want to use straight the library with CRS...

Actually it is that simple, You can just compile the libs with ALL default libaries selected that a standard LibModSecurity install would/should use for default behavior. Yes it might be true that you expect people to "plug n play" the libraries that they would prefer to use but that does not mean that LibModSecurity should not have its own standard and default selection of those libaries

A LibModSecurity default installation would follow the default libs structure:
yajl/2.1.0
pcre2/10.42
libxml2/2.12.6
lua/5.4.6
libcurl/8.6.0
lmdb/0.9.31
libmaxminddb/1.9.1
dirent/1.24
poco/1.13.3

This should be what the precompiled libs and dlls provide by the default option with all features turned on by default and if they want to disable them they can do so using the modsecurity.conf file or by specifing special #defines in the program.

I am currently using LibModSecurity 3 for a custom built web application with the core CRS ruleset which is what i meant earlier it is not using any connectors and is instead directly loading the ruleset into my webapplication as a WAF (Web application firewall)

[airween]

Actually it is that simple, You can just compile the libs with ALL default libaries selected that a standard LibModSecurity install

No, I still think it's not simple. Eg. you listed YOUR installed versions of libraries, but what if other users have different versions?

My other note: personally I don't like to use LMDB, so if I would have an LMDB linked library, there wasn't any chance to disable that.

[ElevationsRPG]

Actually it is that simple, You can just compile the libs with ALL default libaries selected that a standard LibModSecurity install

No, I still think it's not simple. Eg. you listed YOUR installed versions of libraries, but what if other users have different versions?

My other note: personally I don't like to use LMDB, so if I would have an LMDB linked library, there wasn't any chance to disable that.

It is honestly simple: this isn't about personal preference; this is about having one default standard. How should a DEFAULT INSTALL look?

I'm saying to link all of them, and yes, you can still disable the ones you don't intend to use from the config file or by using #defines in the code so that they aren't used. They might be bundled into the libraries and DLLs, but that doesn't mean they are used. Based on your own statement, your issue is regarding their use, not whether they are included(Linked) in the library itself.

-My final note
Again we are talking about precompiled libs and dlls if somone really has an issue with LMDB being linked (not used but linked) or even if they have different versions then they can go compile the source and choose it themselves. The default shipped libs and DLLs which would be part of a DEFAULT INSTALL would not be concerned with such conflicts.

Is having all of them linked and a extra 2MB in size really that big of a problem?

[airween]

It is honestly simple: this isn't about personal preference;

I don't want to mix my personal preference and community acts. I just wrote an example.

this is about having one default standard.

The problem is: there is no standard

How should a DEFAULT INSTALL look?

Default install:

• it still uses old PCRE (actually we are working on the fix)
• it does not use LMDB
• if the ./configure script finds yajl library then it will use that; otherwise the library won't support JSON at all
• if the ./configure script finds libxml2 library then it will use that; otherwise the library won't support XML at all
• few other things...

I'm saying to link all of them, and yes, you can still disable the ones you don't intend to use from the config file or by using #defines in the code so that they aren't used. They might be bundled into the libraries and DLLs, but that doesn't mean they are used. Based on your own statement, your issue is regarding their use, not whether they are included(Linked) in the library itself.

Especially if LMDB is linked to the library then it will use that. There is no option to choice not to use it (I have a plan to solve this issue too).

-My final note Again we are talking about precompiled libs and dlls if somone really has an issue with LMDB

LMDB was just an example, I'm afraid you totally misunderstood this example.

being linked (not used but linked)

Once again: there is no such option. For all linked libraries: LMDB (optional), YAJL, XML... If the build system finds any of them, the compilation process will link them and the library will use them. If someone uses this precompiled version, they will have to install all the libraries - with the same version.

I hope now you see how painful would be this.

or even if they have different versions then they can go compile the source and choose it themselves.

So if I compile the library with PCRE2 version 10.44 and someone grabs it, they have to compile the library used at the system wide (with all the dependent components)?

The default shipped libs and DLLs which would be part of a DEFAULT INSTALL would not be concerned with such conflicts.

See above.

Is having all of them linked and a extra 2MB in size really that big of a problem?

No, +2MB is not a problem.

Other questions:

• do you want to see the library with debug symbols or not? (Do I need to use -g flag or not?)
• do you want any optimization on the compiled library? If yes, on which level? (Consider -O flag)
• do you need development files or not?

Someone says yes for these questions and someone says no. Everyone can decide these if they build for themselves.

[ElevationsRPG]

If someone uses this precompiled version, they will have to install all the libraries - with the same version.

I dont understand this? You are saying precompiled versions they will have to install all the libaries? What? Why would they need all the libaries if its pre-compiled LIB/DLL this makes no sense. They would already be linked to the LibModSecurity3.dll ? No they would not need them installed at all.

do you want to see the library with debug symbols or not? (Do I need to use -g flag or not?)

You would have /Debug and /Release (Debug would contain symbols)

do you want any optimization on the compiled library? If yes, on which level? (Consider -O flag)

/Release would contain optimizations and no symbols yes

do you need development files or not?

No only the precompiled libs and dll file LibModSecurity3.dll

And finally you would have /MT and /MD options aswell here is how the default libs should look:

Dynamic -->
- Debug
- Release
Static-->
- Debug
- Release

Keep in mind i am primarly talking about Windows builds here but you can easily compile the libs for both Windows, Linux and Macos

Windows - .lib and .dll files
Linux - .a and .so files
MacOS - .a and .dylib files

I hope now you see how painful would be this.

While adopting a unified standard across all platforms might seem challenging at first, it ultimately simplifies web application development by reducing the complexity of choosing and integrating libraries. ModSecurity is a fantastic WAF with great potential, and I hope to see it continue evolving with regular updates and community feedback.

This evolution could involve phasing out outdated or unnecessary libraries and adopting modern, secure alternatives. For instance, ensuring that dependencies like PCRE2, yajl, and libxml2 are robust against potential exploits is crucial for improving security. A focus on modernizing ModSecurity and addressing vulnerabilities can not only enhance resilience but also provide developers with greater confidence in its reliability. Although this transition may initially be difficult, it promises a more streamlined and secure development cycle in the long term.

[theseion]

Let's focus on the original issue: compiling ModSecurity for 32-bit Windows. I suppose it's an option to publish both 32 and 64-bit artefacts (this is my assumption, which might be incorrect). I can't personally tell how much effort that would be. Assuming such a 32-bit artefact would be built, would that solve your issue @ElevationsRPG?

As for the discussion on default features, IMO that's an entirely separate topic (and shouldn't be discussed in this issue). Firstly, we already have a default. Secondly, every default will make someone unhappy. And thirdly, is it really worth changing the default and stalling all other work for that? We're pretty limited in terms of resources and I assume (with only little personal experience) that the work required for changing the default might be considerable (including changes to CI, tests, etc.).

[ElevationsRPG]

Let's focus on the original issue: compiling ModSecurity for 32-bit Windows. I suppose it's an option to publish both 32 and 64-bit artefacts (this is my assumption, which might be incorrect). I can't personally tell how much effort that would be. Assuming such a 32-bit artefact would be built, would that solve your issue @ElevationsRPG?

As for the discussion on default features, IMO that's an entirely separate topic (and shouldn't be discussed in this issue). Firstly, we already have a default. Secondly, every default will make someone unhappy. And thirdly, is it really worth changing the default and stalling all other work for that? We're pretty limited in terms of resources and I assume (with only little personal experience) that the work required for changing the default might be considerable (including changes to CI, tests, etc.).

Yes providing a 32 bit artefacts would satisfy my issue. Assuming you mean the lib and dll files. But its a little confusing first I was told there is no default and now there is, anyway your right that deeper conversation about it should be another topic yes even though they happen to correlate with this topic.

[airween]

@ElevationsRPG,

based on #3314 were you able to build 32 bit dll as you wanted?

Do we still need to keep this issue open?

[ElevationsRPG]

Thanks this issue is resolved.