Skip to content

ProtectionAI v1.7.3

Choose a tag to compare

View all tags
@Cwgtshome Cwgtshome released this 03 Aug 12:57
v1.7.3
b675949

101 registered [WorkspaceView] modules, 30 AI copilot tools, 4 AI providers, 7 UI languages,
3,056 tests. Ribbon: 17 tabs, 85 groups, 144 controls. No counts move.

Changed

  • "Are the outputs live, and how do I drop them" now sits at the centre of the status bar. Both
    the ■ STOP (F12) control and the output-state chip were at the far left of a strip that also
    carries the relay name, the test-set state, the licence and the clock — the most consequential
    thing the shell can tell an operator, competing with the least. They are now a single cluster
    pinned to the true horizontal centre of the window, which is where the eye goes and where a
    glance lands when someone is holding test leads.

    The status bar is now one item holding a three-column grid rather than a row of docked items.
    That is the substance of the change: a DockPanel, which is the StatusBar's default items
    panel, can dock left or right but cannot centre against the window, so the safety cluster could
    not have been placed there by alignment alone. The outer columns are equal-width stars and the
    middle is Auto, so the cluster stays centred at any width regardless of how much text either
    side happens to hold. Verified in the running app: the pair straddles the window centre to within
    2 px at 5146 px wide.

    The output-state chip is also larger — 12.5 px caption against the 11 px of the surrounding status
    text, with more padding and a taller minimum. Matching the licence state and the clock would have
    set the words that answer "can I touch the wiring" at the size of the words that answer "what time
    is it". The four renderings, their glyph shapes and the rule that colour never carries the state
    alone are unchanged.

Added

  • scripts\check-theme.ps1 — audits both semantic palettes without launching anything: every
    x:Key in one theme must exist in the other (the dictionaries are swapped wholesale at runtime,
    so a key present in only one resolves to nothing after a theme switch, silently and in one theme
    only), and 88 foreground/background pairs are checked against the floor their role requires —
    4.5:1 for text and for any caption on a filled chip or button in every state, 3:1 for structural
    lines, focus rings and the ribbon category accents. The contrast claims in the theme files'
    comments were verified once, by hand, and every later edit was on trust; they are now asserted.

  • scripts\check-theme-runtime.ps1 — the half a static audit cannot reach. It drives the
    published binary, switches Light then Dark, and samples rendered pixels against the declared
    palette. A correct palette on disk and the wrong colours on screen is exactly the shape of the
    AvalonDock tab-strip defect fixed in v1.7.0, where every resource mapping applied and the tabs
    stayed light in dark mode. It also asserts that the emergency-stop field is safety yellow
    #FFD100 in both themes and identically so, because that theme-invariance is a claim about
    safety chrome and nothing else was checking it. A blank capture is reported as INCONCLUSIVE
    rather than as a failure, so a sleeping monitor can never be mistaken for a theming defect.

Installer

ProtectionAI-Setup.msi is a Windows Installer (MSI) package. It installs ProtectionAI in Program Files, creates a Start Menu shortcut, registers Apps & Features uninstall support, and supports in-place major upgrades. ProtectionAI.App.exe is the same application as a self-contained single-file executable, for people who cannot run an installer.

This release is not Authenticode code signed. Windows SmartScreen will warn you when you run it, and that warning is expected. The checks below prove integrity (the bytes are the bytes we built) and source binding (the signed manifest came from this repository, tag and commit). They are not a Windows trust decision and do not stop SmartScreen warning.

Artifact digests (SHA-256)

105c51c9f4b5f6f1af69e5054b7377b2ec3e3a64b72174e2273afbf46156ec00  protectionai-1.7.3-cyclonedx.json
543929834be1b3576cc63ffe44766dbac9da455da54055087e10ec4bca4131b4  protectionai-1.7.3-cyclonedx.json.sha256
89008b1fd7865dc82413feb2b54e905af928557ed64c23c1bfd87e70edc23c04  ProtectionAI-Setup.msi
bf6f6c9bd6213f8e729f96f29629a647f94d42bd51a2a9d7e663c6aba94fa9e4  ProtectionAI.App.exe

Published alongside the artifacts as SHA256SUMS, with a detached Sigstore signature (SHA256SUMS.sig), the ephemeral signing certificate (SHA256SUMS.pem) and a self-contained bundle (SHA256SUMS.cosign.bundle). The software bill of materials (protectionai-1.7.3-cyclonedx.json) and its checksum sidecar (protectionai-1.7.3-cyclonedx.json.sha256) are both attached and covered by the signed manifest.

1. Verify integrity — the files are what we built

PowerShell:

foreach ($line in Get-Content .\SHA256SUMS) {
  $expected, $name = $line -split '\s+', 2
  $actual = (Get-FileHash $name.Trim() -Algorithm SHA256).Hash.ToLower()
  "{0}  {1}" -f $(if ($actual -eq $expected) { "OK  " } else { "FAILED" }), $name.Trim()
}

POSIX shell:

sha256sum -c SHA256SUMS

2. Verify authenticity — the digest list itself is genuine

Step 1 only proves the files match the list. This proves the list was produced by this release workflow. Install cosign and run:

cosign verify-blob SHA256SUMS \
  --signature SHA256SUMS.sig \
  --certificate SHA256SUMS.pem \
  --certificate-identity https://github.com/Cwgtshome/ProtectionAI/.github/workflows/release.yml@refs/tags/v1.7.3 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-github-workflow-repository Cwgtshome/ProtectionAI \
  --certificate-github-workflow-ref refs/tags/v1.7.3 \
  --certificate-github-workflow-sha adca8c4936acac67074e38781928178320ac0b9c

Or with the bundle, which needs no separate certificate:

cosign verify-blob SHA256SUMS \
  --bundle SHA256SUMS.cosign.bundle \
  --certificate-identity https://github.com/Cwgtshome/ProtectionAI/.github/workflows/release.yml@refs/tags/v1.7.3 \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  --certificate-github-workflow-repository Cwgtshome/ProtectionAI \
  --certificate-github-workflow-ref refs/tags/v1.7.3 \
  --certificate-github-workflow-sha adca8c4936acac67074e38781928178320ac0b9c

Pin all five certificate constraints exactly as shown: identity, issuer, repository, ref and SHA. Together they reject a signature from another workflow, repository, tag or commit. There is no long-lived private key: the certificate above was issued to this workflow's OIDC identity, is valid for minutes, and the signing event is recorded in the public Rekor transparency log.

3. Build provenance — not available for this release

No GitHub-hosted SLSA build-provenance attestation was recorded, so gh attestation verify will not find one. GitHub's attestation store is not offered to user-owned private repositories on this plan, and the source repository is private.

What still holds: the signed SHA256SUMS manifest binds every shipped content file by digest, and the Sigstore certificate in step 2 binds that manifest to this repository, tag ref and exact source SHA against a public transparency log. What is missing is GitHub's separate SLSA predicate and attestation-store record; no SLSA level is claimed.

Built from Cwgtshome/ProtectionAI@adca8c4. See docs/RELEASE-INTEGRITY.md for what each file is and why it exists.

Assets 10
Loading