Skip to content

Security dependencies: unreachable rclone code removed, Common v0.4.26 - #2

Merged
inkly merged 8 commits into
mainfrom
chore/security-deps
Sep 22, 2026
Merged

inkly merged 8 commits into
mainfrom
chore/security-deps

Conversation

@inkly

@inkly inkly commented Sep 22, 2026

Copy link
Copy Markdown
Collaborator
  • CI and releases build with the latest Go 1.26 patch; the module requires Go 1.26.8.
  • The rclone-backed cloud-drive code was unreachable in the shipped service (its mounting was commented out, its routes not registered; the core serves cloud drives). It is removed, and rclone v1.62.2 with it: two dozen advisories, and the go-smb2 one, disappear. The amd64 binary goes from 53.6 MB to 25.0 MB.
  • jwt, kin-openapi and Common v0.4.26.
  • The message bus client sends the internal secret.
  • The unused npm SDK scaffolding (77 Dependabot alerts) is gone.

setup-go read the version from go.mod, which installs exactly the go directive (1.26.0), so tests and release binaries were built without the later 1.26.x standard library security fixes. Ask for 1.26 with check-latest so every run gets the newest patch release.
Common v0.4.26 requires go 1.26.8, so the go directive moves up with it. It also replaces mholt/archiver/v3 (and rardecode v1, xi2/xz) with mholt/archives and pulls golang-jwt/jwt/v4 v4.5.2, ulikunitz/xz v0.5.15 and klauspost/compress v1.18.7, which clears the archiver, rardecode, xz and jwt/v4 advisories reachable through Common.

LocalStorage used none of what Common removed (jwt.JWT, file.AddFile, file.GetCompressionAlgorithm), so no code changes.
rclone v1.62.2 has 18 advisories that govulncheck finds reachable from the cloud mounts, and 26 Dependabot alerts: credential headers forwarded on redirect, root escapes through backend name encodings and symlinks, panics in the local backend, and more. v1.75.1 is the first release that fixes all of them.

rclone is used as a library here, so the code follows its API changes:
- mountlib.Options and vfscommon.Options now hold fs.Duration and vfscommon.FileMode instead of time.Duration and os.FileMode. The option values are unchanged, only converted. Fields added since v1.62 keep their zero value, which is what they had before (disabled or not set).
- mountlib.MountFn returns the mountpoint it actually used as an extra value; our FUSE mount returns the one it was given.

Only rc.Params is used from fs/rc. rcserver is linked in through cmd/mountlib, but it only starts from rclone's own cobra command (cmd.Main), which this service never runs, so no remote control server is started.

With it come azidentity v1.14.0, go-ntlmssp v0.1.1, go-chi v5.3.1, protobuf v1.36.11, x/oauth2 v0.36.0 and grpc at the development version rclone pins. The SMB backend now uses github.com/cloudsoda/go-smb2, the maintained fork with the fix for GO-2026-5051, so hirochachacha/go-smb2 leaves the build. MVS also raises resty, moby/sys/mountinfo, samber/lo, zap and ini.v1; they build unchanged.
rclone v1.75.1 pins grpc at a development snapshot (v1.84.0-dev, 2026-07-23) that lacks the fix for GO-2026-6443 / GHSA-2v4p-qf9q-27wj: a server panics on a request with neither :authority nor Host. The v1.84.0 release carries that fix (internal/transport rejects the request, internal/xds/server checks for an empty authority).

The advisory still lists v1.84.0 as affected, because its range only names the later master commit (v1.85.0-dev.0.20260825072537-93e31b48545e) as fixed, so scanners will keep showing it until the range is updated. That master snapshot was not used: it also pulls google.golang.org/api, gax-go and OpenTelemetry forward past what rclone v1.75.1 was released with. This service runs no gRPC server, so the panic was not reachable either way.
kin-openapi v0.117.0 has four advisories on the v2 request validator: GO-2025-3533 (decompression bomb in request body decoding, reachable), GO-2026-6112 (nil-pointer panic on a content parameter without a schema, reachable), GO-2026-6274 (nil-pointer panic in ConvertErrors on a malformed multipart body) and GO-2026-6095 (ValidationHandler falls back to NoopAuthenticationFunc). v0.149.0 is the latest release and fixes all four.

The validator is still deepmap/oapi-codegen v1.12.4's echo middleware: it builds unchanged against v0.149.0, so the move to oapi-codegen/echo-middleware was not needed, and codegen/ does not need regenerating (go generate with oapi-codegen v1.12.4 gives the same code). JWT still runs before validation and the JWT skipper is unchanged. The explicit NoopAuthenticationFunc stays: authentication is echo-jwt's job, and GO-2026-6095 is about the ValidationHandler default, which this service does not use.

Checked by sending 21 requests (valid and invalid bodies, missing and wrong-typed parameters, readOnly fields, unknown path, wrong method) through the same validator setup with v0.117.0 and v0.149.0: every status code is the same. Only the wording of the date-time format error changed.
package.json, yarn.lock and tsconfig.json built a TypeScript client of the v2 API for the @icewhale npm scope. The workflow that published it was removed earlier, and nothing else (workflows, GoReleaser, PKGBUILD, the Go build) reads these files. yarn.lock was the source of 77 Dependabot alerts (49 of them on axios).
The generated message bus client did not go through Common's HTTP helpers, so its calls carried no Authorization header. The bus is about to require this boot's secret on loopback calls, and would then refuse the event type registration at startup and every event this service publishes (disk, USB, merge and storage status, notifications).

The client now gets Common's InternalRequestEditor. It adds the secret only for loopback destinations and never replaces an Authorization header already set. When the secret file is missing the request goes out as before.

TestMessageBusSendsTheInternalSecret points the runtime path at a temporary directory holding message-bus.url (an httptest server) and internal.secret, registers event types through store.MessageBus(), and checks the bus received the secret.
The Dropbox and Google Drive mounts built on rclone could not be reached in
the shipped service:

- main.go never initialised service.MountLists, never loaded the rclone
  config (configfile.Install) and never called CheckAndMountAll; all three
  have been commented out since upstream's "Note rclone (#47)" in March 2023.
- /v1/recover, the OAuth callback and the only code that created a remote,
  was not registered in the router.
- /v1/cloud and /v1/driver were in the router but not registered with the
  gateway. The gateway matches the longest registered prefix, and the CasaOS
  core registers /v1/cloud, /v1/driver and /v1/recover itself, so the
  dashboard's calls (CasaOS-UI src/service/cloud.js and driver.js) reach the
  core, which drives an rclone daemon over /var/run/rclone/rclone.sock.
- With MountLists nil, GET /v1/cloud could only return an empty list and
  DELETE /v1/cloud dereferenced a nil mount point.
- No other service in the distribution calls these endpoints.

Removed: the storage service, the rclone FUSE mount in pkg/mount (Mount,
Bind and the umount helpers stay), the cloud, driver and recover handlers,
the drivers/ and internal/ trees and the packages and model types only they
used. go mod tidy drops rclone, bazil.org/fuse, resty, logrus and the rest of
their graph, including grpc and its open advisory GO-2026-6443.

Release-style armv7 binary: 52.4 MB on main, 82.4 MB with rclone v1.75.1,
23.7 MB now. govulncheck: 0 affected before and after.
@inkly
inkly merged commit ae29bbe into main Sep 22, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant