🔵 Dev Dockerfiles run as root with an unpinned base image

[Ejirowebfi]

Severity: Low · Area: Infra (frontend/Dockerfile.dev, contracts/Dockerfile.dev, docker-compose.yml)

Description

Neither frontend/Dockerfile.dev nor contracts/Dockerfile.dev declares a non-root USER, so both containers run their build/dev tooling as root by default. docker-compose.yml bind-mounts live source into the frontend container (./frontend:/app), and contracts/Dockerfile.dev pins its base image to a mutable, dated tag (rust:1.75-slim) with no digest pin. This is development-only blast radius (these are not the images used for any production deployment, per the README's Vercel/Netlify/static-hosting deployment guidance), but a compromised transitive build dependency (npm ci, cargo build) would still run as root with write access to the bind-mounted host source tree.

Tasks

• Add a non-root USER directive to both Dockerfile.dev files, with appropriate ownership of working directories.
• Pin contracts/Dockerfile.dev's base image by digest (rust:1.75-slim@sha256:...) rather than a mutable tag.
• Confirm hot-reload/volume-mount workflows (CHOKIDAR_USEPOLLING, etc.) still function correctly for a non-root user, adjusting file permissions/ownership in the Dockerfile as needed.

Acceptance Criteria

• docker compose up -d still functions identically for local development (hot reload, contract building) after the change.
• Neither container runs its main process as root, verified via docker compose exec <service> whoami.
• The Rust base image is pinned by digest.

---

Issue 28 of 30 from the 2026-08 codebase audit tracked in ISSUES.md.

[joshkirojohn212-jpg]

Hi maintainer,

I would like to work on this issue.

From my understanding, the goal is to replace the compile-time HISTORY_MAX_DEPTH constant with an admin-configurable on-chain value while enforcing a hard upper bound at the contract level. This will allow LedgerLens to adjust history retention requirements without requiring contract redeployment, while preserving predictable storage costs and maintaining compatibility with existing integrations.

I have experience working with Rust smart contracts, storage-driven configuration patterns, and state management in blockchain applications. I am comfortable implementing configurable contract parameters, validation logic, and storage-backed settings while ensuring behavior remains deterministic and well-tested.

If assigned, I will:

• Review the current history storage implementation and trace how HISTORY_MAX_DEPTH is used throughout the score history lifecycle

• Replace the existing compile-time depth constant with the proposed MAX_HISTORY_DEPTH and DEFAULT_HISTORY_MAX_DEPTH constants

• Add the new HistoryMaxDepth storage key to DataKey and implement storage helpers for retrieving and persisting the configured depth

• Update push_score_history to use the configured depth from contract storage rather than a compile-time value

• Implement set_history_max_depth with proper admin authorization and validation to reject zero values and values exceeding the configured ceiling

• Implement get_history_max_depth to expose the current configured value while correctly falling back to the default when no configuration exists

• Add the new InvalidHistoryDepth error and ensure validation failures return the appropriate contract error

• Carefully implement and verify the lazy-truncation behavior when history depth is reduced, ensuring existing entries remain intact until the next submit_score operation triggers the eviction logic

• Add comprehensive Rustdoc documentation explaining the depth configuration behavior and explicitly documenting the lazy-truncation edge case

• Update the README to include both configuration functions and their intended usage

• Add and validate all required test cases covering default values, depth increases, depth decreases, ceiling enforcement, invalid depth handling, and lazy-truncation behavior

• Verify that storage usage remains bounded by the hard ceiling and that the configurable depth integrates cleanly with the existing ring-buffer implementation

I will also ensure the implementation remains consistent with existing Soroban storage patterns, keeps function signatures clean, and avoids introducing unnecessary coupling throughout the history management code.

Kindly assign this issue to me. Thank you!

[grantfox-oss]

🦊 GrantFox — @joshkirojohn212-jpg has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #1116)
2. Your PR will be reviewed by the Favourorg maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!

@joshkirojohn212-jpg's PR #1140 was approved and merged by @Ejirowebfi.

🏆 @joshkirojohn212-jpg: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (274 total points). Track your full progress on GrantFox.

👏 Great work, @joshkirojohn212-jpg! Keep contributing to Favourorg.

[github-actions]

🎉 This issue has been resolved in version 1.8.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀