Source: modsecurity-apache Severity: normal libapache-mod-security2 ships /etc/modsecurity/modsecurity.conf.recommended not as modsecurity.conf. So, the user needs to cp that .recommnded file to /etc/modsecurity/modsecurity.conf to get a starting point. It is then not a conffile for dpkg.
If it is possible that a package delivers a working default configuration, it should do so (and that configuration should be active.) modsecurity.conf.recommended sounds to me that this should be the case here. The downside of the current sitation means that the conf file will not be updated when a package update happens and the user didn't change the recommendations. changes to their modsecurity.conf (IOW the user had modsecurity.conf == modsecurity.conf.recommended when they copied it). This might also keep people exposed to fixed vulnerabilties, when those fixes require to update the configuration. (A step further would be to think about something like /etc/modsecurity/site-conf.d/, where users can put in their modifications and this diectory is included in the modsecurity configuration… That would decrease the probability that users get confile prompts even more) -- tobi -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (100, 'bullseye-fasttrack'), (100, 'bullseye-backports-staging'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled