De igual forma, las distribuciones también hacen referencia a la colección de un conjunto variado de aplicaciones y paquetes de software junto con el sistema operativo, siendo muy común en las distribuciones de Linux, como Debian, Ubuntu, Red Hat, etc.

Cuando nos encontramos con una distribución, normalmente tiene asociada una licencia, siendo la más habitual la licencia GPL (General Public License (Licencia Pública General). Es una licencia creada para proteger la libre distribución, modificación y uso de software) u Open source. Otro tipo de distribución presente en el mercado, es la distribución binaria, donde nos encontramos con un instalador (fichero .exe o .msi en sistemas Microsoft Windows), que puede ser descargado desde Internet. Las distribuciones pueden ser oficiales si provienen de los autores o autoras originales o distribuciones 3rd party (software desarrollado por tercera personas o empresas).

Un sistema de gestión de paquetes es una colección de herramientas que sirven para automatizar el proceso de instalación, actualización, configuración y eliminación de paquetes de software. Normalmente, este término se usa para referirse a los gestores de paquete en sistema Linux, que los usan como base principal de gestión de paquetes. Como ejemplo, en Ubuntu nos encontramos el Centro del software o en versiones antiguas el Gestor de Paquetes Synaptic.

En estos sistemas, el software se distribuye en forma de paquetes, que se encapsulan en un único fichero. Dentro del paquete nos encontramos: el software propiamente dicho, el nombre completo del paquete, una descripción de su funcionalidad, el número de versión, el distribuidor del software, la suma de verificación y una lista de otros paquetes requeridos para el correcto funcionamiento del software. Esta información se suele introducir normalmente en una base de datos de paquetes local.

En la mayoría de los casos, un programa está formado por un conjunto de archivos. Normalmente, esos archivos necesitan ser copiados en determinadas carpetas o directorios, y en muchos casos, deben registrarse en el registro de Windows, si utilizamos ese sistema operativo.

Los instaladores van a realizar todas las operaciones anteriores de forma transparente al usuario. El uso del instalador suele ser muy sencillo. En la actualidad, los instaladores presentan al usuario una serie de formularios donde le van mostrando las indicaciones pertinentes, limitando al usuario a pequeñas modificaciones o directamente a pulsar el botón siguiente. El instalador copiará los archivos de la aplicación a instalar en los directorios adecuados, registrará la aplicación, creará los menús y los accesos directos en el Escritorio.

Ejemplos de instaladores son: InstallAnywhere, InstallBuilder, Windows Installer, InstallShield, InstallAware, Emco Package Builder, Visual Studio 2019, NSIS, Null soft Scriptable Install System, Iexpress, IzPack, etc.

Los pasos en la instalación son los siguientes:

1. Verificación de la compatibilidad: se debe comprobar que se cumplen los requisitos para la instalación, tanto hardware como software.
2. Verificación de la integridad: se verifica que el paquete de software es el original.
3. Creación de los directorios requeridos.
4. Creación de los usuarios requeridos: cada grupo de usuarios puede usar un determinado software.
5. Copia, desempaque y descompresión de los archivos desde el paquete de software.
6. Compilación y enlace con las bibliotecas requeridas.
7. Configuración.
8. Definición de las variables de entorno requeridas.
9. Registro de la aplicación ante el autor o autora de la aplicación.

Los asistentes de instalación son aplicaciones que ayudan al usuario a personalizar la instalación de software. Cuando utilizamos un instalador, normalmente tiene asociado un asistente de instalación. Cada paso de la instalación se muestra mediante un formulario con la información del paso se está dando. Los asistentes nos permiten elegir los directorios donde queremos que se instale la aplicación, el grupo de programas donde se integra la aplicación en el menú del escritorio, información sobre la licencia, registro de la aplicación, etc.

Ese fichero será un fichero de ejecutable en Windows (extensión exe), un paquete Debian (fichero con extensión deb) en distribuciones Linux basadas en Debian (Debian, Ubuntu, etc.), un paquete rpm en distribuciones estilo Red Hat (Red Hat, Suse, etc).

Si nos encontramos en Windows, el paquete autoinstalable será una aplicación que, una vez lanzada por el usuario, realizará la descompresión de todos los archivos de la aplicación, creará las carpetas que la aplicación necesita, copiará los archivos a sus directorios de destino, añadirá y/o modificará entradas en el Registro de Windows, añadirá las entradas en el menú de aplicaciones y mostrará accesos directos en el Escritorio.

Durante todo este proceso, el usuario puede interaccionar eligiendo componentes a instalar, modificando los directorios de instalación, si se crean o no accesos directos, o puede optar por las opciones por defecto.

Si estamos distribuyendo una aplicación para Ubuntu, por ejemplo, lo que se crea es un paquete deb. Este tipo de archivo contiene todos los archivos y directorios de la aplicación. Cuando el usuario quiere realizar la instalación del paquete, ejecuta el "Software de Ubuntu", que nos irá mostrando las ventanas de instalación de la aplicación.

En la actualidad existe un amplio abanico de herramientas de creación de paquetes de instalación. Las más extendidas para crear instaladores son las siguientes: InstallAnywhere, InstallBuilder, Windows Installer, InstallShield, InstallAware, Emco Package Builder, Visual Studio 2019, NSIS, Null soft Scriptable Install System, Iexpress, IzPack, etc.

La instalación de una aplicación es el primer contacto que va a tener un usuario con la aplicación.

Las herramientas de instalación señaladas con anterioridad permiten a los programadores crear instaladores para Windows y algunas también para Linux. Si tomamos como ejemplo NSIS(Nullsoft Scriptable Install System) nos encontramos con una herramienta open-source (software desarrollado y distribuido libremente) que permite crear instaladores para nuestras aplicaciones en Windows. NSIS crea instaladores capaces de instalar, desinstalar, configurar el sistema, extraer archivos, etc. Este sistema está basado en scripts, con lo que el programador va a tener el control total en cualquier parte del instalador. El lenguaje script soporta variables, funciones, manipulación de cadenas, como un lenguaje de programación normal, pero diseñado para la creación de instalables.

Si trabajamos en Linux, necesitamos crear un paquete de instalación acorde con la distribución Linux donde queramos instalarlo. Si nos encontramos en Linux Ubuntu, el tipo de paquete será debian (.deb). El paquete de instalación deb, va a empaquetar todos los ficheros que necesita nuestra aplicación y debe de estar configurado para indicar al "Software de Ubuntu", donde se deben copiar esos archivos y que opciones de configuración se deben modificar.

En los sistemas Windows o Mac OS, los programas que queremos instalar se suelen buscar en Internet y se encuentran, en su mayoría, en forma de instaladores ejecutables. También es muy común la distribución de software en Cds y DVDs. En sistemas open source como Ubuntu GNU/Linux nos encontramos esta forma de distribución de software, pero la mayoría del software se encuentra empaquetado en ficheros .deb, (.rpm en Red Hat), que contienen programas y las bibliotecas que necesitan. Los repositorios son servidores que contienen conjuntos de paquetes. A esto servidores se accede con herramientas como Centro de Software

Los repositorios van a centralizar todos los paquetes que se pueden instalar, ofreciendo un amplio abanico de software. En Ubuntu, generalmente, se querrá tener al menos los repositorios oficiales de Ubuntu (que pueden incluir el CD de instalación) pero es bastante común tener otros repositorios (de otros empaquetadores) activados.

En ambos casos, el programador utilizará herramientas de generación de instaladores que le permitan personalizar su instalación.

Generalmente, cuando se crea un instalador para una aplicación, este instalador mostrará el logotipo de la aplicación, o de la empresa de desarrollo, tendrá un icono propio, unos colores y formato de ventana propios, formularios en los que se muestren los acuerdos de licencia, donde se pueden seleccionar el idioma de instalación, los directorios donde se desean copiar los archivos de la aplicación, etc.

Todos estos parámetros permiten crear un instalador propio para cada aplicación.

Normalmente, los logotipos suelen incluir símbolos que se asocian claramente con quienes representan.

El logotipo es el activo más importante de un servicio y producto y se utiliza como sello distintivo. Es por ello que, a la hora de diseñar el logotipo de una aplicación, debemos tener presente algunos conceptos. Para que un logotipo resulte exitoso se debe seguir el principio fundamental de diseño de "menos es más", la simplicidad va a permitir que el logotipo sea:

• Legible.
• Escalable.
• Reproducible.
• Distinguible.
• Memorable.

En un instalador se puede insertar el logotipo arriba, abajo, a la derecha o la izquierda del instalador. El tamaño del logotipo vendrá en función del ancho/alto especificado, del ancho y alto del instalador y de la fuente utilizada en el instalador. Normalmente el logotipo será una imagen que insertaremos en el instalador, usando la herramienta de creación de instaladores.

Si tomamos como ejemplo NSIS, para añadir el logotipo en el instalador, se hace con el atributo AddBrandingImage. Este atributo presenta la siguiente sintaxis:

(left|right|top|bottom) (width | height) [padding]

Cuando se diseña un instalador para una aplicación de interfaz gráfica, la interfaz del instalador deber adquirir y presentar la información de forma consecuente a la interfaz de la aplicación a la que sirve. En el caso de los fondos del instalador, estarán organizados en función del diseño estándar que se mantiene en todas las ventanas de la aplicación.

El fondo del instalador, por tanto, deberá implementar las mismas reglas de diseño para mantener la interacción en toda la aplicación.

Cuando el color de fondo es blanco (o, sencillamente, no hay color de fondo) el usuario interpreta esa información como relevante y su nivel de atención aumenta considerablemente.

Cuando se hace un instalador, los botones que se implementan son los de aceptar o rechazar el acuerdo de licencia. Los botones normalmente que aparecen son: siguiente, anterior, instalar  y finalizar.

En el proceso de instalación gráfica de una aplicación, lo que se nos presentan son un conjunto de ventanas, en las que el usuario toma algunas decisiones. Los botones de cada una de las ventanas, son de aceptar o cancelar los valores ofrecidos por el instalador, y siguiente o anterior, para avanzar o retroceder en las ventanas de instalación.

Siempre hay que ser consistente con todos los elementos que forman parte de una aplicación, incluido su instalador.

Mantener la consistencia implica que el formato de las ventanas, los colores, iconos, imágenes, botones y demás componentes gráficos guarden el mismo formato, tanto en colores, fuentes y tamaños.

La forma más habitual de los botones gráficos es la rectangular, aunque a veces pueden tener las esquinas redondeadas. Otras formas cada vez más comunes son la circular, elíptica, trapezoidal…

La mayoría de las aplicaciones que se distribuyen están a disposición de cualquier usuario en alguna página web, o páginas de descargas. Esta disposición global de las aplicaciones, implica que cualquier usuario de cualquier parte del mundo, pueda tener acceso a la aplicación y pueda descargarla e instalarla.

Cualquier aplicación que se desee distribuir a cualquier lugar, debe tener la interfaz implementada en inglés, pero es razonable traducir la interfaz a varios idiomas, y que el usuario final elija durante el proceso de instalación el idioma en el que desea que se instalada.

El programador deberá tener en cuenta es su diseño, la posibilidad de que su aplicación se pueda distribuir en varios idiomas. Si esta posibilidad está presente, el programa instalador también deberá presentarse en diferentes idiomas y en él se podrá elegir el idioma de instalación final.

Para generar paquetes instalación de una aplicación, disponemos de varias alternativas:

• Utilizar entornos de desarrollo.
• Hacer uso de herramientas externas.
• Instalar en modo desatendido.

La primera alternativa es la utilización de las herramientas de generación de paquetes incorporadas en el Entorno de Desarrollo. Los entornos de desarrollo, suelen disponer de herramientas de generación de paquetes, pero no suelen incorporar herramientas que creen instaladores "amigables". En el caso del entorno de desarrollo NetBeans, podemos crear un paquete de instalación JAR de nuestra aplicación Java, sin embargo, la instalación y la ejecución del paquete, deberá realizarla el usuario.

Existen en el mercado herramientas que complementan a los entornos de desarrollo para la creación de paquetes de instalación. Estas herramientas, en el caso de aplicaciones Java, pueden crear el paquete JAR, o directamente partiendo del paquete JAR generado a partir del entorno de desarrollo, crear un nuevo proyecto de instalación, donde se cree un instalable o un autoinstalable, para la aplicación desarrollada.

En este punto, vamos a profundizar en la creación de paquetes de instalación para aplicaciones Java.

En un entorno de desarrollo para Java como NetBeans, una vez depurado y probado el proyecto, vamos a proceder a construirlo y crear el fichero JAR. Cuando se realiza este paso, en el explorador del proyecto aparece una nueva carpeta de nombre dist. En esta carpeta se va a crear el fichero JAR. Si la aplicación requiere bibliotecas adicionales para poder ejecutarse, algo habitual en aplicaciones con interfaz gráfico, dentro de dist se crea una subcarpeta de nombre lib, que contiene las librerías necesarias para la ejecución (las que no estén incluidas en el JDK).

La aplicación así generada, se puede ejecutar dentro del IDE y fuera de él. Para ejecutarla dentro de NetBeans, se selecciona el proyecto con el ratón en el explorador de proyectos, y se selecciona la opción ejecutar del menú contextual. Si la generación realizada en el paso anterior fue correcta, nos mostrará la ejecución de la aplicación desarrollada. Si queremos ejecutar la aplicación implementada fuera del IDE, navegamos por el explorador de nuestro sistema operativo (Windows, o Linux) y hacemos doble clic sobre el fichero Jar que se encuentra en la carpeta dist de nuestro proyecto.

Para distribuir la aplicación a otros usuarios, en primer lugar, debemos comprobar que la aplicación funciona fuera del IDE. Para distribuir la aplicación, primero creamos un fichero zip que contenga el fichero de aplicación Jar y el directorio lib conteniendo las librerías que necesita la aplicación.

Una vez que se ha distribuido el fichero zip, la ejecución de la aplicación fuera del IDE se puede realizar de varias formas. La manera más rápida de ejecutar la aplicación, es descomprimir el fichero zip en cualquier carpeta seleccionada por el usuario final, y hacer doble clic sobre el fichero JAR.

Si la aplicación no se ejecuta, puede que tengamos problemas con la asociación de fichero JAR con aplicaciones, en nuestro sistema operativo. Esto puede deberse a dos razones:

• Que el tipo de fichero JAR no esté asociado a Java Runtime Environment.
• Que el tipo de fichero JAR estén asociados a JRE (Acrónimo de Java Runtime Environment (Entorno de Ejecución para Java). Es un conjunto de utilidades que permite la ejecución de programas Java), pero la opción -jar no está incluida en el comando que se pasa a JRE al hacer doble clic en el icono.

A continuación, veremos todos los pasos necesarios para realizar el empaquetado y distribución de una aplicación java.

Hay muchas herramientas externas a los entornos de desarrollo que nos permiten crear paquetes de instalación para aplicaciones. Dentro de las aplicaciones Java, hay varias herramientas que nos permiten crear un instalador a partir del paquete JAR. Entre esas herramientas nos encontramos con IzPack y NSIS.

Izpack es una herramienta que nos permite crear instaladores a partir de aplicaciones Java. Funciona en cualquier sistema operativo que tenga instalada una Máquina Virtual Java (JVM). Con esta herramienta podemos personalizar el instalador de una aplicación Java. La aplicación se puede descargar para cualquier sistema operativo que tenga instalada un JRE o JDK de Java. Una vez instalada la herramienta, ya podemos implementar instaladores para aplicaciones Java que hayamos desarrollado.

Para crear instaladores con IzPack, debemos crear un documento XML, donde cada tag (etiqueta) tiene un significado para IzPack. Definidos todos los atributos que queramos en el fichero xml, ya podemos generar nuestro programa de instalación; para ello, sólo debemos ejecutar el siguiente comando:

“ruta de instalación IzPack”/bin/compile instalacion.xml -o install.jar 

Donde el fichero instalacion.xml contiene las características de la instalación e install.jar en nuestra aplicación Java ya empaquetada.

A diferencia de IzPack, NSIS es una herramienta específica para entornos Windows, pero también es libre. NSIS nos proporciona un completo entorno para crea instaladores, tanto para aplicaciones Java, como aplicaciones desarrolladas en otros lenguajes.

Nullsoft Scriptable Install System funciona a través de un lenguaje propio de scripts. Para implementar un instalador, el programador o programadora escribe el script correspondiente, que una vez finalizado, será compilado por NSIS, creando un ejecutable como instalador.

NSIS proporciona un amplio abanico de script de ejemplo, que combinándolos y adaptándolos a nuestras necesidades, nos permiten crear instaladores completos, incluidos los desinstaladores.

En el siguiente apartado, vamos a ver, mediante un ejemplo como se utiliza NSIS.

El uso de instalaciones desatendidas es útil cuando se deben instalar programas en gran cantidad de ordenadores, cuando hay que instalar sistemas operativos.

Para automatizar el proceso de instalación, podemos crear un script que nos guarde las pulsaciones del ratón y del teclado y los datos que introducimos. De esta forma, al ejecutarse el instalador, reproduciría el patrón que nosotros hemos grabado previamente en el instalador.

Otra forma de realizar instalaciones desatendidas, es la utilización de los parámetros que los instaladores ponen a nuestra disposición. Por ejemplo, con el instalador NSIS podemos utilizar el parámetro /S para ejecutarlo en modo silencioso. INNO Setup es otro instalador para aplicaciones en Windows, que permite la instalación desatendida. Cuando arrancamos un programa que ha sido empaquetado con este instalador, y le hacemos clic en el pequeño icono, podemos ver que debajo de la opción cerrar aparece la opción "About Inno Setup". Este es el claro ejemplo de un instalador del tipo INNO. Para poder instalar en modo silencioso un programa que sido empaquetado con el instalador de INNO, el parámetro que tenemos que usar es /SP- /VERYSILENT /NORESTART.

Los paquetes MSI, o también conocidos como Windows Installer suelen estar en combinación con InstallShield. En el caso del segundo lo que tenemos que intentar ver, es si podemos extraer de alguna manera los ficheros de ahí dentro, bien sea con un descompresor como Winrar, o bien haciendo una instalación administrativa con el parámetro /a. Esto último, lo que nos hará será extraernos todos los ficheros que están empaquetados en el instalador hacia una carpeta determinada. Una vez tengamos sus archivos fuera seguramente encontraremos un archivo MSI, que es el instalador de Windows. Este tipo de instalador lo podemos poner en modo silencioso con los comandos /qn (o/qb o /quiet) /norestart. También puede ser que directamente nos saque el contenido del programa. En este caso, lo podemos re-empaquetar con otro instalador que si admita switches silenciosos o con un compresor con el modo silencioso marcado (como por ejemplo WinRar).

Los parámetros de la instalación van a personalizar la aplicación, dando la opción al usuario que realiza la instalación de elegir entre diferentes alternativas y opciones, para ajustar la instalación de la aplicación a sus necesidades.

Dado que la mayoría de las aplicaciones actuales se distribuyen a través de repositorios que se encuentran alojados en sitios web, las aplicaciones son accesibles para cualquier usuario de cualquier parte del mundo.

Todas las aplicaciones se distribuyen bajo diferentes acuerdos de licencia, por tanto, el usuario debe configurar es la aceptación o rechazo del acuerdo de licencia, si el usuario no acepta los términos de la licencia, la instalación será abortada.

En las instalaciones se pueden incluir aplicaciones o barras de herramientas para exploradores web adicionales, estas instalaciones son opcionales, eligiendo el usuario final su instalación o no.

Una vez que el usuario acepta los términos de la licencia, el siguiente parámetro a configurar, suele ser la ruta de instalación de los archivos de la aplicación, el instalador ofrece una ruta por defecto, que el usuario puede modificar si lo desea.

Elegido las carpetas donde se van a copiar los archivos necesarios de la aplicación, el siguiente paso que se parametriza es la creación de accesos directos en los menús de inicio del sistema operativo y de un acceso directo en el escritorio, estos parámetros deben ser configurables. En Windows se suele dar la opción al usuario de crear o no un acceso directo en el escritorio y un acceso directo en el Inicio Rápido.

El último parámetro que suele ser accesible por el usuario es la opción de ejecutar la aplicación una vez instalada.

Cuando se implementa una aplicación para ejecutar en interfaz gráfica (GUI), se basa en requerimientos no funcionales de usabilidad. En el caso de los instaladores de interfaz gráfica, también nos encontramos con una interfaz amigable.

En todo proceso de instalación de software en interfaces gráficas, se siguen una serie de pasos aceptados y estandarizados, que son los siguientes:

1. Ventana de selección de idioma.

   Lo primero que decide el usuario es el idioma en el que se le mostrarán los mensajes del proceso de instalación del programa.

2. Ventana de bienvenida.

   Información de la versión de la aplicación, recomendaciones, etc.

3. Acuerdo de licencia. Aceptación de los términos de uso.

   Se tienen que aceptar los términos de licencia del software que se quiere instalar. Si no es así, la instalación será abortada en este momento.

4. Aceptación o no aceptación de herramientas opcionales a instalar.

   Se trata normalmente de complementos web para nuestro navegador. Podemos seleccionarlos o no, y esa elección no tendrá efecto sobre nuestra instalación.

5. Selección de la ubicación donde se guardan los archivos.

   Normalmente, el programa nos propone por defecto la ruta C:\programas pero el usuario debe poder cambiar esta ubicación y elegir otra distinta.

6. Selección de accesos directos.

   Opcional en todo caso.

7. Proceso de instalación.

   En este punto, comienzan a copiarse los archivos en el disco duro del ordenador del usuario, en la ubicación que él haya elegido.

8. Finalización.

   El proceso de instalación termina en este punto y debe avisar al usuario de su terminación.

En el caso de la distribución de software, sobre todo a través de descargas de Internet, nos garantiza la autenticidad del fichero, el autor y que durante la descarga no ha sufrido ningún tipo de alteración.

La plataforma Java nos permita firmar digitalmente ficheros Jar. Cuando se firma un fichero Jar, los que se está asegurando a los usuarios que ejecuten la aplicación es la autoría de ese software. Cuando digitalizamos el fichero, cualquiera puede reconocer la firma digital del autor. El proceso de reconocimiento de la firma digital se denomina verificación.

La firma y verificación de ficheros es una parte importante de la arquitectura de seguridad de la plataforma Java. Podemos configurar la política de seguridad para permitir a un applet (Componente de una aplicación que se ejecuta en el contexto de otro programa, por ejemplo, un navegador) y a una aplicación puedan realizar operaciones normalmente prohibidas como pueden ser la lectura y escritura de ficheros locales, ejecución programas, etc.

La plataforma Java permite firmar y verificar usando números especiales denominados claves públicas y privadas. Las claves públicas y privadas vienen en parejas, y tienen roles complementarios. La clave privada es el "lápiz" electrónico que nos permite firmar un fichero. La clave privada sólo es conocida por el autor de la firma. Un fichero firmado con llave privada, solo puede ser verificado con su correspondiente llave pública. Existe un elemento adicional necesario para la firma y verificación. Este elemento es el certificado que el firmador incluye en un fichero JAR firmado. El certificado es una declaración digital firmada reconocida por una autoridad de certificación que indica quién es el dueño de una clave pública determinada. Resumiendo, la firma digital:

• El desarrollador firma el fichero JAR usando una llave privada.
• La correspondiente llave pública se coloca en el fichero JAR, junto con el certificado, que estará disponible para que cualquiera pueda verificar la firma.

En este documento, vamos a resumir cómo utilizar las herramientas proporcionadas en el Kit de Desarrollo Java ™ para firmar y verificar los archivos JAR:

La plataforma Java ™ le permite firmar digitalmente los archivos JAR. Firmamos digitalmente un archivo por la misma razón que podemos firmar un documento en papel con pluma y tinta, para que los lectores sepan que escribió el documento, o al menos que el documento tiene nuestra aprobación.

Cuando usted firma una carta, por ejemplo, todos los que reconocen su firma pueden confirmar que escribió la carta. Del mismo modo cuando se firma digitalmente un archivo, cualquier persona que "reconoce" su firma digital sabe que el archivo procede de usted. El proceso de "reconocimiento" de las firmas electrónicas se llama verificación.

La posibilidad de firmar y verificar archivos es una parte importante de la arquitectura de seguridad de la plataforma Java. La seguridad es controlada por la política de seguridad que esté en vigor en tiempo de ejecución. Puede configurar la directiva para conceder privilegios de seguridad para los applets y aplicaciones. Por ejemplo, puede conceder permiso a un applet para realizar operaciones normalmente prohibidas, tales como leer y escribir archivos locales o ejecutar programas locales ejecutables. Si ha descargado un código firmado por una entidad de confianza, puede utilizar este hecho como un criterio para decidir cuál de los permisos de seguridad asignará al código.

Una vez que usted (o su navegador) han comprobado que un applet es de una fuente confiable, usted puede relajar las restricciones de seguridad para que el applet realice operaciones que normalmente estarían prohibidas. Un applet de confianza puede tener libertades como se especifica en el archivo de política en vigor.

La plataforma Java permite a la firma y la verificación mediante el uso de números especiales llamados claves públicas y privadas. Las claves públicas y claves privadas vienen en pares, y desempeñan papeles complementarios.

La clave privada es la "pluma" electrónica con la que se puede firmar un archivo. Como su nombre indica, la clave privada es conocida sólo por usted, para que nadie más puede "falsificar" su firma.

Un archivo firmado con su clave privada sólo puede ser comprobada por la correspondiente clave pública.

Las claves pública y privada por sí solas, sin embargo, no son suficientes para verificar realmente la firma. Incluso si usted ha verificado que un archivo firmado contiene un par de claves correspondientes entre sí, aún necesita alguna manera de confirmar que la clave pública en realidad proviene de la persona de la que la firma pretende provenir.

Se requiere un elemento más, por lo tanto, para hacer la firma y verificación. Este elemento adicional es el certificado de que el firmante incluye en un fichero JAR firmado. Un certificado es una declaración firmada digitalmente de una autoridad de certificación reconocida que indica que es dueño de una clave pública determinada. Una autoridad de certificación son las entidades (generalmente empresas especializadas en seguridad digital) que son de confianza en toda la industria para firmar y emitir certificados para las teclas y sus propietarios.

En el caso de los archivos JAR firmados, el certificado indica que es dueño de la clave pública contenida en el archivo JAR.

Al firmar un fichero JAR su clave pública se coloca dentro del archivo, junto con un certificado asociado para que sea de fácil acceso para su uso por cualquier persona que desee verificar su firma.

Para resumir la firma digital:

• El firmante firma el archivo JAR utilizando una clave privada.
• La clave pública correspondiente se coloca en el archivo JAR, junto con su certificado, por lo que está disponible para su uso por cualquier persona que quiera verificar la firma.

Resúmenes y el fichero de firmas.

Al firmar un fichero JAR, cada fichero del archivo tiene una entrada de resumen en el archivo de manifiesto. He aquí un ejemplo de lo que tal entrada podría ser:

Name: test/classes/ClassOne.class
            SHA1-Digest: TD1GZt8G11dXY2p4olSZPc5Rj64=

Los valores son representaciones hash o codificadas de los contenidos de los archivos tal como estaban en el momento de la firma. El resumen de un archivo cambiará sí y sólo si el propio fichero cambia.

Cuando se firma un archivo JAR se genera automáticamente un archivo de firma y se coloca en el directorio META-INF del archivo JAR, el mismo directorio que contiene el archivo de manifiesto. Los archivos de firmas tienen nombres de archivo con una extensión. SF. He aquí un ejemplo del contenido de un archivo de firma:

Signature-Version: 1.0
            SHA1-Digest-Manifest: h1yS+K9T7DyHtZrtI+LxvgqaMYM=
            Created-By: 1.6.0 (Sun Microsystems Inc.)
            Name: test/classes/ClassOne.class
            SHA1-Digest: fcav7ShIG6i86xPepmitOVo4vWY=
            Name: test/classes/ClassTwo.class
            SHA1-Digest: xrQem9snnPhLySDiZyclMlsFdtM=
            Name: test/images/ImageOne.gif
            SHA1-Digest: kdHbE7kL9ZHLgK7akHttYV4XIa0=
            Name: test/images/ImageTwo.gif
            SHA1-Digest: mF0D5zpk68R4oaxEqoS9Q7nhm60=

Como puede ver, el archivo de firma contiene entradas de resumen para los archivos del archivo comprimido que se parecen a las entradas de valor de síntesis, en el manifiesto. Sin embargo, mientras que los valores de resumen en el manifiesto se calculan a partir de los propios archivos, los valores de resumen en el archivo de firma se calculan a partir de las entradas correspondientes en el manifiesto. Los archivos de firma también contienen un valor de resumen para el manifiesto completo (ver la cabecera SHA1-Digest-Manifest en el ejemplo anterior).

Cuando un fichero JAR firmado está siendo verificado, los resúmenes de cada uno de los archivos se vuelven a calcular y comparar con los resúmenes, registrada en el manifiesto para asegurar que el contenido del archivo JAR no han cambiado desde que se firmó. Como una comprobación adicional, los valores de resumen para el archivo de manifiesto en sí se vuelven a calcular y se compara con los valores registrados en el archivo de firma.

Puede obtener información adicional sobre los archivos de firma en la página Formato de manifiesto de la documentación del JDK ™.

El archivo de bloque de firma.

Además de los archivos de firmas, se coloca automáticamente un archivo de bloque de firma en el directorio META-INF cuando se firma un archivo JAR. A diferencia del archivo de manifiesto o el archivo de firma, los archivos de bloques de firmas no son legibles.

El archivo de bloque de firma contiene dos elementos esenciales para la verificación: La firma digital para el archivo JAR que se generó con la clave privada del firmante El certificado que contiene la clave pública del firmante, para ser utilizado por cualquier persona que desea verificar el archivo JAR firmado.

Los nombres de los archivos de bloques de firmas suelen tener una extensión. DSA lo que indica que fueron creados por el algoritmo predeterminado de firma digital. Otras extensiones de nombre de archivo son posibles si las claves asociadas con algún algoritmo estándar de otros se utilizan para la firma.

Firmar archivos JAR.

Se utiliza la firma de JAR y una herramienta de verificación para firmar ficheros JAR. La invocación de la firma JAR y herramienta de verificación mediante el comando jarsigner, por lo que nos referiremos a ella como "Jarsigner".

Para firmar un fichero JAR, primero debe tener una clave privada. Las claves privadas y sus correspondientes claves públicas se almacenan en bases de datos protegidas llamadas Keystore. Un keystore puede contener las claves de muchos firmantes potenciales. Cada clave del almacén de claves puede ser identificado por un alias que suele ser el nombre del firmante y que posee la clave. La clave que pertenecen a María Jiménez, podría tener el alias de "Maria", por ejemplo.

La forma básica del comando para la firma de un archivo JAR es:

jarsigner jar-file alias

En este comando:jar-file es la ruta del archivo JAR a firmar, alias es el alias que identifica la clave privada que se utiliza para firmar el archivo JAR, y el certificado asociado.

La herramienta Jarsigner le pedirá la contraseña para el almacén de claves y alias.

En esta forma básica del comando se supone que el almacén de claves a utilizar está en un archivo llamado keystore en su directorio personal. Se va a crear la firma y los archivos de bloques de firmas con nombres x.SF y x.DSA respectivamente, donde x son las primeras ocho letras del alias, todas en mayúsculas. Este comando básico sobrescribe el archivo JAR original con el fichero JAR firmado.

En la práctica, es posible que desee utilizar este comando junto con uno o más de estas opciones, que debe preceder a la ruta jar-file.

Cuando se implementa un paquete software para su distribución, existe la posibilidad de alojarlo en un servidor web para que sea accesible a un conjunto de usuarios. Estos usuarios pueden instalar directamente el paquete en su ordenador, simplemente haciendo clic en un hipervínculo. Esta forma de distribuir software es muy común en distribuciones Linux como Ubuntu.

Para poder instalar aplicaciones desde un servidor, lo único que el usuario realiza es la pulsación sobre el hipervínculo donde aparece el paquete que quiere instalar. 

Para poder realizar esta instalación, existe apturl. AptUrl es un miniprograma gráfico para instalar programas desde el repositorio donde se encuentran. Para poder distribuir aplicaciones utilizando esta herramienta, se edita una página web, donde se suele dar una descripción del programa a instalar, y se añade el enlace siguiente:

<a href=”apt:paquete”>Nombre del paquete a instalar</a>

Si queremos distribuir múltiples paquetes en el mismo enlace, la sintaxis sería la siguiente:

<a href=”apt:paquete1, paquete2, paquet3”> Nombre de la aplicación </a>

Un ejemplo de instalación de esta forma, sería:

apturlapt:pidgin,pidgin-plugin-pack

Donde se instalaría la aplicación Pidgin y Pidgin Plugin Pack .

Se puede presentar otra posibilidad, y es que la distribución se produzca a través de un fichero que tenga empaquetada y comprimida la aplicación. Se pueda dar el caso de la distribución a través de fichero iso, los cuales nos van a obligar a crear un CD o DVD con el software de instalación de la aplicación, o bien utilizar programas como Daemon's tool para montar la imagen ISO y poder instalar el software.

Otro tipo de distribución, muy común en Linux, es la posibilidad de descargar desde Internet paquetes deb o rpm. Esto paquetes contienen aplicaciones instalables en nuestra distribución, deb si estamos en Ubuntu. Para poder instalar estos paquetes se puede usar el gestor de paquetes de Ubuntu, bien entorno gráfico, o bien en entorno de consola.

Otra forma de distribuir software a través de web, sería el empaquetado en paquete jar o archivos comprimidos zip o rar. En el caso de la primera forma de distribución, lo único que necesitamos para instalar el paquete, sería disponer de una máquina virtual Java. En el caso de distribuir los paquetes comprimidos, necesitamos en el ordenador cliente un programa para descomprimir compatible. En todos los casos, hay que tener en cuenta que el software que se descarga y se quiere instalar, esté diseñado para nuestro sistema operativo y sea compatible con nuestra arquitectura.