Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Run device attestation after enrollment (Desktop)

Abierto
  • ¿Algo no está bien?
#3,735 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust
Área
desktop, security

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
Rust
Estrellas
2.9k
Forks
121
Merge medio
19 h 4 min
PR fusionados (30 d)
96

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de DefGuard/defguard

Todos los issues de DefGuard/defguard

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.