Revisar la procedencia de una versión

Mucha gente revisa el repositorio de un proyecto, pero lo que se instala es el archivo de release. Son dos cosas que deberían corresponderse: la etiqueta del repositorio marca el código de una versión y la release se arma a partir de él. Algunas diferencias son normales (archivos que se generan al empaquetar); otras no.

Abre guia-de-archivos-generados.txt para saber qué diferencias se esperan y compara release-3.3.0-contenido.txt con etiqueta-v3.3.0-contenido.txt.

Revisar solo el repositorio da una falsa tranquilidad: el archivo que descarga una empresa puede traer algo que el repositorio no muestra. Comparar la release con la etiqueta convierte una diferencia en un hecho verificable y barato de comprobar, sin necesidad de entender el contenido del archivo extra.

La firma de una release dice con qué clave la respaldó quien la publicó. Una clave nueva no es mala por sí sola, pero un cambio de clave que coincide con otro cambio (un publicador nuevo, un archivo que no está en el repositorio) merece una pregunta al proyecto: ¿se anunció esa clave por un canal conocido?

Abre publicaciones.csv y mira la columna clave_de_firma de la versión 3.3.0.

El historial de mantenedores dice quién puede publicar y desde cuándo. Un permiso reciente no es una falta: los proyectos incorporan gente nueva. Es un dato más del cuadro, que se anota junto con los demás.

En mantenedores.csv busca a la persona que publicó la 3.3.0 (está en publicaciones.csv) y calcula los días entre la fecha de su permiso de publicar y la fecha de esa release.

Hay un archivo que no está en el repositorio, una clave nueva y un publicador reciente. Ninguna de esas cosas prueba una intención. Lo correcto es documentar lo observado con la evidencia, avisar al proyecto y al equipo de seguridad por un canal oficial, y mientras tanto no instalar esa versión.