Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

amber: repro_deps_pinned and repro_build_env_declared only look at the repo root

Open
  • Is something wrong?
#536 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
tooling

Research direction

Start in packages/darnit-amber/src/darnit_amber/handlers.py at the requirements lookup around line 141, then inspect the container_files table around line 261 and the related controls. Decide how multiple matching files should affect the result before implementing bounded-depth discovery for the paths described. Done means nested requirements and container files are recognized and the aggregation behavior is covered by tests.

Written by the indexing model from the issue text.

Description

module-reproducibility

repro_deps_pinned and repro_build_env_declared look for their evidence at the repository root only, so a project that keeps requirements files and Dockerfiles in subdirectories scores WARN despite having fully pinned dependencies and a declared build environment.

git clone https://github.com/bouhoula/alsacnc.git
cd alsacnc && git checkout v1.0.3 # cd13e98
darnit audit --show-all --framework amber .

Total: 5 | Pass: 0 | Fail: 0 | Warn: 5 | N/A: 0 | Error: 0 | Pending LLM: 0
RE-01.01 .. RE-03.01: WARN - Could not automatically verify

Repo has:
requirements/crawler_requirements.txt db-dtypes==1.0.5, lxml==4.9.3, ...
requirements/ml_requirements.txt
requirements/observatory_requirements.txt
requirements/shared_requirements.txt
docker/docker-compose.yaml
docker/classifiers/Dockerfile
docker/crawler/Dockerfile
docker/ml-eval/Dockerfile
.dockerignore

Every requirement line is pinned to an exact version. The USENIX Security '24 artifact appendix states: "The artifact requires Docker and Docker Compose."

Cause:

packages/darnit-amber/src/darnit_amber/handlers.py:141

requirements = path / "requirements.txt"

Exact filename at the repo root. The container_files table (~L261) is keyed the same way - "Dockerfile", "Containerfile" - so three Dockerfiles one directory down are invisible.

Possible solution:
Search a bounded depth (two levels covers this case) for *requirements*.txt, Dockerfile*, docker-compose*.y*ml and lock files, rather than the root alone. #450 widened the set of names recognised; this is the same class of false negative in the path.

One design question that comes with it: if several requirements files are found, how does the control aggregate? All-pinned vs any-unpinned should be stated rather than resolved by taking the first match. alsacnc has four, all fully pinned, so it's PASS either way - but a repo with three pinned and one loose is the interesting case.

Second entry in darnitdevorg/amber-corpus (#534). Badges: Available, Functional, Results Reproduced , an evaluator independently reproduced this artifact's results.

Compare with the AEADProtocols case in the sibling issue, there the evidence lives in prose and an external image, which is genuinely hard. Here it's in a file, at a path the control doesn't look at.

Dominant language
Python
Stars
22
Forks
27
Avg merge
2d 28m
Merged PRs (30d)
40

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from darnitdevorg/darnit

All issues in darnitdevorg/darnit

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.