The generated data (owasp_rules.json, waf_patterns/**) is derived from
third-party projects but was implicitly covered by the blanket MIT LICENSE
with no NOTICE. Add the missing attribution — additively and reversibly:
- THIRD_PARTY_NOTICES.md (new): per-source attribution
- OWASP CoreRuleSet -> Apache-2.0 (owasp_rules.json + waf_patterns/**)
- JayBizzle/Crawler-Detect -> MIT (bad-bot list)
- mitchellkrogza/...bad-bot -> MIT (bad-bot list)
- matomo/referrer-spam-... -> Public Domain (referrer spam)
- LICENSES/Apache-2.0.txt (new): canonical license copy (Apache-2.0 §4a).
- README: License section now scopes MIT to the original project code; the
generated data is redistributed under its upstream licenses. Resources now
credit the real bad-bot sources (removed the unused ai.robots.txt mention).
- Converters (owasp2json, json2nginx, json2apache, json2traefik, json2haproxy)
emit a provenance header on every generated file (Apache-2.0 §4b "state
changes"); owasp_rules.json gains a top-level _provenance key. Loaders accept
both the {_provenance, rules} object and the legacy bare-array form.
- owasp_rules.json wrapped as {_provenance, rules} (rule content unchanged).
- update_patterns.yml jq updated for the object shape.
LICENSE stays MIT (GitHub detection unaffected). Propagation of the headers to
waf_patterns/** is left to the daily update_patterns workflow.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Enables weekly Dependabot updates (minor/patch grouped to limit PR noise)
for the ecosystems present in this repo (GitHub Actions plus the relevant
package managers and Dockerfiles). Config-only, no code changes.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
- New workflow step builds release_notes.md from runtime data: build date,
resolved CRS tag (queried from upstream API), total OWASP rule count,
category count, per-backend bot counts, archive sizes (du -h), and
SHA-256 checksums of every zip.
- Replace deprecated actions/create-release@v1 + 4x upload-release-asset@v1
with a single softprops/action-gh-release@v2 step that publishes the body
and all four archives in one go.
- Release body becomes a self-contained, email-friendly summary visible in
GitHub notification mails: coverage, backends table, quick-install
one-liner, and supply-chain-verifiable SHA-256 list.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Drops the self-hosted runner-02 default. With no self-hosted runner registered
on the repo, workflows now run reliably on ubuntu-latest without needing a
RUNS_ON repo variable override.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- VitePress: custom theme (SF system fonts, glass nav, soft surfaces, pill buttons,
light/dark code blocks, refined feature cards, platform showcase + stat strip).
- Replace every emoji across docs and README with inline SVG icons.
- Verify and fix doc accuracy against actual scripts: JSON schema (category+pattern only),
env-var configuration for json2*/import_* scripts, owasp2json CLI surface.
- Add public assets (logo.svg, favicon.svg, hero-shield.svg) and Shiki haproxy alias.
- Workflows default to self-hosted runner-02 with a configurable fallback to GitHub
runners via the RUNS_ON repo variable.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Create docs/ directory with VitePress configuration
- Add documentation for all web servers (Nginx, Apache, Traefik, HAProxy)
- Add bad bot detection and API reference documentation
- Add GitHub Actions workflow for automatic deployment to GitHub Pages
- Configure VitePress with sidebar, navigation, and search
- Remove redundant 'gh auth login' command in CI workflow (fixes exit code 1 error)
- Use GH_TOKEN env var instead of GITHUB_TOKEN for gh CLI
- Update Nginx README to clarify that individual category .conf files should not be included directly
- Document that users must use waf_maps.conf (http block) + waf_rules.conf (server block)
Fixes#17
Explanation of the Workflow:
Checkout: Checks out the repository. fetch-depth: 0 gets the full Git history, which is necessary for tag manipulation.
Setup Python: Sets up Python 3.11.
Cache: Caches the pip directory to speed up dependency installation.
Install Dependencies: Installs dependencies from requirements.txt.
Run Scripts: Runs the owasp2json.py, json2nginx.py, json2apache.py, json2traefik.py, and json2haproxy.py scripts to generate the WAF configurations. These steps will now fail fast if any of the scripts encounter an error.
Generate Bad Bot Blockers: Executes badbots.py.
Commit and Push (Conditional):
Configures Git with a bot user.
Adds all changes.
Uses git diff --quiet --exit-code to check for changes. If there are no changes, the git diff command exits with a non-zero code, and the if condition is false.
If there are changes, commits them with a descriptive message and pushes to the repository.
continue-on-error: true is used only on this step because it's okay if there are no changes to commit.
Create Zip Archives: Creates ZIP files containing the generated configurations for each web server. The (cd ... && zip ...) command ensures that the ZIP files contain the correct directory structure (e.g., nginx_waf.zip should contain a nginx/ directory).
Delete Existing Release: Deletes the latest tag (both locally and remotely) and the latest release (if they exist). This ensures that we always have a clean "latest" release. Uses the gh CLI (GitHub CLI) for release management.
Create GitHub Release (Conditional): The if: success() condition ensures that this step only runs if all preceding steps were successful. This prevents creating a new release if the rule generation failed. Creates a new release tagged as latest.
Upload Assets (Conditional): Uploads the generated ZIP files as assets to the new release. Also uses if: success().
Clean Up (Optional): Removes the pip cache. if: always() ensures this runs even if previous steps fail.
Notify on Failure (Optional): Uses if: failure() to run only if a previous step failed. This step currently just prints a message, but you can replace it with a notification mechanism (e.g., sending a message to Slack or sending an email). You'll need to set up the necessary secrets (like SLACK_WEBHOOK) for your chosen notification method.
