attestation-service
title: Proceso de lanzamiento del Servicio de Verificación de Celo descripción: Detalles del proceso de lanzamiento para actualizar el servicio de verificación en la plataforma de Celo.
Proceso de Lanzamiento del Servicio de Verificación
Detalles del proceso de lanzamiento para actualizar el servicio de verificación en la plataforma Celo.
Este proceso de liberación está actualmente en uso.
Versionamiento
Las liberaciones del Servicio de Verifiación se realizan según sea necesario. Las versiones se numeran de acuerdo a la versión semántica, como se describe en semver.org.
Las compilaciones de desarrollo deben identificarse con -devy solo debería existir un commit con una versión liberada x.y.z para cualquier (x, y, z).
Documentación
La documentación se mantiene en el repositorio de celo-org/docs y está alojada en docs.celo.org.
Identificando lanzamientos
Ramas de Git
El desarrollo se realiza en la rama master, que corresponde a la siguiente versión principal o menor. Los cambios que se incluyan en una versión de parche de una versión menor existente se incorporan a esa rama de la versión existente.
Etiquetas de Git
Cada versión debe ser creada en Github y etiquetada con el número de versión, por ejemplo attestation-service-vX.Y.Z. Cada versión debe incluir un resumen de su contenido, con enlaces a pull requests e incidencias y una descripción detallada de los cambios más destacados.
Las etiquetas deben ser firmadas y pueden verificarse con el siguiente comando.
git verify-tag attestation-service-vX.Y.Z
En Github, cada etiqueta de lanzamiento debe tener firmas adjuntas que se pueden utilizar para verificar las imágenes Docker.
Etiquetas Docker
Cada imagen Docker se etiqueta con attestation-service-<commithash>. Al igual que una etiqueta Git apunta inmutablemente a un hash de confirmación, la etiqueta Docker debería apuntar inmutablemente a un hash de imagen.
Además, cada imagen Docker correspondiente a una versión liberada debe etiquetarse con attestation-service-vX.Y.Z.
Las últimas imágenes calificadas para su despliegue en diversas redes también están etiquetadas de la siguiente manera:
- Alfajores:
attestation-service-alfajores - Baklava:
attestation-service-baklava - Mainnet:
attestation-service-mainnet
Firmas
Los artefactos producidos por este proceso de compilación (por ejemplo, etiquetas, imágenes Docker) serán firmados por una clave de desarrollador principal.
Las claves públicas para los desarrolladores del núcleo están alojadas en celo.org y pueden importarse a gpg con el siguiente comando:
gpg --auto-key-locate wkd --locate-keys $EMAIL
Las claves principales de desarrollador alojadas actualmente y utilizadas para las versiones de Attestation Service incluyen:
Proceso de construcción
Imágenes de Docker
Las imágenes Docker se crean automáticamente con Google Cloud Build cuando se envían a master y a todas las ramas de publicación. Las compilaciones automatizadas se etiquetarán en Google Container Registry con el hash de confirmación correspondiente.
Debe producirse una firma sobre la imagen construida automáticamente en el hash de confirmación correspondiente e incluirse con la publicación en Github.
Las firmas de las imágenes de lanzamiento pueden verificarse con el siguiente comando:
docker save $(docker image inspect us.gcr.io/celo-testnet/celo-monorepo:attestation-service-vX.Y.Z -f '{{ .Id }}') | gpg --verify attestation-service-vX.Y.Z.docker.asc -
Probando
Además de las pruebas monorepo CI, se espera que todas las versiones pasen por pruebas manuales según sea necesario para verificar las propiedades de seguridad, la exactitud de la documentación y la compatibilidad con las versiones desplegadas y previstas de celocli y las billeteras, incluido Valora. Los lanzamientos implican actualmente la coordinación con Valora para ejecutar las pruebas de verificación e2e en CI.
Proceso de promoción
Control de las fuentes
Las versiones de parches deben construirse seleccionando todos los commits incluidos de master a la rama release/attestation-service/x.y, si es necesario creada a partir de la etiqueta attestation-service-vX.Y.Z de la versión mayor o menor más reciente. El primer commit de este proceso debe cambiar el número de versión codificado en el código fuente de x.y.z a x.y.z+1-dev y la confirmación final debe cambiar el número de versión a x.y.z+1.
Las versiones mayores y menores deben construirse enviando un commit a la rama master para cambiar el número de versión codificado de x.y.z-dev a x.y.z. Debe crearse una etiqueta attestation-service-vX.Y.Z en este commit que haga referencia única a un commit; las notas de la versión deben publicarse junto a esto. El siguiente commit debería cambiar el número de versión de x.y.z a x.y+1.0-dev, o x+1.0.0-dev si la siguiente versión prevista es una versión mayor.
Distribución
La distribución de una imagen sigue este calendario:
| Fecha | Acción |
| T-1w |
|
| T |
|
| A + 1 en adelante |
|
Parches de emergencia
Los errores que afecten a la seguridad, la estabilidad o la funcionalidad básica del protocolo de identidad de Celo o que impidan la incorporación de nuevos usuarios a las billeteras, incluido Valora, pueden tener que publicarse fuera del ciclo de publicación estándar. En este caso, debe crearse una versión de parche de emergencia sobre todas las versiones menores compatibles que contenga el cambio mínimo y la prueba correspondiente para la corrección.
Si el problema no es explotable, las notas de publicación deben describirlo detalladamente y la imagen debe distribuirse públicamente.
Si el problema es explotable y no se dispone de medidas de mitigación, debe prepararse un parche de forma privada y deben distribuirse binarios firmados a partir de commits privados. Establecer la confianza es clave para sacar adelante el arreglo. Se puede contratar una auditoría de un tercero acreditado para verificar la liberación y ayudar a ganarse esa confianza.
Revelación de vulnerabilidades
Las vulnerabilidades de las versiones de Attestation Service deben revelarse de acuerdo con la política de seguridad.