Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Allow verification at an explicit timestamp, and report which collateral was used

未关闭
#84 7 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

@samlaf 已经在做这个了。

开始于 2026年9月1日。

  • #3 来自 @samlaf —— 已关闭,未合并
  • #93 来自 @samlaf —— 未关闭

评估

难度
4/5
预计耗时
3-5 天
新手友好度
45/100
Issue 类型
功能
描述清晰度
基本清楚
活跃度
活跃
技术栈
azure, rust

调研方向

从 crates/attestation/src/dcap.rs 和带时间戳的 DCAP 验证测试开始,然后跟踪 verify_azure_attestation_with_given_timestamp 和 AttestationVerifier::verify_attestation。验证能够接受可选的 collateral 和显式时间戳,同时保留基于挂钟的默认值,并且其结果报告实际使用的 collateral 时,此更改即完成。

由索引模型根据 Issue 内容生成。

描述

Hello :) Dropping this Claude-authored issue. Think it's clear/clean enough as is, but happy to chat about it if it needs clarification.

The problem: archived attestations stop being verifiable

We use the attestation crate as a relying party for a one-time event rather than a live
handshake. When a Seismic network is founded, each founding node produces Azure TDX +
vTPM evidence bound to its freshly generated keys; we verify it against a measurement
policy, and we archive the evidence as permanent provenance. Those founding keys enter the
genesis validator set, so "this key came from a real TEE running this image" is a claim
later readers need to check for themselves, years afterwards.

Today they can't. Re-verification goes through AttestationVerifier::verify_attestation,
which verifies at SystemTime::now() against collateral fetched now. TCB Info, QE Identity
and both CRLs carry nextUpdate on a roughly 30-day cadence, and the Azure AK chain has an
ordinary notAfter. So about a month after founding, re-verification of perfectly good
archived evidence starts failing, and the property degrades into "the operator says it
verified once".

What we want is the validity-at-creation-time property archived evidence is supposed to
have: evaluate the chains and TCB status as of when the evidence was collected, against the
collateral that was current then.

The crate is already almost there

All the machinery exists — a single now already gates every freshness check (root CA CRL,
TCB Info window and chain, QE Identity window and chain, PCK chain validity, and the Azure
AK chain via verify_ak_cert_with_azure_roots), and Option<QuoteCollateralV3> already
means "use this, don't fetch". verify_dcap_attestation_with_given_timestamp and
verify_dcap_attestation_with_timestamp_sync are public and take both.

Your own tests rely on exactly this, for exactly our reason:

// crates/attestation/src/dcap.rs
// To avoid this test stopping working when the certificate is no longer
// valid we pass in a timestamp
let now = 1769509141;

The gap is only that the parameterization doesn't reach the two places we have to go
through:

  1. The Azure path. verify_azure_attestation_with_given_timestamp and its _sync
    sibling take now and Option<QuoteCollateralV3>, but are module-private; the two
    public entry points bind now to unix_time_now_secs().
  2. AttestationVerifier. We need the measurement-policy check, so we can't call the
    DCAP function directly — and verify_attestation has no way to pass either input.

And one thing genuinely missing: nothing reports which collateral bundle a verification
used
, so there's no way to archive it.

What we'd need

Two additions, no wire or payload change:

  1. An optional (collateral, now) input pair on the AttestationVerifier verify call —
    Some(collateral) meaning "no network fetch", None for now meaning "wall clock", so
    existing behaviour is the default.
  2. The collateral the verification actually used, in the verify result.

The second one matters more than it looks. The obvious workaround — fetch a second copy
alongside verification and archive that — is subtly wrong: a PCCS cache refresh between the
two fetches makes the archived bundle a bundle rather than the bundle the verification
consumed. For provenance that distinction is the whole point.

Nothing else is needed for our case. QuoteCollateralV3 already derives serde, and every
other time-sensitive Azure input (AK leaf, AK intermediates, vTPM quote, HCL report, TD
quote) already rides in the evidence message, with the Microsoft/Azure roots compiled in.
DCAP collateral is the only input a verifier fetches, so these two changes close the gap
completely.

How this relates to work in flight
  • #58 / #63 / #65 are about where collateral comes from, to avoid a fetch during a
    handshake. This is about which instant verification is evaluated at and what the
    verifier reports
    — orthogonal. If #65 ever lands, archived evidence would carry its
    collateral for free, which suits us, but we'd still need the explicit now, since
    bundling collateral doesn't stop it expiring.
  • #70 (verifier builder) composes cleanly: now and collateral are per-verification
    inputs, not per-verifier configuration, so they belong on the call rather than the
    builder.
  • #79 (return ExpectedMeasurements) touches the surface our second ask needs. Since
    the return type is already changing there, a small outcome struct carrying both the
    matched measurements and the collateral used would fold in naturally. I'd rather propose
    against the direction you're taking than cut across it — hence this issue before a PR.

Nothing here adds to the evidence payload, so it's also neutral with respect to the rustls
64 kb cap in #75.

Happy to implement whichever shape you prefer, and to wait for #70/#79 if they're close.

主要语言
Rust
星标
6
派生
3
平均合并
1 天 2 小时
30 天内合并 PR
3

环境准备

这个项目没有提供开发容器、Dockerfile 或贡献指南,环境需要你自己搭建:先看它的 README,通用步骤见我们的新手贡献指南。

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

flashbots/attested-tls 的其他 Issue

查看 flashbots/attested-tls 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。