renderer/Dockerfile and bridges/remote-renderer/Dockerfile copied *-0.1.0-SNAPSHOT.jar, but the reactor version is ${revision} (1.x), so neither built a released version. Both now resolve the released qbit-document-renderer / qqq-remote-renderer-transport and their runtime libraries at an exact, required RENDERER_VERSION / TRANSPORT_VERSION from the QRun-IO Gitea Maven registry and Maven Central (via a small release-image/pom.xml per image; Maven checks registry checksums). SNAPSHOT and *forge* versions are refused. Reviewed hardening is unchanged (digest-pinned BUILD_IMAGE/JAVA_IMAGE, UID 65532, Zint built from vendor/, no reactor build context). Adds renderer/IMAGE-PUBLISH.md (repeatable build, scan, publish steps and the 1.0.0 pins) and renderer/image-pins.sh (prints the gg-forge-cd classpath and SHA256 pins from a published image).
No image-publishing workflow exists in this repo, so none is added; the manual steps are documented.
Version
1.0.0. renderer/ and bridges/remote-renderer/ sources are identical between v1.0.0 and v1.1.0-RC.1, and gg-forge pins 1.0.0. Versus the 2026-11-05 local qualification (a 0.1.0-forge build): transport source is unchanged; the engine gained the barHeight refusal (UNSUPPORTED_BARCODE_OPTION) for fixed-geometry encoders and GS1 DataBar stacked (10b3a71), plus OpenHTML now at the family version. Java, Zint and patchset hashes and all third-party JAR hashes are identical to the local image.
Verified
mvn -B -pl renderer,bridges/remote-renderer/transport -am verify in the reviewed Maven image (no skip flags): 15 + 174 + 19 tests, 0 failures, Checkstyle clean, BUILD SUCCESS.
Both images built from 1.0.0 and pushed to ghcr.io/gg-engineering/qqq-document-renderer and qqq-remote-renderer (tag 1.0.0, manifest digests in IMAGE-PUBLISH.md flow).
Service image run read-only, non-root, caps dropped, no-new-privileges; over real mTLS (ephemeral certs) it answered CATALOG, and rendered PDF (Code128, GS1-128, Zint DotCode) and ZPL.
Trivy (vuln, HIGH/CRITICAL): 0 in Java JARs; 2 HIGH in the pinned Ubuntu base (apt/libapt-pkg6.0t64 2.8.3, fixed 2.8.4ubuntu0.1), not fixable without changing the reviewed base digest.
Not verified
No cluster run, no handshake against Forge, no gVisor/hostile-input qualification (service is TRUSTED_LAB only), no byte-for-byte rebuild of the OpenHTML jar from vendor/, pull-secret read access to the new packages.
## What
`renderer/Dockerfile` and `bridges/remote-renderer/Dockerfile` copied `*-0.1.0-SNAPSHOT.jar`, but the reactor version is `${revision}` (1.x), so neither built a released version. Both now resolve the released `qbit-document-renderer` / `qqq-remote-renderer-transport` and their runtime libraries at an exact, required `RENDERER_VERSION` / `TRANSPORT_VERSION` from the QRun-IO Gitea Maven registry and Maven Central (via a small `release-image/pom.xml` per image; Maven checks registry checksums). SNAPSHOT and `*forge*` versions are refused. Reviewed hardening is unchanged (digest-pinned `BUILD_IMAGE`/`JAVA_IMAGE`, UID 65532, Zint built from `vendor/`, no reactor build context). Adds `renderer/IMAGE-PUBLISH.md` (repeatable build, scan, publish steps and the 1.0.0 pins) and `renderer/image-pins.sh` (prints the gg-forge-cd classpath and SHA256 pins from a published image).
No image-publishing workflow exists in this repo, so none is added; the manual steps are documented.
## Version
1.0.0. `renderer/` and `bridges/remote-renderer/` sources are identical between `v1.0.0` and `v1.1.0-RC.1`, and `gg-forge` pins 1.0.0. Versus the 2026-11-05 local qualification (a `0.1.0-forge` build): transport source is unchanged; the engine gained the `barHeight` refusal (`UNSUPPORTED_BARCODE_OPTION`) for fixed-geometry encoders and GS1 DataBar stacked (10b3a71), plus OpenHTML now at the family version. Java, Zint and patchset hashes and all third-party JAR hashes are identical to the local image.
## Verified
- `mvn -B -pl renderer,bridges/remote-renderer/transport -am verify` in the reviewed Maven image (no skip flags): 15 + 174 + 19 tests, 0 failures, Checkstyle clean, BUILD SUCCESS.
- Both images built from 1.0.0 and pushed to `ghcr.io/gg-engineering/qqq-document-renderer` and `qqq-remote-renderer` (tag `1.0.0`, manifest digests in `IMAGE-PUBLISH.md` flow).
- Service image run read-only, non-root, caps dropped, no-new-privileges; over real mTLS (ephemeral certs) it answered CATALOG, and rendered PDF (Code128, GS1-128, Zint DotCode) and ZPL.
- Trivy (vuln, HIGH/CRITICAL): 0 in Java JARs; 2 HIGH in the pinned Ubuntu base (`apt`/`libapt-pkg6.0t64` 2.8.3, fixed 2.8.4ubuntu0.1), not fixable without changing the reviewed base digest.
## Not verified
No cluster run, no handshake against Forge, no gVisor/hostile-input qualification (service is TRUSTED_LAB only), no byte-for-byte rebuild of the OpenHTML jar from `vendor/`, pull-secret read access to the new packages.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Both Dockerfiles copied 0.1.0-SNAPSHOT jars that the reactor no longer produces
(version is ${revision}), so neither built a released version. They now resolve the
released qbit-document-renderer and qqq-remote-renderer-transport (and their runtime
libraries) at an exact, required RENDERER_VERSION / TRANSPORT_VERSION from the
QRun-IO Gitea Maven registry and Maven Central, refusing SNAPSHOT and local
(*forge*) versions. The reviewed hardening is unchanged: digest-pinned
BUILD_IMAGE/JAVA_IMAGE, non-root 65532, read-only-root friendly, Zint built from
vendor/. The reactor build context is no longer needed.
Adds IMAGE-PUBLISH.md (repeatable build/scan/publish steps and the 1.0.0 pins) and
image-pins.sh (prints the gg-forge-cd classpath and SHA256 pins from a published
image). Images for 1.0.0 were built, smoke-tested over mTLS and published to GHCR
under gg-engineering by hand; no workflow publishes images.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What
renderer/Dockerfileandbridges/remote-renderer/Dockerfilecopied*-0.1.0-SNAPSHOT.jar, but the reactor version is${revision}(1.x), so neither built a released version. Both now resolve the releasedqbit-document-renderer/qqq-remote-renderer-transportand their runtime libraries at an exact, requiredRENDERER_VERSION/TRANSPORT_VERSIONfrom the QRun-IO Gitea Maven registry and Maven Central (via a smallrelease-image/pom.xmlper image; Maven checks registry checksums). SNAPSHOT and*forge*versions are refused. Reviewed hardening is unchanged (digest-pinnedBUILD_IMAGE/JAVA_IMAGE, UID 65532, Zint built fromvendor/, no reactor build context). Addsrenderer/IMAGE-PUBLISH.md(repeatable build, scan, publish steps and the 1.0.0 pins) andrenderer/image-pins.sh(prints the gg-forge-cd classpath and SHA256 pins from a published image).No image-publishing workflow exists in this repo, so none is added; the manual steps are documented.
Version
1.0.0.
renderer/andbridges/remote-renderer/sources are identical betweenv1.0.0andv1.1.0-RC.1, andgg-forgepins 1.0.0. Versus the 2026-11-05 local qualification (a0.1.0-forgebuild): transport source is unchanged; the engine gained thebarHeightrefusal (UNSUPPORTED_BARCODE_OPTION) for fixed-geometry encoders and GS1 DataBar stacked (10b3a71), plus OpenHTML now at the family version. Java, Zint and patchset hashes and all third-party JAR hashes are identical to the local image.Verified
mvn -B -pl renderer,bridges/remote-renderer/transport -am verifyin the reviewed Maven image (no skip flags): 15 + 174 + 19 tests, 0 failures, Checkstyle clean, BUILD SUCCESS.ghcr.io/gg-engineering/qqq-document-rendererandqqq-remote-renderer(tag1.0.0, manifest digests inIMAGE-PUBLISH.mdflow).apt/libapt-pkg6.0t642.8.3, fixed 2.8.4ubuntu0.1), not fixable without changing the reviewed base digest.Not verified
No cluster run, no handshake against Forge, no gVisor/hostile-input qualification (service is TRUSTED_LAB only), no byte-for-byte rebuild of the OpenHTML jar from
vendor/, pull-secret read access to the new packages.🤖 Generated with Claude Code
Both Dockerfiles copied 0.1.0-SNAPSHOT jars that the reactor no longer produces (version is ${revision}), so neither built a released version. They now resolve the released qbit-document-renderer and qqq-remote-renderer-transport (and their runtime libraries) at an exact, required RENDERER_VERSION / TRANSPORT_VERSION from the QRun-IO Gitea Maven registry and Maven Central, refusing SNAPSHOT and local (*forge*) versions. The reviewed hardening is unchanged: digest-pinned BUILD_IMAGE/JAVA_IMAGE, non-root 65532, read-only-root friendly, Zint built from vendor/. The reactor build context is no longer needed. Adds IMAGE-PUBLISH.md (repeatable build/scan/publish steps and the 1.0.0 pins) and image-pins.sh (prints the gg-forge-cd classpath and SHA256 pins from a published image). Images for 1.0.0 were built, smoke-tested over mTLS and published to GHCR under gg-engineering by hand; no workflow publishes images. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>