This is cosmetic, but since it had me scratching my head for a while I figured it's helpful to log as a bug.
In ngx_http_modsecurity_module.c:ngx_http_modsecurity_init_main_conf() the module emits an error log entry noting the number of rules loaded and the version of libmodsecurity3. The version number comes from constants which are derived from the header file modsecurity/modsecurity.h.
|
MODSECURITY_MAJOR, MODSECURITY_MINOR, MODSECURITY_PATCHLEVEL); |
These symbols are resolved at compile time from the header file, but the module itself is dynamically linked and so this may not reflect the version of the library in use by the module.
Practically, fixing this would require a new API in libmodsecurity to request the library version and calling that from the connector. This would not be a backward-compatible change and may not make sense outside of a significant update.
This is cosmetic, but since it had me scratching my head for a while I figured it's helpful to log as a bug.
In
ngx_http_modsecurity_module.c:ngx_http_modsecurity_init_main_conf()the module emits an error log entry noting the number of rules loaded and the version of libmodsecurity3. The version number comes from constants which are derived from the header filemodsecurity/modsecurity.h.ModSecurity-nginx/src/ngx_http_modsecurity_module.c
Line 691 in 9eb44fd
These symbols are resolved at compile time from the header file, but the module itself is dynamically linked and so this may not reflect the version of the library in use by the module.
Practically, fixing this would require a new API in libmodsecurity to request the library version and calling that from the connector. This would not be a backward-compatible change and may not make sense outside of a significant update.