EditorLayout owned the stack-image-update state plus a 5-minute
polling interval as part of a 30-line useEffect that already
juggled six other concerns (selected file, active view, stacks
refresh, auto-update settings, git-source pending, …). The image-
update slice has clean boundaries: it depends on activeNode.id,
mutates one state object, and is otherwise unrelated to the rest
of the effect.
Move it into a dedicated hook at frontend/src/hooks/useImageUpdates.ts.
The hook owns the stackUpdates state, runs an initial fetch on
activeNode.id change, schedules the 5-minute poll, and exposes a
refresh() callback for the four manual-trigger sites
(deploy success, image-update action, manual registry-refresh
poll). The hook destructure aliases refresh to fetchImageUpdates so
existing call sites in EditorLayout don't need to be renamed.
This is the first slice of audit finding 1.6 (EditorLayout 3129-line
refactor); the next slice is useFleetNotifications.
DockerController.pruneManagedOnly removed managed volumes,
networks, and images one at a time inside a serial for-await loop.
Each remove call hits the Docker daemon over the Unix socket with a
synchronous-from-the-caller's-perspective HTTP round-trip, so a
prune over N items took the sum of N round-trips. The daemon
handles concurrent removes fine for these resource types.
Wrap each loop in Promise.all so wall time tracks the slowest
single remove rather than the sum. The existing per-item try/catch
keeps the partial-failure semantics: a single resource that fails
to delete logs and continues; the rest still get removed.
JavaScript single-threading makes the shared reclaimedBytes
counter safe under the parallel awaits.
Each test file's setupTestDb() previously re-ran the full
DatabaseService init path: initSchema (~30 CREATE TABLE IF NOT
EXISTS), 14 idempotent migrate*() methods, a bcrypt hash, and the
admin / settings seed inserts. With 82 files this was a meaningful
slice of the per-fork cold-start cost.
Move the build into a vitest globalSetup that runs once before any
worker boots. The baseline DB lands at a fixed temp path; each
worker's setupTestDb copies it into the per-file data dir, opens the
copy via DatabaseService.getInstance() (re-running the same
idempotent init as a no-op pass), then UPDATEs the seeded local
node's compose_dir to match the per-file COMPOSE_DIR (the baseline
recorded /app/compose because COMPOSE_DIR was unset when the seed
fired in initSchema; without realigning, file-routes tests 400 on
path traversal).
TEST_JWT_SECRET moves from a per-file randomBytes assignment to a
fixed constant in a new testConstants module so the value the
baseline seeds matches the value test files import for direct token
signing. setupTestDb re-exports it for back-compat with the existing
import sites.
A baseline-less measurement on the same machine flakes 30 of 82
files at the no-cap baseline; with this baseline copy, the same
tree drops to 0-3 failures (the residual environmental Windows
flakes) and ~47-52 s wall time.
Vitest's fork pool default scales with availableParallelism, which
on machines with many cores spawns dozens of fresh workers. Each
worker dynamic-imports the full Express stack (TypeScript transform
+ DB constructor + every migration) and saturates CPU on cold start.
Most of the previous suite wall time was spent waiting on this
contention rather than running tests.
Cap concurrency at 4 workers via the new top-level maxWorkers /
minWorkers options (Vitest 4 unified the previous
poolOptions.forks.maxForks under maxWorkers across pool types).
Local backend wall time drops from ~93 s to ~32-60 s on typical
runs. The pre-existing pre-cap fork-contention flakes (rate
limiting, metrics-routes, fleet integration) clear consistently
on the warm path; the remaining variance is environmental
(background processes, antivirus on Windows) and is what it was
before this change minus the contention floor.
testTimeout (30 s) and hookTimeout (45 s) stay generous so the
stress path in database-metrics and the HTTP integration suites
still cover their cold-start envelope on slow runners.
backend/tsconfig.json had no incremental setting, so every tsc run
re-checked the full project from cold. The two frontend tsconfigs
already declared a tsBuildInfoFile path under node_modules/.tmp/ but
without incremental: true the file was never written, and the path
itself sits inside node_modules where npm ci wipes it on every fresh
install — neither of which actually persists incremental state.
Add incremental: true to all three configs and drop the broken
tsBuildInfoFile overrides. TypeScript's default places the buildinfo
next to the tsconfig (e.g. backend/tsconfig.tsbuildinfo); the root
.gitignore already covers *.tsbuildinfo so nothing leaks into git.
Local cold-vs-warm tsc --noEmit on the backend dropped from ~3.0s
to ~1.4s — ~2x speedup on the warm path. CI builds are still cold
because runners do not cache the buildinfo between jobs; that is a
separate workflow change.
* perf(frontend): parallelize auth bootstrap fetches
AuthContext.checkAuth previously chained three sequential fetches:
/api/auth/status, then /api/auth/check, then /api/permissions/me.
The status check has to come first because its response decides
whether to early-return on the setup or mfa-pending path. The next
two are independent for an authenticated session and were costing
an extra round-trip on every cold load.
Run /api/auth/check and /api/permissions/me in parallel via
Promise.all. The permissions request is wasted on the rare
not-authenticated path (cookie expired or logged out) but that
trade-off is worth saving the round-trip on the common success
path. The .catch(() => null) on the permissions fetch and the
inner try/catch around .json() preserve the original fault
tolerance: a network failure or malformed body falls back to no
permissions data, with the global role still authoritative.
* fix(frontend): commit auth state without waiting on /permissions/me
The previous Promise.all awaited both fetches before calling
setAppStatus('authenticated'), so a slow /api/permissions/me would
delay the dashboard commit relative to the old serial code. The E2E
deploy-feedback tests at e2e/deploy-log-panel.spec.ts:168 and :236
race the dashboard render after page.reload() and were timing out
waiting for GET /api/stacks/<name> because the click target was not
yet wired when the slower permissions response held up state.
Keep both requests in parallel on the wire, but await only the auth
check before committing state. The permissions promise resolves in
the background and updates state via void permsPromise.then() so the
non-critical request never gates the bootstrap.
xterm-the-terminal-emulator and its three addons (fit, search,
serialize) used to be imported at module scope by Terminal.tsx,
BashExecModal.tsx, and HostConsole.tsx along with xterm's CSS.
Even though only Terminal.tsx is rendered eagerly inside the editor
layout, the static imports forced the ~660 KB xterm chunk plus the
xterm.css bytes into every cold app start regardless of whether a
user ever opened a terminal.
Move the bootstrap into a new frontend/src/lib/xtermLoader.ts
module. loadXtermModules() Promise.alls the four addon imports plus
the CSS, caches the result on a shared promise, and returns the
constructors. On rejection the cache is cleared so the next mount
can retry instead of rethrowing the same failed promise.
Three consumers (Terminal, BashExecModal, HostConsole) swap their
value imports for type-only InstanceType aliases from the loader,
then call loadXtermModules() inside their existing useEffect. A
mounted/cancelled flag in each effect closure prevents
initialisation if the component unmounts during the load.
The vite.config.ts manualChunks group from #823 already groups all
@xterm/* packages into the xterm chunk, so it now loads on demand
instead of being bundled into the entry chunk.
Monaco-editor and @monaco-editor/react were imported eagerly from
main.tsx so that the locally-bundled Monaco was registered with
@monaco-editor/react (CSP blocks the default CDN load). This pulled
the ~3 MB monaco chunk into every cold app start regardless of
whether a user ever opened the editor.
Move the Monaco setup into a new frontend/src/lib/monacoLoader.tsx
module that exports React.lazy-wrapped Editor and DiffEditor
components. The lazy factory awaits a one-shot setupMonaco() that
dynamic-imports monaco-editor, @monaco-editor/react, and the editor
worker, then calls loader.config({ monaco }) and sets
window.MonacoEnvironment before resolving the underlying component.
Concurrent first mounts share a single setup promise so the work
runs at most once per process. The three consumers (EditorLayout,
FileViewer, GitSourceDiffDialog) wrap their editor in <Suspense>
with a transparent fallback that preserves layout while the chunk
loads.
main.tsx loses three eager imports plus the MonacoEnvironment +
loader.config bootstrap. The vite.config.ts manualChunks group from
PR #823 was already prepared for this; the monaco chunk now loads
on demand instead of being bundled into the entry chunk.
* perf(frontend): split heavyweight vendors into manual chunks
Vite's default chunking grouped monaco-editor, the xterm addons,
recharts, @xyflow/react + @dagrejs/dagre, and motion into shared
chunks with the Sencho app code. Any small change in the app would
bust the cache for the heavyweight vendor code, costing repeat
visitors a fresh download.
Add explicit manualChunks for monaco, xterm, charts, flow, and
motion. Each vendor is large enough to justify its own HTTP/2
stream, and grouping them by library keeps their cache key stable
across feature releases.
Also wire rollup-plugin-visualizer behind ANALYZE=true so
`ANALYZE=true npm run build` emits dist/stats.html for ad-hoc
bundle inspection without affecting CI or production builds.
Bump build.chunkSizeWarningLimit from the default 500 KB to 1500 KB
since the monaco chunk is intentionally large; this preserves the
warning's signal value for genuine future regressions.
* fix(frontend): use manualChunks function form for vite 8 typing
Vite 8's OutputOptions overload narrows manualChunks to the
ManualChunksFunction shape, so the object form rejected the chunk
keys with TS2769. Convert to the equivalent function form using
node_modules path matching; same chunk groupings as before.
Also pin rollup-plugin-visualizer to ^6.0.0; 7.x raised the engine
floor to Node 22 and CI runs Node 20, so npm emitted EBADENGINE
warnings. Version 6 supports Node 18+ and exposes the same
visualizer({ filename, gzipSize, brotliSize }) API.
Both frontend-builder and backend-builder ran `npm install` even
though `prod-deps` already used `npm ci`. `npm install` walks the
dep graph and silently rewrites the lockfile when there is drift,
which costs build time and lets a stale lockfile slip into a release
image. `npm ci` enforces the lockfile, fails fast on drift, and skips
the resolution work since the dep tree is fully described by the
lockfile.
Both lockfiles are in sync (verified with `npm install
--package-lock-only` reporting "up to date"), so the change is a
pure tightening with no behavior delta in the happy path.
@aws-sdk/client-ecr and @aws-sdk/client-s3 each pull in dozens of
@smithy/* and middleware-* transitive packages but only fire when an
operator configures an ECR registry or cloud backup respectively. Move
both to optionalDependencies so the package classification matches
their runtime role and operators who never use either feature can run
`npm ci --omit=optional` for a ~150 MB-slimmer image.
The default Dockerfile install (`npm ci --omit=dev`) keeps shipping
the SDKs, so default installs are unchanged. The dynamic imports in
CloudBackupService.loadS3Sdk and RegistryService.fetchEcrToken now
catch a missing-module failure and throw a wrapped Error whose
message names the recovery path (`reinstall without --omit=optional`)
and whose cause propagates the original module-not-found error for
debugging.
Bumps tsconfig.json's target and lib to ES2022 so `new Error(msg,
{ cause })` is typed; Node 25 already supports this at runtime.
@aws-sdk/client-s3 pulls in dozens of @smithy/* and middleware-*
transitive packages. Cloud backup is a Skipper+ opt-in feature and
the bulk of installs never configure it, but the eager top-level
import meant every cold start parsed the whole SDK regardless.
Wrap the import in a load-and-cache helper, make buildS3Client
async, and have it return both the S3Client and the SDK namespace
so each caller constructs commands from the same lazily-loaded
module. The pattern matches the existing dynamic import of
@aws-sdk/client-ecr in RegistryService and the lazy-loaded
composerize and isomorphic-git in PR #819.
Tests use vi.mock('@aws-sdk/client-s3', ...) returning named
exports, which works the same way for dynamic imports as it did
for the static ones.
Both modules are opt-in:
- composerize (~2 MB) is only used by /api/convert when a user pastes a
docker run command into the converter UI.
- isomorphic-git plus isomorphic-git/http/node (~5 MB combined) only fire
when a stack is created from a Git source.
Previously each was imported at module scope, parsing the whole package on
every cold start regardless of whether the feature was used. Wrap them in
small load-and-cache helpers so the first call resolves the module via
Node's loader and every subsequent call returns the cached reference.
The pattern matches the existing dynamic import of @aws-sdk/client-ecr in
RegistryService. Existing tests using vi.mock('isomorphic-git', ...) and
vi.mock('isomorphic-git/http/node', ...) keep working without changes
because dynamic and static imports share the same module registry.
MonitorService.evaluate() forked the docker CLI every 30s and
walked the human-readable Reclaimable strings ("1.196GB", etc.)
with a regex to compute the janitor threshold check. The Docker
Engine API returns raw byte counts, and the existing
DockerController.getDiskUsage() already wraps it for images,
containers, and volumes. Extend that helper with reclaimable
build-cache bytes so MonitorService can sum the four categories
in one call.
Drops the child_process / promisify imports from MonitorService and
removes about 30 lines of stdout parsing. Also widens the explicit
return type of getDiskUsageClassified so the new fields aren't
silent runtime additions.
Every mutating /api/* request runs an individual INSERT into audit_log
which serializes against other writers under burst load (SQLite's
single-writer model). Buffer the writes in DatabaseService and flush
them in a single transaction either every second or once the buffer
reaches 100 entries, whichever comes first.
Read paths (getAuditLogs, getAuditLogsInRange, cleanupOldAuditLogs)
drain the buffer first so callers always see a consistent view, which
keeps the existing test pattern of insert-then-read working.
Graceful shutdown flushes before db.close() so no entries are lost on
clean exit. The 1s flush timer is unref'd so the buffer cannot keep
the process alive on its own. The CLI resetMfa script flushes
explicitly before returning since it exits before the timer fires.
The boot path awaited SelfUpdateService.initialize, DockerEventManager.start,
and TrivyService.initialize one at a time even though none of them depend on
each other. Group them into a single Promise.all so total cold-start time is
the slowest one rather than the sum.
Also convert the inner `docker compose version` probe in
SelfUpdateService.initialize from execFileSync to execFileAsync. Without that,
the synchronous spawn would block the event loop for up to 5 seconds and
silently serialize the other two members of the parallel block, defeating
the parallelization win for in-container deployments.
The synchronous service starts (Monitor, AutoHeal, ImageUpdate, Scheduler,
Mfa) are grouped together up front. They schedule timers whose first ticks
fire 5+ seconds out, so they safely run alongside the awaited block.
The remote-node HTTP proxy and WebSocket forwarder read getTier() +
getVariant() on every forwarded request to set the Distributed License
Enforcement headers. Each call hits system_state 5+ times. Add a
30-second cached snapshot inside LicenseService and route every
license_status write through a new private setLicenseStatus() helper
so activate, deactivate, validate, and the auto-demote paths inside
getTier() all invalidate the cache.
Routing all license_status writes through one chokepoint also closes
a latent drift window: the self-heal paths in getTier() (trial
expired, offline grace exceeded, subscription expired) used to mutate
state silently and now invalidate the cache the same way explicit
license events do.
The TTL becomes a safety net against any future write that bypasses
the helper, not a load-bearing freshness bound. Existing 44 license
and distributed-license tests pass unchanged.
getGlobalSettings() runs a SELECT * on every call and is hit from 22
files, including the auth middleware (every authenticated request),
the WebSocket upgrade handler (every connection), and the debug-mode
gate (every diagnostic log line). Cache the result inside the service
on first read and invalidate on updateGlobalSetting().
The cached snapshot is Object.freeze'd and the public return type is
now Readonly<Record<string, string>> so accidental mutations are
caught at compile time. The settings GET handler that delete'd private
keys now takes a defensive shallow copy first.
The 5-second TTL cache in utils/debug.ts is now redundant and removed;
the service-level cache is strictly fresher (invalidates on write
rather than going stale for up to 5s).
The seven @types/* packages contain only TypeScript declaration files,
which are erased at compile time and have no runtime use. Listing them
under dependencies kept them installed in the production image for no
benefit; they belong under devDependencies so `npm ci --omit=dev`
prunes them from the runtime install.
Packages moved: @types/compression, @types/cors, @types/dockerode,
@types/express, @types/http-proxy, @types/semver, @types/ws.
The /fleet/configuration endpoint fetched remote node config via a direct
backend-to-backend fetch that omitted the distributed license headers
(x-sencho-tier, x-sencho-variant). Remote nodes evaluated their own
Community tier and returned locked: true for Webhooks, Scanning, and
Backup even when the main node held a Skipper/Admiral license.
Forward the same tier/variant headers that remoteNodeProxy already
injects so tier gates on remote nodes honour the main node's license.
MFA and Backup are also hidden for remote node cards in the Status tab:
- MFA is a user session feature managed on the main node; remote nodes
are accessed via node_proxy Bearer tokens with no userId, so the value
was always "Not set" and provided no useful information.
- Backup (Sencho Cloud Backup) runs fleet-wide from the main node and
captures all nodes' compose files; remote nodes never configure it
independently, so showing it there was misleading.
Removing both fields from remote cards keeps the grid at 6 items (3
even pairs) and eliminates stale or irrelevant data.
* feat(scaffold): fully automate release blog post publishing
Eliminates the manual PR-review step from the release blog scaffold pipeline.
The workflow now commits the generated post directly to sencho-website main.
scaffold-release-post.mjs changes:
- Remove renderPrBody and all body_file handling
- Update findLastAnchor to accept any post with a version: field, not just
category: release posts. This allows narrative retrospectives to anchor
the 5-release window.
- Add buildHeadline: generates a post title from the top two added items and
the total item count, e.g. "Sencho v0.69: Custom OIDC provider, Trivy
scanning, and 12 more"
- Add buildDescription: auto-generates a ~160-char SEO description from the
version range and top three added items
- Add calcReadingTime: estimates reading time from changelog word count
- Add coveredVersionsProse: formats "v0.65.0 through v0.69.0"
- Add updateMeta: inserts the new post into src/data/blog/meta.ts for
Worker-side SEO meta injection
- Remove the tmpdir/os import (no longer needed)
release-blog-template.tsx.tmpl changes:
- Replace all TODO placeholders with template variables (__TITLE__,
__DESCRIPTION__, __READING_TIME__, __COVERED_VERSIONS_PROSE__)
- Remove the screenshot placeholder section (auto-generated posts have no
screenshot; the intro links to docs.sencho.io instead)
release-blog-scaffold.yml changes:
- Remove permission-pull-requests: write from app token (no PR created)
- Replace "Commit and open draft PR" step with a simple git commit + push to
sencho-website main. No duplicate-check step needed.
- Include src/data/blog/meta.ts in the git add so the Worker SEO mapping
stays in sync automatically.
* fix(ci): use escapeTsxString in updateMeta to handle backslashes in blog post title and description
CodeQL flagged two high-severity alerts: title and description written
into meta.ts via updateMeta were only single-quote-escaped, leaving
raw backslashes unescaped. A value containing a backslash followed by
a special character would produce a malformed escape sequence in the
generated TypeScript source. The escapeTsxString helper already handles
both cases; use it consistently instead of an open-coded replace.
Two small hardenings flagged by CodeQL:
- routes/registries.ts: drop the redundant startsWith block-list and rely
solely on URL parsing + protocol allow-list. The startsWith pass was
unreachable defense (any non-http/https scheme already fails the
protocol check below it) and was tripping js/incomplete-url-scheme-check.
- services/TemplateService.ts: replace the .includes('api.linuxserver.io')
substring match with new URL(registryUrl).hostname comparison. The
substring form would mis-classify a malicious admin-set URL like
https://evil.example/api.linuxserver.io/... as the LSIO registry and
apply the LSIO response parser to its payload. Hostname compare closes
that.
Behavioral parity for the happy path: every previously-accepted URL still
parses; the LSIO branch still triggers when the hostname is exactly
api.linuxserver.io.
* refactor(backend): sanitize user input before logging to close CRLF injection
Adds a small sanitizeForLog helper that strips CR, LF, tab, and ASCII
control characters (0x00-0x1F, 0x7F) from a value before it is embedded
in a console.log/warn/error/debug call. Wraps every call site where a
user-controlled value (req.params, req.body, req.query, or a value
derived from them) flows into a log message.
Closes the bulk of the open CodeQL alerts in this family:
- 96 js/log-injection
- 28 js/tainted-format-string
The helper is in backend/src/utils/safeLog.ts. Routes still pre-validate
input at the request boundary; this is the second line of defense and
gives static analyzers a sanitizer they can trace through. JSON
responses, Docker filter labels, and other non-log call sites are
intentionally left unwrapped.
* refactor(backend): printf-style format strings for tainted-log call sites
CodeQL's js/tainted-format-string rule flags template literals in the first
arg of console.X when any interpolated value is user-controlled, regardless
of whether each value is sanitized inline. The canonical mitigation is to
use a static format string and pass values as positional args.
Converts the 28 flagged template literals to printf-style ("%s") format
strings, with sanitizeForLog applied to each positional arg. Also fills in
the log-injection wraps on 9 sites where a user-controlled value was
missed in the first sweep (agents, fleet, gitSources, imageUpdates,
GitSourceService).
No behavior change at runtime. Node's util.format substitutes %s tokens
identically to template-literal interpolation.
* fix(backend): wrap nodeId/snapshotId in fleet restore debug log
CodeQL flagged the unwrapped numeric args even though they cannot
contain control chars in practice. Apply the sanitizer for taint-flow
recognition.
Adds two private helpers and routes the legacy stack-scoped methods
through them so every fs call has a name + path check immediately
above the call site:
- assertWithinBase(filePath): throws INVALID_PATH if the path resolves
outside this.baseDir. Wired into the bare readFile/writeFile/access
wrappers and hasComposeFile(dir).
- resolveStackDir(stackName): throws INVALID_STACK_NAME if the name
fails isValidStackName, then asserts the joined path is within base.
Wired into getComposeFilePath, saveStackContent, envExists,
getEnvContent, saveEnvContent, createStack, deleteStack,
backupStackFiles, restoreStackFiles.
Routes still pre-validate at the request boundary; this is the
second line of defense and gives static analyzers a guard they can
trace through. The existing resolveSafeStackPath used by file-explorer
methods is unchanged (it adds symlink-escape detection on top).
The duplicate inline regex in createStack is removed because
resolveStackDir now performs the same check via isValidStackName.
Resolves four DOMPurify advisories all patched in 3.4.0:
- GHSA-39q2-94rc-95cp (ADD_TAGS function form bypasses FORBID_TAGS)
- GHSA-v9jr-rg53-9pgp (CVE-2026-41238: prototype pollution to XSS via
CUSTOM_ELEMENT_HANDLING fallback)
- GHSA-h7mw-gpvr-xq4m (CVE-2026-41240: FORBID_TAGS bypass via function-based
ADD_TAGS predicate)
- GHSA-crv5-9vww-q3g8 (CVE-2026-41239: SAFE_FOR_TEMPLATES bypass in
RETURN_DOM mode)
Bump is on the npm overrides entry (dompurify is a transitive dep), which
forces the resolved version up the tree. Lockfile picks up 3.4.1 (latest
3.4.x). Frontend build clean, dev server boot clean, no runtime errors.
* fix(docker): build compose plugin from ./cmd, not ./cmd/compose
The compose-builder stage in Dockerfile was building ./cmd/compose, which
in docker/compose v5.1.2 is `package compose` (cobra command definitions),
not the CLI plugin entry point. `go build -o file pkg` against a non-main
package writes a Go archive; COPY and chmod accept it, but the kernel
cannot exec an ar-format file, so the Docker CLI plugin manager rejected
the binary and surfaced only as `docker: unknown command: docker compose`
in the v0.64.0 release smoke gate. The plugin's actual main package is at
./cmd (cmd/main.go calls plugin.Run from the cli-plugins framework), per
the upstream Makefile in v5.1.2.
Also fix the version ldflag to target the v5 module path: in v5 the module
moved from github.com/docker/compose/v2 to .../v5, so the previous
-X .../v2/internal.Version= silently no-op'd and `docker compose version`
would have reported an empty string even after the build target fix.
Add -trimpath and -s -w to match the upstream Makefile's release flags.
Add an inline ELF-magic sanity check inside the compose-builder stage so
this exact failure mode (non-main package emitting an archive) fails the
build at the producer instead of surfacing 200 lines later. Hex match via
`od -tx1` works on both busybox and GNU coreutils; the named-character
form (`od -c`) renders fields differently across the two.
Add a binary smoke step to the docker-validate PR job that mirrors the
release-time gate, so a regression in either the CLI or compose source
build is caught at PR review time rather than at tag-push time.
* fix(vex): match Trivy purl format for bundled docker/docker version
The compose plugin build target fix exposes a real consequence: now that
compose-builder produces a true ELF binary (rather than a Go archive),
Trivy can read the embedded Go module metadata and correctly reports the
bundled docker/docker dependency as `v28.5.2+incompatible`. The existing
VEX subcomponent ID omitted the `+incompatible` Go-module suffix, so
Trivy's purl matcher rejected the suppression and CVE-2026-34040 surfaced
in the docker-validate scan against the rebuilt image.
Update the @id to the literal version Trivy emits and bump the document
version per OpenVEX spec. The justification (compose acts as a CLI
client, never as a daemon, so the authz-hook path is unreachable) is
unchanged and continues to apply to v28.5.2+incompatible identically.
* docs(security): explain why CVE-2026-34040 cannot be upgraded out
A direct in-build upgrade attempt (`go get github.com/docker/docker@<sha
of docker-v29.3.1>`) fails with:
invalid version: go.mod has post-v1 module path
"github.com/moby/moby/v2" at revision f78c987a
moby/moby migrated its Go module path to `github.com/moby/moby/v2` on
the docker-29.x branch. The legacy `github.com/docker/docker` import path
is therefore frozen at v28.5.2+incompatible from Go's perspective; the
proxy.golang.org listing for that module path confirms no v29.x version
is resolvable. compose v5.1.2 (and v5.1.3, the latest tag at the time of
writing) both still import the legacy path, so the bundled docker/docker
library cannot be moved past v28.5.2+incompatible until upstream compose
migrates its imports.
Document the constraint in two places so a future maintainer (or future
me) does not re-attempt the same `go get` and arrive at the same dead
end:
- Dockerfile compose-builder stage: comment block above the build step.
- security/vex/sencho.openvex.json: expand the CVE-2026-34040 statement's
impact_statement to spell out the upstream module-split blocker. The
not_affected status (compose runs as a CLI client, never executes the
daemon authz hook code path) is the principled triage and remains the
correct OpenVEX call, not a deferred upgrade.
No build or runtime behaviour changes. Pure documentation enrichment.
* fix(security): mirror CVE-2026-34040 VEX statement in .trivyignore
Trivy reports `Some vulnerabilities have been ignored/suppressed` but
still fails the docker-validate scan on CVE-2026-34040, because the
OpenVEX statement's product identifier `pkg:oci/sencho` cannot match
the build-local image tag `sencho:pr-test`. Trivy does not generate an
OCI purl for images that lack a registry digest (aquasecurity/trivy
issue 9399), so VEX product matching is a no-op at PR and release scan
time. The dual-layer pattern documented in .trivyignore's header was
designed for exactly this case: VEX is the canonical, attested,
published triage record, and .trivyignore mirrors entries that scan-time
matching cannot resolve, with a comment pointing to the corresponding
VEX justification.
The CVE-2026-34040 OpenVEX statement is unchanged (status=not_affected,
justification=vulnerable_code_not_in_execute_path). The .trivyignore
entry is a build-time scan filter only, with a referencing comment so
auditors land on the VEX file as the source of truth. CVE-2026-39883
already follows this pattern and continues to.
* refactor(backend): use stacksRouter.param for stackName validation
Registers a router-level param validator on :stackName so the 400
'Invalid stack name' guard runs once per route entry instead of being
duplicated in every handler. Removes ~22 inline isValidStackName checks
across the stacks router (deploy, down, env, files, services,
update-preview, rollback, backup, etc.).
Validation now fires before per-handler tier and permission checks,
which matches the standard input-validate-first pattern. The body-field
validators in POST / and POST /from-git remain inline because they
operate on req.body, not the route param.
Closes#752
* fix(stacks): remove unused stackName local in upload multer wrapper
The multer middleware wrapper for POST /:stackName/files/upload no longer
needs a local stackName binding now that param-level validation handles
the check. Removes the stale assignment that ESLint flagged and corrects
the leftover indentation on the requirePaid line.
Adds backend/src/utils/parseIntParam.ts with a shared parseIntParam
helper that writes a 400 'Invalid <label>' response and returns null on
non-numeric route params. Consolidates the parseInt + isNaN + 400 shape
that was inlined or duplicated across multiple routers.
Updated:
- routes/fleet.ts: replaced the local parseIdParam wrapper.
- routes/autoHeal.ts: replaced the local parsePolicyId wrapper.
- routes/notifications.ts: replaced parseRouteId wrapper plus an inline
notification-id site.
- routes/apiTokens.ts, routes/labels.ts, routes/registries.ts,
routes/scheduledTasks.ts, routes/users.ts: replaced inline copies.
Out of scope (route handlers without an existing isNaN check, kept
intentionally untouched to avoid introducing new 400 responses): alerts,
nodes, webhooks, and several user-routes handlers that rely on a
downstream 404 instead.
Closes#748
* refactor(backend): extract replica guard helper for security routes
Adds blockIfReplica(res, resource) in middleware/fleetSyncGuards.ts and
replaces six inline FleetSyncService.getRole() === 'replica' checks
across the security policies and CVE suppressions endpoints.
Error responses now use a uniform shape:
403 { error: 'Cannot modify <resource> on a replica instance.
Connect to the primary.', code: 'REPLICA_READ_ONLY' }
The new code field gives callers a stable discriminator without
matching prose.
Closes#750
* test(suppressions): match stable REPLICA_READ_ONLY code instead of prose
The replica guard helper exposes a stable code field for callers to
discriminate without grepping the human-readable error string. Switch
the replica-rejection assertion to use that code so the test no longer
breaks when the unified error template wording is tuned.
Collapses the three near-identical /:stackName/restart, /:stackName/stop,
and /:stackName/start handlers in routes/stacks.ts into a single
bulkContainerOp helper. Preserves the asymmetric notifyActionFailure
behavior (restart and stop notify, start does not).
Closes#751
Replaces five inline new Set([...]) literals scattered across
routes/security.ts and routes/fleet.ts with two shared constants
(FINDING_SEVERITIES, POLICY_SEVERITIES) exported from
utils/severity.ts. Pure refactor: no error response or status code
changes.
Closes#749
* ci: add CodeQL analysis and Docker ecosystem to Dependabot
Add CodeQL workflow running javascript-typescript analysis weekly and on
every PR/push to main, using the security-extended query suite. All three
codeql-action steps are SHA-pinned.
Add the docker package-ecosystem to dependabot.yml so Dependabot opens
weekly PRs to bump Dockerfile digest pins (FROM node:22-alpine@sha256:...
and the golang builder stage) when upstream images are updated.
* ci(codeql): upgrade codeql-action to v3.35.2
v3.29.0 uses Node.js 20, which is deprecated on GitHub-hosted runners as
of April 2026, causing SARIF upload failures with "Resource not accessible
by integration." v3.35.2 runs on Node.js 24 and resolves the deprecation.
* ci(codeql): add actions:read permission for workflow run API
CodeQL v3.35.2 calls the GitHub Actions REST API to fetch workflow run
context for SARIF correlation, which requires actions:read. Without it,
the analyze step fails with "Resource not accessible by integration"
when calling /repos/{owner}/{repo}/actions/runs/{run_id}.
* feat(security): add SBOM attestations, VEX document, and retire .trivyignore
Add OpenVEX triage document (security/vex/sencho.openvex.json) for the 5
residual CVEs vendored inside docker/compose v5.1.2 that were carried over
from the previous PR. All 5 are marked not_affected with justifications.
Configure Trivy in both CI and release workflows to consume the VEX document
via trivy.yaml so the same source of truth gates PR scans and release scans.
Delete .trivyignore, which is fully superseded by the VEX file.
Add two new release pipeline steps after image publication:
- CycloneDX 1.6 SBOM via anchore/sbom-action (also installs syft)
- SPDX 2.3 SBOM via syft directly (reuses OCI layer cache from prior step)
Both are attached as cosign OCI referrer attestations (keyless, OIDC-signed)
and uploaded as GitHub Release assets alongside the OpenVEX file.
Bump docker-publish.yml permissions from contents:read to contents:write,
required for softprops/action-gh-release to create Release assets.
Add docs/operations/verifying-images.mdx with copy-paste verification
commands for all supply-chain artifacts: signature, SLSA provenance,
CycloneDX SBOM, SPDX SBOM, OpenVEX, and Rekor entry. Update docs.json
navigation and expand the Supply chain security section in docs/security.mdx.
Add a Verifying Release Artifacts section to SECURITY.md.
* fix(vex): cover otel SDK CVE-2026-39883 in rebuilt Docker CLI binary
The rebuilt Docker CLI v29.4.0 vendors otel/sdk v1.42.0, which still
contains CVE-2026-39883 (BSD kenv PATH hijacking; fixed in v1.43.0).
docker-compose v5.1.2 vendors otel/sdk v1.38.0 separately. The original
VEX statement only covered the compose binary's location and version,
so Trivy's scan of /usr/local/bin/docker was not suppressed.
Add a second subcomponent entry for the CLI binary path with the
correct vendored version. The not_affected justification (BSD-only
code path; we ship linux/amd64 and linux/arm64 only) holds for both
binaries.
* fix(ci): use list form for vulnerability.vex in trivy.yaml
Trivy's config schema requires vulnerability.vex to be a list (mapped
to the multi-value --vex flag). The previous bare-string value was
silently dropped, so the OpenVEX document was never loaded and HIGH
findings already covered by VEX statements still failed the scan.
* fix(ci): mirror VEX CVE in .trivyignore for local-image scan
Trivy does not emit an OCI purl for locally-built images without a
RepoDigests entry (aquasecurity/trivy#9399), so OpenVEX product
matching against the CI build target sencho:pr-test resolves to no
artifact and every statement is silently dropped. The VEX document
remains the canonical triage record and is still attached as a cosign
attestation on the published image; this file just mirrors the single
CVE that surfaces on the local scan so CI does not block on a finding
already triaged in VEX. Updates the Trivy step comment to document
the relationship between the two files.
* feat(security): rebuild Docker CLI/Compose from source, pin base image digests
Build Docker CLI v29.4.0 and Compose v5.1.2 from source against Go 1.26.2
to resolve 7 CVEs that were accepted in .trivyignore:
- CVE-2026-32280/32281/32282/32283/33810: Go stdlib x509/TLS and DNS
issues in the upstream static CLI binary (compiled with Go 1.26.1).
All fixed by rebuilding with Go 1.26.2.
- CVE-2026-33186: grpc 1.78.0 in Docker CLI. Eliminated from the SBOM
by building with the patched Go toolchain and updated module graph.
- CVE-2026-33671: picomatch ReDoS in npm bundled with node:22-alpine.
Resolved by removing npm/npx from the runtime image entirely (npm is
only needed at build time).
Remaining 5 entries in .trivyignore are vendored deps inside Compose
v5.1.2 (buildkit, moby/docker, otel) that cannot be patched without an
upstream Compose release. These will be expressed as OpenVEX
not_affected statements in the follow-up PR (feat/security-sbom-vex).
Also in this commit:
- Pin all Dockerfile FROM lines to @sha256: digests (node:22-alpine,
tonistiigi/xx, golang:1.26-alpine) to prevent silent base image
changes between scan and publish.
- SHA-pin all GitHub Actions in docker-publish.yml and ci.yml that
were previously referenced by mutable @vN tags.
- Add a binary version smoke test to confirm docker/compose produce
expected output before the multi-arch push proceeds.
* fix(docker): fix cli-builder vendor mode and compose-builder cache path
docker/cli v29.4.0 uses CalVer and ships vendor.mod instead of go.mod,
so plain `go build` fails with "cannot find main module." Fix: copy
vendor.mod -> go.mod and vendor.sum -> go.sum before building, then
pass -mod=vendor so all deps come from the vendored tree with no network
access. Cache mount is not needed with vendor mode and is removed.
compose-builder used /root/go/pkg/mod as the cache mount target, but
golang:alpine sets GOPATH=/go, so the module cache lives at /go/pkg/mod.
The wrong path caused a silent cache miss on every build. Corrected.
The Delete Stack dialog now includes an opt-in checkbox to also remove
associated Docker volumes when the stack is deleted. The checkbox is
unchecked by default and resets to unchecked on every open.
Backend: DELETE /stacks/:name accepts ?pruneVolumes=true and calls
pruneManagedOnly for volumes labeled with the stack project name after
bringing the stack down. Prune failure is non-fatal and logged; the
delete proceeds regardless.
Grid templates are now sorted by star count (descending) so popular
apps surface naturally rather than appearing in registry fetch order.
Featured hero rotates weekly among the top 5 starred apps instead of
always pinning the single highest-starred entry. Rotation is seeded
by week number so all nodes show the same featured app throughout a
given week. Registries with no star data gracefully skip the featured
hero and preserve their natural ordering.
Show the most recent stack event regardless of age. The ticker now
stays populated as long as any event arrived in the current session,
with formatTimeAgo reflecting the true elapsed time (e.g. '2h ago').
Idle state only appears when no events have arrived yet.
Also reduces the update interval from 30s to 10s so relative timestamps
stay responsive.
* feat(dashboard): replace 24h charts with Configuration Status and Recent Activity
The 24-hour CPU/Memory area charts summed per-container metrics normalized
to each container's CPU quota, producing numbers that bore no honest
relationship to host load. The live ResourceGauges strip already shows
accurate host-level stats, making the historical charts both inaccurate
and redundant.
This commit replaces that row with two side-by-side cards:
- **Configuration Status**: aggregates every toggleable feature on the
active node (notification agents, alert rules, routing rules, auto-heal,
auto-update, webhooks, scheduled tasks, MFA, SSO, vulnerability scanning,
cloud backup, and alert thresholds) into a single at-a-glance card.
Tier-locked rows display an upgrade indicator instead of a value.
Each row is clickable and navigates to the relevant settings section.
Data refreshes every 60 s and immediately on state-invalidate events.
- **Recent Activity**: lists the ten most recent notification-history events
for the active node (deployments, image updates, auto-heal actions, scan
findings, cloud backup events, system notices) with category icons and
relative timestamps. Refreshes every 30 s.
New backend endpoints:
- GET /api/dashboard/configuration - per-node feature status with locked/
requiredTier markers so the frontend renders upgrade chips without extra
calls. The endpoint sits after authGate and before the remote proxy so
remote-node requests are transparently forwarded.
- GET /api/dashboard/recent-activity?limit=N - thin wrapper over
DatabaseService.getNotificationHistory.
- GET /api/fleet/configuration - fleet-wide fan-out using the same
Promise.allSettled dead-node-tolerant pattern as /fleet/overview.
Exposed as the new "Status" tab on the Fleet page (after Snapshots).
Shared utilities:
- visibilityInterval and formatCount extracted to frontend/src/lib/utils.ts
so the three polling hooks and two components share a single copy.
* docs(dashboard): fix stale alt text referencing removed historical charts
sencho-quartermaster[bot]