El firmador libre que inició el desarrollo hace unos años utiliza una tecnología basada en la filosofía clásica de Java, de escribirlo una vez y ejecutarlo en todas partes. Sin embargo, hace también años que esto cambió y Oracle decidió que el entorno de ejecución se comenzara a distribuir con cada aplicación.

Debido al cambio de estrategia de Java, las ventajas de portabilidad con respecto a otros lenguajes de programación como es el caso de los compilados ya no aplicaba. Ya no había vuelta atrás y en versiones posteriores a la 8, ya no se distribuye un instalador del entorno de ejecución que se actualice automáticamente en Windows y macOS.

Esto se mencionó en un artículo previo llamado “la obsolescencia de Java 8”, donde también se menciona que Java Web Start (los ficheros JNLP) que lanzan un JAR desde web también terminaba con esta versión, la cual deja de tener soporte completo en el año 2030. No solo la fecha límite se va acercando sino que han ido apareciendo otras dificultades que están acelerando el cambio hacia otro modelo de distribución de la herramienta que requiere cambios importantes.

Cambios relevantes desde el anuncio del fin del modelo de Java 8

Los cambios observados desde entonces que afectan progresivamente a la distribución y mantenimiento del firmador que exigen cambios a menor plazo son los siguientes:

• Existen distribuciones GNU/Linux importantes que no empaquetan Java 8. Este es el caso de Debian, que tiene como política empaquetar solo versiones más recientes. Sin Java 8 no hay una versión Java Web Start que funcione bien con el firmador, dificultando el uso de lanzadores JNLP en Debian para los casos de uso específicos de firma web (existen algunas integraciones).
• La distribución del entorno de ejecución Java de Oracle, usada típicamente en Windows y macOS, no es gratuita para uso comercial. Esto supone que estos usuarios deban usar distribuciones altenativas, como Adoptium, las cuales no suelen incluir actualizaciones de seguridad automáticas o configuración automática para lanzar ficheros .jar o carecen de soporte de Java Web Start (lanzadores JNLP), complicando la configuración en estos casos particulares donde tienen este requerimiento legal.
• El entorno de ejecución de Java en macOS puede tener una arquitectura incompatible con el controlador de las tarjetas de Firma Digital en computadoras Mac modelos 2020 en adelante (procesadores Apple Silicon basados en arquitectura ARM). Esto dificulta la distribución del firmador como aplicación en JAR al depender de un Java con una arquitectura en particular el cual debe ser para Intel, lo que resulta poco intuitivo para los usuarios.
• El lanzador de aplicaciones .jar en Windows falla para algunos usuarios, donde la aplicación al lanzarla se lanza durante un instante una ventana negra, cuyo error no es trivial de diagnosticar para cada caso, donde podría ser un vínculo roto desde la extensión hacia javaw.exe o algún otro problema relacionado, donde en algunos casos ni desinstalando e instalando Java se resuelve, requiriendo una configuración relativamente compleja para resolverlo.

Dados estos 4 problemas presentados antes de la fecha límite de soporte de Java 8, se investigaron soluciones para cada caso. De antemano se asume que ya no se va a poder distribuir un único ejecutable válido para los 3 sistemas operativos soportados y que será una descarga específica para cada sistema operativo. Si bien existen algunos conceptos de un “ejecutable realmente portable” y librerías como Cosmopolitan libc, no tiene como objetivo disponer de entorno gráfico portable en ese ejecutable único.

Distribuir Java con la aplicación tiene también los inconvenientes de tener que actualizar Java incluso sin actualizar la aplicación, además de no poder garantizar con facilidad la integridad y seguridad en caso de alteraciones en el entorno de ejecución Java utilizado por el firmador.

Nuevas tecnologías para una propuesta de solución

Más recientemente, el proyecto GraalVM de Oracle ha realizado una apertura notable hacia la comunidad. GraalVM CE permite convertir las aplicaciones Java en un ejecutable compilado nativo, de carga rápida, sin requerir un entorno de ejecución. Esto permite crear ejecutables eficientes y más rápidos, facilitando el empaquetado y abriendo la posibilidad de ofrecer una interfaz nativa de la librería DSS de la Unión Europea, desarrollada en Java para poder utilizarla desde otros lenguajes, pudiéndose compilar como librería nativa y ofreciendo una interfaz de lenguaje C.

Tras realizar numerosas pruebas con GraalVM CE compilando la librería del firmador y realizando llamadas a funciones en lenguaje C que realizan operaciones de la librería DSS, se pudieron agregar firmas a documentos con éxito en las pruebas iniciales. Adicional a esto, se pueden utilizar características en otros lenguajes de programación para superar limitaciones de Java en el manejo de tarjetas, como por ejemplo poder leer los certificados sin requerir PIN sin las restricciones de interfaces internas no documentadas de Java, facilitando la selección del certificado cuando se tiene más de un dispositivo de firma disponible a la vez en la misma computadora.

En este momento se está probando el modelo de un firmador en modo librería (“libfirmador”) y un firmador que consuma esta librería. Este firmador, realizado en otro lenguaje de programación distinto al actual, puede utilizar librerías con menos limitaciones que la librería Swing de Java, como por ejemplo disponer modo oscuro en todos los sistemas operativos soportados, mejor soporte de pantallas de alta densidad de pixeles, menor consumo de memoria, entre otras ventajas.

Desafíos de la distribución de la aplicación ejecutable

Cambiar de un .jar a un .exe en el caso de Windows implica tener que hacer que cada ejecutable nuevo tenga que ser confiado por el sistema y prevenir el bloqueo por parte del sistema SmartScreen. Parece que existen mecanismos para que el ejecutable quede rápidamente confiado y no bloqueado sin la necesidad de pagar por un oneroso certificado de validación extendida para ejecutables.

Con este mecanismo además se solventa el problema en Windows de la pantalla negra en algunos casos. También se planea poder distribuir el firmador de manera gratuita mediante la tienda de aplicaciones de Microsoft, que permite automatizar las actualizaciones y más recientemente esta tienda funciona con aplicaciones clásicas de escritorio, antes estando limitada a aplicaciones UWP.

Para el caso de macOS, está previsto poder distribuirlo como un paquete de aplicación, cuya estructura es la típica de este sistema: un directorio con extensión .app que contiene metadatos para icono, ejecutable y ciertas propiedades. Fácil de agregar a Aplicaciones, también puede empaquetarse en una imagen .dmg para facilitar “arrastrarlo” a la carpeta Aplicaciones mostrando el atajo.

Otro problema que quedará resuelto en macOS es la ventana del sistema Gatekeeper que bloquea la instalación si no se ejecuta con control+clic cada vez que se descarga el firmador. Los ficheros .jar no se podían firmar, pero los ejecutables en formato paquete .app sí son firmables y no tendrán este problema. Además, al no depender de Java, se evita el problema con arquitectura ARM, distribuyéndose siempre como Intel mientras las tarjetas dependan de un controlador para Intel, algo que no parece que cambiará a corto plazo. También se podrá distribuir por la Mac App Store de forma gratuita y recibir actualizaciones sin necesidad de un mecanismo propio que tenía ciertas restricciones.

Tanto para Windows como para macOS por tanto quedaría resuelto el problema con la licencia del entorno de ejecución Java de Oracle. El código ejecutable vendría compilado con una versión comunitaria de GraalVM CE que no está afectada por la licencia de la versión no comunitaria, por lo que se podrá utilizar el firmador de forma segura y sin esta dependencia.

En el caso de distribuciones GNU/Linux se proporcionará en las “tiendas” de aplicaciones como repositorios instalables, permitiendo optar por actualizaciones automáticas. Se plantea ofrecerlas al menos en formatos de repositorio APT, Yum y Flatpak para cubrir la mayor cantidad de distribuciones. Además permite reforzar la seguridad donde no se requiere ejecutar aplicaciones fuera de ubicaciones no autorizadas y la firma del ejecutable está controlada por la infraestructura del sistema operativo, mientras que la integridad del JAR descargado había que validarla manualmente.

Conclusión

Para realizar todo esto se requiere tiempo, estimado en meses, incluso unos pocos años, hasta que esta nueva versión reemplace el modelo de distribución en JAR actual. Por ahora se han colocado las primeras piedras que forman la base de lo que será una versión 3 del firmador libre, que aprovechará para realizar diversas mejoras en la arquitectura interna. El JAR seguirá incorporando mejoras en los próximos meses, hasta que la nueva versión con nueva interfaz termine igualando y finalmente reemplazando la actual.