57_WolveandClaude Opus 5
73d5d2f3f1
v1.10.0 carries upstream CVE fixes that the older releases predate, so stop building them. Their series move to patches/archive/<tag>/ rather than being deleted — still available for a deliberate rebuild, just not shipped — and ci/support-matrix.yaml now lists v1.10.0 alone. Dropping the matrix entries was not enough on its own. Two gaps made "not built" untrue: * apply-patches.sh only consulted the matrix `if command -v yq`, and the stock golang CI container has no yq — so in CI the registry was never actually read. The tag fell through to patches/<tag> every time. * An empty or missing patch directory was a warning and exit 0, i.e. "building vanilla upstream". Archiving the directories would therefore have made a dispatch for v1.8.0 publish an un-de-branded, unpatched, CVE-vulnerable build under this project's release name — the exact outcome we are trying to prevent. So the matrix is now an enforced allowlist: a tag it does not list exits 1, as does a patch directory with no patches in it. It is parsed with yq when present and with a small awk parse otherwise, so the allowlist holds in the CI container too. If the parse ever broke, an unmatched tag is refused rather than built, so the failure mode stays closed. PATCH_DIR remains the one bypass, and is now the documented way to rebuild an archived series on purpose. That path also needed a fix: the patch list is globbed before we cd into the source tree, so a relative PATCH_DIR — the form the new error message suggests — globbed fine and then failed in git am. PATCH_DIR is now resolved to an absolute path, with a missing directory reported as such. Also re-pointed the runnable examples in README.md, ci/run.sh and the workflow's dispatch hint from v1.5.0 to v1.10.0; following them verbatim would now hit the refusal. Verified by exercising every branch: v1.10.0 applies; v1.8.0 is refused with exit 1; PATCH_DIR=patches/archive/v1.8.0 rebuilds the archived series; an empty directory and a nonexistent one are both refused. The awk parser was checked against defaulted `patches:` fields, several tags sharing one directory, and comment lines containing decoy `- tag:` text. All seven archived patch files are recorded as pure renames. Note: existing published releases for the retired versions stay downloadable until deleted by hand in Gitea. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
1.9 KiB
Archived patch series
Patch sets for upstream versitygw releases this project no longer builds. They are kept for reference and reproducibility, not because they are safe to ship.
| Patch set | Contents |
|---|---|
v1.8.0/ |
0001-webui-debrand.patch, 0002-webui-dark-theme.patch |
v1.7.0/ |
0001-webui-debrand.patch, 0002-webui-dark-theme.patch |
v1.6.0/ |
0001-webui-debrand.patch, 0002-webui-dark-theme.patch |
v1.5.0/ |
0001-webui-debrand.patch |
Why these are not built
v1.10.0 carries upstream CVE fixes that these releases predate.
Building them would publish known-vulnerable gateways under this
project's release name, so their tags were removed from
ci/support-matrix.yaml. That matrix is an allowlist —
ci/apply-patches.sh refuses a tag it does not list, so neither a tag
push nor a workflow dispatch can rebuild one by accident.
Releases already published for these versions are not removed by archiving the patches. Delete them by hand in Gitea if they should no longer be downloadable.
Rebuilding one anyway
If you genuinely need an archived build — reproducing an old report,
bisecting a regression — point PATCH_DIR at it instead of re-adding
it to the matrix:
VGW_TAG=v1.8.0 bash ci/clone-source.sh
PATCH_DIR=patches/archive/v1.8.0 VGW_TAG=v1.8.0 bash ci/apply-patches.sh
VGW_TAG=v1.8.0 bash ci/build.sh
Don't publish the result to a release unless you mean to ship a vulnerable build.
Un-archiving
To return a version to the supported set, git mv its directory back
to patches/<tag>/ and add its row to ci/support-matrix.yaml. Rebase
the series onto the tag first if upstream has moved — see
../../docs/multi-version-pipeline.md.