Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

amber: repro_deps_pinned and repro_build_env_declared only look at the repo root

オープン
  • 何か問題がありますか？
#536 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
55/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
python
領域
tooling

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Python
スター
22
フォーク
27
平均マージ
1日 20時間
マージ済み PR（30日）
39

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

darnitdevorg/darnit のほかの issue

darnitdevorg/darnit の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。