Determinism Tier 1 follow-up: markdown audit reports embed a wall-clock timestamp
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 48/100
Hướng nghiên cứu
Start in packages/darnit/src/darnit/tools/audit.py at format_results_markdown, which currently writes a wall-clock Generated At stamp. Compare the now_provider kwarg on RemediationExecutor (feature 036) and the scrub() helper plus docstring in tests/darnit/fixtures/error_class_baseline/capture_baseline.py. Decide drop vs opt-in vs injectable clock for the stamp, and whether pass_history[].duration_ms is omitted or documented as non-reproducible. Done when two identical-commit markdown reports match byte-for-byte without scrubbing those fields.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Follow-up to #418 (Determinism Tier 1), which this gap escaped.
Summary
format_results_markdown in
packages/darnit/src/darnit/tools/audit.py embeds a wall-clock stamp
in every report:
**Generated At:** 2026-09-08T15:47:47.180106Z
Consequence: a markdown audit report can never be byte-for-byte
reproducible, even for an identical commit with an identical verdict
set. Two runs one second apart produce different bytes.
A second, smaller instance: pass_history[].duration_ms is
load-dependent. It reads 0 for fast file-existence checks in practice,
but nothing guarantees that.
How it surfaced
Feature 036's SC-002 required capturing a pre-feature output baseline
and diffing post-feature output against it byte-for-byte. Two
consecutive captures of the same commit did not match. Both fields had
to be scrubbed for the baseline to be stable at all -- see the scrub()
helper in tests/darnit/fixtures/error_class_baseline/capture_baseline.py
and its docstring, which documents both as out of scope for 036 and
points here.
#418's survey covered filesystem iteration order, wall-clock injection
into remediation templates, list ordering, and non-atomic writes. It
did not look at the report formatter, which is why this was missed.
Why it matters
Same argument #418 makes: a compliance tool whose report output drifts
run-to-run undermines the "same commit -> same result" premise that
makes an audit trustworthy. Concretely it also:
- Blocks any golden-file regression test of markdown output. Any future
feature wanting to prove "my change is output-neutral" has to
reinvent the same scrubbing. - Makes report diffs noisy in review when an operator commits reports
to a repo (some fleet operators do).
Scope
Decide between:
- Drop the field. Simplest. The information is recoverable from
the attestation timestamp or the file mtime for anyone who needs it. - Make it opt-in via a formatter argument, default off.
- Make it injectable -- feature 036 already established this
pattern for exactly this problem:RemediationExecutorgained a
now_providerkwarg (defaulting todatetime.now) so tests can
pin a fixed clock. Applying the same shape to
format_results_markdownkeeps production behavior while making
the output testable.
Recommend (3) for consistency with the precedent, or (1) if nobody is
actually consuming the field.
Also decide whether duration_ms should be omitted from serialized
pass_history (it is diagnostic, not evidence) or kept and documented
as non-reproducible.
Non-goals
- Re-auditing the other formatters. JSON and SARIF do not embed
timestamps at the per-result level; the attestation predicate has its
own timestamp, which is legitimate and should stay. - Any change to what the audit concludes. This is purely about output
byte-stability.
Constitution alignment
- II. Conservative-by-Default: reproducible reports are a
precondition for the report being usable as evidence.
Related
- #418 (Determinism Tier 1) -- parent; closed by #424 before this gap
was found. - #419 / #420 / #421 -- the rest of the determinism set.
- Feature 036 (#435) -- surfaced this, and established the
now_providerinjection pattern option (3) would reuse.
- Ngôn ngữ chính
- Python
- Star
- 22
- Fork
- 27
- Merge trung bình
- 1 ngày 20 giờ
- Pull request đã merge (30 ngày)
- 39
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của darnitdevorg/darnit
-
`darnit validate` crashes on openssf-baseline.toml summarising levelsCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mởneeds triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
darnitdevorg/darnit#589 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
needs triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 83/100
darnitdevorg/darnit#587 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
needs triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
darnitdevorg/darnit#585 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
quality
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
darnitdevorg/darnit#523 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
documentation good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
darnitdevorg/darnit#516 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của darnitdevorg/darnit
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
onyx-dot-app/onyx#16016 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
black --check exits 0 and prints All done when a multi file run is interruptedCó thể đã có người làm @jiteshgulati đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 2 ngày
-
Non-positive worker counts wait for results without starting workersCó thể đã có người làm @IlyaKhalafi đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
Maintainer thường phản hồi trong vòng 1 ngày