Updates

Signed releases, pinned trust and controlled rollback

DCSF uses a dedicated update origin and signed manifests so package identity is verified before an administrator can apply a release.

Released

DH20.01 is published

The first signed DataHouse release is public. All 51 security remediations and all three operational controls passed the complete 54-gate release matrix.

The signed public package and installer are available.

DCSF

First-release identity

The DataHouse public number remains operator-facing, while the technical version preserves compatibility with the CSF/LFD update mechanism.

Public releaseDH20.01
Technical version15.10.4
Security remediations51 of 51 verified
Operational controls3 of 3 verified
Complete release matrix54 of 54 gates
Stable channelupdate.dcsf.net/v1/stable/
DCSF

Release channel design

The update client separates checking, downloading and applying, allowing operators to inspect each stage.

01

Check

Fetch signed metadata from the fixed DCSF update origin without inheriting ambient proxy settings.

02

Verify

Validate the manifest signature, version policy, package name, digest and archive structure.

03

Stage

Extract into a private location and run release and compatibility checks before activation.

04

Apply

Activate only an accepted candidate and preserve a controlled rollback path.

DCSF

Operator workflow

The installed client checks, downloads and applies a signed release from the pinned channel as separate operations.

dcsf-update check
dcsf-update download
dcsf-update apply
The signed public package and installer are available. manifest.txt · manifest.txt.sig · release.json