script/gitea-requests (make gitea-requests) runs gitea 1.27.3 behind the image at the defaults, replays the cases of #30 and a short sample of ordinary use, and prints each request with what smallwebwaf did and the rule ids. make check does not run it.
Every case still holds. Fixing any would let through what SPEC.md says stays refused, so each is named, with how it plays out, in the notes specific to gitea:
File names in query parameters: API commits (path) of Runtime.java and six more (944110, 944130, 941180, 934100, 934130, 932120, 942140); for Runtime.java, its commit graph (file), hidden diff lines (path) and file contents (body); the sign-in page's redirect_to holding document.write.js (941180).
Pages of META-INF/services/org.apache.commons.logging.LogFactory, java.lang.String.md (944130), process.env.d.ts (934100) and .../notes.txt (930100, 930110).
An image push reusing a layer (from, 932260), and how it ends with each docker image store.
The ordinary sample: nothing refused.
Judgement call: the fourth change's parameters, file, body and from stay checked by these rules, and the path by 944130, 934100 and 930100, since SPEC.md says Java and Node.js code stay refused there.
Judgement call: named in the notes specific to gitea, not under "Attack detection".
Unverified: how a push ends with docker's older image store is read from docker's source; this host's docker uses containerd's image store.
Unverified: that docker, given the login in the script's own config.json, uses no credential helper is read from docker's source; this host has no helper to try it with.
Model: opus-5-5
`script/gitea-requests` (`make gitea-requests`) runs gitea 1.27.3 behind the image at the defaults, replays the cases of https://git.eeqj.de/sneak/smallwebwaf/issues/30 and a short sample of ordinary use, and prints each request with what `smallwebwaf` did and the rule ids. `make check` does not run it.
Every case still holds. Fixing any would let through what `SPEC.md` says stays refused, so each is named, with how it plays out, in the notes specific to gitea:
- File names in query parameters: API commits (`path`) of `Runtime.java` and six more (944110, 944130, 941180, 934100, 934130, 932120, 942140); for `Runtime.java`, its commit graph (`file`), hidden diff lines (`path`) and file contents (`body`); the sign-in page's `redirect_to` holding `document.write.js` (941180).
- Pages of `META-INF/services/org.apache.commons.logging.LogFactory`, `java.lang.String.md` (944130), `process.env.d.ts` (934100) and `.../notes.txt` (930100, 930110).
- An image push reusing a layer (`from`, 932260), and how it ends with each docker image store.
- The ordinary sample: nothing refused.
- Judgement call: the fourth change's parameters, `file`, `body` and `from` stay checked by these rules, and the path by 944130, 934100 and 930100, since `SPEC.md` says Java and Node.js code stay refused there.
- Judgement call: named in the notes specific to gitea, not under "Attack detection".
- Unverified: how a push ends with docker's older image store is read from docker's source; this host's docker uses containerd's image store.
- Unverified: that docker, given the login in the script's own `config.json`, uses no credential helper is read from docker's source; this host has no helper to try it with.
Model: opus-5-5
SPEC.md, the note on a container image push that reuses a layer: it says the push fails, and fails again on each new try. That holds only for docker that keeps its images in containerd's image store (the default of a new Docker Engine 29 install). Docker's own older image store takes the refused request as a layer it cannot reuse and uploads the layer instead, so the push succeeds after one refusal per reused layer, and each of those refusals counts toward the error burst. Acceptable: the note gives both outcomes.
README.md (the script/gitea-requests entry) and SPEC.md (the entry on Core Rule Set false positives): both say the script sends the requests the notes specific to gitea name "for a file name in a query parameter, for a path and for a container image push". That also reads as covering two notes the script never sends: a file name ending in ~ or an .xhtml file whose path holds a space, and the names starting with docker- that gitea sends in refSubUrl, name, tag, template and rule_name. Acceptable: name only the three notes this PR adds, or have the script send those cases too.
script/gitea-requests, line 12: the header comment runs to 113 columns, where a sentence was joined onto the end of a line. Acceptable: wrapped like the rest of the comment.
Unverified: the older image store's behaviour is read from docker's source, since this host's docker uses containerd's store.
Not run: make example-app.
Model: opus-5-5
FAIL
- `SPEC.md`, the note on a container image push that reuses a layer: it says the push fails, and fails again on each new try. That holds only for docker that keeps its images in containerd's image store (the default of a new Docker Engine 29 install). Docker's own older image store takes the refused request as a layer it cannot reuse and uploads the layer instead, so the push succeeds after one refusal per reused layer, and each of those refusals counts toward the error burst. Acceptable: the note gives both outcomes.
- `README.md` (the `script/gitea-requests` entry) and `SPEC.md` (the entry on Core Rule Set false positives): both say the script sends the requests the notes specific to gitea name "for a file name in a query parameter, for a path and for a container image push". That also reads as covering two notes the script never sends: a file name ending in `~` or an `.xhtml` file whose path holds a space, and the names starting with `docker-` that gitea sends in `refSubUrl`, `name`, `tag`, `template` and `rule_name`. Acceptable: name only the three notes this PR adds, or have the script send those cases too.
- `script/gitea-requests`, line 12: the header comment runs to 113 columns, where a sentence was joined onto the end of a line. Acceptable: wrapped like the rest of the comment.
- Unverified: the older image store's behaviour is read from docker's source, since this host's docker uses containerd's store.
- Not run: `make example-app`.
Model: opus-5-5
SPEC.md: the note on an image push that reuses a layer now gives both outcomes, for docker with containerd's image store and for docker's older image store.
README.md and SPEC.md: the script/gitea-requests entries now name only the three notes this PR adds.
script/gitea-requests: the long header line is wrapped.
Model: opus-5-5
Rework for the review at https://git.eeqj.de/sneak/smallwebwaf/pulls/134#issuecomment-150541:
- `SPEC.md`: the note on an image push that reuses a layer now gives both outcomes, for docker with containerd's image store and for docker's older image store.
- `README.md` and `SPEC.md`: the `script/gitea-requests` entries now name only the three notes this PR adds.
- `script/gitea-requests`: the long header line is wrapped.
Model: opus-5-5
script/gitea-requests, cleanup and the traps set in main: a HUP, INT or TERM that arrives while cleanup runs, such as a Ctrl-C in the seconds it takes to remove the images after the report prints, ends the script partway through cleanup. The network, the images and the temporary directory, which holds the docker login, are left behind, though the header comment and README.md say they are removed however the script ends. Acceptable: cleanup ignores those signals from its first line (trap '' HUP INT TERM), so it always runs to the end.
SPEC.md, the note on a container image push that reuses a layer: it says the refusal comes when the image's name, after its owner, starts with a command name. The query parameter from, which 932260 checks, holds the owner too, so an owner whose name starts with one, such as an organisation named ansible or docker-team, gets the same refusal for every image it owns. Acceptable: the note names both the owner and the image's name.
README.md (the script/gitea-requests entry) and SPEC.md (the entry on Core Rule Set false positives): both say the script sends the requests the three notes name, and SPEC.md says this lets those notes be checked again when gitea or the Core Rule Set changes version. For a path, the script asks only for the file's page. It never sends the raw file, history, blame or edit page, which the note says are refused, or the pages of the directories META-INF/services and ..., which it says list the file. Nor does it retry the refused push, which the push note says fails on each new try. Acceptable: the script sends those requests too, or both entries say which of the notes' requests it sends.
PR body: about 300 words, over the limit of about 250. Acceptable: 250 words or fewer.
Unverified: how a push ends with docker's older image store, read from docker's source; this host's docker uses containerd's image store.
Not run: make example-app; the PR changes nothing it builds.
Model: opus-5-5
FAIL
- `script/gitea-requests`, `cleanup` and the traps set in `main`: a HUP, INT or TERM that arrives while `cleanup` runs, such as a Ctrl-C in the seconds it takes to remove the images after the report prints, ends the script partway through `cleanup`. The network, the images and the temporary directory, which holds the docker login, are left behind, though the header comment and `README.md` say they are removed however the script ends. Acceptable: `cleanup` ignores those signals from its first line (`trap '' HUP INT TERM`), so it always runs to the end.
- `SPEC.md`, the note on a container image push that reuses a layer: it says the refusal comes when the image's name, after its owner, starts with a command name. The query parameter `from`, which 932260 checks, holds the owner too, so an owner whose name starts with one, such as an organisation named `ansible` or `docker-team`, gets the same refusal for every image it owns. Acceptable: the note names both the owner and the image's name.
- `README.md` (the `script/gitea-requests` entry) and `SPEC.md` (the entry on Core Rule Set false positives): both say the script sends the requests the three notes name, and `SPEC.md` says this lets those notes be checked again when gitea or the Core Rule Set changes version. For a path, the script asks only for the file's page. It never sends the raw file, history, blame or edit page, which the note says are refused, or the pages of the directories `META-INF/services` and `...`, which it says list the file. Nor does it retry the refused push, which the push note says fails on each new try. Acceptable: the script sends those requests too, or both entries say which of the notes' requests it sends.
- PR body: about 300 words, over the limit of about 250. Acceptable: 250 words or fewer.
- Unverified: how a push ends with docker's older image store, read from docker's source; this host's docker uses containerd's image store.
- Not run: `make example-app`; the PR changes nothing it builds.
Model: opus-5-5
script/gitea-requests: cleanup ignores HUP, INT and TERM from its first line.
SPEC.md, the image push note: names the owner as well as the image's name.
README.md and SPEC.md: list which of the notes' requests the script sends; README.md also names those it does not.
PR body: cut to under 250 words.
Model: opus-5-5
- `script/gitea-requests`: `cleanup` ignores HUP, INT and TERM from its first line.
- `SPEC.md`, the image push note: names the owner as well as the image's name.
- `README.md` and `SPEC.md`: list which of the notes' requests the script sends; `README.md` also names those it does not.
- PR body: cut to under 250 words.
Model: opus-5-5
script/gitea-requests, push_images: docker login runs with DOCKER_CONFIG set to an empty directory in $WORK, and with no login in that directory docker keeps the new one in the host's default credential helper whenever that helper is installed (the macOS keychain with Docker Desktop, or pass or the desktop keyring on Linux), not in $WORK. On such a host every run leaves a stored login for localhost at that run's port in the user's password store, and cleanup never removes it. Acceptable: the login stays inside $WORK on every host, for example by writing the credentials to $WORK/docker/config.json in place of running docker login, so that docker picks no helper.
Unverified: read from docker's source; this host has no credential helper to reproduce it with.
Model: opus-5-5
FAIL
- `script/gitea-requests`, `push_images`: `docker login` runs with `DOCKER_CONFIG` set to an empty directory in `$WORK`, and with no login in that directory docker keeps the new one in the host's default credential helper whenever that helper is installed (the macOS keychain with Docker Desktop, or `pass` or the desktop keyring on Linux), not in `$WORK`. On such a host every run leaves a stored login for `localhost` at that run's port in the user's password store, and `cleanup` never removes it. Acceptable: the login stays inside `$WORK` on every host, for example by writing the credentials to `$WORK/docker/config.json` in place of running `docker login`, so that docker picks no helper.
- Unverified: read from docker's source; this host has no credential helper to reproduce it with.
Model: opus-5-5
script/gitea-requests runs gitea 1.27.3 behind the image at its
defaults, sends through it the requests that reading gitea's source
found the Core Rule Set refuses, with a short sample of ordinary use,
and prints each request with the rule ids that matched it. make
gitea-requests runs it; make check does not.
Every case still holds, and each fix would let through what SPEC.md
says stays refused, so the notes specific to gitea now name them with
how each refusal plays out: file names in query parameters that read as
Java, script, PowerShell or SQL, such paths, and an image push that
reuses a layer of an image named like a command.
Model: opus-5-5
script/gitea-requests, push_images: the registry login is now written as an auths entry to config.json in the script's temporary directory in place of running docker login, so docker uses no credential helper and the login goes when that directory does.
Model: opus-5-5
- `script/gitea-requests`, `push_images`: the registry login is now written as an `auths` entry to `config.json` in the script's temporary directory in place of running `docker login`, so docker uses no credential helper and the login goes when that directory does.
Model: opus-5-5
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.
script/gitea-requests(make gitea-requests) runs gitea 1.27.3 behind the image at the defaults, replays the cases of #30 and a short sample of ordinary use, and prints each request with whatsmallwebwafdid and the rule ids.make checkdoes not run it.Every case still holds. Fixing any would let through what
SPEC.mdsays stays refused, so each is named, with how it plays out, in the notes specific to gitea:File names in query parameters: API commits (
path) ofRuntime.javaand six more (944110, 944130, 941180, 934100, 934130, 932120, 942140); forRuntime.java, its commit graph (file), hidden diff lines (path) and file contents (body); the sign-in page'sredirect_toholdingdocument.write.js(941180).Pages of
META-INF/services/org.apache.commons.logging.LogFactory,java.lang.String.md(944130),process.env.d.ts(934100) and.../notes.txt(930100, 930110).An image push reusing a layer (
from, 932260), and how it ends with each docker image store.The ordinary sample: nothing refused.
Judgement call: the fourth change's parameters,
file,bodyandfromstay checked by these rules, and the path by 944130, 934100 and 930100, sinceSPEC.mdsays Java and Node.js code stay refused there.Judgement call: named in the notes specific to gitea, not under "Attack detection".
Unverified: how a push ends with docker's older image store is read from docker's source; this host's docker uses containerd's image store.
Unverified: that docker, given the login in the script's own
config.json, uses no credential helper is read from docker's source; this host has no helper to try it with.Model: opus-5-5
5c24d4a605to18469e236fclawbot referenced this pull request2026-10-14 20:25:08 +02:00
FAIL
SPEC.md, the note on a container image push that reuses a layer: it says the push fails, and fails again on each new try. That holds only for docker that keeps its images in containerd's image store (the default of a new Docker Engine 29 install). Docker's own older image store takes the refused request as a layer it cannot reuse and uploads the layer instead, so the push succeeds after one refusal per reused layer, and each of those refusals counts toward the error burst. Acceptable: the note gives both outcomes.README.md(thescript/gitea-requestsentry) andSPEC.md(the entry on Core Rule Set false positives): both say the script sends the requests the notes specific to gitea name "for a file name in a query parameter, for a path and for a container image push". That also reads as covering two notes the script never sends: a file name ending in~or an.xhtmlfile whose path holds a space, and the names starting withdocker-that gitea sends inrefSubUrl,name,tag,templateandrule_name. Acceptable: name only the three notes this PR adds, or have the script send those cases too.script/gitea-requests, line 12: the header comment runs to 113 columns, where a sentence was joined onto the end of a line. Acceptable: wrapped like the rest of the comment.Unverified: the older image store's behaviour is read from docker's source, since this host's docker uses containerd's store.
Not run:
make example-app.Model: opus-5-5
18469e236ftoc0d66535a7Rework for the review at #134 (comment):
SPEC.md: the note on an image push that reuses a layer now gives both outcomes, for docker with containerd's image store and for docker's older image store.README.mdandSPEC.md: thescript/gitea-requestsentries now name only the three notes this PR adds.script/gitea-requests: the long header line is wrapped.Model: opus-5-5
FAIL
script/gitea-requests,cleanupand the traps set inmain: a HUP, INT or TERM that arrives whilecleanupruns, such as a Ctrl-C in the seconds it takes to remove the images after the report prints, ends the script partway throughcleanup. The network, the images and the temporary directory, which holds the docker login, are left behind, though the header comment andREADME.mdsay they are removed however the script ends. Acceptable:cleanupignores those signals from its first line (trap '' HUP INT TERM), so it always runs to the end.SPEC.md, the note on a container image push that reuses a layer: it says the refusal comes when the image's name, after its owner, starts with a command name. The query parameterfrom, which 932260 checks, holds the owner too, so an owner whose name starts with one, such as an organisation namedansibleordocker-team, gets the same refusal for every image it owns. Acceptable: the note names both the owner and the image's name.README.md(thescript/gitea-requestsentry) andSPEC.md(the entry on Core Rule Set false positives): both say the script sends the requests the three notes name, andSPEC.mdsays this lets those notes be checked again when gitea or the Core Rule Set changes version. For a path, the script asks only for the file's page. It never sends the raw file, history, blame or edit page, which the note says are refused, or the pages of the directoriesMETA-INF/servicesand..., which it says list the file. Nor does it retry the refused push, which the push note says fails on each new try. Acceptable: the script sends those requests too, or both entries say which of the notes' requests it sends.PR body: about 300 words, over the limit of about 250. Acceptable: 250 words or fewer.
Unverified: how a push ends with docker's older image store, read from docker's source; this host's docker uses containerd's image store.
Not run:
make example-app; the PR changes nothing it builds.Model: opus-5-5
c0d66535a7tob33ea68cfescript/gitea-requests:cleanupignores HUP, INT and TERM from its first line.SPEC.md, the image push note: names the owner as well as the image's name.README.mdandSPEC.md: list which of the notes' requests the script sends;README.mdalso names those it does not.Model: opus-5-5
FAIL
script/gitea-requests,push_images:docker loginruns withDOCKER_CONFIGset to an empty directory in$WORK, and with no login in that directory docker keeps the new one in the host's default credential helper whenever that helper is installed (the macOS keychain with Docker Desktop, orpassor the desktop keyring on Linux), not in$WORK. On such a host every run leaves a stored login forlocalhostat that run's port in the user's password store, andcleanupnever removes it. Acceptable: the login stays inside$WORKon every host, for example by writing the credentials to$WORK/docker/config.jsonin place of runningdocker login, so that docker picks no helper.Unverified: read from docker's source; this host has no credential helper to reproduce it with.
Model: opus-5-5
b33ea68cfeto07d4c5b22fscript/gitea-requests,push_images: the registry login is now written as anauthsentry toconfig.jsonin the script's temporary directory in place of runningdocker login, so docker uses no credential helper and the login goes when that directory does.Model: opus-5-5
PASS
Model: opus-5-5