1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#1108728: libnginx-mod-http-modsecurity: Circular dependency on trix

    From Lloyd@21:1/5 to All on Fri Jul 4 05:50:01 2025
    Package: libnginx-mod-http-modsecurity
    Version: 1.0.3-2+b2
    Severity: important
    Tags: trixie

    Upgrading bookworm -> trixie, libnginx-mod-http-modsecurity triggers
    a circular dependency-like issue and the upgrade is unable to complete:

    dpkg: error processing package nginx (--configure):
    installed nginx package post-installation script subprocess returned error exit status 1
    dpkg: dependency problems prevent configuration of libnginx-mod-http-ndk:
    libnginx-mod-http-ndk depends on nginx-abi-1.26.3-1; however:
    Package nginx-abi-1.26.3-1 is not installed.
    Package nginx which provides nginx-abi-1.26.3-1 is not configured yet.

    dpkg: error processing package libnginx-mod-http-ndk (--configure):
    dependency problems - leaving unconfigured
    dpkg: dependency problems prevent configuration of libnginx-mod-http-modsecurity:
    libnginx-mod-http-modsecurity depends on libnginx-mod-http-ndk; however:
    Package libnginx-mod-http-ndk is not configured yet.
    libnginx-mod-http-modsecurity depends on nginx-abi-1.26.3-1; however:
    Package nginx-abi-1.26.3-1 is not installed.
    Package nginx which provides nginx-abi-1.26.3-1 is not configured yet.

    dpkg: error processing package libnginx-mod-http-modsecurity (--configure):
    dependency problems - leaving unconfigured
    Errors were encountered while processing:
    nginx
    libnginx-mod-http-ndk
    libnginx-mod-http-modsecurity
    Error: Sub-process /usr/bin/dpkg returned an error code (1)

    It appears libnginx-mod-http-modsecurity depends on the next version of nginx, which cannot start until libnginx-mod-http-modsecurity is fully installed.

    A workaround appears to be:

    1. Remove packages libnginx-mod-http-modsecurity & libnginx-mod-http-ndk
    2. Edit nginx.conf to temporarily disable modsecurity which is now missing.
    3. Re-run upgrade to allow it to complete, and nginx to start successfully.
    4. Reinstall libnginx-mod-http-modsecurity & modsecurity-crs (if installed)
    5. Make any necessary changes (I had some breakage in /usr/share/modsecurity-crs/owasp-crs.load)
    6. Re-enable modsecurity in nginx.conf
    7. Restart necessary services.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lloyd@21:1/5 to All on Fri Jul 4 21:30:01 2025
    I gave this some fresh thought and I now suspect the root cause lies within the modsecurity-crs package, which ironically is not mentioned anywhere in the error messages. This may provide some important missing context.

    Once modsecurity was disabled and I was successfully able to reinstall all the packages, I had to remove the following two offending lines from /usr/share/modsecurity-crs/owasp-crs.load before nginx would start:

    IncludeOptional /etc/modsecurity/crs/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

    IncludeOptional /etc/modsecurity/crs/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf

    I now suspect this issue may have cascaded and caused the error messages which blocked the package upgrades.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lloyd@21:1/5 to All on Sat Jul 5 00:00:01 2025
    Ervin Hegedüs wrote:

    The problem is that libmodsecurity3 (the WAF library that Nginx
    uses via libngnx-mod-http-modsecurity module) does not support `IncludeOptional` directive.

    If someone install the package first, this issue comes always.

    Now you upgraded the system, and you upgraded modsecurity-crs
    package too - which overrided your `Include` directive (I guess).

    I think we should replace the mentioned `IncludeOptional`
    directive with the `Include`.

    Hi Ervin, please bear with me as it has been quite some time since I
    set up modsecurity on this box and am not an expert.

    I have attempted to reconstruct the events during the upgrade.

    My understanding is the "IncludeOptional" in the default owasp-crs.load
    is not compatible with nginx. It's likely that I removed this reference
    ages ago to get things working. However, with the file now having been overwritten, it's impossible to know for sure.

    During the upgrade from bookworm -> trixie, modsecurity-crs package was
    updated from version 3.3.4 to 3.3.7:

    Preparing to unpack .../132-modsecurity-crs_3.3.7-1_all.deb ...
    Unpacking modsecurity-crs (3.3.7-1) over (3.3.4-1) ...

    During the upgrade I received a prompt due to file /etc/modsecurity/crs/crs-setup.conf being modified by me:

    Setting up modsecurity-crs (3.3.7-1) ...
    Installing new version of config file /etc/modsecurity/crs/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf ...
    Installing new version of config file /etc/modsecurity/crs/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf ...

    Configuration file '/etc/modsecurity/crs/crs-setup.conf'
    Modified (by you or by a script) since installation.
    Package distributor has shipped an updated version.
    What would you like to do about it ? Your options are:
    Y or I : install the package maintainer's version
    N or O : keep your currently-installed version
    D : show the differences between the versions
    Z : start a shell to examine the situation
    The default action is to keep your current version.
    *** crs-setup.conf (Y/I/N/O/D/Z) [default=N] ?
    Setting up libldap-common (2.6.10+dfsg-1) ...
    Installing new version of config file /etc/ldap/ldap.conf ...

    Note I received no warning that /usr/share/modsecurity-crs/owasp-crs.load
    was modified! I speculate this is because the file is located in /usr that dpkg/apt simply overwrote my changes with the new package version.
    Thus reverting any removal of the IncludeOptional that may have been there.

    If this is what happened, I propose /usr/share is a poor location for
    the config file and owasp-crs.load should be located in /etc so that
    dpkg/apt can detect changes in the future. Otherwise it is sure to
    break everytime the package is updated (if running nginx).

    Regards
    Lloyd

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lloyd@21:1/5 to All on Sat Jul 5 19:30:02 2025
    Hi Ervin,

    If this is what happened, I propose /usr/share is a poor location for
    the config file and owasp-crs.load should be located in /etc so that dpkg/apt can detect changes in the future. Otherwise it is sure to
    break everytime the package is updated (if running nginx).


    yes. Let us figure out how can we solve this.


    Thank you for the detailed explanations. If you agree there is a bug here,
    and I do think so based on the upgrade breakage, I propose the following
    which could be a low-impact quick fix to prevent future upgrade issues:

    The fix does not modify any source files in the upstream at all, but rather
    the way the Debian package is built.

    When I examine the package for modsecurity-crs, it declares the following
    as conffiles in the control archive:

    /etc/modsecurity/crs/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf /etc/modsecurity/crs/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf /etc/modsecurity/crs/crs-setup.conf

    When owasp-crs.load was added to the mix at some point, it never got added
    to the conffiles. From looking at the git repo, I don't see conffiles for
    this package explicitly declared anywhere. So I assume there is an auto- generation happening here, based on package files copied into /etc. Since
    the owasp-crs.load file is placed in /usr/share, the package build scripts ignore it and it never gets added - so every upgrade of the package, this
    file will get clobbered, even if it was modified by the user.

    I think if we added owasp-crs.load to the list as a conffile declaration
    the user will get an interactive prompt during package upgrade if the file
    is modified (and it surely will if using it in the scenario we discussed).

    Regards
    Lloyd

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lloyd@21:1/5 to All on Sat Jul 5 19:50:01 2025
    reassign 1108728 modsecurity-crs
    retitle 1108728 owasp-crs.load overwritten during trixie upgrade, causing dependency loop
    affects 1108728 nginx libnginx-mod-http-ndk libnginx-mod-http-modsecurity thanks

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)