I've uploaded a package with this fixed to unstable, 1:2.24-5, and it's been autobuilt and pushed out. Seems to work okay, and can be co-installed with apache2/sid.
Just uploaded 1:2.24-6 that adds Breaks: apach2-bin per your recent message. Honestly, I'm not confident in my ability to properly back-port security-related patches to old versions of fossil. It's a big network-facing program with a large number of moving parts and a substantial attack surface, all written in C. It uses its own sqlite3 copy when the shared library in Debian isn't a high enough version or doesn't have the right options enabled (currently Debian sqlite3 is compiled without SQLITE_ENABLE_JSON1 so the internal version is used.) All this means it would be super easy for me to miss some issue and introduce a vulnerability if I try to back-port a security patch, particularly without myself deeply understanding the security issue. Stable has 1:2.21-1. I just made a debian-bookworm-proposed-updates branch rooted there and tried to cherry-pick the fix, https://fossil-scm.org/home/info/f4ffefe708793b03 but it does not apply cleanly. Obviously I can do it manually though, however there have been changes in the neighborhood. Also, are you *sure* I shouldn't also be applying https://fossil-scm.org/home/info/71919ad1b542832c to the fixed versions? Because I'm not! I'd be most comfortable if upstream simply made a proper release with this fixed (which I bet they'd do upon request), and I uploaded that with the appropriate "Breaks: apache2-bin (<<...)", and did the (trivial) backport of that package to bookworm and bullseye, with the "breaks:" modified to the appropriate version.
