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

Implementation report: six verifiers written from the v0.2 text alone, run over 2,816 inputs (four findings)

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

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

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
20/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
json, python
領域
documentation, security

調査の方向性

Start by reading trace-v0.2.md, especially §§3.1, 3.1.5, 3.3 and the §5 phase table, alongside trace-claim.json; compare these with the conformance vectors and examples named in the report. Reproduce the four findings against the repository verifier and determine which specification clauses or expected verdicts need correction. Done means the text, schema, verifier behavior and vectors agree on the reported cases; the full protocol and per-input tables are not yet linked.

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

説明

bug needs-review:HIGH

Repository state: commit 473045fd (2026-10-18), trace-v0.2.md and trace-claim.json as given in the repo at that commit. Reference used: verify_record from the same commit (installed from source) and, as a second oracle, the PyPI release agentrust-trace 0.11.0.

Method, briefly. Six fresh language-model agents (two runs each of three models) were each given only the two files above and a fixed function interface, were forbidden to read anything else or to use the network (audited from their tool logs), and had to log every point the text did not decide. Their implementations were run with the reference over 133 real records (your conformance vectors, examples, registry entries, two of our intake fixtures), re-signed twins of the 32 records both oracles accept, and single-point mutants of those twins labelled by the clause they probe. Every disagreement was attributed to a clause and classified independently by two raters who saw only the text and the disagreement. This is part of a measurement study across three specifications (RFC 8785 is the control); the full protocol, corpora, implementations and ratings will be posted with a DOI and I will link it here.

Findings, in the order of how much of the corpus they move.

  1. Required fields: text and schema disagree, and the disagreement decides 30% of the corpus. §3.1 says "All fields are required unless marked OPTIONAL" and its table does not mark tool_transcript or transparency; trace-claim.json omits both from required and describes tool_transcript as "OPTIONAL for Phase 1 records"; the §5 phase table lists transparency among Phase 1 fields and tool_transcript from Phase 2; the Authority clause says the schema is the defective artefact when they disagree. No conformance vector or example carries either field. Four of six implementations followed the schema and agree with verify_record on 97.7% of inputs; two followed §3.1 and reject 857 and 1,029 of the 1,035 inputs the reference accepts. Both raters classified this as self-contradicting text. One edit to either side resolves it; as written, the text's own precedence rule points to the side the vectors do not take.

  2. Trust anchor at the signature step. §3.3 step 1 says the binding is verified against the key in cnf. verify_record raises when no trusted key is supplied; four of six implementations, following step 1 literally, verify against the record's own cnf key and accept (32 of 32 such calls), and no implementation refuses for want of an anchor. The text does not say whether a verifier with no external anchor must refuse, or whether a later appraisal step is meant to carry the anchor. If the intent is that a record checked only against its own key is not valid, the text should say so at step 1; if the intent is that the anchor comes from appraisal, the step should say that too. Both raters classified this as silence.

  3. §3.1.5 measurement rule is not enforced by verify_record. Two of the repo's own example records have appraisal.platform_measurement.measurement different from runtime.measurement; the vector envelope expects rejection; all six implementations reject; verify_record at 473045fd accepts, because the rule lives in a separate component that function does not call. Of the 56 vectors carrying an expected verdict, the four schema-side implementations reproduce 56, verify_record 54, the PyPI release 38.

  4. Embedded-form algorithm set. The text lists ES256 for JWT contexts and fixes no algorithm set for the embedded signature form; 32 records with an EC P-256 cnf key and a raw r||s signature are refused by the reference ("unsupported JWK kty 'EC'; expected 'OKP'") and verified by four of six implementations. Both raters: silence.

Also noted: the PyPI release 0.11.0 ships a schema older than the repo's and rejects 21 of the repo's newer example records for an unknown property (platform_measurement), so anyone pinning the release gets different verdicts from anyone pinning the repo; the two oracles differ on 53 of the 2,816 inputs.

What I am not claiming: that any of the six implementations is correct, or that these are vulnerabilities in a deployed verifier. Each is an input on which two readers of the same text reach different verdicts. Happy to share the per-input tables now if useful, and the full package once it has a DOI.

Disclosure: our intake tooling consumes TRACE records (two fixtures above are ours), and we maintain a companion layer for cA2A and a terms layer that judges TRACE records; no product of ours is evaluated in this study.

主要言語
Python
スター
37
フォーク
33
平均マージ
1日 4時間
マージ済み PR（30日）
111

環境構築

はじめの一歩

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

agentrust-io/trace-spec のほかの issue

agentrust-io/trace-spec の issue をすべて見る

似ている issue

Python の issue をもっと見る

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

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