Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

kms: record OS image version and dev flag on-chain in the next-gen contract

Aperta
#1,384 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust, solidity
Ambito
blockchain, security

Direzione di ricerca

Start with the next-generation KMS contract around DstackKms, addOsImageHash, allowedOsImages, and isAppAllowed, then trace the verifier's attestation paths that consume os_image_hash. Resolve the compatibility and dev-image policy questions before implementing storage and events; done means on-chain metadata can be retrieved for each hash and unavailable platform fields can be filled from it.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Problem

The verifier only reports os_image_is_dev / os_image_version on the TDX legacy path, the one path that downloads the image and reads metadata.json. TDX lite, SEV-SNP, GCP TDX, AWS NitroTPM and Nitro Enclave carry only the manifest digest, so both fields are null there (#1266). Right now relying parties can't tell a dev image from a prod image on those paths, and can't enforce a minimum version. The only thing they can do is keep their own os_image_hash allowlist.

DstackKms already whitelists OS images on-chain, but it stores just a bool for each hash (allowedOsImages), so the chain doesn't know what the hash is.

Proposal

In the next-generation KMS contract, store metadata for each OS image hash, for example:

struct OsImageInfo {
    bool allowed;
    bool isDev;
    string version; // e.g. "0.5.10"
}
mapping(bytes32 => OsImageInfo) public osImages;
  • addOsImageHash takes isDev and version, and emits them in the event.
  • Every attestation path can look up version and dev status by os_image_hash from the same source. This doesn't need image downloads or metadata.json.
  • KMS / relying-party policy can reject dev images or enforce a minimum version from on-chain data.
  • The verifier can fill in os_image_is_dev / os_image_version from the contract when the platform doesn't expose them.

The owner who allowlists a hash vouches for its metadata. This is the same trust we already give to the allowlist.

Open questions

  • Keep allowedOsImages(bytes32) -> bool as a view for compatibility with existing consumers?
  • Should dev images be allowed at all on production KMS instances, or should the contract reject isDev images directly in isAppAllowed?
Lingua principale
Rust
Stelle
551
Fork
97
Merge medio
1g 8h
PR unite (30g)
182

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Dstack-TEE/dstack

Tutte le issue di Dstack-TEE/dstack

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.