Set the chart's placeholder version to 0.10.2

Cosmetic, as in e78f494 and 4cec26e. `make helm-package` passes --version and --app-version from the tag, so neither field decides anything about what release.yaml publishes. Done anyway because a tree heading for v0.10.2 that still says 0.10.1 tells a reader something false. appVersion keeps the v, per APPVERSION_PREFIX in .release.conf.
Move x/crypto to v0.55.0, clear of the ssh CVEs
2026-09-19 18:05:06 +02:00 · 2026-09-19 18:05:06 +02:00 · 2026-09-19 17:56:20 +02:00 · 2026-09-19 17:56:20 +02:00
3 changed files with 9 additions and 9 deletions
@@ -15,5 +15,5 @@ type: application
 # appVersion and image.tag in values.yaml no longer agree, and that is not an oversight:
 # image.tag stays "latest", which is what a local install actually pulls. appVersion is
 # metadata and drives nothing.
-version: 0.10.0
-appVersion: "v0.10.0"
+version: 0.10.2
+appVersion: "v0.10.2"
@@ -1,10 +1,10 @@
 module git.ryuvia.com/niklas/terdut-server

-go 1.26.0
+go 1.25.9

 require (
 	github.com/go-chi/chi/v5 v5.2.5
-	golang.org/x/crypto v0.57.0
+	golang.org/x/crypto v0.55.0
 	modernc.org/sqlite v1.50.1
 )

@@ -14,7 +14,7 @@ require (
 	github.com/mattn/go-isatty v0.0.20 // indirect
 	github.com/ncruces/go-strftime v1.0.0 // indirect
 	github.com/remyoudompheng/bigfft v0.0.0-20230129092748-24d4a6f8daec // indirect
-	golang.org/x/sys v0.48.0 // indirect
+	golang.org/x/sys v0.47.0 // indirect
 	modernc.org/libc v1.72.3 // indirect
 	modernc.org/mathutil v1.7.1 // indirect
 	modernc.org/memory v1.11.0 // indirect
@@ -14,15 +14,15 @@ github.com/ncruces/go-strftime v1.0.0 h1:HMFp8mLCTPp341M/ZnA4qaf7ZlsbTc+miZjCLOF
 github.com/ncruces/go-strftime v1.0.0/go.mod h1:Fwc5htZGVVkseilnfgOVb9mKy6w1naJmn9CehxcKcls=
 github.com/remyoudompheng/bigfft v0.0.0-20230129092748-24d4a6f8daec h1:W09IVJc94icq4NjY3clb7Lk8O1qJ8BdBEF8z0ibU0rE=
 github.com/remyoudompheng/bigfft v0.0.0-20230129092748-24d4a6f8daec/go.mod h1:qqbHyh8v60DhA7CoWK5oRCqLrMHRGoxYCSS9EjAz6Eo=
-golang.org/x/crypto v0.57.0 h1:3ZVCjf8Ggz7zneR/EHRVx68Ctf+2pmIMP2UFhh9cC6M=
-golang.org/x/crypto v0.57.0/go.mod h1:Fdz0i5U6CoizGwLda9DttjSk6qlZo25zYNtR+ycvuZA=
+golang.org/x/crypto v0.55.0 h1:+KWHjbgOaAQ66dh/YlkZKHlz9ZUlq61AFirAR9ntP8M=
+golang.org/x/crypto v0.55.0/go.mod h1:uq0V9dE/fzQuJtbnL+2EhWOE63vo164FY8xqEnV9xis=
 golang.org/x/mod v0.33.0 h1:tHFzIWbBifEmbwtGz65eaWyGiGZatSrT9prnU8DbVL8=
 golang.org/x/mod v0.33.0/go.mod h1:swjeQEj+6r7fODbD2cqrnje9PnziFuw4bmLbBZFrQ5w=
 golang.org/x/sync v0.20.0 h1:e0PTpb7pjO8GAtTs2dQ6jYa5BWYlMuX047Dco/pItO4=
 golang.org/x/sync v0.20.0/go.mod h1:9xrNwdLfx4jkKbNva9FpL6vEN7evnE43NNNJQ2LF3+0=
 golang.org/x/sys v0.6.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg=
-golang.org/x/sys v0.48.0 h1:bbX/i/6MgT9BVLM9RT1thmxL04yeTAhbEz4SyadbXoo=
-golang.org/x/sys v0.48.0/go.mod h1:hNLxWAXmnKAxqDtdwIYC4bM9oQPEecfsnNMuSxOs3og=
+golang.org/x/sys v0.47.0 h1:o7XGOvZQCADBQQ4Y7VNq2dRWQR7JmOUW8Kxx4ZsNgWs=
+golang.org/x/sys v0.47.0/go.mod h1:4GL1E5IUh+htKOUEOaiffhrAeqysfVGipDYzABqnCmw=
 golang.org/x/tools v0.42.0 h1:uNgphsn75Tdz5Ji2q36v/nsFSfR/9BRFvqhGBaJGd5k=
 golang.org/x/tools v0.42.0/go.mod h1:Ma6lCIwGZvHK6XtgbswSoWroEkhugApmsXyrUmBhfr0=
 modernc.org/cc/v4 v4.28.2 h1:3tQ0lf2ADtoby2EtSP+J7IE2SHwEJdP8ioR59wx7XpY=
Author	SHA1	Message	Date
Niklas Ye	989425e550	Set the chart's placeholder version to 0.10.2 CI / chart (push) Successful in 1s Details CI / security (push) Successful in 28s Details CI / test (push) Successful in 2m13s Details Release / test (push) Successful in 1m9s Details Release / chart (push) Successful in 2s Details Release / binaries (push) Successful in 1m41s Details Release / image (push) Successful in 1m42s Details Release / scan-image (push) Successful in 2s Details Cosmetic, as in `e78f494` and `4cec26e`. `make helm-package` passes --version and --app-version from the tag, so neither field decides anything about what release.yaml publishes. Done anyway because a tree heading for v0.10.2 that still says 0.10.1 tells a reader something false. appVersion keeps the v, per APPVERSION_PREFIX in .release.conf.	2026-09-19 18:05:06 +02:00
Niklas Ye	5b1ab2c568	Move x/crypto to v0.55.0, clear of the ssh CVEs v0.10.1's image published, but scan-image refused it. trivy reports ten HIGH advisories against golang.org/x/crypto v0.49.0, CVE-2026-39828 through CVE-2026-56854, all of them in x/crypto/ssh and its agent and knownhosts packages. The last is fixed in 0.55.0 and the rest in 0.52.0. None of them is reachable here. The server imports x/crypto/bcrypt and nothing else from the module, and the image is FROM scratch, holding a single binary. But trivy scans at module granularity and cannot tell that. Shipping a known-vulnerable module version on the strength of a reachability argument is not the call to make inside a dependency pin, so the version moves instead. `9abf07f` was wrong to call v0.49.0 the newest release that keeps go.mod at go 1.25.9. v0.55.0 keeps it there too; the directive is unchanged here. What had held it at 1.26 was the x/sys v0.48.0 that v0.57.0 pulled in. The `go get golang.org/x/sys@v0.42.0` meant to undo that then downgraded x/crypto to v0.49.0 to match, without being asked. x/sys now sits at v0.47.0, the version x/crypto v0.55.0 requires. Checked before tagging rather than by the pipeline: the gate passes, the Dockerfile builds on its Go 1.25 builder, and trivy, run locally with the same flags as `make security-image` (HIGH and CRITICAL, fixed only), exits 0 on the image that build produced.	2026-09-19 18:05:06 +02:00
Niklas Ye	e78f49461a	Set the chart's placeholder version to 0.10.1 CI / chart (push) Successful in 1s Details CI / security (push) Successful in 27s Details CI / test (push) Successful in 2m11s Details Release / test (push) Successful in 1m11s Details Release / chart (push) Successful in 3s Details Release / binaries (push) Successful in 1m32s Details Release / image (push) Successful in 1m41s Details Release / scan-image (push) Failing after 29s Details Cosmetic, as in `4cec26e` and `9669b8f`. `make helm-package` passes --version and --app-version from the tag, so neither field decides anything about what release.yaml publishes. Done anyway because a tree heading for v0.10.1 that still says 0.10.0 tells a reader something false. appVersion keeps the v, per APPVERSION_PREFIX in .release.conf.	2026-09-19 17:56:20 +02:00
Niklas Ye	9abf07f2cb	Build on Go 1.25 again, as the Dockerfile does v0.10.0 never produced an image. Adding bcrypt in `dc3879e` ran `go get golang.org/x/crypto`, which took the newest release, v0.57.0. That version declares `go 1.26.0`, and so does the x/sys v0.48.0 it pulled along, so go.mod's own directive rose from 1.25.9 to 1.26.0. The Dockerfile builds on golang:1.25-alpine with GOTOOLCHAIN=local, and refused: go: go.mod requires go >= 1.26.0 (running go 1.25.14; GOTOOLCHAIN=local) Nothing before the image job could see it. The local toolchain is 1.26, and the pipeline's test job runs on the runner's Go rather than in the Dockerfile's builder. So the gate passed on a module the image could not build. Pinned to x/crypto v0.49.0 rather than moving the builder to 1.26. That is the newest release whose own requirements leave go.mod at 1.25.9 and x/sys where it was. Changing the toolchain the image is built with belongs in its own change, not inside a dependency addition. go.mod now differs from v0.9.4 by the one crypto line and nothing else. bcrypt has not changed in any way that matters here across those releases. Checked by building the Dockerfile locally, which now succeeds. The resulting container serves /incidents/3 as the web UI and answers /api/me with a JSON 401.	2026-09-19 17:56:20 +02:00