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
