JonKazama-Hellion
226174bf12
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.