add support for hw keys certs and attestations by ubiratansoares · Pull Request #2622 · rust-lang/team

ubiratansoares · 2026-07-23T13:40:59Z

Towards #2501. Context here.

This PR introduces a new hardware-keys folder and assumes a convention that each subfolder corresponds to attestation files and (f9) certificates derived from a single Yubikey.

There is a minimal TOML schema addition + validation to link a team member with these folders and files. We don't expose any information from these files through team API for now.

Documentation on how to generate these files to rollow on Forge.

In general we can expect

1 intermediate certificate file + 2 attestations file per key
a few members involved with TUF, signing, etc with 2+ hardware keys to brign info in

That means a few dozens of files a few Kbs each stored at this repo, which sounds doable.

I added two for myself related to PIV 9a (auth) as an example of these files.

github-actions · 2026-07-23T13:58:41Z

Dry-run check results


[WARN  rust_team::sync] sync-team is running in dry mode, no changes will be applied.
[INFO  rust_team::sync] synchronizing crates-io
[INFO  rust_team::sync] synchronizing github
[INFO  rust_team::sync] 💻 Repo Diffs:
    📝 Editing repo 'rust-lang/libz-sys':
      Environments:
        ❌ Delete: copilot

marcoieni

Thanks! Some initial comments 👍

AI disclosure

I used GPT5.6-Sol with the codex harness to find 6/7 of these findings

marcoieni · 2026-07-24T10:16:37Z

 last-name = "Doe"   # Your last name or preferred surname
 account-handle = "john.doe" # The handle to define a @rust-lang.org account (e.g. john.doe@rust-lang.org)
+
+hardware-keys =  ["key-id"]


this is unrelated to [google-workspace] so we should move it at the top, right?

marcoieni · 2026-07-24T10:19:40Z

If we don't want to have a new top-folder directory, we could have hardware-keys under people, which also makes it more clear that it's related to that 🤔

Wdyt?

The con I can think of:

people now has a subdirectory, which might break some scripts

the URL for retreaving hardware keys might be longer?

I thought about this, and tbh I don't have a strong opinion. I think the top-level folder causes less harm.

marcoieni · 2026-07-24T10:23:43Z

+    wrapper(data.people(), errors, |person, _| {
+        for key in person.hardware_keys() {
+            if !data.hardware_keys(key) {
+                dbg!(data);


is this a leftover or you want to have it here? It might be to spammy, right? 🤔

marcoieni · 2026-07-24T10:26:13Z

+        }
+        Ok(())
+    });
+}


we could also add the following validation: "Enforce that a key is only owned by exactly one person" to avoid duplicates and orphans

Added this new check here

marcoieni · 2026-07-24T10:27:43Z


+        let hardware_keys_dir = directory.join("hardware-keys");
+        for entry in std::fs::read_dir(hardware_keys_dir)? {
+            let path = entry?.path();


let's validate that path is a directory. Do we also validate that the directory contains the files we expect? (and only those files?)

For now we don't validate the dir contents because I don't know about whether we should always expect the attestation files for both the 9a and 9c slots. For example, perhaps there is an agreement that only 9a attestation is required.

I can clarify with that with folks involved in TUF, but anyhow, my take would be introduce this additional validation as a follow-up. Let me know whether it makes sense to you!

marcoieni · 2026-07-24T10:31:03Z


+    pub(crate) fn hardware_keys(&self, key_alias: &str) -> bool {
+        self.hardware_keys.contains(&key_alias.to_string())
+    }


given that this is the only operation we do, should we use a BTreeSet instead of a Vec? Also, maybe there's a way to check that the element is contained without allocating a string (to_string) ? 🤔

Added an equivalent check that don't allocate here

marcoieni · 2026-07-24T10:32:06Z

    #[serde(default)]
    permissions: Permissions,
    google_workspace: Option<GoogleWorkspace>,
+    #[serde(skip_serializing_if = "Vec::is_empty", default)]


Suggested change

#[serde(skip_serializing_if = "Vec::is_empty", default)]

#[serde(default)]

no need since the type doesn't inherit Serialize.

ubiratansoares force-pushed the u/yubikeys-schema branch 2 times, most recently from 5a3166c to 4a5d445 Compare July 23, 2026 13:53

add support for hw keys certs and attestations

0e05902

ubiratansoares force-pushed the u/yubikeys-schema branch from 4a5d445 to 0e05902 Compare July 23, 2026 14:52

ubiratansoares marked this pull request as ready for review July 24, 2026 07:12

ubiratansoares requested review from Mark-Simulacrum, emilyalbini, jdno and marcoieni as code owners July 24, 2026 07:12

marcoieni reviewed Jul 24, 2026

View reviewed changes

ubiratansoares added 5 commits July 24, 2026 16:59

improve schema docs

5234235

add schema improvement

3c2492c

improve check against existing hw key

7f98a9c

validating hardware key path

3a3d278

add validation to check dangling assets

d2141a8

	#[serde(skip_serializing_if = "Vec::is_empty", default)]
	#[serde(default)]

Uh oh!

Conversation

ubiratansoares commented Jul 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Jul 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

marcoieni left a comment

Choose a reason for hiding this comment

AI disclosure

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ubiratansoares Jul 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ubiratansoares commented Jul 23, 2026 •

edited

Loading

github-actions Bot commented Jul 23, 2026 •

edited

Loading

ubiratansoares Jul 24, 2026 •

edited

Loading