Antes de que existiera el correo electrónico, una carta importante se cerraba con un sello de lacre. Si el sello llegaba roto, el destinatario sabía que alguien la había abierto en el camino. Lo curioso es que el lacre no decía por sí solo quién la había enviado, porque para eso había que conocer de antemano el sello del remitente. Esa diferencia entre saber que nadie tocó algo y saber quién lo hizo es la que me tocó aprender a golpes distribuyendo AgilEx.
El ejecutable sospechoso
Más de una vez la primera respuesta a una versión nueva fue que Windows la había bloqueado. El problema técnico es fácil de explicar. Cuando conviertes un script de Python en un ejecutable con PyInstaller, el resultado empaqueta un intérprete completo y varias librerías dentro de un solo archivo, y para un antivirus eso se parece mucho a lo que hace un programa malicioso que quiere esconder su contenido. Ante la duda, el antivirus bloquea. En la versión 1.5.0 intenté que el archivo dijera con claridad quién era, llenando sus metadatos con mi nombre como autor, la licencia MIT y una descripción técnica de lo que hace, porque un ejecutable sin esos datos le da al antivirus una razón más para sospechar. Ayudó, pero no alcanzó. Para un funcionario que trabaja con información sensible, un aviso rojo de Microsoft Defender es razón suficiente para no volver a abrir el archivo, y tiene toda la razón en desconfiar.
El sello propio
La otra parte de la respuesta fue firmar el ejecutable con Authenticode, el mecanismo de Windows para firmar programas. Una firma de este tipo es una operación criptográfica, muy distinta de pegar una imagen de mi rúbrica en el programa. Con ella el sistema puede comprobar que el archivo no cambió ni un byte desde que lo firmé. Para la versión 1.5.1, publicada en abril de 2026, renové la firma con un certificado SHA256 de clave RSA de 4096 bits, vigente del 15 de abril de 2026 al 15 de abril de 2029, y le agregué una marca de tiempo de DigiCert para que la firma siga siendo verificable aunque el certificado venza.
Aquí va mi error. Durante un tiempo creí que esa firma iba a quitar la advertencia azul de “Editor desconocido” que muestra Windows. La firma servía para probar que nadie había alterado el programa, pero el certificado era autofirmado, es decir, lo emití yo mismo y ninguna autoridad de certificación reconocida por Microsoft responde por mi identidad. Era mi sello de lacre. Servía para detectar una carta abierta y no le decía nada a quien no conociera mi sello.
Lo que sí construye confianza
Lo que sí hizo el sello propio fue dejar un rastro verificable. En las notas de la versión 1.5.1 publiqué el hash SHA256 del binario y la huella del certificado (el thumbprint), que se mantiene igual durante los tres años de vigencia. Cualquier administrador de sistemas puede calcular el hash del archivo que recibió, compararlo con el publicado y saber en segundos si tiene la versión original o una copia alterada. También subí el ejecutable a VirusTotal, y de 72 motores antivirus solo uno, Bkav Pro, lo marcó por una regla heurística genérica.
Para que Windows reconozca al remitente hace falta otro tipo de sello. Exploré un certificado de validación extendida con una autoridad reconocida, y al final el camino que resolvió el problema para los equipos de la entidad fue otro. La versión 1.5.2 quedó preparada para que el área de seguridad de la entidad firme un instalador MSI con su propio certificado, que es lo que hace desaparecer la advertencia de editor desconocido. Esa historia, la de entregar la firma a quien distribuye la herramienta, es la última entrega de esta serie.
La lección del lacre
Lo que me llevo de este proceso es que la confianza en software público tiene dos capas, y conviene no confundirlas. La integridad la puede garantizar el autor con su propio sello, publicando hashes y firmas que cualquiera pueda verificar. La identidad la tiene que respaldar alguien más, sea una autoridad de certificación o la institución que distribuye el programa. Si estás construyendo herramientas para el sector público, publica desde el primer día el hash de cada versión, y revisa el historial de releases de AgilEx para ver cómo lo hice yo, con aciertos y tropiezos.
Serie AgilEx · 6/7 · Todas las entregas · Anterior, la mesa funcional y la arquitectura (6 de diciembre) · Próxima entrega el 20 de diciembre, sobre soltar la herramienta.
Corrección del 11 de octubre de 2026. Una versión anterior de este post decía que la firma había eliminado la advertencia de editor desconocido y que identificaba a un desarrollador verificado. No era así, porque el certificado de la versión 1.5.1 es autofirmado.
Escrito a título personal. AgilEx es software libre (MIT) de mi autoría; no representa a la Rama Judicial y su uso en un despacho requiere las autorizaciones institucionales que correspondan.