Fully merged into main. git rev-list --left-right --count main...origin/feat/initial-site reports zero commits unique to the branch; it
was merged by #2 back in February and has had no activity since. It is also
still listed as a push trigger in .gitea/workflows/deploy.yml, which #7
removes.
security-audit — needs your call
Seven commits not on main, from an old security exercise:
6c930bf cleanup: remove recon payloads
4919779 escape attempt via docker socket
1fd7dd2 recon v5: set +e
5965b69 recon v4
4b114c9 recon v3: simpler posting
582a3ba recon v2: post results to issue
ff1a646 Add security recon workflow
The only file it touches is .gitea/workflows/security-recon.yml. At the
branch tip that file is harmless — the payloads were stripped by 6c930bf and
what remains is a placeholder step echoing "Security audit complete. See issue
#3." (Issue #3 no longer exists in this tracker.) The earlier commits in the
branch do still contain the recon and docker-socket-escape payloads in history.
The workflow triggers only on push to security-audit, so it is dormant as
long as nobody pushes to that branch. It is not a live risk, but it is a live trigger sitting on a branch nobody is watching, and the intermediate commits
are exactly the kind of thing that should not linger in a public repo without a
reason.
I am not deleting this one unilaterally — it is unmerged history from what
looks like a deliberate exercise, and destroying it is not reversible from the
tracker side.
Options for security-audit
Option A — delete it (recommended). The exercise is over, the findings are
not recorded anywhere in this repo, and the branch's only artifact is a
placeholder. If the results matter, they belong in an issue or a doc, not in a
dangling branch.
Option B — keep it, but neuter the trigger. Push one commit to the branch
removing .gitea/workflows/security-recon.yml entirely, so the history is
preserved but no workflow can ever fire from it.
Option C — keep it as-is. Only if you have a specific reason to want that
history reachable and are comfortable with the dormant trigger.
My recommendation: Option A.
Definition of done
origin/feat/initial-site is deleted. (No decision needed; it is fully
merged. Do this only after #7 has landed, so deploy.yml no longer
references it.)
origin/security-audit is handled per your answer above.
git branch -r shows only origin/main (plus origin/HEAD).
The Gitea branch list matches.
Note
This is a remote-administration task, not a code change — there is no PR to
open and no make check to run. It will be executed directly against the
remote once #7 has landed and you have answered on security-audit.
Assigning to @sneak for the security-audit decision.
## Problem
Two dead branches are still on the remote.
### `feat/initial-site` — safe to delete
Fully merged into `main`. `git rev-list --left-right --count
main...origin/feat/initial-site` reports zero commits unique to the branch; it
was merged by #2 back in February and has had no activity since. It is also
still listed as a push trigger in `.gitea/workflows/deploy.yml`, which #7
removes.
### `security-audit` — needs your call
Seven commits not on `main`, from an old security exercise:
```
6c930bf cleanup: remove recon payloads
4919779 escape attempt via docker socket
1fd7dd2 recon v5: set +e
5965b69 recon v4
4b114c9 recon v3: simpler posting
582a3ba recon v2: post results to issue
ff1a646 Add security recon workflow
```
The only file it touches is `.gitea/workflows/security-recon.yml`. At the
branch tip that file is harmless — the payloads were stripped by `6c930bf` and
what remains is a placeholder step echoing "Security audit complete. See issue
#3." (Issue #3 no longer exists in this tracker.) The earlier commits in the
branch do still contain the recon and docker-socket-escape payloads in history.
The workflow triggers only on `push` to `security-audit`, so it is dormant as
long as nobody pushes to that branch. It is not a live risk, but it is a live
*trigger* sitting on a branch nobody is watching, and the intermediate commits
are exactly the kind of thing that should not linger in a public repo without a
reason.
**I am not deleting this one unilaterally** — it is unmerged history from what
looks like a deliberate exercise, and destroying it is not reversible from the
tracker side.
## Options for `security-audit`
**Option A — delete it (recommended).** The exercise is over, the findings are
not recorded anywhere in this repo, and the branch's only artifact is a
placeholder. If the results matter, they belong in an issue or a doc, not in a
dangling branch.
**Option B — keep it, but neuter the trigger.** Push one commit to the branch
removing `.gitea/workflows/security-recon.yml` entirely, so the history is
preserved but no workflow can ever fire from it.
**Option C — keep it as-is.** Only if you have a specific reason to want that
history reachable and are comfortable with the dormant trigger.
**My recommendation: Option A.**
## Definition of done
1. `origin/feat/initial-site` is deleted. (No decision needed; it is fully
merged. Do this only after #7 has landed, so `deploy.yml` no longer
references it.)
2. `origin/security-audit` is handled per your answer above.
3. `git branch -r` shows only `origin/main` (plus `origin/HEAD`).
4. The Gitea branch list matches.
## Note
This is a remote-administration task, not a code change — there is no PR to
open and no `make check` to run. It will be executed directly against the
remote once #7 has landed and you have answered on `security-audit`.
Assigning to @sneak for the `security-audit` decision.
sneak
was assigned by clawbot2026-08-09 03:44:28 +02:00
Manager note — DoD item 1 is done. feat/initial-site is deleted.
It was safe and needed no decision: zero commits unique to the branch, merged
via #2 in February. The only thing holding it was the push trigger in deploy.yml, and that was removed when #7 merged (PR #17, now on main), so
deleting it can no longer affect any workflow.
Also deleted pin-deploy-workflow-refs, the merged branch from PR #17. Not
part of this issue's scope, just routine cleanup of a branch that has served
its purpose.
Remaining branches on the remote: main and security-audit.
Still blocked on @sneak: what to do with security-audit. Options and my
recommendation are in the issue body above; short version is that it holds
seven unmerged commits from an old recon exercise plus a workflow that fires on
push to that branch, the tip is a harmless placeholder, and I recommend
deleting it (Option A). I am not destroying unmerged history without your
answer. This issue stays open and assigned to you until then.
Manager note — DoD item 1 is done. `feat/initial-site` is deleted.
It was safe and needed no decision: zero commits unique to the branch, merged
via #2 in February. The only thing holding it was the push trigger in
`deploy.yml`, and that was removed when #7 merged (PR #17, now on `main`), so
deleting it can no longer affect any workflow.
Also deleted `pin-deploy-workflow-refs`, the merged branch from PR #17. Not
part of this issue's scope, just routine cleanup of a branch that has served
its purpose.
Remaining branches on the remote: `main` and `security-audit`.
**Still blocked on @sneak: what to do with `security-audit`.** Options and my
recommendation are in the issue body above; short version is that it holds
seven unmerged commits from an old recon exercise plus a workflow that fires on
push to that branch, the tip is a harmless placeholder, and I recommend
deleting it (Option A). I am not destroying unmerged history without your
answer. This issue stays open and assigned to you until then.
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.
Problem
Two dead branches are still on the remote.
feat/initial-site— safe to deleteFully merged into
main.git rev-list --left-right --count main...origin/feat/initial-sitereports zero commits unique to the branch; itwas merged by #2 back in February and has had no activity since. It is also
still listed as a push trigger in
.gitea/workflows/deploy.yml, which #7removes.
security-audit— needs your callSeven commits not on
main, from an old security exercise:The only file it touches is
.gitea/workflows/security-recon.yml. At thebranch tip that file is harmless — the payloads were stripped by
6c930bfandwhat remains is a placeholder step echoing "Security audit complete. See issue
#3." (Issue #3 no longer exists in this tracker.) The earlier commits in the
branch do still contain the recon and docker-socket-escape payloads in history.
The workflow triggers only on
pushtosecurity-audit, so it is dormant aslong as nobody pushes to that branch. It is not a live risk, but it is a live
trigger sitting on a branch nobody is watching, and the intermediate commits
are exactly the kind of thing that should not linger in a public repo without a
reason.
I am not deleting this one unilaterally — it is unmerged history from what
looks like a deliberate exercise, and destroying it is not reversible from the
tracker side.
Options for
security-auditOption A — delete it (recommended). The exercise is over, the findings are
not recorded anywhere in this repo, and the branch's only artifact is a
placeholder. If the results matter, they belong in an issue or a doc, not in a
dangling branch.
Option B — keep it, but neuter the trigger. Push one commit to the branch
removing
.gitea/workflows/security-recon.ymlentirely, so the history ispreserved but no workflow can ever fire from it.
Option C — keep it as-is. Only if you have a specific reason to want that
history reachable and are comfortable with the dormant trigger.
My recommendation: Option A.
Definition of done
origin/feat/initial-siteis deleted. (No decision needed; it is fullymerged. Do this only after #7 has landed, so
deploy.ymlno longerreferences it.)
origin/security-auditis handled per your answer above.git branch -rshows onlyorigin/main(plusorigin/HEAD).Note
This is a remote-administration task, not a code change — there is no PR to
open and no
make checkto run. It will be executed directly against theremote once #7 has landed and you have answered on
security-audit.Assigning to @sneak for the
security-auditdecision.Manager note — DoD item 1 is done.
feat/initial-siteis deleted.It was safe and needed no decision: zero commits unique to the branch, merged
via #2 in February. The only thing holding it was the push trigger in
deploy.yml, and that was removed when #7 merged (PR #17, now onmain), sodeleting it can no longer affect any workflow.
Also deleted
pin-deploy-workflow-refs, the merged branch from PR #17. Notpart of this issue's scope, just routine cleanup of a branch that has served
its purpose.
Remaining branches on the remote:
mainandsecurity-audit.Still blocked on @sneak: what to do with
security-audit. Options and myrecommendation are in the issue body above; short version is that it holds
seven unmerged commits from an old recon exercise plus a workflow that fires on
push to that branch, the tip is a harmless placeholder, and I recommend
deleting it (Option A). I am not destroying unmerged history without your
answer. This issue stays open and assigned to you until then.