Hi, On 08-06-2023 18:13, Ervin Hegedüs wrote:
On Thu, Jun 08, 2023 at 05:19:53PM +0200, Paul Gevers wrote:[Can we discuss this in public somewhere?]eg. under the report page?
Doing so now.
On 08-06-2023 15:43, Ervin Hegedüs wrote:there is a new bug in libnginx-mod-http-modsecurity package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037226Ouch. This is why we have the freeze, to stabilize things.sure, but the package itself has not changed. I think without tests we could't have discovered this.
Sure. That's very common with c-libraries that change their ABI but not their API. The SONAME of the library gets bumped, the package maintainer ships a new binary package (which matches the SONAME), our tooling detects that and we can schedule rebuilds. You *seem* to be in a similar situation, except there was no SONAME bump involved, our tooling didn't detect it and everything went unnoticed until now. I guess https://www.debian.org/doc/debian-policy/ch-sharedlibs.html and maybe https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#libraries can be good reads.
The problem is that when we uploaded the package and that has migrated into testing, then Nginx (and the previous libmodsecurity3 package) used the old PCRE.I don't fully understand this line.sorry, I try to explain it again. libnginx-mod-http-modsecurity uses one of the PCRE packages: the OLD PCRE, or the NEW, PCRE2 library. This is decided when we compile the source.
Again sounds not uncommon. But apparently either nginx or libmodsecurity3 changed it's ABI as a result of that, which broke the reverse dependencies that weren't rebuild.
This package needs few others: Nginx-dev and libmodsecurity-dev. When we uploaded the first release of this package (libnginx-mod-http-modsecurity), both Nginx and libmodsecurity used the OLD PCRE library, therefore this package has been built with the OLD PCRE library too. Meanwhile the Nginx maintainers changed the OLD PCRE by the NEW PCRE2 library. Therefore we changed the PCRE version in libmodsecurity3 too. As I wrote above, libnginx-mod-http-modsecurity does not have any control options to decide which PCRE version wants to use, but during the compile time it sets the symbols. > This is why it compiled to use the OLD PCRE, but not the Nginx, neither the libmodsecurity3 don't use it. Hope now it's clear - let me know if I can help you in this.
I'm not a library expert, but this really, really looks wrong to me.
Meanwhile both packages started to use PCRE2.That was the whole idea, no?The idea was that the libmodsecurity3 uses the PCRE2. As I wrote we can't control the libnginx-mod-http-modsecurity. It's "picking" up the necessary library during the compile time.There is no control in libnginx-mod-http-modsecurity which decides which PCRE library will be used - it Nginx's and/or libmodsecurity3's.But aren't those aligned now on pcre2?We can't align it. It aligns "itself" when it compiling. I successfully reconstructed the issue: installed the packages (nginx, libmodsecurity3, libnginx-mod-http-modsecurity), and the result was the same (dlopen() "/usr/share/nginx/modules/ngx_http_modsecurity_module.so" failed (/usr/share/nginx/modules/ngx_http_modsecurity_module.so: undefined symbol: pcre_malloc)). I removed the package, installed the source package, rebuild it, install it again, and the problem has went. By recompiling the package, I solved the problem, seems now it uses PCRE2.I need help: what would I do in this case?Raise the severity of the bug and document it in the release notes.Sorry for the dumb question, but in which release notes do I need to document?
https://www.debian.org/releases/bookworm/releasenotes which has its source here: https://salsa.debian.org/ddp-team/release-notes/
(Raise the severity is trivial I guess - perhaps I can do that through emailing)The release of bookworm is on Saturday, we can't fix it anymore. Prepare a fixed package for the first point release (after ensuring it's fixed in unstable).uhm, that's a bad news. How can we fix it in unstable?
Figure out what went wrong. I expect a new library package needs to be uploaded (please use experimental for that). Once that's done, a transition can be requested, see https://wiki.debian.org/Teams/ReleaseTeam/Transitions
I think a simple rebuild is not enough,Nor should it. Normally that means that there are other bugs. This smells like like ABI breakage which normally should be handled by transitions, but our tooling didn't detect the transition.Because it is decided at compile time.
One the transition is ACK'ed the rebuild will be scheduled by the release team.
https://github.com/SpiderLabs/ModSecurity-nginx/blob/master/CHANGES#L6 https://github.com/SpiderLabs/ModSecurity-nginx/blob/master/src/ngx_http_modsecurity_module.c#L41 The ABI isn't changed, but the code itself was aligned to Nginx.
I a symbol is dropped, that means a break in the ABI.
Is there anything with that we could prevent this situation?because - as we can see - users started to use this module, so we definitely need to increase the package's version number. Should I upload a new package? But then what should I put into the d/changelog?In case you didn't understand; a rebuild will bump the version number of the binary package(s) (but not the source).ah, okay, so a rebuild will enough. (And it's necessary)Or will the rebuild increase the package's version number? (The point is that users' package manager download the new version with new version of libmodsecurity3)If a rebuild "fixes" the issue, I want to understand why it wasn't detected that it was needed. Because "just doing a rebuild" usually means we would be papering over the real issue.I think this is an Nginx-specific solution, that the user can't control the package "compilation flags", as in case of other applications/libraries. The compiled module "reads" the "settings" from the dependent packages when the compile procedure starts. As I know there isn't any solution to avoid this, but this is why I asked you above: is there any tool which helps to prevent this? This is the "config" file which describes the Nginx-sdk tool, how to build the module: https://github.com/SpiderLabs/ModSecurity-nginx/blob/master/config As you can see, there is no any information about the used PCRE version... I guess you remember my last e-mail in connection with libapache2-mod-security issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037024 This situation is similar: there is a dependency (there: libapr1, here: Nginx), which changed the version since the affected package (there: modsecurity-apache, here: libnginx-mod-http-modsecurity) but here the dependent package changed the 3rd-party library, which has a hard effect for the package in subject.
That situation was different (at least from the symptoms). The problem there was that it was emitting a *warning*, nothing broke. The warning is bad but not a real problem. Missing symbols is a problem.
I hope I could help to understand the situation.
I hope you can figure out more what's wrong. We can't really fix it properly otherwise.
Paul
OpenPGP_signature
Description: OpenPGP digital signature
