Skip to main content

Oci/image/patch

@hivemq/oci/image/patchv2026.06.26.156· 11d agoMODELSWORKFLOWS
01README

Take a single base OCI image identifier and emit its security-patched counterpart under the HiveMQ naming convention (//:-hivemq-patched-). A pure logic model (plan generates the security-upgrade Dockerfile + derives the re-homed target; verify asserts the expected fixed package versions) plus a bundled workflow that orchestrates a container CLI wrapper around it: plan, build the multi-arch image, verify the expected versions on every platform of it, then push. Two workflow variants ship: the Apple @hivemq/container engine (self-hosted macOS) and @hivemq/docker (standard Linux/GitHub-hosted runners). Motivated by PLT-941 (openssl CVE-2026-45447): own the patch cadence instead of waiting on upstream base rebuilds. Registry credentials are injected from a swamp vault at run time and never persisted in a committed instance.

02Models1
@hivemq/oci/image/patchv2026.06.26.2oci_image_patch.ts
fn plan()
Generate the security-upgrade Dockerfile and derive the re-homed target identifier (docker.io/<namespace>/<flattened>:<tag>-hivemq-patched-<date>), platforms, and dpkg verify command. Pure — drives no CLI.
fn verify(platform: string, stdout: string)
Assert the built (not-yet-pushed) multi-arch image meets expectations on every platform: parse each platform's dpkg-query output and fail if any expected package is absent or below its expected fixed version (dpkg version ordering) on any platform. The workflow pushes only after this succeeds.
ArgumentTypeDescription
platformstring
stdoutstring

Resources

plan(infinite)— The build plan: security-upgrade Dockerfile, re-homed target identifier, platforms, dpkg verify command, and expected fixed versions
verification(infinite)— The result of asserting expected fixed package versions are present
03Workflows2
@hivemq/oci/image/patch/containerc1a7b0de-0941-4a11-9c00-c0ffee000941

Take a declared list of base OCI images and emit each one's security-patched counterpart under the HiveMQ naming convention. Fans out over the list: for every image it plans the build, builds the multi-arch image to be published, verifies the expected fixed package versions on every platform of that image, then pushes it — so the artifact that is verified is the artifact that ships. Requires two pre-created model instances (names referenced below): - `oci-image-patch` (type @hivemq/oci/image/

patchFor every image, plan, build multi-arch, verify every platform, then push
1.planoci-image-patch.plan— Generate the Dockerfile + derive the re-homed target identifier
2.buildcontainer.build— Build the single multi-arch image to be published (repeated --arch)
3.inspectcontainer.inspectPlatforms— Capture installed package versions from the built image on every platform
4.verifyoci-image-patch.verify— Assert the expected fixed versions are present on every platform (fails the run otherwise)
5.logincontainer.registryLogin— Authenticate once to the shared registry (creds from vault, piped on stdin)
6.pushcontainer.imagePush— Push the verified multi-arch image and capture the digest
@hivemq/oci/image/patch/dockerd0c4e7a2-0941-4d0c-9e00-c0ffeed0c111

docker-engine variant of @hivemq/oci/image/patch, for standard Linux CI runners (GitHub-hosted) where Apple `container` is unavailable. Takes a declared list of base OCI images and emits each one's security-patched counterpart under the HiveMQ naming convention. Fans out over the list: for every image it plans the build, then builds + inspects every platform single-arch (the docker engine can't hold a multi-arch image locally), verifies the expected fixed package versions on every platform, and

patchFor every image, plan, build + inspect every platform, verify, then push the manifest list
1.planoci-image-patch.plan— Generate the Dockerfile + derive the re-homed target identifier
2.inspectdocker.buildInspectPlatforms— Build each platform single-arch (buildx --load) and capture installed package versions
3.verifyoci-image-patch.verify— Assert the expected fixed versions are present on every platform (fails the run otherwise)
4.logindocker.login— Authenticate once to the shared registry (creds from vault, piped on stdin)
5.pushdocker.buildxBuild— Build + push the verified multi-arch manifest list (rebuilt from the warm buildx cache) and capture the digest
04Previous Versions4
2026.06.26.148Jun 26, 2026
2026.06.25.146Jun 25, 2026
2026.06.25.138Jun 25, 2026
2026.06.25.135Jun 25, 2026
05Stats
D
50 / 100
Downloads
12
Archive size
18.6 KB
  • Has README or module doc0/2missing
  • README has a code example0/1missing
  • README is substantive0/1pending
  • Most symbols documented1/1earned
  • No slow types (deprecated)1/1earned
  • Dependencies pass trust audit2/2earned
  • Has description1/1earned
  • Platform support declared (or universal)2/2earned
  • License declared0/1missing
  • Verified public repository0/2missing
06Platforms
07Labels