Hace unos años investigadores chinos habían logrado reducir la complejidad del algoritmo SHA-1 a 2^69, es decir, habían logrado reducir su complejidad en 2^11 en relación con el ataque de cumpleaños de 2^80, dicho de otro modo, Shandong, Wang, Yin y Yu, durante la "Cripto Conference" de 2004, demostraron que habían debilitado el SHA-1 en un factor de 2048, lo que no es poco.

Ahora, según he podido leer en un boletín de Hispasec, unos investigadores australianos han logrado reducir su complejidad a 2^52, lo que es un logro impresionante, puesto que por cada unidad en la que se reduce el exponente, se reduce la fortaleza del algoritmo en un 50%. Dicho de otro modo, a fecha de hoy podemos decir que el algoritmo SHA-1 se ha debilitado en más de un 99% en relación con su fortaleza inicial derivada del ataque de cumpleaños, lo que es muy significativo, aunque nos parezca que 2^52 es una cifra suficientemente grande...

Si ya en el 2004/2005 se aconsejaba abandonar el SHA-1, con este nuevo avance logrado por los australianos, su sustitución por otros algoritmos más resistentes se hace indispensable. Una posible solución, hasta que se publique el SHA-3, es decir, el algoritmo que está llamado a sustituirlo, sería usar dos algoritmos consecutivos, por ejemplo SHA-1 Y RIPEMD-160, puesto que una colisión en SHA-1 es virtualmente imposible que coincida también en RIPEMD-160. Esta solución de la firma múltiple tiene como ventajas que usa algoritmos disponibles en sistemas criptográficos de todo tipo y no implica un excesiva computación.

Hay que señalar, que los documentos que hayamos firmado usando SHA-1 y que deban tener vigor en el tiempo, puede que no sean seguros dentro de unos meses. Como norma general, deberíamos usar algoritmos criptográficos que estimemos que vayan a ser seguros en un tiempo equivalente a la esperanza de vida de la persona que los utiliza y un 50% más.

Una caída del estándar SHA-1 también afectaría a la seguridad de los certificados digitales, puesto que sería factible generar certificados con el mismo fingerprint que otros, lo que permitiría suplantar la personalidad de personas, o de páginas web.

Hay que señalar, que el e-DNI se han establecido mecanismos que permiten construir el "PAHT" de Certificación (Cadena de Confianza) utilizando SHA-1 o SHA-256, para dar soporte a aquellos sistemas operativos que no contemplan el uso de SHA-256 como algoritmo de "hash" o resumen. Desgraciadamente, este mecanismo que depende del sistema operativo que estamos usando, es transparente al usuario la mayoría de las veces, siendo complicado saber la forma en la que se establece el "path" de confianza, sin embargo el e-DNI siempre usa el inseguro SHA-1 para firmar los documentos, según aparece en la página web oficial del mismo.

También hay que tener en cuenta, que las claves de los e-DNI de los usuarios están firmadas usando SHA-1, lo que puede ser un problema de seguridad a medio y largo plazo y con independencia de la validez en el futuro de los documentos que firmemos, o que hayamos firmado anteriormente, usando el omnipresente algoritmo SHA-1. Sin embargo, las claves raíz y subordinadas del e-DNI, con una vida de 30 y 15 años respectivamente, están firmadas usando SHA-1 y SHA-256, por lo que las podemos considerar seguras en este momento.

Ni que decir que ya he configurado mi GPG para que use la función SHA-256 en la firma de documentos y correos electrónicos, aunque también es cierto que en los correos uso siempre firma doble, GPG y de la FNMT, para que no haya problemas.

"Copyleft 2009 Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved"

ACTUALIZACIÓN:

Recomiendo leer este documento de la Autoridad de Certificación española ANFAC que aunque es anterior a los logros del equipo australiano, dice cosas muy sensatas y que con la situación actual, debemos tener muy presentes:

Ataque SHA-1 [PDF]

Asimismo, recomiendo leer estas recomendaciones de Debian-administración ante los problemas surgidos con el SHA-1

En el artículo anterior de esta serie dedicada a la interoperabilidad vimos algunas estrategias que nos permitían mejorar nuestra capacidad de comunicación con otros usuarios y la seguridad de nuestra información. Estas estrategias se basaban en uso de estándares abiertos y las podemos poner en práctica, sin muchos problemas, en nuestro ámbito doméstico. Sin embargo, lograr la interoperabilidad en las organizaciones es mucho más complicado de lo que parece. Está claro que las medidas y estrategias que vimos en el artículo anterior son un buen comienzo para cualquier organización y son sencillas de implantar en las estaciones de trabajo, pero en las organizaciones, con independencia de su tamaño, es necesario ir más lejos y tener una visión de conjunto, ya que el escenario puede ser muy complejo.

Lo primero que necesita una organización para lograr la interoperabilidad es ser consciente del problema y tomar las medidas adecuadas para solucionarlo. Como ya hemos dicho, el elemento clave para lograr la interoperabilidad es el factor humano. Debemos tener en cuenta que nuestra interoperabilidad dependerá de las decisiones tecnológicas que tome una persona, o grupo de personas, en nuestra organización. Una vez que seamos conscientes del problema, es fundamental la especialización de los responsables de las tecnologías de la información de la organización y la formación de los usuarios.

Debemos estar convencidos de que la interoperabilidad interna y externa de las organizaciones, son claves para el desarrollo eficiente y sostenido de la organización. No creo que sea una buena política el perder un porcentaje de clientes, aunque sea pequeño, por problemas de interoperabilidad, que además, se pueden solucionar sin invertir más dinero, o incluso, ahorrando dinero. Igualmente, ninguna organización puede ser competitiva si arrastra un pesado lastre de "legacy", o si no puede optar libremente por las tecnologías que más le interesen en cada momento.

Desgraciadamente, la realidad es muy distinta y los monopolios tecnológicos han provocado que un elevado porcentaje de organizaciones públicas y privadas sean víctimas del "legacy" y por lo tanto, cautivas de tecnologías privativas, dificultando seriamente su capacidad de innovación, poniendo en riesgo el acceso a su conocimiento e información y limitando su capacidad de comunicación interna o externa.

El marco de interoperabilidad

Una vez que somos conscientes del problema de la interoperabilidad, una buena práctica es elaborar un documento que defina la forma en la que vamos a lograrla en nuestra organización. Este documento recibe diversos nombres, como esquema de interoperabilidad, arquitectura técnica de referencia, marco de interoperabilidad, pero eso es lo de menos. Lo que debemos contestar de forma prioritaria es la pregunta ¿qué es lo que debe contener este importante documento?.

Muchas organizaciones se empeñan en relacionar en sus marcos de interoperabilidad las aplicaciones "estándar" a utilizar en la organización, lo que no es una buena idea, puesto que las aplicaciones cambian con el tiempo, suelen estar ligadas a un determinado marco tecnológico y la mayoría de ellas, permiten usar estándares abiertos y formatos privativos de forma indistinta. Por lo tanto, si no se definen y establecen adecuadamente los estándares abiertos a utilizar en el marco de interoperabilidad, este documento no será muy útil para lograr nuestros objetivos.

Un buen marco de interoperabilidad ha de tener presente el concepto de "neutralidad tecnológica" y debe relacionar con claridad meridiana los estándares abiertos que se usarán en nuestra organización. Además, estos estándares deberían estar clasificados como emergentes o recomendados, obligatorios o normalizados y en abandono, como referencia para los usuarios y desarrolladores de lo que está por venir y de lo que debemos ir abandonando, para no quedar desfasados y no poner en riesgo el acceso, o la seguridad de nuestra información en el futuro.

Por lo tanto, este documento ha de estar vivo y debe estar sometido a cambios y a las sugerencias de los usuarios. De nada sirve un marco de interoperabilidad si no es dinámico y capaz de adaptarse a las nuevas tecnologías y a los nuevos estándares con el paso del tiempo. Asimismo, debe contener una serie de normas claras y positivas que nos permitan lograr la interoperabilidad dentro de la organización de forma transparente y natural.

Una de las tareas más complicadas para establecer un buen marco de interoperabilidad es el establecimiento uno los criterios, normas y estándares, que sean adecuados para la finalidad que pretendemos. Para facilitar este trabajo, lo mejor es definir unos principios básicos a los que someteremos el contenido de todo el documento. Por ejemplo, podemos establecer los siguientes principios:

1. Neutralidad tecnológica y capacidad de adaptarse sin problemas a las nuevas tecnologías.
2. Eliminación del "legacy" y de la dependencia tecnológica de empresas, tecnologías o proveedores.
3. Facilitar el acceso a los servicios de la organización.
4. Lograr la transparencia tecnológica.
5. Eficacia y eficiencia de los métodos y procedimientos.
6. Lograr la interoperabilidad vertical, horizontal y en el tiempo.
7. Mejorar la cooperación y coordinación entre los distintos departamentos de la organización.
8. Mejorar la participación efectiva de los miembros de la organización y en la generación y transferencia de conocimiento dentro y/o fuera de la organización.

Además, un buen marco de interoperabilidad debería cumplir con los siguientes objetivos básicos:

1. Garantizar la comunicación electrónica y el acceso a los servicios de la organización, sin dependencias tecnológicas. Es decir, el marco de interoperabilidad ha de apostar claramente por la eliminación de todas las barreras tecnológicas que pueden existir en la organización, mediante el uso de estándares abiertos y un serio compromiso con la neutralidad tecnológica, pero sin caer en las utopías irrealizables, o en una mera declaración de intenciones. No es un buen marco de interoperabilidad aquel que tiene recomendaciones que no se pueden llevar a cabo, o el que es tan rígido, que no permite poner en práctica proyectos piloto, o iniciativas para la mejora de la infraestructura tecnológica. El marco de interoperabilidad ha de ser un mecanismo flexible y dinámico de coordinación y un instrumento objetivo y positivo para todos los miembros de la organización, conteniendo unas normas claras y precisas, que puedan ponerse en práctica a todos los niveles.
2. Garantizar la interoperabilidad de los servicios y sistemas de información, tanto para la relaciones internas como para las externas.
3. Preservar el conocimiento generado, asegurando el acceso al mismo de forma transparente, controlada y segura, con independencia del momento, o de la plataforma tecnológica con la que fue generado.
4. Garantizar el uso eficaz y eficiente de las infraestructuras tecnológicas de la organización.
   

Algunas estrategias útiles

Si queremos lograr la interoperabilidad dentro de nuestra organización debemos atender a sus dimensiones organizacional, semántica y tecnológica, pero hay algunas estrategias generales que nos pueden ser de utilidad, como por ejemplo, las siguientes:

1. Buscar la accesibilidad de los contenidos y el conocimiento, con independencia de la tecnología que se use para acceder a ellos.
2. Establecer unas políticas de seguridad y privacidad coherentes y fáciles de llevar a cabo, con unos mínimos acordes con el nivel de amenaza y tipo de información a proteger. Hay que tener en cuenta, que la seguridad suele ir reñida con la comodidad.
3. Uso exclusivo de estándares abiertos, convirtiendo a estos estándares toda la información que se encuentre en formatos privativos, o que se encuentre almacenada usando estándares abiertos en situación de abandono.
4. Siempre que sea posible, se debería optar por el uso de software libre. No en vano, el software libre suele usar preferentemente estándares abiertos. Asimismo, es frecuente que el software libre ayude a definir nuevos estándares abiertos y sus especificaciones están disponibles públicamente. La disponibilidad del código fuente también tiene como consecuencia el debate abierto y democrático sobre sus especificaciones y estándares, lo que lo suele hacer que el software libre sea más robusto e interoperable que las aplicaciones privativas equivalentes. No será muy complicado encontrar aplicaciones libres que cumplan con los criterios de nuestro marco de interoperabilidad, por lo que las deberíamos considerar en igualdad de condiciones con sus contrapartidas propietarias en todo plan de adquisición.
5. Si es posible, deberíamos usar aplicaciones, o herramientas de desarrollo, que puedan funcionar en más de una plataforma tecnológica. En este sentido, las aplicaciones JAVA, o tecnologías como el XML, serán de gran ayuda para lograr nuestros objetivos de interoperabilidad sin caer en las trampas de la dependencia tecnológica, o del "legacy". Si optamos por aplicaciones y herramientas multiplataforma, no tendremos problemas para optar por una u otra plataforma tecnológica en base a nuestras necesidades futuras.
6. El uso de la virtualización nos puede ayudar a lograr la interoperabilidad a un coste razonable y sin tener que renunciar a la plataforma tecnológica que consideremos más adecuada en cada momento.
7. Las arquitecturas orientadas a servicios y las aplicaciones Web, si las diseñamos interoperables y basadas en estándares abiertos, nos permitirán independizar la plataforma tecnológica del cliente de la del servidor, lo que aumentará la neutralidad tecnológica de la organización y mejorará su capacidad para cambiar de plataforma tecnológica de los clientes, o del servidor, si se considerase necesario.

El aspecto organizacional de la interoperabilidad es evidente que depende de nuestra organización, por lo que es complicado hablar de un caso general, o de una recomendación básica, que cubra todas nuestras necesidades y situaciones. En el aspecto semántico, la recomendación básica sería el uso de XML, incluso con el establecimiento de diccionarios personalizados y adaptados a las necesidades específicas de nuestra organización. Sin embargo, en el aspecto tecnológico, como más general, sí es posible establecer unas recomendaciones básicas para lograr la interoperabilidad técnica. Cuando pensemos en la interoperabilidad técnica debemos considerar los siguientes escenarios:

1. Las comunicaciones hacia el exterior:
   1. La presentación e intercambio de datos.
   2. La accesibilidad a la información y diseño de las interfaces.
   3. La posibilidad de acceso multicanal.
   4. Los juegos de caracteres e idiomas.
   5. La posibilidad de generación de conocimiento de forma colectiva y concurrente.
   6. Los estándares para el almacenamiento de información y formato de documentos.
   7. La compresión de archivos.
2. En las comunicaciones internas debemos considerar:
   1. La integración de datos y el middleware.
   2. El uso de estándares XML y EDI (Electronic Data Interchange).
   3. El establecimiento de servicios web.
   4. El uso de arquitecturas distribuidas orientadas a servicios (SOA).
   5. El establecimiento de servicios de interconexión.
   6. El uso de protocolos de transferencia de archivos e información.
   7. El transporte y seguridad de la información, teniendo en cuenta además, que la seguridad afecta a todas las capas de comunicación. En general, la seguridad debe tenerse en cuenta para establecer los servicios de seguridad, las infraestructuras de clave pública, los sistemas de cifrado, la seguridad de los servicios web, los cortafuegos y la protección general contra malware e intrusiones.
   8. El establecimiento de servicios de almacenamiento de información.
   9. El acceso a las cuentas de correo corporativas y a los servicios distribuidos.
   10. El establecimiento de servicios de directorio y de nombres de dominio.
   11. El establecimiento de todos los servicios de red.

En todo caso, el 80% de nuestros problemas de interoperabilidad corporativa, en sus dimensiones vertical, horizontal y en el tiempo, deberían desaparecer si usamos estándares abiertos y tenemos en cuenta el principio de neutralidad tecnológica en todas nuestras decisiones, olvidándonos por un momento de la plataforma tecnológica que estamos usando y de las aplicaciones "oficiales" aprobadas en nuestra organización, para comenzar a pensar de forma global y prioritaria, en estándares abiertos.

"Copyleft 2009 Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved"

En los primeros artículos de esta serie hemos explorado el concepto de Interoperabilidad y hemos revisado algunos problemas con los que me he enfrentado a lo largo de mi vida en torno a este problema, pero también es evidente que, según crecía el número de personas y servicios conectados a Internet, los problemas de interoperabilidad ha ido quedando en evidencia y ha sido necesario establecer estrategias para evitarlos o reducirlos. Sin embargo, es prácticamente imposible tratar este problema tan amplio en un simple artículo, así que nos tendremos que conformar con algunas pinceladas e ideas simples de lo que podemos hacer cada uno de nosotros de forma individual para mejorar la interoperabilidad. Desde las instituciones europeas, a gobiernos, pasando por empresas, todos están comenzando a establecer y a documentar estratégicas para combatir, con mayor o menor éxito, los problemas de interoperabilidad y todas pasan por el uso de estándares abiertos, pero lo primero que debemos hacer, si queremos avanzar, es ser conscientes del problema...

TRAS LA ESTELA DE LA ADMINISTRACIÓN

Como comenté en el primer artículo, cuando hablamos de interoperabilidad, lo que es bueno para el Estado, suele ser bueno también para los usuarios, ya que las estrategias para lograr la interoperabilidad entre sistemas heterogéneos son las mismas en todos los casos. De hecho, las Administraciones Públicas disponen de una gran cantidad de documentación muy útil para establecer estrategias contra los problemas de interoperabilidad en todos sus aspectos y dimensiones y por ello, lo mejor es aprovechar todo este trabajo.

Uno de los documentos en castellano que más recomiendo, son los Criterios de seguridad, normalización y conservación, que elaboró el MAP para su uso en la Administración General del Estado. Sin embargo, al ser criterios y recomendaciones, en lugar de una Ley de obligado cumplimiento, es una pena que no se haya hecho demasiado caso en algunas administraciones, así nos habríamos evitado problemas como el que hemos comentado de la página del Defensor del Pueblo Español, o que no sean interoperables las distintas historias clínicas, cuando nos movemos por el territorio nacional. Pero debemos tener en cuenta, que estos criterios, además de garantizar la accesibilidad de nuestra información y servicios para todo el mundo, parten de la lógica más aplastante y nos defienden de las malas decisiones tecnológicas, ayudándonos también, a mantener nuestra información segura y accesible en el tiempo, algo que es muy interesante.

Por ejemplo, entre los criterios de conservación, el 6.2, dice algo que ya deberíamos tener claro en este punto: "Se deben convertir los ficheros antiguos creados con aplicaciones propietarias a formatos que corresponden a especificaciones abiertas libres de patentes y royalties". Es más, el documento recomienda usar formatos abiertos directamente, si la aplicación los soporta nativamente, o usar herramientas de conversión adecuadas, en el caso de que la aplicación no soporte formatos abiertos. Con esto ya podemos establecer una estrategia coherente sobre el tratamiento de los formatos privativos de las aplicaciones que usamos normalmente.

No menos interesante es el criterio de conservación 4.1, que dice: "Se debe seleccionar un conjunto común de estándares de formato de fichero: gráfico, texto, datos, audio y vídeo que faciliten el acceso y circulación de la información, y su posterior recuperación y conservación". Como es lógico, lo mejor sería que estos estándares comunes sean abiertos para que puedan ser usados por todo el mundo sin trabas.

Como se puede ver, lo que nos dice este criterio es de lo más lógico y razonable, si no queremos tener problemas de interoperabilidad, pero desgraciadamente, no siempre lo tenemos presente. Más adelante, en el mismo documento, se especifican una serie de formatos abiertos recomendados para los distintos tipos de información a almacenar; texto, datos estructurados, gráficos, vectoriales o comprimidos. Es evidente que no son todos los que son y dado que el documento es del año 2004, puede que esté un poco anticuado, pero como referencia inicial no están nada mal. Desde mi punto de vista, cuando se habla de estándares abiertos, habría que calificarlos de alguna forma, como emergentes, recomendados, obligatorios, en abandono, etc, como referencia a usuarios y desarrolladores y para permitir a los usuarios la conversión de sus datos a los estándares más adecuados según pasa el tiempo y cambian las tecnologías.

Como podremos comprobar, en este documento oficial no se hace referencia a ningún formato de archivo de los que podemos llamar "estándar de facto", que aunque son usados por muchos usuarios en todo el mundo, ni son un estándar, ni son abiertos por el simple y circunstancial hecho de ser usados masivamente en el mundo. Desde mi punto de vista, considerar un formato privativo como "estándar de facto", es algo perverso que intenta elevar a un nivel similar al de los estándares abiertos, debemos ser conscientes de que no son un un estándar y a la larga, nos puede dar problemas de interoperabilidad.

Incluso un "formato abierto" puede ser fuente de problemas, nada impide que dicho formato quede igualmente abierto a la adición de nuevas funcionalidades, quizás protegidas mediante patentes, para ayudar a que se mantengan los monopolios y por lo tanto, afectando su utilidad para la conservación de la información a largo plazo.

Aunque un formato esté publicado abiertamente, no es un estándar y sigue siendo privativo, por lo que nada obliga a que las modificaciones o extensiones al formato se publiquen igualmente. De hecho, la mayoría de los formatos privativos publicados siguen llenos de "trampas" privativas que complican las cosas a los que los usan como si fueran un estándar abierto en sus aplicaciones. Por lo tanto, con el paso del tiempo aunque un formato esté publicado, puede acabar teniendo partes en el mismo, que solamente sean accesibles desde una aplicación privativa, que incluso puede estar protegida mediante patentes internacionales. La consecuencia directa es que no podemos garantizar la continuidad y libertad de uso de un formato por el simple hecho de que en cierta ocasión se publicó su especificación. Es decir, que hay razones de peso para considerar que un formato abierto, en lugar de un estándar abierto, no debería ser un contenedor adecuado para garantizar la preservación de la información a largo plazo, la propiedad pública de los documentos públicos, o para garantizar la libertad de elección de los usuarios.

Los criterios de normalización, seguridad y conservación para el ejercicio de potestades están en un denso documento de 171 páginas, que recomiendo leerlo detenidamente y aplicarlo en la medida de lo posible, puesto que si lo hacemos, tendremos muchas probabilidades de no tener problemas en el futuro con nuestros datos. He de decir, que es muy posible que este documento sea el embrión de los futuros esquemas nacionales de Seguridad e Interoperabilidad que desarrollarán reglamentariamente la Ley 11/2007, por lo que lo podemos considerar una interesante guía, que además, puede tener una adecuada continuidad en el futuro, proporcionando una buena anticipación de lo que está por venir desde el punto de vista normativo.

EL PROBLEMA DE LOS TIPOS DE LETRA

Los problemas de interoperabilidad pueden ser de lo más curiosos. Por ejemplo, hay gente que me ha comentado que pierden el formato de los documentos cuando los crean con Microsof Office y los intentan abrir con OpenOffice.org bajo Linux, o incluso, cuando los crean con OpenOffice para Windows y los intentan abrir con OpenOffice.org bajo Linux. En este caso, el problema de interoperabilidad puede venir de la mano de los tipos de letra típicos de Windows, como Arial, Times New Roman o Courier New. Estos caracteres privativos, que fueron creados en su momento por Monotype Corp. para Microsoft, tienen una geometría distinta a los tipos de letra usados por otras plataformas como Linux o Mac, y en especial, se diferencian en el espaciado entre la letras, que se denomina kerning. Como es lógico, otra opción sería usar siempre tipos de letra libres que puedan usarse en Linux y en Windows, pero en este caso tendríamos problemas de compatibilidad con los usuarios que usen por omisión las fuentes específicas de Windows, que como hemos dicho, son privativas.

La solución sería instalar los caracteres típicos de Windows bajo linux, lo que aunque es posible, puede ser relativamente complicado de lograr si lo queremos hacer legalmente y sin problemas con los derechos y licencias de Microsoft. El caso es que existe un procedimiento para instalar estas fuentes desde los repositorios de Microsoft, pero como hemos dicho, es complicado, e implica usar una gran cantidad de paquetes adicionales para convertir y adaptar los archivos a Linux.

Lo mejor y más rápido, es recurrir a unas fuentes libres, creadas por RedHat, que se denominan "Liberation Fonts" y que son compatibles, o interoperables, con las de Windows. Hay que señalar, que la mayoría de las distribuciones, al menos así ocurre con mi Mandriva 2008.1, disponen de un paquete específico con estas fuentes, pero en caso necesario, nos las podemos bajar directamente de RedHat.

Tras instalar las fuentes en el directorio /usr/share/fonts/liberation de nuestro sistema Linux, será necesario configurar Gnome, o el Kde, para que las use adecuadamente y estén disponibles para todas las aplicaciones del sistema. Asimismo, podemos usar las tablas de sustitución de OpenOffice bajo Linux para que use automáticamente las correspondientes "Liberation fonts" cuando detecte una fuente Arial, Times New Roman, o Courier en un archivo procedente de Windows. Esto también lo podemos hacer con OpenOffice, o con Microsoft Office bajo Windows, para que seleccione automáticamente las fuentes adecuadas de Windows, cuando abramos un documento creado en Linux que use las "Liberation Fonts". Claro que debemos tener la precaución de usar las "Liberation Fonts", en lugar de las fuentes típicas de Linux, cuando queramos tener interoperabilidad con Windows, por lo que son las que yo uso normalmente en mis documentos.

MEJORANDO LA INTEROPERABILIDAD DE OPENOFFICE.ORG

Como hemos comentado en nuestro artículo anterior y sin entrar en polémicas entre bondades o defectos de las suites ofimáticas libres o privativas, lo cierto es que OpenOffice.org es una buena opción si queremos usar los estándares abiertos más avanzados, como el Open Document Format (ODF), o el Portable Document Format (PDF), ya que ambos están soportados de forma nativa y de forma muy interesante, por esta aplicación ofimática libre.

Además, OpenOffice.org puede abrir y almacenar archivos en los formatos de Microsoft Office, lo que puede que no sea una buena idea, en lo que respecta a la conservación de documentos a largo plazo, o a la interoperabilidad con otros usuarios, pero también es cierto, que OpenOffice.org, gracias a esta funcionalidad, puede ser usada como herramienta de conversión desde los formatos privativos de Microsoft a estándares abiertos.

Anteriormente hemos visto la forma de mejorar la interoperabilidad entre las aplicaciones Windows y Linux a nivel de caracteres, lo que es especialmente interesante para mejorar la interoperabilidad en lo que a la estructura de documentos se refiere, pero también se pueden hacer algunas cosas más, para mejorar la interoperabilidad de OpenOffice.org y sus funcionalidades con otros estándares abiertos, como el PDF.

Por ejemplo, si instalamos Sun PDF Import Extension [Beta], podremos modificar los archivos de OpenOffice.org almacenados en formato PDF, aunque no dispongamos de los archivos originales. Cuando tenemos esta extensión, los archivos PDF son importados en Draw e Impress, para conservar su estructura y para permitir una edición básica de los mismos. Esta es una solución muy interesante para hacer pequeñas correcciones, o cambios en el documento PDF, como fechas, cifras, o pequeñas partes del texto. Desgraciadamente, no se pueden importar en este momento los documentos PDF nativos, es decir, los que no han sido creados con OpenOffice.org. Hay versiones de esta extensión para las distintas plataformas para las que está disponible OpenOffice.org en su versión 3.X, por lo que también la podemos usar desde Windows. También está previsto que en siguientes versiones de este añadido se mejoren las capacidades de edición de los documentos PDF.

Esta extensión también permite algo muy curioso e interesante cara a la interoperabilidad y el almacenamiento de la información a largo plazo, como es la exportación de un PDF híbrido, es decir, un PDF con el archivo fuente, en formato ODF, embebido en él. De esta forma, el PDF híbrido se puede abrir desde OpenOffice.org como si fuera un ODF normal, sin perder el formato original del documento y con todas las posibilidades de edición que permite el programa. Sin embargo, los usuarios que no dispongan de OpenOffice.org podrán seguir abriendo la parte PDF de ese archivo híbrido sin problemas, por lo que seguirá siendo interoperable con los lectores PDF tradicionales. En este momento es una de las opciones que más utilizo con OpenOffice.org cuando genero mis documentos y deseo garantizar su interoperabilidad a largo plazo, pero sin renunciar a las posibilidades de edición cuando los abro en mi sistema. Es más, usando Sinadura o PortableSigner, puedo añadir una firma digital a estos archivos PDF, lo que también es interesante, ya que firmar el documento, no me impide editarlo posteriormente aunque, como es lógico, con ello se pierde la validez de la firma. Hay que señalar que OpenOffice.org también me permite firmar digitalmente y verificar la firma digital de documentos almacenados en formato ODF.

Para crear un archivo híbrido, una vez instalada la extensión Sun PDF Import, seleccionaremos la secuencia de mandatos Archivo | Exportar en formato PDF y en el recuadro de diálogo que nos aparece en pantalla, seleccionaremos las opciones PDF/A-1, que es una opción para almacenamiento a largo plazo de documentos PDF (encapsula todos tipos de letra que se utilizaron durante la edición y las etiquetas PDF) y la opción Crear archivo híbrido, seguido de la pulsación del botón Exportar. Bastará con seleccionar un nombre y trayectoria para nuestro archivo PDF en el siguiente recuadro de diálogo y volver a pulsar el botón Exportar, para finalizar el procedimiento.

También hay disponible un visualizador de archivos en formato ODF para Firefox. Este visualizador ODF también permite exportar el documento a PDF con solamente pulsar un botón en la interfaz de usuario del "plugin". 

MEJORANDO LA INTEROPERABILIDAD DE MICROSOFT OFFICE

Comenzaremos por mejorar la interoperabilidad de Office 2000, Office XP y 2003, con Office 2007. Para ello, existe un paquete de compatibilidad disponible en la misma página de Microsoft. Mediante su instalación, se podrán abrir, editar y almacenar, archivos en los nuevos formatos utilizados por Word, Excel y PowerPoint 2007. El Paquete de compatibilidad también se puede usar con Microsoft Office Word Viewer 2003, Excel Viewer 2003 y con el Visor de PowerPoint 2003, para poder abrir con con ellos los archivos de Office 2007.

Gracias a este paquete de interoperabilidad ascendente, no es necesario actualizarse a Office 2007 para obtener la interoperabilidad con sus formatos más modernos. Desgraciadamente, no siempre se tiene en cuenta esta posibilidad y hay muchos contratos de la Administración en los que se argumenta esa necesidad de interoperabilidad con Office 2007 para pagar nuevas licencias de Office, como ocurrió recientemente con el contrato de actualización de los ordenadores del Defensor del Pueblo Español, que además, se actualizaron a Windows Vista, con la simple excusa de la interoperabilidad, en este caso se gastaron 84.908 euros, para equipar a 190 ordenadores.

Desde el punto de vista de la interoperabilidad bien entendida, los beneficios de este añadido para las versiones de Office anteriores a la 2007, quedan reducidos a poder abrir, editar y almacenar archivos en los nuevos formatos de la última versión. Pero no nos equivoquemos, yo no recomiendo usar los formatos de Office 2007 para almacenar información por los motivos que ya he explicado anteriormente y menos, si queremos que esa información pueda ser usada por otros usuarios sin problemas, o que permanezca en el tiempo, pero para los gustos, los colores.

Microsoft tampoco ha sido ajena a las necesidades y a las nuevas tendencias en materia de interoperabilidad que demandan los usuarios. Se puede decir que las presiones para lograr una mayor interoperabilidad con los productos de Microsoft, aunque no sin resistencia por parte de la empresa, están obrando sus frutos en el mercado global. Por ello, en mayo de 2008 Microsoft anunció que con el Service Pack 2 para Office 2007, que se lanzaría en el primer semestre 2009, se ampliarían los formatos soportados por Office, añadiendo compatibilidad con XML Paper Specification (XPS), Portable Document Format (PDF) 1.5, PDF/A y Open Document Format (ODF) v1.1. Con este Service Pack los usuarios podrán abrir, editar y almacenar documentos en ODF y almacenar archivos en XPS y PDF, sin necesidad de recurrir a ninguna aplicación externa. Incluso se puede configurar Microsoft Office, para que use ODF como formato por omisión a la hora de almacenar documentos, en lugar de los formatos nativos de Office, que desde mi punto de vista, sería lo más recomendable, si deseamos obtener interoperabilidad con otros usuarios y en el tiempo. Sin embargo, también es cierto, que ha habido quejas sobre la implementación del estándar abierto ODF en el SP2 que se publicó el pasado abril, por lo que esperamos que mejore en el futuro el soporte proporcionado por Microsoft al estándar abierto ODF 1.1.

Lo cierto es, que poco a poco, pero sin pausa, las Administraciones Públicas españolas se van adaptando a la Ley 11/2007 y ya van apareciendo páginas de la Administración que presentan la documentación usando exclusivamente estándares abiertos e interoperables, dejando de aparecer el peligroso y omnipresente DOC de ellas. Incluso ya se comienzan a ver páginas en las que se usan el formato ODT como formato para distribución de formularios y documentos editables, de forma alternativa al DOC.

Para lograr la interoperabilidad de Office con los formatos ODF, también se puede recurrir al añadido OpenXML/ODF Translator Add-in for Office, que podemos encontrar en Sourceforge. El objetivo de este proyecto, que ha sido nominado para los premios de la Comunidad de 2009, es la de permitir la interoperabilidad entre las aplicaciones basadas en ODF 1.1, como OpenOffice.org y las basadas en el estándar ECMA Office OpenXML, como es el caso de Office 2007. Hay que señalar, que este es un proyecto muy activo, siendo la última versión del "plugin" de marzo de 2009 y que existe una versión para la línea de mandatos de este conversor, que puede ser usada para convertir archivos una gran cantidad de archivos en procesos por lotes, liberando a nuestra organización de los peligrosos formatos privativos.

Como podemos ver, el ODF ya no es un formato ajeno a Office y no hay problemas para usar este estándar abierto como formato por omisión para el almacenamiento y recuperación de documentos creados con Office. Con los añadidos disponibles libremente en la Red podemos convertir el ODF en nuestro formato estrella para el almacenamiento de información, con independencia de la tecnología que usemos. Como hemos visto, el ODF es un formato que podemos abrir con casi cualquier aplicación, tanto privativa como libre, desde procesadores de textos, a navegadores web.

Con muy poco esfuerzo podemos hacer que nuestras aplicaciones sean compatibles con los estándares abiertos ODF y PDF, garantizando así la accesibilidad y la recuperación de nuestra información desde cualquier plataforma tecnológica. Como es lógico, cuantos más usuarios instalen estos añadidos en sus sistemas Office, más interoperabilidad ganaremos entre todos y más sencillo será el intercambio de información en la Red, así como su conservación a largo plazo.

Por supuesto, visto lo visto, las Administraciones Públicas deberían tener instaladas todas estas herramientas de interoperabilidad por omisión en todos sus sistemas Windows y en base a lo que se establece en la Ley 11/2007, hacer uso de ellas para utilizar solamente estándares abiertos en sus relaciones con otras administraciones y con los ciudadanos, que como se puede ver, se puede lograr con independencia de la plataforma tecnológica que se esté utilizando. Para ampliar la información sobre las ventajas del uso del estándar ODF, recomiendo la lectura de los documentos que hay en esta página de la Comisión Europea.

"Copyleft 2009 Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved"

“La capacidad de los sistemas de tecnologías de la información y de las comunicaciones (TIC) y de los procesos empresariales a los que apoyen, de intercambiar datos y posibilitar la puesta en común de información y conocimientos”.

“La habilidad de los sistemas, unidades o fuerzas para proveer servicios a y para aceptar servicios de otros sistemas, unidades o fuerzas, y para usar los servicios así intercambiados para operar efectivamente juntos”.

“neutralidad tecnológica es la condición en la que una acción, definición, ley, estándar, etc, no se formula de tal manera que sesgue todas las decisiones subsecuentes a favor de una tecnología en particular, entre aquellas capaces de resolver el problema”.

“... La neutralidad tecnológica reconoce algo evidente: La tecnología cambia constantemente. Si la ley se “casa” con una tecnología en particular muy seguramente la norma se quedará obsoleta rápidamente”.

“... la neutralidad tecnológica es una contradicción andante, ya que la tecnología no es neutra. La tecnología afecta a la sociedad. Pero el uso del concepto como tal es un invento de Microsoft... es pues un concepto de marketing, pura propaganda....”.

”Principio de neutralidad tecnológica y de adaptabilidad al progreso de las técnicas y sistemas de comunicaciones electrónicas garantizando la independencia en la elección de las alternativas tecnológicas por los ciudadanos y por las Administraciones Públicas, así como la libertad de desarrollar e implantar los avances tecnológicos en un ámbito de libre mercado. A estos efectos las Administraciones Públicas utilizarán estándares abiertos así como, en su caso y de forma complementaria, estándares que sean de uso generalizado por los ciudadanos.”

Estándar abierto es el que cumple las siguientes características:

1) Está publicado y su especificación y documentación completas están disponibles de forma gratuita o al precio de coste de su distribución.

2) Su propiedad intelectual se ofrece de forma irrevocable libre de regalías, de cualquier otro derecho de explotación de la propiedad intelectual, y no sujeto a patentes o a contratos que restrinjan su uso y reutilización directa o indirectamente.

3) Existe al menos una implementación de referencia que desarrolla todas las funcionalidades de la especificación, que está disponible bajo una licencia que permite que sea usada para cualquier propósito, y que puede ser copiada, estudiada mejorada y distribuida libremente, con o sin cambios.

A través de mi buen amigo Juantomás, anterior Presidente de Hispalinux, me he enterado de la presentación del libro "La Sociedad de Control" de José Alcántara. El acto tendrá lugar el miércoles 29 de abril, a las 12:30 del mediodía, en el Centro de Innovación de BBVA (Plaza de Santa Bárbara nº 2, Madrid; Metro Alonso Martínez). Y he de decir, que comparto la idea de que este acto, dado los turbulentos tiempos que corren para la libertad en la Red y la libre difusión de la cultura, es mucho más que la presentación de un libro.

Al igual que le preocupa al autor del libro y al mismo Juantomás, a mi también me preocupan las presiones a REDTEL y el paquete de medidas para las telecomunicaciones, que se quiere aprobar el próximo día 5 de mayo en la Unión Europea. Por ello, yo también considero muy positivo que se aclaren estos hechos y se hagan oír el mayor número de voces en contra de estas medidas liberticidas, que pueden acabar con la libre difusión de la cultura y con la necesaria neutralidad de la Red.

Desde mi punto de vista, sin cultura no hay Red, es la cultura la verdadera esencia y utilidad de la misma y debemos tener claro que no es solamente cultura, aquella que tiene un precio. De hecho, si la cultura no se integra en la sociedad, no importa su precio, simplemente no es cultura.

Esta es una obra clave, necesaria y polémica quizás, en el que se exponen éstos y otros peligros que amenazan nuestros derechos y libertades en la red de redes. Da lo mismo la excusa, ya sea la seguridad, o los derechos intelectuales, todo sirve para restar derechos y libertades en la Red y lo peor, es que en la lucha por esa minoritaria cultura de pago, también puede caer la vasta cultura de dominio público, o la popular, que también es cultura y más arraigada que las otras.

El libro, como todos los de la colección "planta 29", está publicado bajo una licencia de dominio público y por ello, se puede descargar libremente de la Red. No deja de ser cusioso, que esta editorial, cuyas obras se publican todas con licencias libres, haya comenzado a tener beneficios tras solamente un año de andadura y en un momento de profunda crisis, en el cierran cientos de empresas y otras miles declaran pérdidas.

"Copyleft 2009 Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved"

b) Ahora, abriremos una consola como root y configuraremos el entorno de Java, si no lo tuviéramos ya configurado para dicho usuariot. Para ello, usaremos en la consola la siguiente secuencia de mandatos, o aquellos que correspondan en función a nuestra versión de Java y el directorio de instalación. Como es lógico, tras escribir cada una de las líneas, tendremos que pulsar la tecla Enter:

export PATH=/usr/java/jre1.6.0_12/bin:$PATH
JAVA_HOME="/usr/java/jre1.6.0_12/"
export JAVA_HOME

c) Hecho esto, ya podemos proceder a arrancar el instalador de Sinadura, para lo que nos situaremos en el directorio en el que lo hemos guardado antes y usaremos el mandato:

java -jar sinaduraDesktop-1.3.1-unix32-install.jar

Al poco tiempo, si tenemos Java correctamente configurado en nuestro sistema para el usuario root, se abrirá el entorno gráfico de instalación de Sinadura, que como hemos dicho, es muy similar al de PortableSigner. Veamos paso a paso este proceso:

a) Primero, cambiaremos los permisos del directorio resources, que ha de ser compartido por todos los usuarios en lectura y escritura. Desde una consola como usuario root, escribiremos el siguiente mandato seguido de la pulsación de la tecla Enter. Este paso no es necesario cuando instalamos el programa como un usuario distinto de root:

chmod -R /usr/local/sinadura/resources

b) Seguidamente, crearemos un directorio de trabajo en el área personal de cada usuario. Para ello, abriremos una consola como el usuario que desea usar el programa y usaremos el siguiente mandato seguido de Enter. Este paso no es necesario cuando lo instalamos como un usuario distinto de root:

mkdir /home/usuario/sinadura

c) Hecho esto, ya podemos arrancar el programa, para ello, usaremos la secuencia de mandatos Menú Inicio | Officina | Sinadura – Firma Digital (ver la nota final para la instalación del programa como usuarios distintos de root):

g) Para salir de la aplicación, haremos clic sobre el aspa que aparece en la parte superior derecha de la ventana, o seleccionaremos la secuencia de mandatos Archivo | Salir.

Con todo lo anterior, ya tenemos instalado y configurado Sinadura, quedando a falta de instalar los certificados de usuario, para poder empezar a firmar documentos PDF. En la siguiente y última entrega de esta serie dedicada a Sinadura, veremos la forma de utilizarlo.

Nota para instalaciones como usuario distinto de root:

Si se instala el programa como un usuario distinto de root, el programa de instalación no genera el acceso directo en el menú Inicio, al menos, en mi sistema Mandriva basado en KDE. Si en nuestro sistema pasa lo mismo y estamos usando el KDE, una vez que hemos entrado en el sistema como un usuario normal, haremos clic con el botón derecho del ratón sobre el escritorio y seleccionaremos la secuencia de mandatos Crear nuevo | Enlace a aplicación.

En la pestaña "General" haremos clic sobre el icono de la parte superior izquierda, seleccionaremos la marca de verificación Otros iconos y haremos clic sobre el botón Examinar. Debemos seleccionar el icono sinadura48.png, que encontraremos en el directorio /home/usuario/sinadura/resources/images y haremos clic sobre el botón Abrir. Seguidamente, escribiremos Sinadura en la línea de entrada de texto de esa misma pestaña.

Después, seleccionaremos la pestaña "Aplicación" y escribiremos Sinadura en las dos líneas de entrada de texto, Descripción y Comentario y escribiremos la cadena '/home/fernando/sinadura/sinadura/bin', incluidas las comillas simples, en la línea de entrada Orden. Para finalizar, haremos clic sobre el botón Aceptar. Ahora cuando hagamos doble clic sobre ese icono en el escritorio del KDE, arrancará el programa y nos aparecerá su interfaz de usuario que hemos visto antes.

"Copyleft 2009 Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved"

Tras este artículo dedicado a la piratería del software, veo con satisfacción esta noticia, que recomiendo leer. En ella se comenta que el CENATIC, participará en la campaña 100% software legal del Ministerio de Industria, Turismo y Comercio. El objetivo, es reafirmar que el Software Libre y de Fuentes Abiertas es totalmente legal y que también cuenta con una serie de licencias que han de ser respetadas.

Así que debéis recordad siempre que el Software Libre es 100% Legal, os lo podéis descargar de Internet, usarlo y copiarlo, por lo que no es lógico recurrir al software pirata, cuando puedes solucionar tus necesidades con Software Libre.

No te compliques la vida, usa Software Libre.

"Copyleft 2009 Fernando Acero Martí­n. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved".

Parece que Intenet está revuelta en toda Europa y España, como parte de Europa que es, tampoco es una excepción. Ayer se publicó en Kriptópolis un artículo, en la que se relacionaba el procedimiento para darse de un operador de telecomunicaciones, en caso de que se pactase en España, al más puro estilo francés, la limitación, o el control, de las tecnologías P2P. Como consecuencia, hay muchos que argumentan que con ello, se podrían producir bajas masivas de líneas ADSL, o como poco, cambios de operador. Es curioso, que durante mucho tiempo se ha usado el argumento de la velocidad de las descargas como incentivo para las ventas de líneas ADSL y ahora las operadoras pueden renegar de ello. Parece lógico por lo tanto, que si el usuario fue convencido para contratar una línea ADSL mediante el argumento de poder realizar descargas de cualquier tipo y a una mayor velocidad, de aprobarse una limitación a las descargas P2P, se sienta "engañado" y quiera darse de baja de un servicio que ya no cumple con sus expectativas. La revolución de la "blogocosa" está en marcha, y como argumento de "ventas" para la campaña de las bajas masivas, incluso se ha publicado un curioso vídeo, con las opiniones vertidas por los internautas en Twitter al respecto. Limitación del P2P, que todo hay que decirlo, cada día se ve más cercana y cierta.

Pero éste es un problema que se venía venir de lejos, no es de ahora, de hecho, en los últimos años se han producido una serie de hechos que han movilizado a la comunidad de Internet y a los agentes sociales en defensa de sus derechos. Desgraciadamente, no todos estos esfuerzos han tenido éxito.

El primero, fue el intento de aprobar en la LISI (Ley de Impulso de la Sociedad de la Información) el tristemente famoso artículo 17bis, que afortunadamente fue retirado, no sin la activa participación de la sociedad en el debate, por el Ministro Montilla. Pero como hemos dicho, la movilización social no siempre ha tenido, éxito, como por ejemplo, cuando se entregaron más de 2 millones de firmas contra el "Canon" digital y que como todos sabemos, no tuvieron el más mínimo efecto. Al final, como se temía, se implantó un injusto sistema de compensación por copia privada, que grava con un "tributo" el moderno papiro de la civilización actual, el soporte para la información digital. Desde discos duros, a memorias flash, pasando por teléfonos móviles y PDA's, casi todo lo que almacene un bit de información, además de los consabidos "cederrones" y "deuvedés", todo tiene que pagar el "tributo" con independencia del uso real que se haga de ello, algo a todas luces injusto.

También ha habido otros problemas, como la arbitraria limitación a los Ayuntamientos para poner accesos WIFI gratuitos, la acusada asimetría, los elevados precios y las reducidas velocidades de las líneas ADSL españolas, la retención de datos de Internet, la criminalización de la tecnología, la consideración del acceso a Internet de banda ancha como servicio universal, la retirada de la normativa regulatoria de la banda ancha, las líneas de más de 30 Mb/s, el tratamiento de las obras sujetas a derechos de autor en Internet, con cuestionadas campañas pagadas por todos los españoles y otras tantas otras cosas, que nos han afectado en los últimos meses y que de algún modo, han creado indignación, alarma o incluso, activas movilizaciones sociales.

Buscando información sobre todos estos asuntos en Internet, me encontrado en la Web de la Asociación de Internautas, una reciente, interesante y escandalosa carta abierta al Ministro de Industria Turismo y Comercio, el Sr Sebastián, de la que recomiendo encarecidamente su lectura y que se está propagando por Internet como una mancha de aceite. Dicha carta, además de denunciar la precaria situación de la Internet española, algo que no nos es ajeno y de los derechos de los Internautas en esta piel de toro, tema debatido hasta la saciedad, muestra sin fisuras ni ambages, el nombre de la persona que hay detrás de "la mano que mece la cuna", es decir, de la persona que en teoría, está detrás de casi todos estos hechos que me preocuparon y que me preocupan en relación con el desarrollo y consolidación de la Sociedad del Conocimiento en España. Lo que más me llama la atención, es que si estos hechos son ciertos y ocurrieron en contra de las declaraciones y promesas de los propios ministros del ramo, nunca tuvieran consecuencias políticas para el responsable, o responsables, de los mismos.

He de reconocer, que leyendo la carta se me han abierto los ojos y he llegado a comprender muchas cosas sobre las antes que no encontraba una adecuada relación causa-efecto. Tampoco he podido evitar, que durante su lectura me viniera a la cabeza el contenido de la excelente y reciente conferencia de D. Carlos Sánchez Almeida, titulada "Resistencia digital y derechos humanos", conferencia que ahora se me antoja como una inspiración. Supongo que a muchos de vosotros os pasará lo mismo.

"Copyleft 2009 Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved".

Ahora que ya hemos instalado, o actualizado, Java en nuestro sistema, estamos listos para instalar PortableSigner, que es la aplicación que nos permitirá firmar digitalmente un archivo PDF, usando para ello un certificado digital X.509 de 1024 bits, almacenado en en un contenedor PKCS#12. Por ejemplo, podemos usar para firmar nuestro PDF un certificado de software de los que emite la Fábrica Nacional de Moneda y Timbre, a través de Ceres.

Recordemos que el formato PDF es un formato abierto, multiplataforma, que es estándar ISO 19005 en su versión 1.4 e ISO 32000 en su versión 1.7. Por ello, es muy interesante que podamos firmar este tipo de documentos, que serán legibles y sus firmas verificables, casi con total independencia de la plataforma en la que se cree o se lea posteriormente y gracias a un plugin que hay disponible para OpenOffice. Incluso es posible editarlos cuando han sido generados desde un texto o se les ha aplicado el OCR de Acrobat, pero ésta es otra historia. Es decir, que un PDF que creemos y firmemos en Linux será legible y verificable desde Windows o viceversa, así como desde otros sistemas operativos como MAC OS X; en definitiva, un lujo. En otro artículo que estoy preparando, hablaré un poco sobre la forma de mejorar la interoperabilidad entre sistemas Windows y Linux, al tiempo que garantizamos el acceso a nuestros archivos en el futuro, usando para ello formatos abiertos.

Comenzaremos por descargar la última versión de PortableSigner, que es la 1.6.110, desde la página oficial del proyecto en Sourceforge. Como veremos, hay opciones para varias plataformas. Recomiendo seleccionar la descarga del archivo instalador Java, que es independiente de la plataforma, es decir, el archivo PortableSigner-Install-1.6.110.jar. Después de hacer clic sobre el archivo, lo almacenaremos en un directorio de nuestro sistema.

Seguidamente, abriremos una consola como root y configuraremos el entorno de Java, si no lo tuviéramos configurado para el usuario root. Para ello, usaremos la secuencia de mandatos:

export PATH=/usr/java/jre1.6.0_12/bin:$PATH
JAVA_HOME="/usr/java/jre1.6.0_12/"
export JAVA_HOME

Hecho esto, ya podemos proceder a arrancar el instalador de PortableSigner con el mandato:

java -jar PortableSigner-Install-1.6.110.jar

Al poco tiempo, si tenemos Java correctamente configurado en nuestro sistema para el usuario root, se abrirá el entorno gráfico de instalación de PortableSigner, proceso de instalación que vamos a ver paso a paso:

1. La primera ventana nos solicitará el idioma de instalación. En mi caso, recomiendo elegir inglés [ENG], seguido de un clic sobre el botón “Ok”, ya que del otro idioma que hay disponible para la instalación es el alemán, y siento decir, que de este idioma no tengo casi ni idea.

Para facilitar el acceso al programa, recomiendo crear un enlace directo en el escritorio, que en mi sistema está basado en el KDE. Una vez que hemos entrado en el sistema como un usuario normal, haremos clic con el botón derecho del ratón sobre el escritorio y seleccionaremos la secuencia de mandatos Crear nuevo | Enlace a aplicación.

En la pestaña “General” haremos clic sobre el icono de la parte superior izquierda, seleccionaremos la marca de verificación Otros iconos y haremos clic sobre el botón Examinar. Debemos seleccionar el icono PortableSignerLogo.png, que encontraremos en el directorio /usr/local/MagWien/PortableSigner/ y haremos clic sobre el botón Abrir. Seguidamente, escribiremos PortableSigner en la línea de entrada de texto de esa misma pestaña.

Después, seleccionaremos la pestaña “Aplicación” y escribiremos PortableSigner en las dos líneas de entrada de texto, Descripción y Comentario y escribiremos la cadena '/usr/local/MagWien/PortableSigner/PortableSigner', incluidas las comillas simples, en la línea de entrada Orden. Para finalizar, haremos clic sobre el botón Aceptar. Ahora cuando hagamos doble clic sobre ese icono en el escritorio del KDE, arrancará el programa y nos aparecerá su interfaz de usuario, que es la que se muestra en la imagen siguiente. También podemos esta aplicación abriendo una consola de usuario y tras ir al directorio /usr/local/MagWien/PortableSigner, usando el mandato:

./PortableSigner

En la siguiente y última entrega de esta serie dedicada a PortableSigner, veremos la forma de utilizarlo para firmar nuestros documentos en PDF.

"Copyleft 2009 Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved".