Bug 1672678

Any update here?

libmodsecurity-3.0.3-1.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-ee5a421a8a

libmodsecurity-3.0.3-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-9a7ee8ddd8

libmodsecurity-3.0.3-1.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-1e12b7c8b4

Updates will hit testing repos soon, please test and provide feedback via karma if possible.

libmodsecurity-3.0.3-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-ee5a421a8a

libmodsecurity-3.0.3-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-9a7ee8ddd8

libmodsecurity-3.0.3-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-1e12b7c8b4

I don't think we can push this to Fedora outside of Rawhide. A rebuild is needed on aarch64 for dependent packages since it apparently breaks the ABI on those platforms so it's too late for f30.

I need to double check that epel7 is x86_64-only in which case it would be OK to push there.

No, epel7 is also not OK apparently: https://koji.fedoraproject.org/koji/buildinfo?buildID=1240700

Which packages depend on this ABI version?
If yuo have an access, you can update everything within one update cycle (build libmodsecurity, make override in Bodhi, build dependants, push all builds as one solid update).

> Which packages depend on this ABI version?

I don't know and it would be easy to find out with dnf, but end users are entitled to stability for a given Fedora release so we can't push this update outside of rawhide right now.

Also, I misread the report and even x86_64 breaks:

https://taskotron.fedoraproject.org/artifacts/all/7b2bc0be-53eb-11e9-9601-525400fc9f92/tests.yml/libmodsecurity-3.0.3-1.fc29.log
https://taskotron.fedoraproject.org/artifacts/all/7b45338c-53eb-11e9-9d55-525400fc9f92/tests.yml/libmodsecurity-3.0.3-1.fc29.log
https://taskotron.fedoraproject.org/artifacts/all/d0fadd02-53e8-11e9-9d55-525400fc9f92/tests.yml/libmodsecurity-3.0.3-1.fc30.log
https://taskotron.fedoraproject.org/artifacts/all/d11716d4-53e8-11e9-9601-525400fc9f92/tests.yml/libmodsecurity-3.0.3-1.fc30.log

I don't see any dependants from "libmodsecurity", except its auxiliary packages (libmodsecurity-devel, libmodsecurity-static).

# repoquery --whatrequires libmodsecurity
libmodsecurity-devel-0:3.0.2-3.el7.x86_64
libmodsecurity-static-0:3.0.2-3.el7.x86_64

I really doubt you would break anything with bumping ABI in "libmodsecurity".

I tried this instead:

    dnf repoquery --enablerepo=*-source --whatrequires libmodsecurity-devel

No dependent package, which means it's good to go in rawhide and f30. We can't break f29 because there may be users of the package and they shouldn't have to rebuild whatever uses this library on their systems, I'm one of them.

Sorry for late response, I'll unpush them on the stable branch, I usually dont update the stable branches unless the project is in it early stages (.0 is often buggy), plus I checked that nothing depend on it.


@Dridi: out of curiosity, do you use libmodsecurity 3.x in production ? (via Apache httpd/nginx/varnish/ ...), I'm asking because the plan is to make mod_secuirty3 the main package and leave mod_security (aka mod_security2) for while before retiring it (probability when RHEL 7 will hit EOL)

This ticket is still in ON_QA state. Could you check and resolve it?
Thanks.

I tried to reply to this ticket on June 11th but I've been unable to login with either my FAS account or my email/password for a long while now (not that I checked everyday).

My wannabe answer from then:

> We may have to rethink how we ship libmodsecurity, see this thread:
>
> https://github.com/SpiderLabs/ModSecurity/issues/2115

Dridi

Okay, but meanwhile libmodsecurity developers elaborate consistent ABI scheme support, we can push the package to Rawhide (where ABI change doesn't affect anything), and close the bug.

I think they will more likely not guarantee ABI stability, but this is only my assumption from the first reply I got. They may surprise me, but I don't think they will commit to any form of stability, from what I could glean from coworkers even simply plugging a leak ended up with an ABI change between 3.0.2 and 3.0.3 and I wouldn't be surprised if they added such a goal to their 3.1 roadmap instead.

However this is pure speculation, if interested parties have a github account, they can subscribe to that thread and wait for upstream's statement.

OK. Would you mind to push libmodsecurity-3.0.3 update to Rawhide, since it can be used there as is?

It was already done by Athmane Madjoudj:

https://apps.fedoraproject.org/packages/libmodsecurity/

Thanks, haven't noticed that for some reason. So this issue be closed with CLOSED/RAWHIDE.