Docker Build Uses pip install Without Hash Pinning

[henry0816191]

Problem

The Dockerfile uses pip install . to install paperscout and its dependencies, pulling whatever versions pip resolves at build time without hash verification. This means the same Dockerfile can produce different images depending on when it is built, and a supply-chain attack on any transitive dependency would be silently incorporated into the production image. For a service that handles Slack OAuth tokens and PostgreSQL credentials, non-reproducible builds represent a meaningful attack surface.

Acceptance Criteria

• Update Dockerfile to install dependencies from a hash-pinned requirements file (e.g., pip install --require-hashes -r requirements.txt)
• Pin the base Docker image to a digest (e.g., python:3.12-slim@sha256:...) rather than a mutable tag
• Add a multi-stage build if not already present: build stage installs dependencies, final stage copies only the installed packages
• Verify the image builds and all tests pass inside the container
• Document the rebuild process in CONTRIBUTING.md or deploy/SERVER_SETUP.md

Implementation Notes

This item is closely related to item 3 (No dependency lockfile). If pip-tools or uv is adopted for the lockfile, the same requirements.txt with hashes can be used in the Dockerfile. The --require-hashes flag enforces that every package in the requirements file has a hash, providing tamper detection. Consider also adding --no-deps to prevent pip from pulling unlisted transitive dependencies.

References

• Eval finding: Test 26 (Dependency Health), cluster Dependencies and Build
• Related files: Dockerfile, docker-compose.yml, pyproject.toml