57_WolveandClaude Opus 5
4852777c57
Upstream released v1.11.0 (e42ae7a, 2026-11-06): 42 commits, mostly
fixes, plus two WebUI features that add ~415 lines to explorer.html
(on-demand bucket size calculation, restore archived objects).
The series needed no content changes — the regenerated patches differ
from the v1.10.0 ones only in their `index <blob>..<blob>` lines, since
the de-brand edits sit above the regions upstream touched. Regenerating
them is still worthwhile: the v1.10.0 patches' pre-image blobs do not
exist in a v1.11.0 clone, so `git am --3way` could not use its 3-way
fallback and was silently applying them directly.
Verified before committing:
- round-trips from a clean clone to tree 8d509fe
- residual branding identical to the patched v1.10.0 tree (23
occurrences, same per-file spread, no regressions)
- all 5 light-mode Tailwind classes in the new explorer markup are
overridden in theme.css
- series touches only webui/; file count 1049 -> 1051
- goreleaser builds all 8 targets plus deb/rpm
- matrix accepts v1.11.0, refuses v1.10.0, PATCH_DIR still rebuilds
the archived series
v1.10.0 moves to patches/archive/ as *superseded*, not vulnerable: it is
the release carrying upstream's CVE-2026-111943 notice, and that fix
comes from the Go toolchain (>= 1.26.10 / 1.27.3) rather than from the
tag. The archive README and the top-level README now say so, instead of
implying every archived series predates a security fix.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.10.0/ |
0001-webui-debrand.patch, 0002-webui-dark-theme.patch |
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
Two different reasons, worth keeping straight:
v1.5.0throughv1.8.0predate the upstream CVE fixes announced in v1.10.0. Building them would publish known-vulnerable gateways under this project's release name.v1.10.0is archived only because it is superseded byv1.11.0, which carries 42 further upstream fixes. It is not vulnerable in the way the older sets are.
Either way 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.