La sección bundle: qué se produce
Los formatos que puede generar el empaquetador, los metadatos que cada tienda y cada gestor de paquetes exige, y las tres claves que deciden si tu instalador se puede firmar más adelante.
La sección
Por qué no siempre «todos» los formatos
"targets": "all" parece la opción sin pérdida y tiene dos costes reales.
El tiempo. Cada formato es un proceso de empaquetado completo. En Linux, generar los tres —el paquete de Debian, el de Red Hat y la imagen autocontenida— triplica el tiempo de una compilación que ya era lenta. En integración continua eso se paga en cada ejecución.
Los formatos que no vas a soportar. Publicar un paquete de Red Hat que nadie ha probado nunca no es generosidad: es una promesa implícita de que funciona. Si tu política de soporte del nivel 3.4 nombra dos distribuciones, genera los formatos de esas dos.
La lista explícita es también documentación: quien la lea sabe qué distribuyes sin tener que preguntar.
Los metadatos, y dónde se ven
Se rellenan una vez y aparecen en sitios que no se ven hasta el final:
| clave | dónde se ve |
|---|---|
copyright |
propiedades del fichero en Windows, ventana de información en macOS |
category |
la Mac App Store, y el menú de aplicaciones de un escritorio Linux |
shortDescription |
el resumen de un paquete de Debian, la ficha de una tienda |
longDescription |
la descripción completa del paquete |
publisher |
el nombre que Windows enseña en el diálogo de instalación |
Ninguno cambia cómo funciona la aplicación, y todos aparecen en el momento en que alguien decide si instalarla. Rellenarlos ahora cuesta diez minutos; rellenarlos en la fase XII significa recompilar y volver a firmar tres instaladores.
Las tres claves que condicionan la firma
Estas son las que este nivel quiere dejar marcadas.
createUpdaterArtifacts. Si está desactivada, la compilación produce instaladores perfectamente válidos y ningún artefacto de actualización. El fallo aparece cuando ya has publicado la primera versión y quieres publicar la segunda: no hay nada que servir. Actívala desde el principio aunque todavía no tengas updater.
La sección macOS. Dentro del bundle hay una subsección por plataforma, y la de macOS lleva las claves de firma: la identidad, los permisos declarados y la versión mínima del sistema. La versión mínima es la que más sorprende: decide en qué máquinas se puede instalar, y por tanto qué motor de webview tienes garantizado. Es la misma decisión del nivel 3.3, escrita aquí.
La sección windows. Lleva la huella del certificado, el algoritmo y —esto es lo importante— la dirección del servicio de sellado de tiempo. Sin sellado, la firma deja de ser válida el día que el certificado caduca, y eso incluye las copias ya instaladas. Nivel 62.
Lo que no está aquí
Dos cosas que la gente busca en bundle y viven en otro sitio:
- La configuración del updater —la clave pública y las direcciones donde buscar— está en
plugins.updater, no aquí. Aquí solo se decide si se generan sus artefactos. - El instalador del componente de webview en Windows está en la subsección de Windows del bundle y decide qué pasa cuando el usuario no tiene WebView2: descargarlo al vuelo, empaquetarlo, o dar por hecho que está. Es una decisión de tamaño contra fiabilidad, y el nivel 59 la trata.