Semgrep blocks on gha-curl-pipe-shell, and it is pointing at the publish step
added an hour ago. The rule exists for `curl https://…/install.sh | bash`:
remote content reaching an interpreter. What this actually did was pipe a JSON
response into a python3 -c inline script -- the interpreter and its program both
live in the workflow file, and the server only ever supplied data.
A false positive, then, but the rule cannot see the difference between an
interpreter reading a program from stdin and one reading data, and neither can
the next person to read the step. Responses go to a file and are read from
there. Same shape as the finding suggests, and worth having anyway: a response
that is on disk can be looked at when a call misbehaves, instead of vanishing
into a pipe.
Verified by falsification rather than by a green run: the same ruleset against
the previous revision of this file reports 1 blocking finding, against this one
zero. Without that check a passing scan only proves the rule was not loaded.
The v2.0.0 tag built fine and then died on its last step: gitea.com's
release-action declares `using: go`, the runner has to compile it, and act
cannot -- exec: "go": executable file not found, exit 127, after a green build.
The zip existed and never got attached, so the Discord announcement went out
while the download link pointed at nothing.
This is a known failure. It was diagnosed on another repo in June and the note
from then says in as many words that this repo carries the same pattern and
should migrate before its next release. It did not, and here we are.
The publish step is a plain curl call against the Gitea API now, running in the
job image with curl and python3, independent of go, the action cache, and
whatever @main happens to point at. Idempotent by design: a re-run reuses an
existing release and replaces the asset rather than failing on the duplicate,
which is exactly the state a recovery run finds.
MessagePack moves from the 3.1.4 floor to 3.1.7, which is what the trivy scan
was failing on. The range already allowed it -- NuGet resolves the lower bound
of a range, and trivy reads it the same way, so the floor is the version that
counts. The advisories are recursion depth in Skip and an LZ4 decompression
fault, both reachable only through crafted input; this plugin serialises its own
payloads and reads back its own bytes from a local database, so the practical
exposure is someone who already has write access to the file. Lifted because it
costs nothing and a scan that stays red for a known-harmless reason is how a real
finding gets missed later.
Rueckbau des Inline-Workarounds. Der Runner konnte den reusable workflow
nicht mehr laden, weil git fetch gegen die Forge crashte. Ursache war kein
Bug, sondern eine Kompromittierung ueber CVE-2026-59774: ein injizierter
packObjectsHook ersetzte git pack-objects durch einen Malware-Dropper.
Gitea laeuft jetzt auf 1.27.2, der Hook ist entfernt, fetch funktioniert
wieder. Die Scan-Definition liegt damit wieder an einer Stelle statt in
sieben Dateien. Details: Obsidian "Projekte/Hellion Forge/Forge
Security-Incident 2026-08-15.md".
act_runner laedt reusable workflows per git-clone ueber HTTPS. Dieser Pfad
ist auf der Forge seit 2026-08-12 defekt (git upload-pack --stateless-rpc
bricht mit BUG "packfile_uris requires sideband-all" ab). Die Scans liefen
bisher nur ueber eine im Juni gecachte Kopie im Runner.
Der Scan steht jetzt vollstaendig in dieser Datei, der Quellstand kommt als
tar-Archiv statt ueber actions/checkout. Zurueckbauen, sobald git fetch
ueber HTTPS wieder funktioniert.
Both the DE and EN embed carried the same release url, which makes
Discord merge url-identical embeds and render only the first embed's
description. The EN block was posted and stored but never shown, so
every auto-announce from v1.4.6 onward displayed German only.
Drop the url from the EN embed so Discord stacks both as separate
cards with both descriptions visible.
Pull in the refreshed linter and tooling configs (editorconfig,
gitignore, gitattributes, prettierignore, prettierrc, markdownlint,
yamllint, env.example, dotnet-tools) and run prettier and markdownlint
in --fix / --write mode across the repo so the existing tree matches
the new rules.
- prettier 2-space indent on yaml/yml and json overrides, asterisk
strong, underscore emphasis, proseWrap always
- markdownlint MD007 indent aligned to 2 and MD049 to underscore so
prettier output stays passing
- preflight Block F also ignores CLAUDE.md (gitignored personal file)
- prettierignore extended to keep HellionChat.yaml manifest and the
NuGet packages.lock.json out of the formatter
No semantic content changed; csharpier, build, full build-suite
(729/729) and the new prettier/markdownlint/yamllint checks all green.
The release-action@main reads GITHUB_REF directly and rejects anything
that doesn't start with refs/tags/. The previous workflow tried to work
around this by passing tag_name as an action input, but the action's
action.yml never declared tag_name (or body_path) - both inputs were
silently ignored, which is why every Gitea release since v1.4.1 was
published with an empty body.
Changes:
- New "Validate tag ref" step fails fast with a clear message when the
workflow is dispatched from a branch ref instead of a tag ref.
- workflow_dispatch.inputs.tag dropped; recovery now means picking the
tag from Gitea's Ref dropdown so GITHUB_REF lines up with refs/tags/.
- release-body.md is re-emitted as a step output and passed via body:
(the input the action actually reads) instead of body_path.
- tag_name input removed from the action call - the action derives the
tag from GITHUB_REF_NAME on its own.
Both workflows looked for "**Hellion Chat <version>" as the changelog
subblock header, but the yaml convention is "**v<version> — <subtitle>"
(matches verify-changelog-sync.sh and the slim-rule grep). Plus the
indent-strip was 2 spaces, but prettier writes the changelog block with
4-space indent. Both regressions silently failed every release-workflow
run since the format change — likely why v1.4.3 was released manually.
Sync header marker to "**v$version " and indent-strip to 4 spaces in
both files.
Gitea Actions reads exclusively from .gitea/workflows/, not from
.github/workflows/. Since the cutover in v1.4.3 only the security
workflow has been running — release and forge-announce silently sat in
the wrong directory and never fired on any tag push. v1.4.3 must have
been released manually.
Move build, release and forge-announce yamls to .gitea/workflows/. The
.github/forge-posts/ and .github/release-footer.md data files stay where
they are; the workflows reference them by repo-relative path and that
keeps working.
For the v1.4.4 backfill: workflow_dispatch via the Gitea web UI with
tag=v1.4.4 will run release.yml + forge-announce.yml against the tagged
tree (which doesn't contain this migration). The dispatch yaml itself
is read from the default branch, not the tag, so the missing yamls in
the v1.4.4 tag tree don't matter.
Add .prettierrc.json, .markdownlint.json, .yamllint.yaml, .gitattributes
Run CSharpier, Prettier and markdownlint across the entire codebase.
No logic changes — formatting, using order and line endings only.
Semgrep rule IDs follow the pattern <pack>.<rule>. The pack name is
csharp.lang.security.sqli.csharp-sqli and the rule inside it is also
called csharp-sqli, so the full ID needs the trailing .csharp-sqli
again. Without it the exclude flag silently filters a different
subset of rules and the actual rule still runs.
Semgrep flags eight CommandText-with-string-interpolation call sites
in MessageStore.cs as SQL-injection patterns. All are safe in this
context: table names and clause fragments come from internal code
constants, the actual values are bound via SqlParameter, and the
plugin SQL surface is local-only with no external input vector.
CodeQL would not flag these because it does dataflow analysis and
sees the constants. Semgrep only matches patterns. Excluding the rule
for this repo only via the new semgrep-exclude-rules input keeps the
rule active for the other Hellion repos where it might catch real
issues (e.g. the web apps).
Calls JonKazama-Hellion/security-workflows for Semgrep SAST + Trivy
filesystem vulnerability scan. Runs on push to main/master, on every
PR, and weekly Monday 06:00 UTC.
JonKazama-Hellion
renovate-bot