Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#1,384 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
rust, solidity
Domínio
blockchain, security

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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?
Linguagem predominante
Rust
Estrelas
561
Forks
99
Merge médio
1d 5h
PRs com merge (30d)
182

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de Dstack-TEE/dstack

Todas as issues de Dstack-TEE/dstack

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.