CI: use libmodsecurity release binaries in the Windows nginx jobs
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 55/100
Direzione di ricerca
Open .github/workflows/test_new.yml and find the build-windows job with the windows-nginx-* steps. First check whether the trigger condition is met: does a libmodsecurity release (expected v3.0.18) attach libmodsecurity-<version>-windows-x64.zip? If not, the issue is blocked. If yes, replace the source-build/Conan steps with gh release download, verify the sha256, set MODSECURITY_INC/MODSECURITY_LIB and copy the DLL into objs, and optionally move to windows-2025. Done is a green CI run. Note the caveat: leave test.yml's build-windows building from source, and the workflow YAML plus CI debugging experience needed makes this non-trivial for a first-timer.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
Once libmodsecurity publishes prebuilt Windows binaries with its releases (owasp-modsecurity/ModSecurity#3702, closing owasp-modsecurity/ModSecurity#3313), the windows-nginx-* jobs in test_new.yml could use the latest release zip instead of building libModSecurity from source on every run.
Trigger: the first libmodsecurity release that has libmodsecurity-<version>-windows-x64.zip attached (expected v3.0.18).
Why
Building libmodsecurity on Windows means building its dependencies with Conan. That takes about 15-18 minutes per job and has broken this CI twice in October 2026, both times for reasons unrelated to the connector:
- HTTP 429 from
git.openldap.orgwhen Conan downloads the lmdb sources. #403 worked around it with Conan download retries. - yajl failing to configure with CMake 4 (
CMP0026, owasp-modsecurity/ModSecurity#3604) on thewindows-2025image, which now ships Visual Studio 2026. ConanCenter has no prebuilt packages for that compiler, so every dependency was built from source. #403 moved the jobs towindows-2022as a workaround.
The release zip is self-contained: the dependencies are linked statically, and the release workflow checks that libModSecurity.dll depends only on system DLLs and the VC++ runtime. It is built with the dynamic CRT (/MD), the same as the current source build.
What to change
In the build-windows job (windows-nginx-*) of .github/workflows/test_new.yml:
- Replace the "Get libModSecurity source", "Setup Conan", "Retry rate-limited Conan downloads" and "Build libModSecurity" steps with a download of the latest release zip:
(thegh release download -R owasp-modsecurity/ModSecurity --pattern 'libmodsecurity-*-windows-x64.zip' --pattern 'libmodsecurity-*-windows-x64.zip.sha256'-debugzips don't match this pattern). Then verify the zip withsha256sum -corgh attestation verify <zip> --repo owasp-modsecurity/ModSecurity, and extract it. - Point the nginx build at the extracted directories. The zip is a
cmake --installtree, sobin/libModSecurity.dll,lib/libModSecurity.libandinclude/modsecurity/map to:export MODSECURITY_INC=<dist>/include export MODSECURITY_LIB=<dist>/lib cp <dist>/bin/libModSecurity.dll objs - Optionally move the jobs back to
windows-2025, since they no longer depend on Conan or CMake.
Keep one job building from source
With release binaries, these jobs test the connector against the latest libmodsecurity release instead of v3/master. That matches what users run, but two things would go unnoticed until the next release: a v3/master change that breaks the connector, and a connector PR that relies on an API only v3/master has.
So keep build-windows in test.yml building libModSecurity v3/master from source with Conan. The Linux jobs already build v3/master from source.
References
- #403: Conan download retries,
windows-2022for thetest_new.ymlWindows jobs - #389: retries for the pcre2, zlib and OpenSSL downloads
- owasp-modsecurity/ModSecurity#3702: Windows release workflow
- owasp-modsecurity/ModSecurity#3604: yajl / CMake 4
CMP0026
- Lingua principale
- Perl
- Stelle
- 1.9k
- Fork
- 311
- Merge medio
- 7h 5m
- PR unite (30g)
- 2
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di owasp-modsecurity/ModSecurity-nginx
-
Possible dereference of NullAperta:1st_place_medal: good first issue enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
owasp-modsecurity/ModSecurity-nginx#359 · 3 commenti ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 62/100
-
bug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 30/100
owasp-modsecurity/ModSecurity-nginx#400 · 2 commenti ·
-
Module logs version of libmodsecurity headers it was built against, not dynamically linked versionAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
owasp-modsecurity/ModSecurity-nginx#383 · 1 commento ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
owasp-modsecurity/ModSecurity-nginx#375 · 2 commenti ·
Tutte le issue di owasp-modsecurity/ModSecurity-nginx
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
✏️ Editing - Tags
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
openfoodfacts/openfoodfacts-server#15127 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
FIDO2 (ecdsa-sk / ed25519-sk) ingress keys rejected: missing in get_supported_ssh_algorithms_listAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
ovh/the-bastion#695 ·
-
Range length wrong when an abbreviated range end contains a 0 (`pages = {315-20}` gives `\range{pages}{11}`)Forse già presa @plk l’ha presa 2 giorni fa. ApertaBug fixedindev
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
virtualmin/virtualmin-nginx#89 · 1 commento ·