Destructive Command Guard Files

Two fixes. One made the Oh My Pi bridge let a command through unjudged; the other made the installers skip signature checking with some distro builds of cosign.

Oh My Pi users: refresh the bridge after upgrading. The [#504] fix is in the generated dcg-guard.ts file, not only in the dcg binary, so an existing bridge keeps the old behaviour until it is rewritten.

• dcg update rewrites your user/profile bridge for you when omp is on your PATH (it runs the new installer, which runs dcg install --omp --force). It does not if you pass --no-configure.
• If you upgraded any other way (package manager, manual download, dcg update --no-configure), run dcg install --omp --force. Without --force the command sees the existing bridge and leaves it alone.
• A project-scoped bridge (dcg install --omp --project) is never touched by dcg update. Run dcg install --omp --force --project in that project, or dcg doctor --fix there.
• dcg doctor reports an old bridge as "OUTDATED OR DAMAGED".

Restart omp afterwards so it loads the new file.

Fixed

• The OMP bridge judged nothing when the command's working directory did not exist (#504, 38de715). The bridge started dcg inside that directory; when it was missing, starting dcg failed with an ENOENT error naming the dcg binary, and the command ran with no verdict and no audit record, even with DCG_UNVERIFIED_DECISION=deny. The bridge now starts dcg from the nearest existing parent directory, so the same project config, allowlists and Git branch apply, and passes the real working directory along. Directory-scoped allowlist entries are not applied when that directory does not exist. If dcg still cannot start, the log names the binary and both directories, and DCG_UNVERIFIED_DECISION=deny blocks the command; without that setting the command is allowed, as before.
• The installers skipped signature verification with cosign builds that add a version suffix (#505, 6ba4a76). install.sh and install.ps1 could not read a cosign version such as Arch's v3.1.3+dirty, treated it as older than the CVE-2026-22703 fixes, and skipped the Sigstore bundle check with a warning. Both now read the version as SemVer: build metadata is ignored, and a pre-release such as v3.0.4-rc.1 still counts as older than v3.0.4.

Full detail: CHANGELOG.md (github.com).

Assets

Six archives, each holding only the dcg binary (dcg.exe on Windows): x86_64-unknown-linux-musl (static), aarch64-unknown-linux-gnu (glibc 2.28 or newer), x86_64-apple-darwin, aarch64-apple-darwin, x86_64-pc-windows-msvc, aarch64-pc-windows-msvc. Every archive and both installers have a .sha256, a minisign signature (key 69B3955C8D2E62A8, the key pinned in install.sh, install.ps1 and release/minisign.pub) and a key-based Sigstore bundle (.sigstore.json, the installers' pinned cosign key). SHA256SUMS is signed with the same minisign key. Built on self-hosted machines with the dsr release process; GitHub Actions were not used.

:::bash
V=v0.15.1; T=aarch64-apple-darwin   # or x86_64-unknown-linux-musl, etc.
curl -fLO "https://github.com/Dicklesworthstone/destructive_command_guard/releases/download/$V/dcg-$T.tar.xz"
curl -fLO "https://github.com/Dicklesworthstone/destructive_command_guard/releases/download/$V/dcg-$T.tar.xz.minisig"
minisign -Vm "dcg-$T.tar.xz" -P RWSoYi6NXJWzaRs1mJmOwwXrZfPWcq6MXnQlNMLBYKzlIQTLwuVQG6uO