Request
Please consider cutting an 8.1.1 patch release from stable-8.1.
Why
stable-8.1 already contains the fixes for four HIGH-severity advisories, but none of them
have reached a released artifact: v8.1.0 (2026-07-06) is still the only 8.1 release.
Anyone tracking the 8.1 line therefore runs a binary with all four, even though the 8.0 and
8.2 lines are clean (8.0.7 and 8.2.0 both ship the fixed dependency set).
Versions below were read directly from go.mod at each ref:
| Advisory |
Dependency |
v8.1.0 (released) |
Fixed in |
stable-8.1 today |
| CVE-2026-46600 |
golang.org/x/net |
v0.55.0 |
0.56.0 |
v0.57.0 ✅ |
| CVE-2026-56852 |
golang.org/x/text |
v0.38.0 |
0.39.0 |
v0.40.0 ✅ |
| GHSA-hrxh-6v49-42gf |
google.golang.org/grpc |
v1.81.1 |
1.82.1 |
v1.83.0 ✅ |
| CVE-2026-71556 |
github.com/go-git/go-git/v5 |
v5.19.1 |
5.19.2 |
v5.19.2 ✅ |
Nothing to fix on the dependency side
This is purely a release-cadence request — the work is already done. #12774
("chore: [stable-8.1] bump go packages", merged 2026-08-12) bumped every affected module,
and the branch is clearly maintained (backports through 2026-08-14, plus #12807 bumping
golang.org/x/image today). The fixes just need a tag.
Downstream impact
I maintain the container images in owncloud-docker/ocis.
Our Trivy gate scans the built ocis binary, so to keep publishing owncloud/ocis:8.1 at
all we have to carry all four advisories as suppressions in
v8/8.1/.trivyignore
(most recently CVE-2026-46600, in owncloud-docker/ocis#37 — it was breaking our nightly
build). Those entries are the only reason the 8.1 image is green, and they are exactly the
kind of suppression we would rather not ship. An 8.1.1 would let us drop all four.
For reference, the same scan on the 8.0.7 and 8.2.0 images is clean, and master is clean
too — 8.1 is the only line where fixes are sitting unreleased.
If 8.1 is not a maintained line
If the intent is that 8.1 users move to 8.2 rather than receive patches, please just say so
and close this — that is a perfectly good answer. We would then retire the 8.1 image tag
instead of maintaining the suppression list.
A note on the channel
SECURITY.md asks that vulnerabilities not be filed as public issues, and I want to be
explicit that I do not think this is one: every advisory here is already public, sits in a
public third-party dependency, and is already fixed on a public branch. Nothing
undisclosed is revealed, and the actual ask is about release timing. Happy to move this to
security.owncloud.com if you would prefer.
Request
Please consider cutting an 8.1.1 patch release from
stable-8.1.Why
stable-8.1already contains the fixes for four HIGH-severity advisories, but none of themhave reached a released artifact: v8.1.0 (2026-07-06) is still the only 8.1 release.
Anyone tracking the 8.1 line therefore runs a binary with all four, even though the 8.0 and
8.2 lines are clean (8.0.7 and 8.2.0 both ship the fixed dependency set).
Versions below were read directly from
go.modat each ref:stable-8.1todaygolang.org/x/netgolang.org/x/textgoogle.golang.org/grpcgithub.com/go-git/go-git/v5Nothing to fix on the dependency side
This is purely a release-cadence request — the work is already done. #12774
("chore: [stable-8.1] bump go packages", merged 2026-08-12) bumped every affected module,
and the branch is clearly maintained (backports through 2026-08-14, plus #12807 bumping
golang.org/x/imagetoday). The fixes just need a tag.Downstream impact
I maintain the container images in owncloud-docker/ocis.
Our Trivy gate scans the built
ocisbinary, so to keep publishingowncloud/ocis:8.1atall we have to carry all four advisories as suppressions in
v8/8.1/.trivyignore(most recently CVE-2026-46600, in owncloud-docker/ocis#37 — it was breaking our nightly
build). Those entries are the only reason the 8.1 image is green, and they are exactly the
kind of suppression we would rather not ship. An 8.1.1 would let us drop all four.
For reference, the same scan on the 8.0.7 and 8.2.0 images is clean, and
masteris cleantoo — 8.1 is the only line where fixes are sitting unreleased.
If 8.1 is not a maintained line
If the intent is that 8.1 users move to 8.2 rather than receive patches, please just say so
and close this — that is a perfectly good answer. We would then retire the
8.1image taginstead of maintaining the suppression list.
A note on the channel
SECURITY.md asks that vulnerabilities not be filed as public issues, and I want to be
explicit that I do not think this is one: every advisory here is already public, sits in a
public third-party dependency, and is already fixed on a public branch. Nothing
undisclosed is revealed, and the actual ask is about release timing. Happy to move this to
security.owncloud.com if you would prefer.