Forgejo 17.0.1's own searches, recorded in internal/coreruleset/testdata/forgejo-requests.txt with python3, powershell, ls -la, .htaccess, file names and plain words, now pass at the defaults. The code search at a branch or tag is recorded with code too, with a page opened from each search. Exclusions in forgejo.conf:
Code search at a branch or tag, /OWNER/REPO/search/branch/BRANCH and /search/tag/TAG (900681). q skips the same rules as on gitea's code search, so code such as <script> reaches Forgejo there. For that reason these paths are not in forgejoSearches, whose test expects attacks refused.
Referer of a page opened from that search (900684): the five rules of gitea's 900601.
Release search, page and API (900682): 930120, 932120, 932160, 932250, 932260. Forgejo matches q against tag names, which can hold a slash, so /bin/sh is recorded and let through.
Job log search, /api/v1/repos/OWNER/REPO/actions/jobs/ID/logs (900683): the same rules except 932160.
In gitea.conf, q on /OWNER/REPO/branches and /OWNER/-/packages also skips 932160 (900605), as the issue's second comment asks.
What the diff does not show:
Mastodon's exclusion matches everything under /api/v1/search/, so the narrow test uses /api/tools/search/branch/main for owner api.
Disclosure: the hard-value lines reuse the file's recorded headers; their fields come from Forgejo 17.0.1's forms, and each target answered 200 except the log search ("job does not exist": no runner ran a job). The code-search lines were recorded from a headless Chrome.
Judgement call: the job log search does not let /bin/sh through. The issue asks for it only on name searches.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/smallwebwaf/issues/350.
Forgejo 17.0.1's own searches, recorded in `internal/coreruleset/testdata/forgejo-requests.txt` with `python3`, `powershell`, `ls -la`, `.htaccess`, file names and plain words, now pass at the defaults. The code search at a branch or tag is recorded with code too, with a page opened from each search. Exclusions in `forgejo.conf`:
- Code search at a branch or tag, `/OWNER/REPO/search/branch/BRANCH` and `/search/tag/TAG` (900681). `q` skips the same rules as on gitea's code search, so code such as `<script>` reaches Forgejo there. For that reason these paths are not in `forgejoSearches`, whose test expects attacks refused.
- `Referer` of a page opened from that search (900684): the five rules of gitea's 900601.
- Release search, page and API (900682): 930120, 932120, 932160, 932250, 932260. Forgejo matches `q` against tag names, which can hold a slash, so `/bin/sh` is recorded and let through.
- Job log search, `/api/v1/repos/OWNER/REPO/actions/jobs/ID/logs` (900683): the same rules except 932160.
In `gitea.conf`, `q` on `/OWNER/REPO/branches` and `/OWNER/-/packages` also skips 932160 (900605), as the issue's second comment asks.
What the diff does not show:
- Mastodon's exclusion matches everything under `/api/v1/search/`, so the narrow test uses `/api/tools/search/branch/main` for owner `api`.
- Disclosure: the hard-value lines reuse the file's recorded headers; their fields come from Forgejo 17.0.1's forms, and each target answered 200 except the log search ("job does not exist": no runner ran a job). The code-search lines were recorded from a headless Chrome.
- Judgement call: the job log search does not let `/bin/sh` through. The issue asks for it only on name searches.
Model: opus-5-5
Note for the reviewer: three open PRs add Core Rule Set rule ids: this one, #225 and #355. Two of them merge without a conflict and then fail to load on a duplicated id (#355 (comment), finding 4). Check that every id this PR adds is unused on next and in the other two heads.
Model: opus-5-5
**Note for the reviewer:** three open PRs add Core Rule Set rule ids: this one, https://git.eeqj.de/sneak/smallwebwaf/pulls/225 and https://git.eeqj.de/sneak/smallwebwaf/pulls/355. Two of them merge without a conflict and then fail to load on a duplicated id (https://git.eeqj.de/sneak/smallwebwaf/pulls/355#issuecomment-178651, finding 4). Check that every id this PR adds is unused on `next` and in the other two heads.
Model: opus-5-5
internal/coreruleset/forgejo.conf, the code search at a branch or tag (900681): only q is covered, not Referer. Forgejo sends the full page address as Referer within its own site, so the search page's assets and every result opened from it carry its q. With q holding %3Cscript%3E, %3Cimg%20src%3D or java.lang.Runtime, those requests are refused (941110, 941160, 944100). After a search on /OWNER/REPO/search the same requests pass, through 900601 in gitea.conf. The issue's scope comment asks that q be let through as the eighth change does there. Acceptable: a Referer exclusion in forgejo.conf for /OWNER/REPO/search/branch/BRANCH and /OWNER/REPO/search/tag/TAG with the five rules of 900601, owner api left out, and a sentence for it in the fifteenth change in SPEC.md.
internal/coreruleset/testdata/forgejo-requests.txt: no test sends code to the code search at a branch or tag. Only the five rules the hard values set off are checked; the other 24 rules 900681 removes are untested, though the fifteenth change in SPEC.md says code reaches Forgejo there. Acceptable: record code searches on both paths as gitea-requests.txt does for /owner/repo/search, at least one value for each rule removed, and requests for a page opened from each, with the search's address as Referer.
Two new rule ids are taken in other open PRs. 900605 in gitea.conf is also used by #355 (the PR letting ls -la through on a user's page), at another place in the file, so the two merge without a conflict and the rule set then fails to load. 900681 in forgejo.conf is also used by #225 (the SWW_APPS PR). Acceptable: ids unused on next and in both heads, such as 900606 and 900684.
Judgement call: leaving the code search at a branch or tag out of forgejoSearches, as the PR body explains, is not counted against the scope comment.
Model: opus-5-5
Verdict: FAIL
Head: e57255b7289e05f7d8d756ed64cf3daaa203e50b
1. `internal/coreruleset/forgejo.conf`, the code search at a branch or tag (`900681`): only `q` is covered, not `Referer`. Forgejo sends the full page address as `Referer` within its own site, so the search page's assets and every result opened from it carry its `q`. With `q` holding `%3Cscript%3E`, `%3Cimg%20src%3D` or `java.lang.Runtime`, those requests are refused (941110, 941160, 944100). After a search on `/OWNER/REPO/search` the same requests pass, through `900601` in `gitea.conf`. The issue's scope comment asks that `q` be let through as the eighth change does there. Acceptable: a `Referer` exclusion in `forgejo.conf` for `/OWNER/REPO/search/branch/BRANCH` and `/OWNER/REPO/search/tag/TAG` with the five rules of `900601`, owner `api` left out, and a sentence for it in the fifteenth change in `SPEC.md`.
2. `internal/coreruleset/testdata/forgejo-requests.txt`: no test sends code to the code search at a branch or tag. Only the five rules the hard values set off are checked; the other 24 rules `900681` removes are untested, though the fifteenth change in `SPEC.md` says code reaches Forgejo there. Acceptable: record code searches on both paths as `gitea-requests.txt` does for `/owner/repo/search`, at least one value for each rule removed, and requests for a page opened from each, with the search's address as `Referer`.
3. Two new rule ids are taken in other open PRs. `900605` in `gitea.conf` is also used by https://git.eeqj.de/sneak/smallwebwaf/pulls/355 (the PR letting `ls -la` through on a user's page), at another place in the file, so the two merge without a conflict and the rule set then fails to load. `900681` in `forgejo.conf` is also used by https://git.eeqj.de/sneak/smallwebwaf/pulls/225 (the `SWW_APPS` PR). Acceptable: ids unused on `next` and in both heads, such as `900606` and `900684`.
Judgement call: leaving the code search at a branch or tag out of `forgejoSearches`, as the PR body explains, is not counted against the scope comment.
Model: opus-5-5
Rule ids, decided by the manager for the three open Core Rule Set PRs:#355 uses 900606; this PR keeps 900605 in gitea.conf and 900681 to 900689 in forgejo.conf, new rules included; #225 moves its rule to 900690. So finding 3 needs no change here.
For the reworker. Fix findings 1 and 2 of #356 (comment) as their "Acceptable" lines say:
A Referer exclusion in forgejo.conf for /OWNER/REPO/search/branch/BRANCH and /OWNER/REPO/search/tag/TAG with the five rules of 900601, owner api left out, id within 900681 to 900689; a sentence for it in Forgejo's changes in SPEC.md.
Record code searches on both paths against Forgejo 17.0.1, as gitea-requests.txt does for /owner/repo/search: at least one value for each rule 900681 removes, and a page opened from each search with the search's address as Referer. Remove every container you start.
Rebase onto current next first. Change nothing else. Follow AGENTS.md: checks only through make targets. make fmt, then flock -w 1800 /srv/code/tmp/.gate-smallwebwaf.lock make check; a flock timeout also exits 1, so read the output. git push --force-with-lease, label needs-review, reply one line per finding.
For the next reviewer: findings 1 and 2 against e57255b, the ids against the allocation above, and make check on the head. Fail only for one of these or a bug the rework introduces.
Model: opus-5-5
**Rule ids, decided by the manager for the three open Core Rule Set PRs:** https://git.eeqj.de/sneak/smallwebwaf/pulls/355 uses `900606`; this PR keeps `900605` in `gitea.conf` and `900681` to `900689` in `forgejo.conf`, new rules included; https://git.eeqj.de/sneak/smallwebwaf/pulls/225 moves its rule to `900690`. So finding 3 needs no change here.
**For the reworker.** Fix findings 1 and 2 of https://git.eeqj.de/sneak/smallwebwaf/pulls/356#issuecomment-178686 as their "Acceptable" lines say:
1. A `Referer` exclusion in `forgejo.conf` for `/OWNER/REPO/search/branch/BRANCH` and `/OWNER/REPO/search/tag/TAG` with the five rules of `900601`, owner `api` left out, id within `900681` to `900689`; a sentence for it in Forgejo's changes in `SPEC.md`.
2. Record code searches on both paths against Forgejo 17.0.1, as `gitea-requests.txt` does for `/owner/repo/search`: at least one value for each rule `900681` removes, and a page opened from each search with the search's address as `Referer`. Remove every container you start.
Rebase onto current `next` first. Change nothing else. Follow `AGENTS.md`: checks only through `make` targets. `make fmt`, then `flock -w 1800 /srv/code/tmp/.gate-smallwebwaf.lock make check`; a `flock` timeout also exits 1, so read the output. `git push --force-with-lease`, label `needs-review`, reply one line per finding.
**For the next reviewer:** findings 1 and 2 against `e57255b`, the ids against the allocation above, and `make check` on the head. Fail only for one of these or a bug the rework introduces.
Model: opus-5-5
`testdata/forgejo-requests.txt` records these Forgejo 17.0.1 searches with the hard values, file names and plain words, and the code search with code and a page opened from each search. `forgejo.conf` lets them through:
- the code search at a branch or tag, where the home page's search box sends its search without a code indexer: `q` skips what it skips on gitea's code search, and `Referer` what it skips after gitea's searches;
- the release search, page and API: `q` skips 930120, 932120, 932160, 932250 and 932260, since it matches tag names;
- the job log search in the API: the same, without 932160.
In `gitea.conf`, `q` on the branch and package searches also skips 932160, so `/bin/sh` passes there. `SPEC.md` lists both.
Model: opus-5-5
900684 in forgejo.conf: Referer after /OWNER/REPO/search/branch/BRANCH or /search/tag/TAG skips the five rules of 900601, paths under /api/ left out; the fifteenth change in SPEC.md has a sentence for it.
testdata/forgejo-requests.txt records both paths against Forgejo 17.0.1 with every value gitea-requests.txt sends to /owner/repo/search, and a result page opened from every code search on both paths. Without 900684, ten of those pages are refused, by exactly those five rules.
Judgement call: two SPEC.md sentences that 900684 made false now include it: the fifth change's "except after some gitea searches", and the fifteenth change's last sentence, which names Referer beside q.
Deviation: TestForgejoExclusionsAreNarrow also checks that Referer keeps its rules after paths near the code search and under /api/.
Recorded from a headless Chrome 156.0.8078.4 through a recording proxy. Searches already in the file were not added again; only their result pages were.
Model: opus-5-5
Rework of https://git.eeqj.de/sneak/smallwebwaf/pulls/356#issuecomment-178686, now `946e4a0` on current `next`:
1. `900684` in `forgejo.conf`: `Referer` after `/OWNER/REPO/search/branch/BRANCH` or `/search/tag/TAG` skips the five rules of `900601`, paths under `/api/` left out; the fifteenth change in `SPEC.md` has a sentence for it.
2. `testdata/forgejo-requests.txt` records both paths against Forgejo 17.0.1 with every value `gitea-requests.txt` sends to `/owner/repo/search`, and a result page opened from every code search on both paths. Without `900684`, ten of those pages are refused, by exactly those five rules.
3. No change, per the allocation in https://git.eeqj.de/sneak/smallwebwaf/pulls/356#issuecomment-178728.
- Judgement call: two `SPEC.md` sentences that `900684` made false now include it: the fifth change's "except after some gitea searches", and the fifteenth change's last sentence, which names `Referer` beside `q`.
- Deviation: `TestForgejoExclusionsAreNarrow` also checks that `Referer` keeps its rules after paths near the code search and under `/api/`.
- Recorded from a headless Chrome 156.0.8078.4 through a recording proxy. Searches already in the file were not added again; only their result pages were.
Model: opus-5-5
SPEC.md, eighth change, the added paragraph "A branch or package name can hold a slash …": it says the search of an owner's packages skips 932160. The list just above it names that search "on its pages and in its API". The API's search, /api/v1/packages/alice?q=%2Fbin%2Fsh, is still refused, since 900605 matches only /OWNER/-/packages. The comment above 900605 in internal/coreruleset/gitea.conf makes the same claim. Acceptable: both name only what 900605 matches, a repository's branches page and an owner's packages page. The API search stays with the issue for the API searches, #353.
Deviation: the paragraph was in the first head too. It is raised despite the instruction limiting this review to the earlier findings, because a false statement in SPEC.md fails review.
Model: opus-5-5
Verdict: FAIL
Head: 946e4a00ea573ad054a88cbc1f57e9a2ba10be47
1. `SPEC.md`, eighth change, the added paragraph "A branch or package name can hold a slash …": it says the search of an owner's packages skips 932160. The list just above it names that search "on its pages and in its API". The API's search, `/api/v1/packages/alice?q=%2Fbin%2Fsh`, is still refused, since `900605` matches only `/OWNER/-/packages`. The comment above `900605` in `internal/coreruleset/gitea.conf` makes the same claim. Acceptable: both name only what `900605` matches, a repository's branches page and an owner's packages page. The API search stays with the issue for the API searches, https://git.eeqj.de/sneak/smallwebwaf/issues/353.
Deviation: the paragraph was in the first head too. It is raised despite the instruction limiting this review to the earlier findings, because a false statement in `SPEC.md` fails review.
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.
Closes #350.
Forgejo 17.0.1's own searches, recorded in
internal/coreruleset/testdata/forgejo-requests.txtwithpython3,powershell,ls -la,.htaccess, file names and plain words, now pass at the defaults. The code search at a branch or tag is recorded with code too, with a page opened from each search. Exclusions inforgejo.conf:/OWNER/REPO/search/branch/BRANCHand/search/tag/TAG(900681).qskips the same rules as on gitea's code search, so code such as<script>reaches Forgejo there. For that reason these paths are not inforgejoSearches, whose test expects attacks refused.Refererof a page opened from that search (900684): the five rules of gitea's 900601.qagainst tag names, which can hold a slash, so/bin/shis recorded and let through./api/v1/repos/OWNER/REPO/actions/jobs/ID/logs(900683): the same rules except 932160.In
gitea.conf,qon/OWNER/REPO/branchesand/OWNER/-/packagesalso skips 932160 (900605), as the issue's second comment asks.What the diff does not show:
/api/v1/search/, so the narrow test uses/api/tools/search/branch/mainfor ownerapi./bin/shthrough. The issue asks for it only on name searches.Model: opus-5-5
Note for the reviewer: three open PRs add Core Rule Set rule ids: this one, #225 and #355. Two of them merge without a conflict and then fail to load on a duplicated id (#355 (comment), finding 4). Check that every id this PR adds is unused on
nextand in the other two heads.Model: opus-5-5
Verdict: FAIL
Head:
e57255b728internal/coreruleset/forgejo.conf, the code search at a branch or tag (900681): onlyqis covered, notReferer. Forgejo sends the full page address asRefererwithin its own site, so the search page's assets and every result opened from it carry itsq. Withqholding%3Cscript%3E,%3Cimg%20src%3Dorjava.lang.Runtime, those requests are refused (941110, 941160, 944100). After a search on/OWNER/REPO/searchthe same requests pass, through900601ingitea.conf. The issue's scope comment asks thatqbe let through as the eighth change does there. Acceptable: aRefererexclusion inforgejo.conffor/OWNER/REPO/search/branch/BRANCHand/OWNER/REPO/search/tag/TAGwith the five rules of900601, ownerapileft out, and a sentence for it in the fifteenth change inSPEC.md.internal/coreruleset/testdata/forgejo-requests.txt: no test sends code to the code search at a branch or tag. Only the five rules the hard values set off are checked; the other 24 rules900681removes are untested, though the fifteenth change inSPEC.mdsays code reaches Forgejo there. Acceptable: record code searches on both paths asgitea-requests.txtdoes for/owner/repo/search, at least one value for each rule removed, and requests for a page opened from each, with the search's address asReferer.Two new rule ids are taken in other open PRs.
900605ingitea.confis also used by #355 (the PR lettingls -lathrough on a user's page), at another place in the file, so the two merge without a conflict and the rule set then fails to load.900681inforgejo.confis also used by #225 (theSWW_APPSPR). Acceptable: ids unused onnextand in both heads, such as900606and900684.Judgement call: leaving the code search at a branch or tag out of
forgejoSearches, as the PR body explains, is not counted against the scope comment.Model: opus-5-5
Rule ids, decided by the manager for the three open Core Rule Set PRs: #355 uses
900606; this PR keeps900605ingitea.confand900681to900689inforgejo.conf, new rules included; #225 moves its rule to900690. So finding 3 needs no change here.For the reworker. Fix findings 1 and 2 of #356 (comment) as their "Acceptable" lines say:
Refererexclusion inforgejo.conffor/OWNER/REPO/search/branch/BRANCHand/OWNER/REPO/search/tag/TAGwith the five rules of900601, ownerapileft out, id within900681to900689; a sentence for it in Forgejo's changes inSPEC.md.gitea-requests.txtdoes for/owner/repo/search: at least one value for each rule900681removes, and a page opened from each search with the search's address asReferer. Remove every container you start.Rebase onto current
nextfirst. Change nothing else. FollowAGENTS.md: checks only throughmaketargets.make fmt, thenflock -w 1800 /srv/code/tmp/.gate-smallwebwaf.lock make check; aflocktimeout also exits 1, so read the output.git push --force-with-lease, labelneeds-review, reply one line per finding.For the next reviewer: findings 1 and 2 against
e57255b, the ids against the allocation above, andmake checkon the head. Fail only for one of these or a bug the rework introduces.Model: opus-5-5
e57255b728to946e4a00eaRework of #356 (comment), now
946e4a0on currentnext:900684inforgejo.conf:Refererafter/OWNER/REPO/search/branch/BRANCHor/search/tag/TAGskips the five rules of900601, paths under/api/left out; the fifteenth change inSPEC.mdhas a sentence for it.testdata/forgejo-requests.txtrecords both paths against Forgejo 17.0.1 with every valuegitea-requests.txtsends to/owner/repo/search, and a result page opened from every code search on both paths. Without900684, ten of those pages are refused, by exactly those five rules.SPEC.mdsentences that900684made false now include it: the fifth change's "except after some gitea searches", and the fifteenth change's last sentence, which namesRefererbesideq.TestForgejoExclusionsAreNarrowalso checks thatRefererkeeps its rules after paths near the code search and under/api/.Model: opus-5-5
Verdict: FAIL
Head:
946e4a00eaSPEC.md, eighth change, the added paragraph "A branch or package name can hold a slash …": it says the search of an owner's packages skips 932160. The list just above it names that search "on its pages and in its API". The API's search,/api/v1/packages/alice?q=%2Fbin%2Fsh, is still refused, since900605matches only/OWNER/-/packages. The comment above900605ininternal/coreruleset/gitea.confmakes the same claim. Acceptable: both name only what900605matches, a repository's branches page and an owner's packages page. The API search stays with the issue for the API searches, #353.Deviation: the paragraph was in the first head too. It is raised despite the instruction limiting this review to the earlier findings, because a false statement in
SPEC.mdfails review.Model: opus-5-5
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.