Every release carries the same set of files:
| File | What it is |
|---|---|
dplens-<version>.msi | The installer. <version> is MAJOR.MINOR.<build>, where <build> is the commit count of the release — it is also the MSI's ProductVersion, so a newer build number always upgrades an older one and a downgrade is refused. |
dp-deploy.exe | The deployment bundle builder (see the deployment bundle). |
SHA256SUMS | One SHA-256 per file. Its first line states whether the release is signed or an unsigned pre-release. |
sbom.cdx.json, sbom.spdx.json | The software bill of materials (CycloneDX and SPDX) of the shipped binaries. |
cargo-tree.txt | The dependency set the build resolved; the published bill of materials is checked against it. |
SIGNING-SKIPPED.txt | Present only on an unsigned pre-release: names the artefacts whose signature checks were skipped and why. |
1. Check the checksums
cd <download folder>
$sums = Get-Content SHA256SUMS | Where-Object { $_ -notlike '#*' }
foreach ($line in $sums) {
$hash, $name = $line -split '\s+', 2
$actual = (Get-FileHash $name -Algorithm SHA256).Hash.ToLower()
"{0} {1}" -f $(if ($actual -eq $hash) { 'OK ' } else { 'FAIL' }), $name
}
Every line must read OK. A FAIL means the file is not the one the release published — do not install it.
2. Check the Authenticode signature
Signed releases carry an Authenticode signature (SHA-256, RFC 3161 timestamped) on every executable we publish, including the code inside the MSI, and on the MSI itself. Verify the two files you downloaded with the Windows SDK's signtool, or with PowerShell alone:
Get-AuthenticodeSignature .\dplens-<version>.msi, .\dp-deploy.exe | Format-List Path, Status, SignerCertificate
Status must be Valid and the signer certificate must name the DPLens publisher. With signtool (Windows SDK):
signtool verify /pa /v dplens-<version>.msi
signtool verify /pa /v dp-deploy.exe
Unsigned pre-releases
A pre-release may be published unsigned. Where it is, it says so in three places: the release name says (UNSIGNED pre-release), the first line of SHA256SUMS says UNSIGNED, and SIGNING-SKIPPED.txt is attached. Such a build is complete and checksummed but carries no signature — Get-AuthenticodeSignature reports NotSigned. Treat an unsigned pre-release as evaluation software: do not deploy it to a production estate. A full release is never published unsigned, so never accept an unsigned file that claims to be one.
3. The SBOM
sbom.cdx.json (CycloneDX 1.5) and sbom.spdx.json (SPDX 2.3) list every Rust crate compiled into the shipped binaries. Build-time tooling is not shipped and is not listed. The list is checked against the dependency set the build actually resolved, so it can neither omit nor invent a dependency. DPLens loads no code at run time (no plug-ins, no scripts), so the SBOM is the complete inventory.
4. What the installer verifies for you
At install the MSI verifies a supplied licence key against the target host before the service starts and fails loudly on any mismatch; see the deployment bundle for the fleet path. The agent itself reads only the Windows Event Log, the files you configure and the network sources you enable; it never contacts the publisher (no telemetry, no licence server).