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

Run device attestation after enrollment (Desktop)

Aperta
  • Qualcosa non va?
#3,735 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

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
Ambito
desktop, security

Direzione di ricerca

Start by tracing the desktop enrollment flow and the existing periodic posture-data checks, including disk-encryption checks. Then follow the core's EK certificate validation and device-status updates; done means all listed enrollment, periodic, failure, fingerprint, CA, and unsupported-client scenarios produce the specified statuses and metadata.

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

Descrizione

User story

As an admin, I want each device to be attested when it's enrolled and periodically afterwards, so that its attestation status is always current.

Acceptance criteria
  • The desktop client runs attestation automatically after the device is enrolled, with no user action.
  • The client re-runs attestation periodically, using the same interval and mechanism as the existing posture data checks (e.g. disk encryption).
  • The core validates the device's EK certificate against the EK CA database, including manually added CAs:
    • The certificate chains to a known CA → Attested.
    • The attestation is valid but the CA is unknown → Unrecognized (#3734 ).
    • There's no TPM, the attestation is invalid, or the client doesn't support attestation → Not attested.
  • Each successful attestation stores or updates the attestation date, certificate owner and fingerprint.
  • If a previously attested device fails a later attestation, its status changes to Not attested.
  • If the device's fingerprint changes, its verification status is reset to Not verified.
Test scenarios
  1. Enroll a device with a supported TPM → it becomes Attested, with a date and fingerprint, without any user action.
  2. Enroll a device with no TPM → it becomes Not attested.
  3. Enroll a device with a TPM from an unknown CA → it becomes Unrecognized.
  4. Wait for the next periodic check → the attestation date updates.
  5. Make attestation fail on an attested device (e.g. disable the TPM) → at the next periodic check it becomes Not attested.
  6. A verified device reports a different fingerprint → it becomes Not verified.
  7. An older client without attestation support → the device is Not attested.
Notes
  • Use the device's WireGuard public key as the attestation nonce. This binds the attestation to the client configuration.
  • Attestation results will be part of every config polling request and stored in Core. Separate #3782
Lingua principale
Rust
Stelle
2.9k
Fork
121
Merge medio
21h 54m
PR unite (30g)
67

Preparare l'ambiente

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 DefGuard/defguard

Tutte le issue di DefGuard/defguard

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.