The reviews of the spec update, #9, found gitea requests that the Core Rule Set would refuse at the spec's defaults. Those it named are in SPEC.md; the ones below are not. They were found by reading the source of gitea 1.27.3 and running requests through Coraza 3.7.0 with the Core Rule Set 4.25.0 and the spec's changes applied, not against a running gitea, so each still needs checking.
Cases found so far:
File names in the query parameters that carry a gitea file path, branch or sign-in redirect, refused by the Java, script, PowerShell and database-name rules (944110, 944130, 941180, 934100, 934130, 932120, 942140). Examples: listing the commits of OpenJDK's src/java.base/share/classes/java/lang/Runtime.java through the API, or expanding a diff's hidden lines in it; the sign-in page's redirect_to for a page such as document.write.js.
Names that start with install-script in those parameters, refused by 932120.
File views refused outright by their path: META-INF/services/org.apache.commons.logging.LogFactory and java.lang.String.md (944130), process.env.d.ts (934100), and a path with a ... segment (930100).
A container image push that reuses a layer from an image whose name starts with a command name, refused through the from parameter.
The commit graph's file filter, and the file-contents API call that takes its file list in a query parameter of the body, which are still checked.
When milestone 1 (#13) runs in front of a real gitea, replay these requests, and the ordinary traffic in its request log, through the Core Rule Set at the spec's defaults. For each refusal that holds, either change the default or name the case in SPEC.md with how the refusal plays out. New cases found before then are added here rather than to the spec update.
Model: opus-5-5
The reviews of the spec update, https://git.eeqj.de/sneak/smallwebwaf/pulls/9, found gitea requests that the Core Rule Set would refuse at the spec's defaults. Those it named are in `SPEC.md`; the ones below are not. They were found by reading the source of gitea 1.27.3 and running requests through Coraza 3.7.0 with the Core Rule Set 4.25.0 and the spec's changes applied, not against a running gitea, so each still needs checking.
Cases found so far:
- File names in the query parameters that carry a gitea file path, branch or sign-in redirect, refused by the Java, script, PowerShell and database-name rules (944110, 944130, 941180, 934100, 934130, 932120, 942140). Examples: listing the commits of OpenJDK's `src/java.base/share/classes/java/lang/Runtime.java` through the API, or expanding a diff's hidden lines in it; the sign-in page's `redirect_to` for a page such as `document.write.js`.
- Names that start with `install-script` in those parameters, refused by 932120.
- File views refused outright by their path: `META-INF/services/org.apache.commons.logging.LogFactory` and `java.lang.String.md` (944130), `process.env.d.ts` (934100), and a path with a `...` segment (930100).
- A container image push that reuses a layer from an image whose name starts with a command name, refused through the `from` parameter.
- The commit graph's file filter, and the file-contents API call that takes its file list in a query parameter of the body, which are still checked.
When milestone 1 (https://git.eeqj.de/sneak/smallwebwaf/issues/13) runs in front of a real gitea, replay these requests, and the ordinary traffic in its request log, through the Core Rule Set at the spec's defaults. For each refusal that holds, either change the default or name the case in `SPEC.md` with how the refusal plays out. New cases found before then are added here rather than to the spec update.
Model: opus-5-5
clawbot
self-assigned this 2026-09-29 00:41:05 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The reviews of the spec update, #9, found gitea requests that the Core Rule Set would refuse at the spec's defaults. Those it named are in
SPEC.md; the ones below are not. They were found by reading the source of gitea 1.27.3 and running requests through Coraza 3.7.0 with the Core Rule Set 4.25.0 and the spec's changes applied, not against a running gitea, so each still needs checking.Cases found so far:
src/java.base/share/classes/java/lang/Runtime.javathrough the API, or expanding a diff's hidden lines in it; the sign-in page'sredirect_tofor a page such asdocument.write.js.install-scriptin those parameters, refused by 932120.META-INF/services/org.apache.commons.logging.LogFactoryandjava.lang.String.md(944130),process.env.d.ts(934100), and a path with a...segment (930100).fromparameter.When milestone 1 (#13) runs in front of a real gitea, replay these requests, and the ordinary traffic in its request log, through the Core Rule Set at the spec's defaults. For each refusal that holds, either change the default or name the case in
SPEC.mdwith how the refusal plays out. New cases found before then are added here rather than to the spec update.Model: opus-5-5