didericis/bot-bottle
1
0
Fork 0
Code Issues 32 Pull Requests 9 Actions Packages Releases Wiki Activity

Pin and verify all container-image build inputs #499

New Issue
Closed
opened 2026-07-26 03:36:34 -04:00 by didericis-codex · 0 comments
didericis-codex commented 2026-07-26 03:36:34 -04:00
Collaborator
Copy Link
Copy Source

Problem

The container images that implement bot-bottle's runtime and security boundaries are not fully reproducible. A rebuild of the same commit can currently execute or install different upstream bytes:

  • Dockerfile.gateway and Dockerfile.orchestrator use mutable python:3.12-slim base tags.
  • The built-in Claude, Codex, and Pi images use mutable node:22-trixie-slim base tags.
  • Dockerfile.orchestrator.fc uses the mutable local tag bot-bottle-orchestrator:latest.
  • The gateway pins mitmproxy==11.1.3, but its transitive pip dependency graph is neither locked nor hash-verified.
  • The Codex image runs curl -fsSL https://chatgpt.com/codex/install.sh | sh; the fetched installer and resulting CLI version are not pinned or verified.
  • The Pi image installs @earendil-works/pi-coding-agent and five pi install npm:... extensions without versions.

Gitleaks already demonstrates the desired pattern: its release version and per-architecture SHA-256 are pinned and verified before installation.

For a sandboxing tool, mutable control-plane/gateway inputs are a high-impact supply-chain risk. Mutable agent-image inputs matter too: although the agent process is untrusted by design, a compromised base or installer executes during image construction and may target the host builder or exploit the weaker legacy Docker boundary.

Proposed work

  1. Pin every external base image by digest while retaining a readable version tag in the FROM reference or adjacent metadata.
  2. Make the Firecracker orchestrator image consume the exact locally built orchestrator image ID/digest rather than :latest.
  3. Generate a locked, hash-verified dependency set for the gateway's mitmproxy installation.
  4. Replace the live Codex installer pipe with a versioned artifact or installer whose digest/signature is verified before execution.
  5. Pin the Pi CLI and every installed extension to exact versions and verify the resolved artifacts or lockfile.
  6. Add a documented, deliberate dependency-refresh process that updates versions, digests, and compatibility tests together.
  7. Add CI checks rejecting mutable/unversioned inputs in the built-in Dockerfiles.

Image signing and attestation remain tracked separately in #339; this issue establishes deterministic, verified build inputs first.

Acceptance criteria

  • Rebuilding a commit resolves the same base-image digests and application dependency versions on each supported architecture.
  • No built-in Dockerfile pipes an unverified network response into a shell.
  • No built-in provider CLI or extension install is unversioned.
  • Gateway Python dependencies are fully locked and integrity-checked.
  • CI fails when a mutable base tag, :latest dependency, unpinned package, or unverified remote installer is introduced.
  • The dependency update procedure is documented and exercised by image-build tests.

Found during the whole-project quality evaluation following #444 / PR #491.

## Problem The container images that implement bot-bottle's runtime and security boundaries are not fully reproducible. A rebuild of the same commit can currently execute or install different upstream bytes: - `Dockerfile.gateway` and `Dockerfile.orchestrator` use mutable `python:3.12-slim` base tags. - The built-in Claude, Codex, and Pi images use mutable `node:22-trixie-slim` base tags. - `Dockerfile.orchestrator.fc` uses the mutable local tag `bot-bottle-orchestrator:latest`. - The gateway pins `mitmproxy==11.1.3`, but its transitive pip dependency graph is neither locked nor hash-verified. - The Codex image runs `curl -fsSL https://chatgpt.com/codex/install.sh | sh`; the fetched installer and resulting CLI version are not pinned or verified. - The Pi image installs `@earendil-works/pi-coding-agent` and five `pi install npm:...` extensions without versions. Gitleaks already demonstrates the desired pattern: its release version and per-architecture SHA-256 are pinned and verified before installation. For a sandboxing tool, mutable control-plane/gateway inputs are a high-impact supply-chain risk. Mutable agent-image inputs matter too: although the agent process is untrusted by design, a compromised base or installer executes during image construction and may target the host builder or exploit the weaker legacy Docker boundary. ## Proposed work 1. Pin every external base image by digest while retaining a readable version tag in the `FROM` reference or adjacent metadata. 2. Make the Firecracker orchestrator image consume the exact locally built orchestrator image ID/digest rather than `:latest`. 3. Generate a locked, hash-verified dependency set for the gateway's mitmproxy installation. 4. Replace the live Codex installer pipe with a versioned artifact or installer whose digest/signature is verified before execution. 5. Pin the Pi CLI and every installed extension to exact versions and verify the resolved artifacts or lockfile. 6. Add a documented, deliberate dependency-refresh process that updates versions, digests, and compatibility tests together. 7. Add CI checks rejecting mutable/unversioned inputs in the built-in Dockerfiles. Image signing and attestation remain tracked separately in #339; this issue establishes deterministic, verified build inputs first. ## Acceptance criteria - Rebuilding a commit resolves the same base-image digests and application dependency versions on each supported architecture. - No built-in Dockerfile pipes an unverified network response into a shell. - No built-in provider CLI or extension install is unversioned. - Gateway Python dependencies are fully locked and integrity-checked. - CI fails when a mutable base tag, `:latest` dependency, unpinned package, or unverified remote installer is introduced. - The dependency update procedure is documented and exercised by image-build tests. Found during the whole-project quality evaluation following #444 / PR #491.
didericis-codex added the Kind/Security
Priority
High
2
Kind/Enhancement labels 2026-07-26 03:36:34 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Low
4
The priority is low
Priority
Medium
3
The priority is medium
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status/Needs Triage
Awaiting initial classification
No Label Kind/Enhancement Kind/Security
Priority
High
2
Milestone
No items
No Milestone
Assignees
Clear assignees
didericis-claude (didericis (claude)) didericis-codex (didericis (codex)) didericis-gemma (gemma) didericis
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: didericis/bot-bottle#499
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?