You are viewing fernando_acero

Directo desde el Vaticano...

IBSN, blog, id
hit counter




"No sabemos qué sistema operativo usa Dios, pero nosotros usamos Linux"
Hermana Judith Zoebelein
Webmaster del Vaticano
Seguir a @facemar en Twitter

Fernando Acero Martin

Crea tu insignia

Licencia Creative Commons

Blog Fernando Acero por Fernando Acero Martín se encuentra bajo una Licencia Creative Commons Reconocimiento-NoComercial-SinObraDerivada 3.0 Unported. El presente blog no tiene finalidad informativa, de creación de opinión pública, o de entretenimiento, tiene como finalidad principal, la enseñanza y la divulgación de experiencias, proyectos, pensamientos y conocimientos del autor.

Se permite la copia textual, la traducción y la distribución de los artículos del presente blog en cualquier medio, a condición de que este aviso sea conservado, no se modifiquen.

Se permite la cita.

El autor no cobrará por el ejercicio de los dos derechos anteriores, siempre que no se haga uso comercial de los mismos.

No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre.

Basada en una obra en fernando-acero.livejournal.com.
"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."
IBSN, blog, id

En febrero de este año decidí cambiar la licencia de mis artículos y de mi página web, tras leer el Anteproyecto de Ley de Propiedad Intelectual (LPI) que se nos venía encima. El texto que elegí era el siguiente:

"Copyleft Fernando Acero Martín. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre."

Pues bien, creo que es el momento de cambiar un poco mi licencia a la vista del texto del Proyecto de Reforma de la LPI aprobado en el Congreso. Y si nos ceñimos a la realidad, también hay que decir que dicha aprobación no se hizo sin una buena dosis de indignación y malestar por parte de amplios sectores de la sociedad española, especialmente, al ver en vivo y en directo, la forma tan criticable en la que se desarrolló la polémica votación de un tema tan importante para todos.

Es una pena de la nueva LPI no considere que el autor es el único que debe y puede decidir sobre su obra y en especial, sobre la mejor forma de comercializarla y divulgarla, creando derechos "irrenunciables", que pueden ir claramente en contra de lo que desea para su obra y que por cierto, son una enorme traba a la cultura libre.

Y dicho así, no parece que en la LPI se considere la creación intelectual como un derecho humano, que es como debería ser considerada y con ello, respetar al autor y sus deseos para su obra por encima de cualquier otra consideración. Ya es triste, que me tenga que quebrar la cabeza para intentar proteger mi obra de una Ley que presuntamente está elaborada para defender mis derechos como autor. Señores yo quiero que mi obra se divulgue y se cite libremente y sin coste alguno para los que lo hacen.

De todos modos, eso solamente es un sentimiento personal, pero si me paro a analizar las consecuencias que puede tener este texto, solamente puedo decir que se me ponen los pelos de punta. Es una Ley diseñada para ir en contra de la corriente y en especial, en contra de los nuevos modelos de negocio que están apareciendo en la Red, que favorece más a las industrias que a los autores. No voy a insistir sobre ello puesto que otros muchos más doctos que yo han hecho este análisis antes y seguro que con mucho más tino que el que suscribe.

Cuando cambié mi licencia en febrero pasado, fue una modesta medida que para mi sorpresa tuvo una gran aceptación entre la audiencia y algunos autores que suelen poner sus obras a disposición del público con licencias libres, hicieron lo mismo que yo y modificaron sus licencias adecuadamente. Pues para todos ellos, aquí va una nueva propuesta, que espero que sea de su agrado. Ahora con Reforma de la LPI pasando sin problemas por el Congreso camino del Senado, le he dado una segunda lectura más detallada y me he parado a pensar en el Artículo 32.2, que dice lo siguiente:

“La puesta a disposición del público por parte de prestadores de servicios electrónicos de agregación de contenidos de fragmentos no significativos de contenidos, divulgados en publicaciones periódicas o en sitios Web de actualización periódica y que tengan una finalidad informativa, de creación de opinión pública o de entretenimiento, no requerirá autorización, sin perjuicio del derecho del editor o, en su caso, de otros titulares de derechos a percibir una compensación equitativa. Este derecho será irrenunciable y se hará efectivo a través de las entidades de gestión de los derechos de propiedad intelectual”.

Es evidente por lo tanto, que si queremos que nos enlacen y nos citen libremente y que nadie cobre por un trabajo que es nuestro, que ponemos a disposición de todos con licencias libres, es conveniente dejar bien claro que nuestro artículo, publicación, blog o página web, no tiene finalidad informativa, de creación de opinión pública, o de entretenimiento y pensando en ello, mi licencia queda como sigue:

"Copyleft Fernando Acero Martín. El presente artículo no tiene finalidad informativa, de creación de opinión pública o de entretenimiento. Tiene como finalidad principal, la enseñanza y la divulgación de experiencias, proyectos, pensamientos y conocimientos del autor. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre por el ejercicio de los dos derechos anteriores."

Asimismo, también recomiendo eliminar los blogs, o de nuestras páginas web, cualquier referencia, apartado o sección que introduzca la palabra "opinión", "entretenimiento", "noticias" o "información", especialmente, si la finalidad de nuestro blog o de nuestra página web, no es principalmente el informar, crear opinión pública o entretener, evitando así, cualquier confusión o ambigüedad a la hora de considerar por parte de terceros el el carácter del contenido de nuestro blog o página web.



"Copyleft Fernando Acero Martín. El presente artículo no tiene finalidad informativa, de creación de opinión pública o de entretenimiento. Tiene como finalidad principal, la enseñanza y la divulgación de experiencias, proyectos, pensamientos y conocimientos del autor. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre por el ejercicio de los dos derechos anteriores."

"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."
IBSN, blog, id


Después de que mi ordenador portátil, un "Packard Bell modelo EASYNOTE BG46-T-001 Limited Edition" sufriera de molestos cuelgues aleatorios, descubrí que tenía problemas con su módulo de memoria RAM de 4 Gb. Tras sustituirlo, decidí que también era momento de cambiar de sistema operativo, que era una más que obsoleta Mandriva. La decisión inicial fue la de probar con una Kubuntu 14.04 Long Time Suport.

La elección de Kubuntu en lugar de Ubuntu ha venido por el simple hecho de que siempre he usado KDE con mis sistemas Linux, a excepción de con mi querido Linex, que siempre lo he tenido con Gnome. Evidentemente, la elección de una distribución LTS, es decir, con soporte extendido de cinco años, ha sido por comodidad. El portátil lo uso cuando no tengo otra opción, por ejemplo, cuando tengo que hacer algo fuera de casa y salvo casos muy especiales, como cursos y otros eventos en los que hay desarrollo y programación por medio, el 80% de las veces lo uso para leer el correo, navegar por Internet y escribir texto más cómodamente. El tener la oportunidad de no tener que reinstalar el sistema operativo cada dos años más o menos, pero sin renunciar a que el sistema esté adecuadamente actualizado, me parecía una opción interesante y me proporcionaba cierta tranquilidad, por lo que una distribución LTS era la opción ideal.

Ante un cambio de sistema operativo siempre se considera que será un cambio a mejor, pero también hay cierta incertidumbre sobre el funcionamiento de determinado hardware, sobre todo, cuando está especialmente diseñado para funcionar con Windows y ante la posibilidad de perder opciones o funcionalidades que antes estaban disponibles. La instalación de una nueva distribución en un equipo siembre es una aventura. Por ejemplo, el EASYNOTE tiene un curioso problema con la WebCam Webcam Chicony Sonix 213, cuando se usa con algunas distribuciones Linux y que que tiene la mala costumbre de mostrar las imágenes del revés, problema que logré solucionar en su momento, por lo que cabe la posibilidad que este sea un trabajo que habría que repetir.

La instalación básica de Kubuntu 14.04 es muy sencilla. Solamente hay que seleccionar el idioma, la zona horaria, el particionado del disco y los datos de usuario. Tras introducir estos datos, el sistema se instala en unos 20 minutos y si se ha seleccionado la opción correspondiente durante la instalación, se conectará a Internet y se actualizará antes de acabar, más sencillo imposible,

He de decir que Kubuntu 14.04 me ha gustado mucho y también es cierto, que con esta distribución he ganado algunas cosas interesantes. Por ejemplo, ahora dispongo de cifrado de la partición /home, lo que aparece como opción durante la instalación cuando se introduce el nombre y la contraseña del usuario, o que permite que mis datos estén razonablemente a salvo de miradas indiscretas y de la manipulación en caso de robo, pérdida, o acceso no autorizado al portátil. Anteriormente esto lo tenía que hacer mediante Truecrypt, que aunque es un programa que funciona muy bien, no es tan sencillo de usar como arrancar el sistema introducir la contraseña y olvidarse. Por cierto, por si hay problemas en el futuro con esta partición cifrada, es conveniente copiar y poner a buen recaudo la clave de cifrado que muestra el programa la primera vez que se arranca. En caso necesario, se puede usar el mandato ecryptfs-unwrap-passphrase, seguido de nuestra contraseña de usuario. Otra cosa que he ganado es el soporte USB para teléfonos móviles Android, pudiendo acceder sin problemas tanto a la memoria del teléfono como de su tarjeta de memoria MicroSD.

Durante la instalación realicé el particionado a mano y algo tuvo que pasar con la partición de swap, que aunque estaba presente como /dev/sda6, no estaba activada en el sistema. Activarla no ha sido un problema demasiado grave. Primero he usado el mandato sudo swapon -s, para ver si estaba activada, comprobando que no era así y solamente he tenido que hacer lo siguiente:

Mediante el mandato sudo fstab -l /dev/sda he obtenido el listado de todas las particiones del disco, la que nos interesa es la que tiene aparece como sistema Linux swap / Solaris, que en mi caso, como he dicho, es la /dev/sda6. Después he obtenido el UUID de la partición mediante el mandato sudo mkswap /dev/sda6, que era UUID=cf71ef3e-4532-4593-843b-jpklw4a13bff. Una vez obtenido este dato, solamente he tenido que modificar el fichero /etc/fstab/ como root mediante un editor de textos como gedit o vim, para que muestre lo siguiente:


# swap was on /dev/sda6 during installation
UUID=cf71ef3e-4532-4593-843b-jpklw4a13bff none            swap    sw              0

Con ello, ya tendremos la swap activada la próxima vez que arranquemos nuestra Ubuntu 14.04, pero si no queremos arrancar el sistema otra vez en ese momento, solamente tenemos que usar el mandato sudo swapon /dev/sda6 para activarla, seguido de sudo swapon -s /dev/sda6, para comprobar que está activada. Otra forma de obtener la UUID para el disco es usando el Editor de Particiones de Ubuntu. Tras seleccionar la partición swap, debemos pulsar el botón derecho del ratón y seleccionar la opción Propiedades en el menú que aparece, nos aparecerá una ventana con los datos de dicha partición y entre ellos encontraremos el UUID.

Sin embargo, este procedimiento desactiva la swap cifrada que se debería activar con el cifrado de la partición de usuario, pudiendo exponer información del usuario si se necesitase usar el espacio de la swap. La solución es seguir estos dos procedimientos de forma consecutiva:

a) No se monta la partición swap

b) Disk drive for dev/mapper/cryptswap 1 is not ready

Con el cambio de distribución también he ganado y mucho, con el soporte para la tarjeta WiFi de Qualcom Atheros AW-GE780 802.11bg Wireless Mini PCIe Card. El controlador que usaba con la Mandriva anterior era muy inestable y tenía tendencia a desconexiones, pérdidas de las DNS y molestos bloqueos ocasionales del sistema. Ahora, la conexión WiFi va como la seda y funciona sin problemas incluso tras muchas horas de conexión.

Una de las cosas que más me ha molestado tras la instalación, es que el Touchpad Synaptic PS/2 Pad, tiene problemas con el doble clic si se hace pulsando dos veces sobre el Touchpad. A pesar de haber tocado y retocado la configuración para controlar el comportamiento de este dispositivo, llegando incluso a bloquearse con algunas configuraciones, al final parece que es un poco "sordo" a la hora de reconocer un doble clic y sin importar los ajustes que se realicen en la configuración. La solución más rápida es relativamente sencilla, basta con usar el botón izquierdo del Touchpad, o alternativamente, pulsar la tecla Intro, una vez que se ha seleccionado lo que se desea.

Antes de la instalación tenía muchas incertidumbres con el uso de DNIe, pero he logrado hacer que funcione con esta distribución y sin demasiados problemas. Lo he usado para firmar correos, autenticarme con la página web de la AEAT y del 066 y para firmar documentos en formato Open Document Format con Libre Office. Para su configuración, he seguido paso a paso el tutorial de instalación del DNIe para Ubuntu 12.04, pero cuando tocaba compilar el módulo PKCS11 para el DNIe, lo que he hecho, es usar el paquete que hay disponible en la página oficial del DNI electrónico para la distribución Ubuntu 12.04.

A pesar de lo anterior, cuando he intentado usar la última versión de Sinadura con el DNIe, no he logrado que funcione por el momento. He modificado a mano el archivo /usr/local/sinadura/resources/preferences/preferences-sinadura-console.properties
para que apunte al módulo /usr/lib/libpkcs11-dnie.so, con el siguiente código:


Tarjeta criptografica=1; Certificado Software=0
preferencias.radioCertType.active=0
 
# dispositivo de firma hardware
# hardware.dispositive=/usr/lib/opensc/opensc-pkcs11.so
  hardware.dispositive=/usr/lib/libpkcs11-dnie.so

Pero cada vez que intento firmar algo, Sinadura siempre me responde: "No dispone de ningún driver instalado para el uso de tarjetas inteligentes.", por lo que lo tendré que ver este asunto más despacio. Creo que el problema puede estar que Sinadura espera encontrar los archivos en otro sitio, de hecho, tras compilar el móduloPKCS11 con Mandriva 2010.1, aparecía con el nombre opensc-pkcs11.so y estaba en el directorio opensc, pero cualquier cosa es posible.

Además de este problema con el DNIe, también he notado que esta versión de Sinadura es algo inestable, con Kubuntu 14.04 LTS, pero este problema es posible que se deba a que se me ha pasado algo por alto durante la configuración de Java. Hay que señalar, que con el paquete Openjdk 7u51, que es la versión por defecto que usa Kubuntu 14.04 LTS, ya tenía los mismos problemas, por lo que es posible que tenga que revisar la instalación de Java para estar seguro de que no se usan librerías que no se corresponden con la versión adecuada de Java. Hay un tutorial muy bueno sobre la configuración de Java en Ubuntu 14.04, que recomiendo leer detenidamente.

En relación con los lectores de tarjetas inteligentes, en este momento dispongo de dos. Uno es el C3PO LTC31 en su primera versión (carcasa de color azul), que es reconocido directamente por Kubuntu 14.04 LTS una vez que han sido instalados todos los paquetes necesarios. El segundo, es el lector Castles Technology Co., Ltd EZUSB PC/SC Smart Card Reader, que no he logrado hacer que funcione con la distribución Kubuntu 14.04.

También es cierto, que por falta de tiempo, me he limitado a instalar los controladores para Linux que proporciona el fabricante para este dispositivo (en la caja dice que es completamente compatible con Linux), por lo que será necesario ver este tema más despacio. Lo más probable es que sea un problema relacionado con los directorios en los que se instalan los archivos del controlador, o con la versiones de los paquetes que se están utilizando ya que dicho lector que me funciona sin problemas en otras distribuciones Linux, como la Mandriva 2010.1.

Realmente el hacer que funcione el lector de Castles es por simple curiosidad, ya que el lector de de la empresa C3PO es mucho más cómodo para usarlo con el portátil por ser más pequeño que el de Castles. Sin embargo, este dispositivo tiene un pequeño problema que debemos tener en cuenta cuando lo usemos y que a mí me costó tener que cambiar de DNIe. Antes de usarlo debemos saber que la luz verde de funcionamiento del dispositivo de C3PO no parpadea cuando el DNIe está siendo accedido por una aplicación y se enciende una luz roja, cuando está inactivo y es completamente seguro retirar el DNIe del lector.

Mi recomendación es no sacar el DNIe del lector mientras que no se encienda el led rojo del mismo del lector de C3PO. Para ello, hay que salir de la aplicación que está haciendo uso del DNIe y esperar unos segundos hasta que se encienda el led rojo. También debemos tener en cuenta, que el DNIe solamente puede atender a una aplicación a la vez, por lo que si abrimos al mismo tiempo varias aplicaciones que puedan hacer hacen uso de él, como el correo electrónico y el navegador, cuando cerremos una de ellas, la otra impedirá que se ponga en rojo el led que nos permitirá extraerlo sin problemas.

Sin embargo, tras instalar el DNIe comprobé que no podría firmar correos con openpgp con Thunderbird. Al parecer, gpg-agent no entregaba la contraseña correcta a openpgp para firmar el mensaje. En este punto no puedo decir si el problema estaba provocado por intentar reutilizar el archivo de configuración /home/usuario/.gnupg que tenía en la Mandriva enterior y que usaba algunas opciones incompatibles con la nueva versión de gpg, por una contraseña incorrecta o por un paquete pinentry inadecuado y que había instalado para trabajar con el DNIe.

Tras editar el archivo de configuración de gpg-agent, para que usase el módulo pinentry que tenía instalado en /usr/bin, comprobé que seguía sin funcionar, así para salir del paso y con la certeza de que el problema venía de la forma en la que gpg-agent pasaba la contraseña a gnupg, edité manualmente el archivo /home/usuario/.gnupg/gpg.conf y comenté con un símbolo "#" la línea "use-agent" del mismo. Con ello, ya pude enviar sin problemas correos firmados con con gnupg y con el DNIe.

Otra cosa que he comprobado, es que Kubuntu 14.04 LTS gestiona mucho mejor los recursos del sistema, con lo que se calienta menos y dura más la batería,que con la versión anterior de Mandriva. Este equipo dispone de dos botones táctiles que sirven para activar y desactivar la Wifi y el modo de funcionamiento de bajo consumo, lo que es muy útil cuando se está con baterías y se quiere alargar su funcionamiento. Dichos botones funcionan bien con esta versión, aunque en el caso de la luz del botón que controla la WiFi, se queda encendida o pagada, con independencia de la situación real de la tarjeta, por lo que es necesario recurrir al indicador de la conexión WiFi de la Barra de Tareas para comprobar su estado.

Otra cosa que he probado que funciona sin problemas, es la conexión Bluetooth que usa un adaptador RFCOM de Toshiba. Una vez vinculado el dispositivo que se desee, se pueden intercambiar archivos entre el ordenador y el teléfono, o se puede compartir una conexión de red sin cable con el teléfono, lo que he probado con un teléfono Samsung Galaxy S4. He de decir también que la integración del Bluetooth con el KDE es tan impecable como cómoda en esta distribución.

Después de revisar todo, desde el punto de vista del hardware, lo único que me queda por configurar es la WebCam, pero eso es algo que no me corre mucha prisa, ya que por comodidad suelo usar el móvil con el kit de manos libres para las videoconferencias y hangouts.

Sin embargo, puede que en este caso tenga más problemas que con Mandriva para hacer que funcione esta WebCam con Kubuntu 14.04. De primeras, aunque la reconoce perfectamente y carga el módulo uvcvideo sin problemas, cuando uso el mandato lsusb -d 04f2:b012 -v | grep "14 Video", el sistema me dice que no puede abrir el dispositivo:


Couldn't open device, some information will be missing
      bFunctionClass         14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video

No me cabe la menor duda de que la resolución de los problemas con la WebCam, del doble clic con el Touchpad, la configuración del lector de tarjetas de Castles y la activación de Sinadura para su uso con el DNIe, entrarán dentro de mis planes a corto plazo, pero cada cosa a su tiempo y sin muchos agobios. Pero también es cierto, que mientras que la WebCam no funcione, me ahorro el tener que taparla con cinta aislant. Asimismo, el tema del lector de Castles no corre mucha prisa ya que tengo otro que funciona perfectamente. Lo del tema de Sinadura, me corre más prisa, pero aunque por el momento no puedo firmar un documento PDF con Sinadura y la firma reconocida del DNIe, no tengo problemas para firmarlos con firma digital avanzada de la FNMT. A pesar del problema anterior con el uso del DNIe y Sinadura, en lo que se refiere al uso de la firma digital, creo que he ganado mucho con esta distribución, ya que por falta de un adecuado soporte por parte de la Administración, el DNIe nunca me funcionó con la Mandriva anterior y siempre tuve que recurrir a la firma avanzada de la FNMT cuando usaba el portátil.

ACTUALIZACIÓN 01MAY14

1) He solucionado el problema del lector EZ100 de Castles bajando la última versión de los controladores de la web del fabricante. Es un lector bastante bueno y que con los controladores nuevos, debería funcionar sin problemas con Linux. La URL de descarga es la siguiente:

http://www.casauto.com.tw/db/pictures/modules/PDT/PDT060207001/201181015...

2) También he solucionado el problema con la Web Cam, que por cierto en Ubuntu se visualiza la imagen correctamente y sin tener que parchear el controlador, la solución también ha sido muy sencilla. Desde Ekiga he seleccionado la secuencia de mandatos Editar | Preferencias | Vídeo | Dispositivos y en el cuadro de diálogo que aparece, he pulsado el botón Detectar dispositivos. En el cuadro de diálogo me aparece lo siguiente:

Dispositivo de entrada USB 2.0 1.3M UVC Web Cam (PTLIB/V4L2)
Tamaño 704x576
Formato PAL (Europa)
Canal 0

Curiosamente, a pesar de que funciona, si uso el mandato lsusb -d 04f2:b012 -v | grep "14 Video", el sistema me sigue diciendo que no puede abrir el dispositivo, por lo que parece que es el funcionamiento normal del mismo:


Couldn't open device, some information will be missing
      bFunctionClass         14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video
      bInterfaceClass        14 Video

3) Lo del doble clic del Touchpad he comprobado que también me pasa con otras distribuciones virtualizadas mediante VirtualBox, por lo que no es un problema exclusivo de Ubuntu y como también me pasa con otros portátiles, por ejemplo, con un Toshiba en el trabajo, que usa otro touchpad, puede que sea un problema del KDE.

Dicho lo anterior, se puede decir que todo el hardware presente en el Packard Bell modelo EASYNOTE BG46-T-001 Limited Edition, funciona al 100% con Ubuntu 14.04, lo que desde mi punto de vista me ha facilitado mucho las cosas.

Lo que se está haciendo más de rogar es un problema de software, es decir,l tema de Sinadura. Desde el proyecto me han proporcionado una nueva versión del archivo sinaduraDesktop-3.3.3.jar para que Sinadura se adapte a la ubicación y el nombre del controlador del DNIe del paquete oficial para Ubuntu 12.04, pero no he logrado por el momento, ni con la inestimable y magnífica ayuda de los responsables del proyecto, que funcione adecuadamente todavía. También parece que hay algunos problemas con unas librerías que provocan una salida imprevista del programa en ciertas circunstancias:

/tmp/swtlib-32/libswt-atk-gtk-3655.so
/tmp/swtlib-32/libswt-pi.gtk-3655.so
/tmp/swtlib-32/libswt-gtk-3655.so

He configurado el sistema para que funcione con la última versión de Java 7 en lugar que con java-7-openjdk-i386, que es lo que instala Kubuntu por defecto. Partiendo de la base que Sinadura y el DNIe funcionan adecuadamente con Mandriva 2010.1 y una versión muy antigua de java-openjdk, es decir, sin necesidad de instalar Java 7, el problema no puede ser demasiado complicado, solamente que no hemos dado con la tecla adecuada.

El resultado tras cambiar el archivo sinaduraDesktop-3.3.3.jar, es que ahora Sinadura accede sin problemas al controlador del DNIe e intenta leer los certificados, pero luego no muestra pinetry para introducir el pin del mismo y devuelve (lo de la hora a la que estaba trabajando en el tema, es solamente es medida del vicio que tengo con estas cosas):

00:51:44 Se ha producido un error en la carga del certificado, es posible que el dispositivo no este configurado correctamente.

Afortunadamente tengo un fin de semana largo para investigar y probar.

ACTUALIZACIÓN 03MAY14

En relación con la instalación del DNIe, he encontrado este procedimiento en la Red, explicando paso a paso como instalar y compilar una versión de OpenscDNIe para nuestra distribución Ubuntu 14.04 LTS, pero desgraciadamente a mi no me ha funcionado:

Instalar DNIe electrónico en Ubuntu 14.04

El problema es que yo dispongo de un DNIe V2, que es de los últimos modelos que están entregando y esta versión de OpenSCDNIe no es compatible con él. El problema es que una vez que se introduce el PIN de acceso, el controlador no es capaz de entregar los certificados a la aplicación.

La solución si tenemos un DNIe V2, es usar los paquetes compilados para Ubuntu 12.04 que hay disponibles en la página web DNIelectrónico.es, o en la página web de la FNMT.

Asimismo, ya he logrado solucionar el problema con pgp-agent y pinentry, simplemente lo he vuelto a activar en el archivo /home/usuario/.gnupg/gpg.conf y he creado un archivo /home/usuario/.gnupg/gpg-agent.conf con el siguiente contenido:


pinentry-program /usr/bin/pinentry-qt4
no-grab
default-cache-ttl 300




"Copyleft Fernando Acero Martín. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre."

"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."
IBSN, blog, id





Parece que la comunidad de software libre en particular, y los usuarios de Internet en general, no ganan para sustos y preocupaciones en los últimos días. A fecha de hoy han aparecido problemas en la práctica totalidad de las tecnologías que se usan para hacer que las conexiones sean seguras en Internet y en especial, GnuTLS y OpenSSL. Pero también debemos recordar que hace unos años también hubo serios problemas de seguridad con SSH.

Como ya se ha escrito y hablado mucho sobre el fallo de OpenSSL y llego un poco tarde con mi artículo, solamente resumiré e intentaré aclarar algunas cosas y en la medida de lo posible, aprovecharé para actualizar algo la situación y recomendar algunas acciones prácticas.

Un poco de lo que sabemos

En relación al fallo de OpenSSL sabemos, entre otras cosas, lo siguiente:

a) Es un fallo que lleva algo más de dos años en el código de OpenSSL y convierte inseguras desde la versión 1.0.1 a la 1.0.1f, siendo la versión 1.0.1g, la que resuelve el problema en este momento. Por ser un programa ampliamente utilizado para asegurar las conexiones en Internet, ha afectado a una gran cantidad de servidores y conexiones seguras de todo tipo. Entre los servidores que han podido estar afectados, se han incluido en algunas listas los de Google, Yahoo, Facebook o Twitter, etc. Pero dada la marcada polémica suscitada con la publicación de las listas de servidores afectados y pensando en lo que nos puede pasar en el peor de los casos, lo más razonable es pensar que cualquier servidor ha sido afectado, incluido el de nuestro banco y tomar a la mayor brevedad las medidas que recomendaré más adelante.

b) Este fallo permite obtener todo el contenido de la memoria de un servidor en bloques de 64 kB y ello incluye, entre otras cosas jugosas, las claves privadas usadas para identificar el servidor y asegurar las conexiones SSL. Una vez obtenidas, es posible suplantar dicho servidor y actuar como MitM. Pero como he adelantado en la primera frase de este párrafo, también se puede extraer cualquier otra información que esté siendo procesada en el servidor en ese momento. Eso incluye los datos personales de los usuarios, o sus claves de acceso al servidor. Asimismo, es importante saber, que si un servidor afectado ha sido atacado explotando este fallo en SSL, puede que no quede ningún rastro en el mismo que demuestre que ello ha sido así.

Si tenemos en cuenta lo que hemos dicho en el punto anterior y lo que hemos dicho en este, es posible que algunos responsables de servidores que fueron afectados por el fallo, no lo reconozcan abiertamente por problemas de reputación, o simplemente, aunque estuvieron afectados y es un hecho evidente para ellos por la versión de OpenSSL que utilizaban, desconocen si han sido atacados, o las consecuencias del ataque, por lo que no alertan a sus usuarios. Por lo tanto, mi recomendación en este caso, es ponerse siempre en el peor caso posible y actuar en consecuencia.

c) Aunque el fallo afecta principalmente a servidores y conexiones VPN (Redes Privadas Virtuales), lo que incluye infinidad de servicios en la nube, también puede afectar a otros dispositivos de nuestro entorno que pueden usar OpenSSL para asegurar ciertas conexiones. Por ejemplo: smartphones, puntos de acceso WIFI, tablets, routers ADSL, switches configurables, Smart TV's, receptores de satélite, reproductores multimedia o dispositivos de almacenamiento masivo (NAS) con conexión a Internet, etc.

Recordemos que Android se basa en el kernel de Linux y que tanto Android como Linux, están disponibles en varios miles de millones de dispositivos en este momento. Sin embargo, en muchas ocasiones, como meros usuarios de la tecnología, no somos conscientes del software que usa realmente nuestro flamante dispositivo.

Aprovecho para traer a estas líneas, algo que ya se está comentando con cierta preocupación en algunos foros. La llegada del Internet de las cosas provocará que este problema se multiplique de forma exponencial y más, si los fabricantes de hardware no se conciencian de que la seguridad de sus dispositivos debe estar en el ciclo de vida de los mismos como una de sus prioridades fundamentales. El problema para los fabricantes que opten por fabricar equipos que exploten las enormes posibilidades del Internet de las cosas, es que el ciclo de vida para muchos de estos dispositivos de uso común puede ser extremadamente largo en relación a los ciclos de vida del software.

d) Aunque Robin Seggelmann, el desarrollador que introdujo el error en 2012, ha declarado y en varias ocasiones, que no lo hizo de forma deliberada y que la NSA no estaba detrás del fallo, posteriormente, la agencia de noticias Bloomberg ha anunciado que la NSA conocía el fallo desde sus orígenes y que lo estaba explotando activamente. Como no podía ser de otro modo, la NSA ha negado posteriormente que esa noticia fuera cierta, por lo que cada uno puede pensar lo que quiera al respecto.

e) Aunque todos los expertos en seguridad coinciden al decir que el error es muy grave y que Bruce Schneier incluso ha llegado a decir textualmente lo siguiente:"Catastrophic is the right word. On the scale of 1 to 10, this is an 11", lo cierto es que el NIST ha clasificado esta vulnerabilidad como de riesgo medio CVSS v2 Base Score: 5.0 (MEDIUM) (AV:N/AC:L/AU:N/C:P/I:N/A:N), lo que puede llevar a cierta polémica.

f) Después de descubrirse el fallo, aparecieron una serie de noticias relacionadas con la explotación del mismo, como la relacionada con el joven canadiense arrestado por usar dicha vulnerabilidad de forma efectiva con los servidores de Canada Revenue Agency (CRA) o la relacionada con la explotación con éxito de la vulnerabilidad contra los servidores de Yahoo mail. Pero ¿cómo se han podido detectar este tipo de ataques, cuando decimos que no deja rastro en un servidor?. Evidentemente al mismo tiempo que han aparecido los programas que explotan el problema, también han aparecido las contramedidas especializadas para detectarlo y minimizarlo. Por lo que si alguien usa algún exploit relacionado con HeartBleed contra un servidor, debe saber que puede ser cazado en el intento y que igualmente, puede tener que responder por ello.

También se ha comentado, en base a un ataque realizado con éxito poco después de desvelarse la vulnerabilidad, que para explotarla con éxito era necesario que los servidores hubieran sido arrancados inmediatamente antes del ataque, lo que es improbable que ocurra en un sistema en producción. Pero desde mi punto de vista, lo único que se logra si ataca un servidor cuando acaba de ser arrancado, es facilitar la localización en la memoria de la información relevante para el atacante, por ejemplo, la posición en memoria de los certificados digitales del servidor. Si algo está en la memoria del servidor, dadas las características del fallo y con independencia del momento en el que se realice el ataque, siempre estará disponible para un eventual atacante que tenga paciencia para localizarla.

Más recientemente se ha usado dicha vulnerabilidad para saltarse la seguridad de Redes Privadas Virtuales, lo que abre una nueva y preocupante dimensión al problema de Heartbleed.

También se ha comentado algo que es muy preocupante para muchos usuarios de la Red Tor, la existencia de nodos de dicha Red, teóricamente segura, que eran vulnerables a Heartbleed. Dicho descubrimiento ha provocado que los responsables de la Red Tor, comiencen a rechazarlos mediante la creación de una "black list" de los mismos. Sin embargo, ¿cómo se puede tener la seguridad en una red abierta, como es el caso de Tor, de que los nodos que estamos usando en determinado momento no están afectados?. ¿Quién garantiza que en un momento determinado no se introduzca de forma maliciosa un nodo vulnerable en la Red Tor con el objeto de monitorizar el tráfico e la Red Tor?. Ante esta situación, hay algunos que aconsejan alejarse de la Red Tor, o incluso de Internet, durante un tiempo, si es que se necesita de privacidad.

g) El que no se haya actualizado al día de la fecha está en grave riesgo y va con tiempo negativo. En este momento no paran de salir a la luz pruebas de concepto (PoC) y exploits relacionados con esta grave vulnerabilidad del OpenSSL. Esto hace que el riesgo crezca de forma exponencial con el tiempo para los más retrasados. Como están las cosas, un eventual atacante, incluso con pocos conocimientos sobre el tema, dispone de todo lo necesario para tener éxito en un ataque:


  1. Sabe que existe una vulnerabilidad.

  2. Dispone de herramientas para saber si una determinada página es vulnerable.

  3. Dispone de software para atacar de forma efectiva un servidor vulnerable.

Qué podemos hacer

Las acciones a tomar para protegernos dependerán de si tenemos un servidor, somos clientes de un servidor seguro (https), o si tenemos hardware afectado, por lo que revisaremos cada caso de forma individual.

a) Si tenemos un servidor seguro, las acciones son cuatro y han de ser inmediatas:


  1. Revocar nuestros certificados digitales del servidor.

  2. Instalar la nueva versión de OpenSSL, la 1.0.1g o superior.

  3. Solicitar e instalar nuevos certificados digitales.

  4. Solicitar a todos los usuarios del servidor que cambien sus contraseñas lo antes posible.

b) Si somos usuarios o clientes de servidores seguros, lo que me atrevo a decir que somos todos los que usamos Internet, la acción es única y también ha de ser inmediata. No es otra que cambiar todas las contraseñas que usamos normalmente para conectarnos a servidores seguros a través de Internet. Por ejemplo: redes sociales, correo electrónico, servicios bancarios, administración electrónica, etc.

Los usuarios también deben tener en cuenta dos cosas en relación a la actualización de sus contraseñas:


  1. Si quieren saber si un determinado servicio está afectado en la actualidad, pueden usar esta página de McAfee para comprobarlo. Evidentemente si el servidor todavía está afectado, no tiene mucho sentido cambiar nuestra contraseña, por lo que en este caso lo que debemos hacer es enviar un correo a su administrador indicándole que su página es vulnerable y no conectarnos a dicha página, ni cambiar nuestra contraseña, hasta que no lo solucionen adecuadamente. Si usamos nuestras contraseñas, o intentamos actualizar nuestras contraseñas en este momento sobre un servidor que todavía no ha sido actualizado, lo más probable es que sean robadas sin remedio.

  2. Si recibimos un correo electrónico indicando que debemos cambiar nuestras contraseña en determinado servicio (red social, banco, etc) y dicho correo viene con un enlace, debemos desconfiar y no usar dicho enlace para cambiar nuestras contraseñas. Lo más probable es que sea un ataque de phishing que usa una URL falsa y su intención es robarnos limpiamente la contraseña que introduzcamos. Si queremos conectarnos a una página segura o cambiar nuestras contraseñas de acceso a las mismas, lo que debemos hacer siempre es acceder directamente a la página escribiendo la URL (https) en el navegador. No debemos usar nunca un enlace recibido mediante un correo electrónico, aunque nos parezca legítimo y la página a la que accedemos a través de él nos parezca la correcta primera vista.

  3. También es muy sano, tras conectarnos a una web segura (https), que antes de introducir nuestras credenciales, es decir, nuestro nombre de usuario y contraseña, que comprobemos el certificado digital de dicha página, para ver que se corresponde con la página que esperamos y que es válido.

c) Si tenemos hardware que pueda estar afectado, el problema se complica y mucho por dos motivos principalmente. El primero, es que es difícil saber, sin la ayuda del fabricante del mismo, si nuestro hardware es vulnerable ante un determinado problema de seguridad, como es el caso del OpenSSL. El segundo, es que siempre dependemos para su actualización de nuestro smartphone, tablet, router, etc, y en la mayoría de los casos de forma secuencial en el tiempo, del fabricante del software origen del problema, en este caso OpenSSL, del fabricante del software que lo integra, por ejemplo Google, del fabricante del hardware que lo usa, por ejemplo Samsung, o incluso, del proveedor de servicios de Internet que lo comercializa (por ejemplo, una compañía telefónica, que en ocasiones personalizan el software). Esta absurda cadena alarga los tiempos de actualización de los dispositivos más de lo necesario y hace que una vulnerabilidad, por pequeña que sea, se pueda convertir en una pesadilla para los usuarios, en especial si afecta, como es el caso, a su información sensible, o le provoca molestas denegaciones de servicio.

En estos casos debemos hacer lo siguiente:

Si no está disponible, consultar al fabricante o al proveedor de servicios de Internet que lo comercializa, sobre la forma de protegernos hasta que esté disponible la actualización que corrija el problema.


  1. Consultar al fabricante del dispositivo, o al proveedor de servicios de Internet que lo comercializa, sobre el problema y preguntarle si hay disponible una actualización de seguridad para el mismo en ese momento.

  2. Si la hay y está disponible para nosotros, instalarla lo antes posible y siguiendo las indicaciones del fabricante del dispositivo.

Tanto Microsoft como Apple han manifestado que tanto los dispositivos basados en Windows Mobile, como en iOS y OSx, así como sus servicios web, no están afectados por el problema del OpenSSL.

En el caso de Android, los móviles más vulnerables al fallo de OpenSSL son los que tienen versiones 4.1 de este sistema operativo, aunque también es cierto, que algunas versiones de Android 2.4 Jelly Bean, que han sido personalizadas por fabricantes u operadores, también pueden ser vulnerables.

Incluso móviles que se han actualizado recientemente a Android KitKat 4.4 pueden estar afectadas por este fallo, por usar versiones de OpenSSL tan antiguas como la 1.0.1e. Sin embargo, aunque tengan instalado un OpenSSL afectado en un dispositivo Android, la posibilidad de explotación del fallo también depende de la configuración del móvil, por lo que lo mejor es usar la aplicación indicada anteriormente para comprobarlo.

De todos modos, si nuestro smartphone está afectado por el fallo, lo más recomendable es no usarlo para realizar conexiones seguras, o manejar información sensible, hasta que dispongamos de una actualización adecuada, lo que puede tardar bastante, si además de Google, dependemos del fabricante y/o del operador para hacerlo.

Existen algunas opciones para saber si nuestro smartphone está afectado por problemas con el SSL o con el TLS:

a) Apple (fallo en el TLS por goto fail).
b) Aplicación Android para comprobar el fallo de OpenSSL.

Pero esta seguridad en relación a los sistemas operativos de los smartphones es relativa. Aunque nuestro smartphone no se vea afectado por el problema de OpenSSL y esto es aplicable de forma indistinta a dispositivos Android, iOS, o Windows Mobile, eso no nos garantiza que no se haya utilizado para acceder a un servidor vulnerable. Por lo que debemos estar atentos a todas las actualizaciones de aplicaciones que se produzcan estos días en relación a este fallo de seguridad y si sabemos que una aplicación móvil ha sido afectada, ya sea por usar la librería afectada internamente, o por conectar con un servidor afectado, no debemos utilizarla hasta que se actualice la aplicación y/o el servidor del servicio y cuando todo esté en orden, deberemos cambiar la contraseña de acceso a dicho servicio lo antes posible.





"Copyleft Fernando Acero Martín. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre."


"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."

El grave fallo de seguridad en GnuTLS (y II)

IBSN, blog, id






En un artículo anterior ya hablamos del origen y de las consecuencias para la seguridad del fallo en la librería GnuTLS, ahora nos centraremos en la forma de solucionarlo y en las distintas estrategias en función de la situación en la que se encuentre nuestra distribución.

¿Qué es más seguro el software libre o el privativo?

Esta es una eterna pregunta eterna, que a lo largo de la historia, ha provocado encarnizadas discusiones en los foros más diversos, pero para no entrar en la polémica, no consideraremos el hecho de que en el caso del software libre el código fuente está disponible. Creo que es evidente, tras los sonados fallos de seguridad recientes, que la disponibilidad del código fuente no ha ayudado mucho a evitarlos, es más, considero que sin herramientas automatizadas como las que proporciona Coverity, es complicado auditar miles de líneas de código fuente. Por ello creo que hay que avanzar en este tipo de herramientas y al mismo tiempo, mejorar las pruebas que se realizan del código.

Si atendemos a las estadísticas de fallos detectados en el código fuente, como índice de la calidad y/o seguridad del software, creo que la mejor referencia es el Informe anual de Coverity 2013 [PDF]. Si tenemos en cuenta que el estándar de la industria del software para considerar que un programa tiene calidad suficiente, es de menos de 1 fallo por cada 1.000 líneas de código, hemos de decir, que tanto el software libre, como el software privativo, pasan ampliamente el corte, con una densidad media de 0,59 para el caso del software libre y de 0,72 para el software privativo, como vemos, unos datos relativamente similares y mejores que el estándar. Aunque hay proyectos de software libre, como Python, que destacan de forma notable sobre la media, con una densidad de fallos de solamente 0,005.

Sin embargo, creo que es justo decir que las empresas de software privativo han hecho un gran esfuerzo en los últimos años, al pasar de una densidad de 20 a 30 errores por cada 1.000 líneas de código que presentaban 2006, a los muy aceptables 0,72 de media de la actualidad. Hay que destacar, que esas mismas fechas el software libre presentaba una densidad de solamente 0.434 errores.

Pero ¿cuál es el motivo por el que ha aumentado el índice de fallos en el software libre y ha disminuido tan notablemente el del software privativo?. Creo que el problema está en el aumento de las líneas de código de los proyectos, algo que ocurre casi inevitablemente al madurar los mismos y aumentar las prestaciones de librerías y programas. El software libre, por su modelo de desarrollo distribuido y mayores dificultades para auditar el software, es muy propenso a que aumenten los fallos cuando aumentan las líneas de código si no se establecen estrategias adecuadas para evitarlo.

Lo que sí es cierto, es que normalmente, cuando son detectados, los fallos se reparan más rápidamente en el caso del software libre, algo que también se refleja en el informe. Este hecho fue evidente con los fallos de seguridad detectados durante el concurso Pwn2own, durante el que fueron hackeados los principales navegadores del mercado. En este caso, con un concurso que se llevó a cabo entre los días 12 y 13 de marzo de 2014, la versión de Mozilla Firefox que solucionaba los problemas detectados, la 28.0, ya se podía descargar de los servidores de Mozilla el día 18 de Marzo.

Pero este no es un caso aislado, esta rapidez en la resolución de fallos también fue detectada por Coverity en ediciones anteriores del informe, destacando el caso de Amanda (software libre para realizar copias de seguridad), que tras arrojar el mayor índice de fallos cuando se analizó el código, la comunidad de desarrolladores de dicha aplicación respondió rápidamente y en menos de una semana, se corrigieron todos los errores, pasando a ser el proyecto de software libre con menos errores de todos los revisados. Por lo tanto, si consideramos el tiempo de reacción dentro de la métrica, podemos decir que el software libre también es más seguro que el privativo.

Pero ¿qué ocurrió con GnuTLS?. Según los datos de Coverity, GnuTLS se comenzó a analizar con su herramienta Coverity Scan en abril de 2011, algo que se hizo regularmente hasta junio de 2011, pero pasó mucho tiempo sin auditorías, hasta la última, que se realizó el pasado día 17 de abril de 2014, posiblemente con un afán de mejorar el código tras el fallo "goto result". Los datos de esta auditoría son estos:

Último análisis: 17 de abril de 2014
Líneas de código analizadas: 150.350
Densidad cada 1.000 líneas: 0,55

Cambios desde la comprobación del 10 de junio de 2011
Nuevos fallos detectados 73
Eliminados 366

Fallos en la versión actual:
Totales: 487
Pendientes: 82
Solucionados: 403

Como se puede ver, no son unos datos malos, de hecho, son mejores que la media del privativo del informe de Coverity, que para los proyectos en c y c++. de entre 100.000 y 500.000 líneas de código muestran una densidad de errores 0,81, pero peores para el software libre, que para ese mismo número de líneas, muestra una densidad de 0,50.

Aunque es complicado ver si los fallos remanentes de GnuTLS en este momento, como ocurrió con el "goto result", son críticos o no para la funcionalidad y/o seguridad de la librería. De todos modos, creo que es sano realizar este tipo de auditorías del código de forma sistemática y evitar, como ocurrió con GnuTLS, el pasar varios años sin auditarlo de ninguna forma, puesto que como he indicado anteriormente, es complicado detectar fallos cuando crecen el número de líneas, o hay muchos desarrolladores en el proyecto.

Estrategia de actualización

Una vez que hemos tomado conciencia de que nuestro software es vulnerable, las dos vías son actualizar o parchear. Si nuestra distribución continua manteniendo soporte, la solución es sencilla, esperar que aparezca el paquete .dbm o .rpm correspondiente en los repositorios y actualizarlo lo antes posible. En este sentido, es muy recomendable considerar a la hora de elegir una distribución, el hacerlo sobre una LTS (Long Time Support), que como Ubuntu 14.04 LTS "Trusty Tahr", que está previsto que tenga 5 años de soporte.

Si nuestra distribución ya no tiene soporte, lo más recomendable es actualizarse a una que sí lo tenga. Si hemos tenido la precaución de tener una partición /home, dicho proceso no debe ser demasiado traumático ya que nuestros datos no se deberían ver afectados si tenemos cuidado durante la instalación y elegimos las opciones correctas.

Sin embargo, puede que no nos interese o no podamos, por los motivos que sea, el proceder a la actualización de toda la distribución, en ese caso la única opción pasa por actualizar el paquete o modificarlo adecuadamente, opción que no tienen los usuarios de software privativo cuando pierden el soporte, ya que para actualizarlo/compilarlo o para parcherarlo en estas circunstancias, es imprescindible contar con el código fuente del mismo.

Podemos pensar que para actualizarlo/compilarlo, nos bastará con bajarnos la última versión de la librería del repositorio correspondiente y usar la secuencia de mandatos:


./configure
make
make check
make install

Dicha secuencia es posible que nos sirva en muchos casos, puede que en la gran mayoría, pero tiene sus riesgos que debemos evaluar. Por ejemplo, si cogemos la última versión de OpenSSL, es decir, la 1.0.1g y usamos los mandatos anteriores para instalarla en una Mandriva 2010 (Mandriva usa la OpenSSL 0.9.8 de 25 Mar 2009 y no está afectada por el fallo "Heartbleed", pero la usaremos a modo de ejemplo de lo que estamos explicando), lo que lograremos realmente, es romper el sistema de paquetes que dependen de esta librería y con ello, no podremos instalar o desinstalar ningún paquete .rpm, lo que podemos considerar un desastre que nos puede llevar a tener que instalar todo el software, con todo lo que implica si nuestra distribución está muy "tocada" y no se han usado paquetes .rpm o .deb, para instalar todo lo que necesitamos o hemos modificado en ella y mantenemos copia de los mismos.

Hay que tener en cuenta, que cuantas más dependencias, más riesgos se corren y hay dos tipos de dependencias, las que tiene el programa o librerías para poder ser complilada y las de los otros paquetes que dependen de ella.

Por ejemplo, si intento compilar la última versión estable de la librería GnuTLS, la 3.2.9 en una Mandriva 2010, con mi configuración actual, compruebo que la única dependencia que tengo es una librería criptográfica denominada Nettle, en su versión 2.7.1. Nettle se añadió como dependencia a partir de la versión 2.10.5 de GnuTLS. Sin embargo, si yo intento desinstalar GnuTLS en Mandriva 2010 mediante su gestor de paquetes, el sistema me avisa de que hay 650 paquetes que dependen de GnuTLS, por lo que un poco de cautela no nos vendrá mal antes de decidirnos por instalar directamente la última versión de GnuTLS.

Podemos pensar que es tan sencillo como compilar e instalar Nettle y/o Gmplib, que también necesitaremos para compilar las últimas versiones de GnuTLS, si no la tenemos instalada. Pero también hay que tener en cuenta, que todo lo que instalemos puede tener otras dependencias, que pueden ser versiones más recientes de librerías existentes o de herramientas de compilación o nuevas versiones, por lo que cuanto menos dependencias generemos en nuestra actualización mejor que mejor.

En el caso de Nettle, cuando lo intento compilar solamente me lanza una dependencia, y aunque solamente se usa para las pruebas del código, es la OpenSSL 1.0.1g, que como hemos dicho, es incompatible con el sistema de paquetes .rpm de la Mandriva 2010, aunque también es cierto, que no es frecuente que una actualización a una versión más moderna de una librería genere este tipo de incompatibilidades en Linux.

En este punto hay dos opciones:

a) Tomar el código fuente de la misma versión de la librería GnuTLS que tenemos instalada en nuestro sistema, que en el caso de Mandriva 2010, es la 2.8.4, e intentar parchearla. Para ello, la tendremos que comparar con el código final del archivo /lib/x509/verify.c y con que es el parche que han generado los desarrolladores para resolver el problema, para ver si lo podemos hacer sin grandes problemas.

Para ello accedemos al ftp del proyecto y nos bajamos dicha versión, junto con su archivo de firma. Alternativamente nos podemos bajar el .rpm con el código fuente de Mandriva.

Ahora, lo primero que tenemos que hacer, es comprobar la firma. Para ello, con gpg (GnuPG) instalado en nuestro sistema, importaremos al anillo de confianza la clave de Simón, que es uno de los desarrolladores de GnuTLS y seguidamente usaremos el siguiente mandato desde el directorio en el que se encuentran los dos archivos anteriores:


gpg --verify gnutls-2.8.4.tar.bz2.sig
gpg: Firmado el vie 18 sep 2009 10:51:45 CEST usando clave RSA ID B565716F
gpg: Firma correcta de "Simon Josefsson "
gpg:                 alias "Simon Josefsson "

Una vez comprobada la firma mediante el mensaje "Firma correcta de "Simon Josefsson "", lo descomprimiremos mediante el mandato:

tar -xjvf gnutls-2.8.4.tar.bz2

Seguidamente analizaremos si es posible parchear el archivo sin problemas. Como premisa general consideraremos que el archivo no se podrá parchear directamente mediante el mandato patch de Linux, por lo que deberemos hacerlo a mano. Como sabemos, el archivo fuente del problema es "/lib/x509/verify.c", así que nos toca compararlo con el parche y el código fuente de la última versión disponible, en lo que al problema se refiere. Como veremos, la función "check_if_ca", se puede parchear sin problemas, ya que el código es casi idéntico a la de la versión anterior a la 3.2.9 de GnuTLS. En el caso de la función "_gnutls_verify_certificate2", veremos que aunque se puede parchear, las cosas se complican algo más, sobre todo, si no se tiene mucha experiencia de programación en C.

b) Por lo tanto, tendremos que recurrir a la segunda opción, es decir, instalar una versión de la librería más moderna que la que estamos usando.

El proceso de elección se basa en ir buscando en las distintas versiones disponibles de GnuTLS, hasta encontrar una que se parezca más a lo que tenemos que modificar, pero que no suponga un problema de dependencias. Por ejemplo, podemos probar con la ultima versión de GnuTLS que no necesitaba Nettle, es decir la 2.10.5. Si queremos conocer las diferencias entre las distintas versiones de GnuTLS, podemos recurrir a la Wikipedia.

En este caso, y para ahorrar trabajo a los lectores, una vez bajado el código fuente de esta versión y comprobada la firma, el parche que propongo aplicar para solucionar el problema de GnuTLS es este que muestro seguidamente. A pesar de esto, recomiendo echar un vistazo al código del archivo "verify.c" resultante tras aplicar el parche y compararlo con el de la versión 3.2.9 GnuTLS. Como se podrá comprobar, mi parche se parece mucho al creado para la versión 3.2.9 por el desarrollador Nikos Mavrogiannopoulos, que por otra parte, es el código en el que se basa el mismo, a excepción de la inicialización a cero de la variable "ret", que no aparece en el código de la versión 3.2.9:


--- verify.c 2010-12-06 14:04:44.000000000 +0100
+++ verify.nuevo 2014-03-09 18:24:37.489058578 +0100
@@ -116,7 +116,7 @@
   if (result < 0)
     {
       gnutls_assert ();
-      goto cleanup;
+      goto fail;
     }
 
   result =
@@ -125,7 +125,7 @@
   if (result < 0)
     {
       gnutls_assert ();
-      goto cleanup;
+      goto fail;
     }
 
   result =
@@ -133,7 +133,7 @@
   if (result < 0)
     {
       gnutls_assert ();
-      goto cleanup;
+      goto fail;
     }
 
   result =
@@ -141,7 +141,7 @@
   if (result < 0)
     {
       gnutls_assert ();
-      goto cleanup;
+      goto fail;
     }
 
   /* If the subject certificate is the same as the issuer
@@ -181,6 +181,7 @@
   else
     gnutls_assert ();
 
+fail:
   result = 0;
 
 cleanup:
@@ -274,7 +275,7 @@
   gnutls_datum_t cert_signed_data = { NULL, 0 };
   gnutls_datum_t cert_signature = { NULL, 0 };
   gnutls_x509_crt_t issuer = NULL;
-  int ret, issuer_version, result;
+  int ret = 0, issuer_version, result=0;
 
   if (output)
     *output = 0;
@@ -307,7 +308,7 @@
   if (issuer_version < 0)
     {
       gnutls_assert ();
-      return issuer_version;
+      return 0;
     }
 
   if (!(flags & GNUTLS_VERIFY_DISABLE_CA_SIGN) &&
@@ -328,6 +329,7 @@
   if (result < 0)
     {
       gnutls_assert ();
+      result = 0;
       goto cleanup;
     }
 
@@ -336,6 +338,7 @@
   if (result < 0)
     {
       gnutls_assert ();
+      result = 0;
       goto cleanup;
     }
 

Para aplicarlo, nos bastará con crear un archivo denominado "verify.patch", con el contenido anterior y tras copiarlo al directorio en el que se encuentra "/lib/x509/verify.c", ejecutaremos el mandato:

patch < verify.patch

Una vez aplicado el parche, podremos proceder a compilar la librería, para ello, usaremos la siguiente secuencia de mandatos:


./configure --prefix=/usr --with-default-trust-store-file=/etc/ssl/ca-bundle.crt / 
--enable-gtk-doc
make
make check

Estos mandatos y en especial "configure", nos informarán si todo está bien para compilar y si la compilación tiene éxito. Si nos aparece algún error en este proceso, lo más probable es que sea un problema de dependencias que deberemos resolver adecuadamente. He de decir, que mi distribución está configurada como estación de trabajo de desarrollo, por lo que la mayoría de los paquetes necesarios para poder configurar y compilar un programa ya estaban instalados y también es cierto que estos paquetes están bastante actualizados, por lo que estos tres mandatos se ejecutaron sin problemas.

Ahora, si todo está bien, estamos en disposición para instalar nuestra librería y la documentación asociada, lo que podemos hacer con los mandatos:


make install
make -C doc/reference install-data-local
ldconfig

Sin embargo, el mandato "make install", aunque parece que es la opción más usada, tiene sus riesgos, sobre todo, si luego no está disponible la operación o regla "unistall" para "make", que nos permitiría eliminar el código que se acaba de instalar en caso de problemas.

Para solucionarlo de forma elegante yo suelo usar el mandato checkinstall. Que tras la configuración, compilación del programa, comprobación del programa e introducción de unos datos que nos pide, nos permite generar un paquete .rpm o .deb, según la distribución que usemos, que será más sencillo de instalar y desinstalar en caso necesario. En este caso, dadas las enormes dependencias de GnuTLS en Mandriva 2010, no se recomienda desinstalar directamente el .rpm de la versión anterior antes de usar "make install", lo que hace mucho más recomendable el hacerlo mediante un paquete .rpm, como si fuera una actualización más del sistema.

NOTA: Si hacemos varias pruebas de compilación antes de instalar, hay que seguir el procedimiento anterior en todas ellas y entre prueba y prueba, es necesario eliminar los archivos de la compilación anterior mediante el mandato "make clean".

Para los más osados, les diré que tras instalar Nettle 2.7.1 y obviando instalar la última versión de SSL, pude compilar e instalar sin problemas la versión 3.2.9 de GnuTLS, que por otra parte, funciona también sin problemas y con ello, de paso, tengo Nettle, que aunque no era necesaria antes de la instalación de GnuTLS, es una librería, que junto con gmplib, que es una librería de aritmética de precisión variable y que ya estaba instalada en mi sistema, son más que interesantes para trastear cosas relacionadas con la criptografía.

Finalmente, ya que estamos, podemos actualizar el archivo /etc/ssl/ca-bundle.crt, que contiene los certificados de las CA en el formato adecuado, para actualizarlo, podemos seguir este procedimiento, que nos garantizará que tenemos los certificados adecuados y que se han eliminado los que ya no son necesarios o los que son inseguros, por lo que recomiendo usarlo de vez en cuando.

Con este artículo he intentado explicar algo de lo que posiblemente se habla en muchos sitios y que es inherente al software libre, la posibilidad de adaptarlo a nuestras necesidades, pero también es cierto, es que no se hace en muchas ocasiones, principalmente por ser una opción de último recurso. Pero como hemos podido ver, es posible y relativamente accesible, incluso para personas que no tienen sólidos conocimientos de programación, si tienen acceso al código que se ha modificado para solucionar el problema.

Evidentemente este procedimiento será más complicado o incluso, imposible, cuanto más se alargue la línea temporal, básicamente por el problema las dependencias directas e inversas del paquete que tengamos que actualizar. Evidentemente, cuanto más cerca se encuentre la versión del paquete a actualizar a la versión que usamos en nuestro sistema, menos problemas tendremos. Por ello, he considerado interesante hablar del procedimiento a seguir para parchear un fuente e instalarlo en nuestro sistema sin demasiados riesgos y hablando de los posibles problemas que se nos pueden presentar en el proceso.

Del mismo modo, cuanto más sepamos de programación, más sencillo se nos hará modificar los fuentes y en caso necesario, incluso podremos hacer un parche a nuestra medida, si el que hay disponible no se adapta demasiado a nuestra versión del programa, lo que puede ser un buen paso previo para participar activamente en proyectos de programación en el futuro.

Complicado o no, hemos demostrado que es posible hacerlo y todo hay que decirlo, es una opción que no está disponible, ni siquiera como un último recurso, a los usuarios de software privativo, que tendrán que optar por pagar una nueva licencia y actualizarse a una nueva versión, aunque ello les suponga incluso, la necesidad de actualizar todo o parte de su hardware, o perder la posibilidad de usar determinado software que era de su interés. Evidentemente, si somos una empresa tenemos un serio problema de este tipo y no sabemos como solucionarlo, otra opción sería contratar los servicios de alguien que sepa hacerlo.

Desde mi punto de vista, el software libre, además de más seguro en este momento, nos proporciona opciones y oportunidades que deberíamos valorar seriamente desde el principio.









"Copyleft Fernando Acero Martín. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre."


"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."
IBSN, blog, id




Cuando he intentando configurar un ordenador con un Linux más bien antiguo (2010) para que funcione el DNIe, me he encontrado un problema con los demonios HALDAEMON (en algunos sistemas HALD) y PCSCD. El primero se encarga de mantener una base de datos con los dispositivos conectados al sistema en tiempo real. El demonio HALDAEMON conecta con el sistema D-bus de mensajes, para proporcionar una API (Application Programing Interface) que pueden usar los distintos programas para encontrar, controlar e invocar operaciones sobre los dispositivos conectados al sistema. El segundo es el demonio que se encarga de la gestión de las tarjetas inteligentes, tales como nuestro DNIe.

Después de un montón de intentos y comprobaciones, que requerían cada una de ellas un tedioso reinicio del sistema y un cambio de configuración, descubro que el demonio PCSCD no arrancaba adecuadamente.Tras verificar mediante el mandato siguiente, que el demonio arrancaba y funcionaba sin problemas de forma manual, pero fallaba al pararlo:

service pcscd restart

Decidí reiniciar de nuevo el sistema, pero sin tocar ninguna configuración y procedí a comprobar el estado del demonio mediante el mandato:

service pcscd status

A lo que el sistema me respondió con este preocupante mensaje:

pcscd dead but subsys locked

Lo que es un indicativo claro de que hay un problema con el arranque del demonio PCSCD, pero como veremos más adelante, este problema es un daño colateral de una secuencia de arranque no correcta para los demonios del sistema. El error sería comenzar a trastear con PCSCD sin hacer algún diagnóstico adicional de las causas del problema Para ello, decidí revisar el contenido del archivo /var/log/messages mediante el mandato:

less /var/log/messages/ | grep pcscd

Gracias a ello, localicé varias líneas en dicho archivo con el siguiente contenido relacionado con PCSCD y HALDAEMON, que creo que es bastante revelador:


Mar 03 21:08:58 localhost pcscd: 
hotplug_libhal.c:562:HPRegisterForHotplugEvents() 
Could not initialise connection to hald.
Mar 03 21:08:58 localhost pcscd: 
hotplug_libhal.c:563:HPRegisterForHotplugEvents() 
Normally this means the HAL daemon (hald)

Ahora parece que el problema está claro. El demonio PCSCD arranca antes que el demonio HALDAEMON, algo que debería ser al contrario para que todo funcionase correctamente. Como es lógico, primero hay que detectar el lector de tarjetas y luego la inclusión de la tarjeta en el lector y para que ello funcione así, HALDAEMON (HALD) tiene que arrancar por completo antes que PCSCD.

Una solución a este problema sería añadir un retardo, por ejemplo de 5 segundos, al arranque del demonio PCSCD. Para ello, habría que editar el archivo /etc/init.d/pcscd y modificar la sección start() añadiendo una línea sleep 5 de forma que aparezca así:


start() {
        gprintf "Starting smart card daemon: "
        sleep 5
        daemon pcscd
        RETVAL=$?
        echo
        [ $RETVAL -eq 0 ] && touch /var/lock/subsys/pcscd
        return $RETVAL
}

Y luego volver a arrancar el demonio con el mandato:

service pcscd restart

Pero sinceramente, aunque funciona, no es la solución más elegante y aunque lo probé en su momento, dicha solución no nos aporta nada al debido conocimiento que deberíamos tener de nuestro querido sistema Linux.

Como hemos dicho anteriormente, el problema es que PCSCD arranca antes que HALDAEMON, por lo que debemos comprobar algunas cosas en nuestro sistema en relación al proceso de arranque y las prioridades de los distintos demonios.

Si usamos cd /etc/rc3.d, accederemos al directorio que controla el arranque de los demonios en el runlevel 3 y desde dicho directorio, podemos usar el mandato siguiente, para comprobar las prioridades de arranque de estos dos demonios:


ls -1 /etc/rc3.d/S*{pcscd,haldaemon}
/etc/rc3.d/S12pcscd@
/etc/rc3.d/S54haldaemon@

El resultado significa que el demonio PCSCD arranca ("S" de start) con la prioridad 12, es decir, al principio del proceso. Sin embargo, HALDAEMON arranca con la prioridad 54, es decir, a mediados del proceso de arranque, que es precisamente lo que no nos conviene. Algo curioso, cuando he instalado ambos demonios con sus paquetes RPM respectivos y la configuración estándar de los mismos debería contemplar precisamente lo contrario.

La solución es modificar la prioridad de arranque. En nuestro caso podemos dejar que el demonio HALDAEMON siga arrancando más o menos a la mitad del proceso, pero PCSCD debemos configurarlo para que arranque al final del proceso de inicio del sistema. ¿Cómo lo hacemos?. Bueno, es relativamente sencillo si sabemos en la forma en la que funcionan los scripts de inicio de los demonios que aparecen en /etc/init.d. Comenzaremos por editar el archivo /etc/init.d/pcscd. En dicho archivo encontraremos una línea comentada (comienza por la almohadilla #) con el siguiente contenido:

# chkconfig: 2345 12 88

¿Qué significa esta línea?. Aunque esté comentada con la almohadilla delante, contiene la información necesaria para que se configure adecuadamente y con las prioridades necesarias en los distintos runlevel del sistema. En este caso estamos indicando al mandato chkconfig que PCSCD se activará en los runlevel 2, 3, 4 y 5, con la prioridad de arranque 12 y con la prioridad de apagado 88, en todos ellos.

Por ejemplo, si queremos que este demonio arranque casi al final del proceso de inicio del sistema, debemos cambiar el número 12, que es la fuente de nuestros problemas, por otro número mayor, por ejemplo 91. En todo caso, el número para PCSCD deberá ser ligeramente mayor que 54, que es la prioridad de arranque de HALDAEMON, ya que además de arrancar más tarde, debemos dar tiempo a que arranque el demonio HALDAEMON con normalidad antes de iniciar el arranque del demonio PCSCD. Así que la línea anterior del archivo /etc/init.d/pcscd, debería quedar de la forma siguiente:

# chkconfig: 2345 91 88

Hecho esto, usaremos el mandato siguiente, para eliminar los enlaces simbólicos a este demonio en los distintos runlevel en los que se encuentra configurado:

/sbin/chkconfig --del pcscd

Después usaremos el mandato siguiente, para volver a crear dichos enlaces simbólicos, pero en esta ocasión, con la prioridad adecuada:

/sbin/chkconfig --add pcscd

De esta forma, si volvemos al runlevel 3, mediante cd /etc/rc3.d/ y usamos el mandato siguiente:


ls -1 /etc/rc3.d/S*{pcscd,haldaemon}
/etc/rc3.d/S54haldaemon@
/etc/rc3.d/S91pcscd@

Comprobaremos que el orden de arranque de ambos demonios es ya es el adecuado y que están lo suficientemente separados, como para permitir el normal arranque de HALDAEMON antes de que se inicie el de PCSCD. Ahora si reiniciamos el sistema mediante el mandato reboot, en teoría, deberían arrancar sin problemas ambos demonios. Lo que podemos comprobar mediante el mandato:


service pcscd status
pcscd (pid 26480) está activo...

Que nos dice que el demonio está activo y nos informa del PID (Process ID) del mismo.

Como podemos ver, el mandato chkconfig es de mucha utilidad a la hora de controlar los servicios (demonios) que deben arrancar en los distintos runlevel del sistema, de esta forma, si usamos el mandato siguiente:


chkconfig --list | grep pcscd
pcscd           0:desactivado   1:desactivado   2:activo        3:activo        4:activo        5:activo        6:desactivado       7:desactivado

Podemos ver, que como aparecía en la configuración de chkconfig que aparecía en el archivo /etc/init.d/pcscd, este demonio se encuentra activado, ahora con la prioridad de arranque 91 y de apagado 88 en los runlevel del sistema con números 2, 3, 4 y 5 (/etc/rc2.d, /etc/rc3.d, /etc/rc4.d y /etc/rc5.d) .

En este punto aclararemos que los runlevel 0, 1, 6 y S están reservados para los siguientes usos:

0 - Parada
1 - Monousuario para mantenimiento del sistema
6 - Rearranque
S - Monousuario con la partición de root montada únicamente, con el objeto de comprobar reparar el sistema de archivos en caso necesario.

En algunos sistemas, como RedHat, el runlevel S es el mismo que el runlevel 1.

Los restantes runlevel son lo siguientes:

2- Multiusuario sin soporte de red.
3- Multiusuario con soporte de red. (Inicia el sistema normalmente)
4- Multiusuario con soporte de red. (Igual que el runlevel 3).
5- Multiusuario gráfico (X11). (Similar al nivel de ejecución 3 + display manager.)

Estos son los runlevel heredados de Unix SystemV, sin embargo, en la actualidad se pueden definir otros runlevel con los números 7, 8 y 9, para completar un total de 10.

Hay que señalar, que es posible que los problemas que experimentan algunos los usuarios a la hora de configurar el DNIe en sus sistemas, tengan un origen similar, que además, no es muy evidente y nos puede llevar mucho tiempo el diagnosticarlo y solucionarlo de forma adecuada.




"Copyleft Fernando Acero Martín 2014. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre."


"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."

El grave fallo de seguridad en GnuTLS (I)

IBSN, blog, id

Cientos de paquetes de Software Libre presentes en la práctica totalidad de las distribuciones Linux, como RedHat, Mandriva, Debian, Ubuntu, etc, pueden haber heredado un grave fallo de seguridad presente en la librería GnuTLS. GnuTLS es una librería de comunicaciones seguras basadas en los protocolos SSL (Secure Sockets Layer ), TLS (Transport Layer Security) y DTLS (Datagram Transport Layer Security), por lo que un fallo en dicha librería presumiblemente afectará a todas las aplicaciones que usen estos protocolos, ya sea mediante enlazado dinámico o estático de la misma, permitiendo el engaño y la monitorización de las comunicaciones de los usuarios, salvo que usen implementaciones propias de estos protocolos y por lo tanto, ajenas al problema de GnuTLS.

El fallo CVE-2014-0092, detectado durante una auditoría de seguridad de Red Hat, afecta a la forma en la que la librería GnuTLS verifica los certificados digitales X.509, pudiendo dar por válido un certificado digital que no lo es. Esta vulnerabilidad, para que pueda ser explotada, necesita un atacante actuando de forma activa como MitM "man-in-the-middle". La mejor forma de solucionar el problema, es actualizar GnuTLS a las versiones (3.2.12 o 3.1.22) o aplicar el parche y compilar de nuevo, en el caso de que no podamos actualizarnos a la última versión y tengamos que usar la rama GnuTLS 2.12.X.

Las estimaciones iniciales indican que más de 250 aplicaciones se basan en GnuTLS para implementar las vitales operaciones de seguridad relacionadas con los protocolos SSL, TLS y DTLS. Sin embargo, no sería de extrañar, que este número se ampliase posteriormente al analizar las dependencias de los distintos paquetes que usan la librería GnuTLS. Sin embargo, me ha llamado la atención, por ejemplo, que en el caso de Mandriva Business Server 1 y de Mandriva Enterprise Server 5, las dos únicas distribuciones de este empresa que todavía gozan de soporte, tras actualizar el paquete GnuTLS el pasado día 10 de marzo de 2014, no se ha actualizado ningún otro paquete que pudiera estar afectado al usar dicha librería de forma estática, lo que puede implicar que no los hay y que el problema es menor del que puede parecer.

En cualquier caso, la primera medida que debemos adoptar ante este grave problema de seguridad, es actualizar GnuTLS lo antes posible, o nos arriesgamos a que algún atacante pueda monitorizar nuestro correo electrónico, o decodificar, sin que nos demos cuenta, las conexiones seguras que realicemos con nuestro banco o con la Administración, a través de Internet. robando nuestras credenciales (nombre de usuario y contraseñas) más preciadas.

El error es el resultado de los mandatos utilizados en la sección del código de GnuTLS que verifica la validez de los certificados digitales, también conocidos como certificados X.509. Un ejemplo de este tipo certificados lo tenemos en los emitidos por la Fábrica Nacional de Moneda y Timbre (FNMT), que son los que usan muchos contribuyentes para realizar la Declaración de la Renta a través de Internet.

Lo más curioso es que dicho error está presente desde el año 2005 y nadie se ha dado cuenta hasta ahora, a pesar de lo crítico que es este paquete para la seguridad de las comunicaciones y que dicho código estaba disponible para cualquiera que quisiera leerlo. Nadie se ha dado cuenta hasta ahora de que las comprobaciones de los certificados X.509 finalizaban antes de tiempo por culpa de una variable, denominada "result", que no se había declarado e iniciado adecuadamente en el programa. Es más, es curioso que los tests que incluye el paquete para comprobar su correcto funcionamiento antes de instalarlo tras una compilación, tampoco han sido diseñados para detectar este grave problema.

Evidentemente, tras este suceso no han tardado a aparecer teorías de la conspiración, sobre todo, después de aparecer otro error, igualmente crítico, en Apple iOS y OS X y que algunos argumentan que tiene cierto parecido con el del GnuTLS, al basarse en una instrucción "goto fail" mal colocada en el código. Error que ya ha sido solucionado por los ingenieros de Apple y que permitiría a un atacante lograr los nombres y contraseñas usados en los distintos servicios sin que el usuario se diera cuenta de ello. De todos modos, con las noticias recientes de la NSA, cualquier cosa puede ser posible.

Sin embargo, aunque parezcan similares los fallos de GnuTLS y de Apple, lo cierto es que se parecen solamente en la instrucción "goto" usada en ambos casos por los programadores y que su función en el programa es provocar un salto incondicional a un determinado lugar del código en el que hay una etiqueta de identificación idéntica a la usada en la sentencia "goto".

Como he indicado antes, en el caso de GnuTLS el fallo permite obtener de forma encubierta los nombres de usuario y las contraseñas, por el manejo poco adecuado de determinados errores que pueden producirse durante el proceso de verificación de la validez de un certificado X.509, lo que se realiza en varias etapas, provocando en algunos casos, una verificación correcta de un certificado que no es correcto. Desde el punto de vista práctico, un atacante podría usar este fallo para crear un certificado especialmente diseñado para que sea validado como correcto por GnuTLS y por lo tanto, ser aceptado por dicha librería para establecer una conexión segura SSL o TLS con una página falsa, permitiendo a su vez, que el atacante, en el papel de "man-in-the-middle", monitorice todo el tráfico generado entre un servidor legítimo y el ordenador del usuario.

Tras analizar el código presente en el archivo /lib/x509/verify.c y compararlo con en el que aparece en el el paquete gnutls-3.2.9, veremos que el problema está en la variable "result" y en las sentencias "goto cleanup" usadas en las funciones “check_if_ca” y “_gnutls_verify_certificate2”, que son las que provocan una inicialización incorrecta de la variable "result" y por lo tanto, el fallo en la verificación del certificado X.509.

Supongo que si el fallo provocase el comportamiento contrario, es decir, dar por no válido un certificado válido, el fallo se hubiera localizado enseguida. Por ello considero importante que las pruebas incluyan otras posibilidades, como verificar que una serie de certificados no son válidos por diversos motivos, por ejemplo, por caducidad, cadena de confianza no adecuada, etc. Ni que decir que considerar no válido un certificado que sí lo es es molesto, pero siempre será menos peligroso que considerar como válido un certificado que no lo es.

Después de ver el origen de los dos fallos anteriores, lo que más me ha sorprendido de todo este asunto, es el uso de sentencias "goto" en el código fuente en un lenguaje de programación estructurado como es el C, algo que creo que puede haber tenido algo que ver con el error y con la tardanza en localizarlo. Aunque algunos autores dicen que "goto" puede simplificar la lectura y seguimiento del código, parece que no ha sido así en este caso.

Lo que sí es cierto, es que tanto en el caso de Apple como en el de GnuTLS, el error se encuentra de forma sorprendente en el código que controla funciones más críticas para la seguridad de un sistema, por lo que creo que dicho código debería haber sido comprobado auditado más cuidadosamente, por ejemplo, usando una batería de pruebas mucho más completa. De todos modos, no hay que dramatizar demasiado, estadísticas recientes indican que en un millón de líneas de código puede haber entre 300 y 500 errores dependiendo de la calidad del software y cabe pensar que algunos de estos errores son y serán críticos.

Ahora queda por ver en la forma que este fallo de GnuTLS afecta a otros paquetes, lo que dependerá de si hacen uso de la librería GnuTLS de forma estática o dinámica. Por ejemplo, el popular apt-get de Debian, usa GnuTLS, pero seguro que hay muchas más aplicaciones implicadas, por lo que los desarrolladores de cada paquete deberán evaluar su impacto y si fuera necesario, proporcionar nuevas versiones de los mismos para erradicar el grave problema del GnuTLS.

En un artículo posterior, hablaremos en la forma en la que he solucionado este problema de seguridad en una obsoleta Mandriva 2010, que ya no tiene soporte del fabricante, algo que no podrán hacer en una situación similar los usuarios de Windows XP a partir del 8 de abril de 2014, pero esto es otra historia.

ACTUALIZACIÓN 03ABR14

Tras una esclarecedora conferencia impartida con la ocasión de las Jornadas de Ciberdefensa del MCCD, por el gran profesional de la seguridad en dispositivos móviles que es Raúl Siles (de la empresa Dinosec), no tengo más remedio que modificar un poco mi artículo y aclarar algunas cosas que considero importantes en relación a estos fallos.

Sirva en mi descargo que en mi entorno no hay nin un dispositivo de Apple, por lo que lo que comenté sobre el error "goto fail" de los dispositivos iOS no se correspondía con mi experiencia directa con este sistema operativo, sino a informaciones recopiladas de Internet al respecto, que por desgracia, parece que me llevaron a tener una idea equivocada del alcance del problema.

El caso es que durante la excelente conferencia y demostración posterior de Raúl sobre la seguridad de dispositivos móviles, que podemos denominar "los pelos como escarpias", he podido ver con mis propios ojos como se producía un ataque MitM (Man in the Middle), en el que durante un acceso a una web presuntamente segura de una empresa, se robaban las credenciales del usuario para acceder a los servicios de la misma.

Evidentemente, este ataque se producía por aceptar el dispositivo iOS, que no tenía actualizado su sistema operativo a la última versión disponible, un certificado X.509 falso. Por cierto, aunque salga el candado en el navegador, sería conveniente echar un vistazo al los certificados antes de seguir.

Visto lo visto, he de decir que el fallo de Linux y de iOS se parecen tanto, que prácticamente permiten hacer las mismas cosas tanto con dispositivos Linux, como con los de Apple y entre ellas, lo más jugoso puede ser un ataque MitM. Asimismo, en ambos casos, se trataba de una instrucción "goto". En el caso de Linux la sentencia "goto" provocaba un valor erróneo de la variable "result" y en el caso de iOS, dos sentencias "goto fail" seguidas y sin la necesaria llave que las separe, hacía que el resultado siempre fuera un certificado válido, con independencia de la validez real del mismo.

Como ha comentado Raúl, dicho error en el iOS no se hubiera producido en Python por el especial uso que hace dicho lenguaje de programación de la identación a la hora de identificar el código que debe trabajar junto (denominado bloque). Ojo, para evitar problemas, se deben usar cuatro espacios en lugar del tabulador en Python. De esta forma, todo el código que forma parte del bloque ha de tener el mismo identado (número de espacios delante) para que Python lo trate adecuadamente.

Dicha función en C y C++ se realiza mediante las llaves, que en ocasiones y como hemos comprobado, son escurridizas. Pero esto solamente es un chascarrillo didáctico, puesto que errores se pueden cometer en cualquier lenguaje y todos ellos tienen algunos que podemos considerar típicos.

Dicho lo anterior, comprendo que muchos hayan pensado que ambos errores, basados en la sentencia "goto", con efectos similares y catastróficos en el uso de TLS, tanto en iOS como en Linux, sean intencionados y no fortuitos. Es más queridos amigos, ahora veo dicha posibilidad, aunque parezca conspirativa, menos descabellada y dentro de los mundos posibles.

Como ya he corregido en mi artículo, tanto el fallo del GnuTLS, como del TLS en iOS permitían un ataque MitM y en ambos casos, como es lógico, se podían robar las credenciales del usuario, aunque se usase una sesión https, además de otros muchos otros ataques, como por ejemplo, la instalación de software malicioso en Linux si se usa TLS para verificar la firma de los paquetes a instalar.

Evidentemente, al estar siendo usado el iOS en una gran cantidad de dispositivos móviles este error es más fácilmente explotable, tal como demostró Raúl durante su conferencia, en conexiones WIFI, incluso en aquellas con los niveles de seguridad más elevados.

Desde aquí quiero agradecer a Raúl su excelente conferencia y el haber compartido con nosotros esta interesante información. Como dice el dicho popular "no te acostarás sin saber una cosa más".





"Copyleft Fernando Acero Martín. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre."


"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."
IBSN, blog, id





Hace tiempo que estoy preocupado con lo que puede ocurrir con la futura Ley de Propiedad Intelectual, lo que se ha reflejado en varios artículos intentando concienciar en relación a este grave asunto. Desde mi punto de vista, el sistema de Propiedad Intelectual es un ecosistema muy delicado, en el que desgraciadamente, hay especies en peligro de extinción y si la Ley no contempla todas las especies presentes de forma adecuada, cabe la posibilidad que la Ley se comporte como un depredador invasor que acabe acelerando la extinción de algunas de ellas y una crisis no es el momento más adecuado para estas peligrosas experiencias legislativas.

Un de las cosas que más me ha alarmado es que el proyecto de Ley, en su exposición de motivos comience por las palabras "Las industrias culturales y creativas...". Siempre he pensado que una Ley de Propiedad Intelectual debería pensar primero en el eslabón más débil, que son los autores, que por otra parte, es lo que dice la ONU que se debe hacer [PDF], es decir, permitir que los autores puedan vivir de su trabajo. Evidentemente, si no hay autores, no hay cultura y si no hay cultura, no hay esa mal llamada industria cultural, creativa o del entretenimiento. Pero parece que no es la prioridad la protección de los autores en este caso que nos ocupa. Por cierto, la ONU también alerta en el documento anterior de los serios peligros de otorgar a las empresas los derechos que les corresponden a las personas.

Realmente el Proyecto de la Ley que se nos viene encima, si no lo modifican, tiene otras muchas cosas preocupantes y que nos pueden afectar muy seriamente:

a) No contempla las licencias libres.

b) Representa una seria limitación al derecho de cita y a los enlaces, que es la esencia de Internet y no contempla en ningún caso, la existencia de este medio para la difusión y comercialización de las obras sin la intervención de intermediarios y en la forma que el autor desee.

c) Dificulta el ejercicio del derecho comunicar o de recibir información.

d) Establece derechos irrenunciables, cuando hay autores, como es mi caso, que llevamos años renunciando a ellos para facilitar la libre difusión del conocimiento y la cultura.

e) No es acorde con lo que se establece en la mal llamada "Constitución Europea". Uno de sus artículos, concretamente el III-248, que encontraremos en la Sección 9 dedicada a "INVESTIGACIÓN Y DESARROLLO TECNOLÓGICO Y ESPACIO" dice lo siguiente:

"La acción de la Unión tendrá por objetivo fortalecer sus bases científicas y tecnológicas, mediante la realización de un espacio europeo de investigación en el que los investigadores, los conocimientos científicos y las tecnologías circulen libremente, favorecer el desarrollo de la competitividad, incluida la de su industria, así como fomentar las acciones de investigación que se consideren necesarias en virtud de los demás capítulos de la Constitución."

f) Aunque prácticamente reduce a la nada el concepto de "copia privada", este Proyecto de Ley continua consagrando el concepto de "canon por copia privada" y lo vincula a la existencia de un soporte físico previo, algo que es completamente anacrónico. Este hecho, me hace dudar sobre el conocimiento real que tienen los legisladores sobre Internet y los nuevos modelos de negocio que permite la Red para los autores. A vista del contenido de este Proyecto de Ley, he decidido modificar la licencia que otorgo a mis artículos, más que nada, para que queden claros mis deseos como autor y sean conscientes los legisladores de que con la Ley que plantean, dicha licencia no va a ser posible, a pesar que es lo que deseo.

Finalmente quiero señalar que no hay mucho tiempo para intentar convencer a nuestros legisladores del serio error que pueden cometer si aprueban el texto tal como está. Una vez que fue publicado en el Boletín Oficial de las Cortes Generales, quedó establecido un plazo de enmiendas por un período de quince días hábiles, que finaliza el día 11 de marzo de 2014.

Desarrollando estos problemas que he citado anteriormente y algunos más, se ha elaborado la siguiente Declaración, que creo que sintetiza y explica el problema que se presenta a ciudadanía en general y a las empresas en particular si se aprueba la Ley tal como está planeada en este momento.

DECLARACIÓN CONJUNTA DE LA RED Y LOS AUTORES CULTURALES SOBRE EL PROYECTO DE REFORMA DE LA LEY DE PROPIEDAD INTELECTUAL

El pasado 14 de febrero de 2014 el Consejo de Ministros aprobó el proyecto de reforma de la Ley de Propiedad Intelectual [PDF] (texto publicado en el B.O.C.G. el 21 de febrero).

Este proyecto de Ley, arcaico en su concepción, recorta numerosos derechos en España, afecta muy negativamente a amplios sectores de la sociedad, pone en peligro la cultura libre y cuestiona el funcionamiento de Internet, limitando la cita y el enlace a una actividad meramente mercantil.

Esto ha generado un rechazo inmediato y casi unánime desde todos los ámbitos posibles por los motivos que exponemos sintéticamente a continuación:


  1. La protección de la propiedad intelectual en Internet no se garantiza imponiendo cánones o tasas arbitrarios. Por el bien de la economía española, ha de garantizarse la sostenibilidad de los creadores digitales en su conjunto, no sólo de una parte. Un sector se desarrolla fomentando los nuevos modelos de negocio digitales en lugar de destruirlos. Cualquier derecho nace del diálogo entre todas las partes afectadas.

  2. La Constitución Española consagra, en su artículo 20, el derecho fundamental “a comunicar o recibir libremente información veraz por cualquier medio de difusión”, lo cual debe conjugarse con cualquier derecho de propiedad, pero jamás anularlo.

  3. Adicionalmente, esta ley cercena otros derechos fundamentales, afecta a valores democráticos esenciales y limita el libre acceso a la información y a la cultura. Ignora la declaración de los Derechos Humanos, conculca derechos constitucionales como la libertad de expresión y la libre creación, viola el secreto de las comunicaciones, es un ataque directo a la neutralidad de la red y no respeta un derecho individual básico: que cada cual ofrezca su obra bajo las condiciones que considere oportunas.

  4. La figura del “derecho irrenunciable” derivado de citar textos en Internet afectaría sin excepción a todos los creadores y les impediría renunciar voluntariamente a ese derecho. Ello pondrá en serio peligro las licencias Creative Commons, ampliamente extendidas y que actualmente ofrecen cobertura jurídica a los derechos de autor de una parte muy significativa de los contenidos de la Red. Nos encontramos ante una imposición del “copyright” sobre los partidarios del “copyleft” que vulnera derechos e intereses colectivos en lugar de garantizarlos y favorece que la recaudación se concentre en muy pocas manos.

  5. Lejos de ser una amenaza, los agregadores de noticias y otras herramientas digitales que enlazan y citan al medio de origen, tales como buscadores, redes sociales o blogs, favorecen el libre acceso ciudadano a la información y generan un amplio tráfico hacia los medios de comunicación. Además, siendo el derecho de cita la esencia del Periodismo, esta ley amenaza frontalmente su ejercicio. Criminalizar los enlaces genera una inseguridad jurídica que cuestiona los fundamentos y el uso de Internet. Garantizarlos, respetando los derechos, beneficia a todos: usuarios, herramientas y medios de comunicación.

  6. La mal llamada “tasa Google” ha sido impulsada sólo por una parte del colectivo de editores, los integrados en AEDE. Otras asociaciones y editores se oponen a esta medida. AEDE debería considerar las consecuencias económicas que supondrá para sus socios salir de los indexadores y las desastrosas consecuencias para sus empleados, como recortes salariales y pérdidas de empleo. Este canon de AEDE aumentará aún más la precariedad de un sector tremendamente castigado por la crisis.

  7. La entrada en vigor de esta Ley supone una tasa adicional para el conocimiento. La entidad de gestión de derechos CEDRO recauda actualmente de los profesionales de todo el sistema educativo. La nueva ley establece que las Universidades paguen también por los contenidos que los profesores publican para sus alumnos, y que hasta hoy se acogían a licencias Creative Commons. CEDRO recaudará en régimen de monopolio un canon de 5 euros por alumno. Consideramos esto un atentado contra la Educación, la investigación y los textos académicos, que pasarán a estar regidos por el “copyright” en lugar de ser de dominio público.

  8. Este canon, con cargo a los Presupuestos Generales del Estado y de cuantía no determinada por la ley, actúa en detrimento de la justa recompensa a los autores y supone una subvención encubierta a los editores, a quienes el art. 2 de la Directiva 2001 de Propiedad Intelectual NO INCLUYE como beneficiarios de derechos de propiedad intelectual, y que pese a ello se llevan el 45% de la recaudación de CEDRO. Es significativo que la redacción de la ley se refiera sólo a las “industrias culturales” ignorando expresamente a “los autores”, agravando una situación que ya se inició con la pérdida de derechos de los periodistas a favor de los editores por la confección de “clippings” (resúmenes de prensa).

  9. Se elimina “de facto” el derecho de copia privada, vinculándolo a la copia material de un soporte físico, práctica ésta casi inexistente en la era digital. La copia privada de una obra es un uso legitimo que existía antes de Internet y seguirá existiendo tras esta reforma. Gravar con un canon a la copia privada equivale a imponer una multa preventiva a cada ciudadano ante un hipotético uso delictivo, por más que éste nunca suceda. Criminalizar al consumidor con fines recaudatorios no es el camino.

  10. No han de apoyarse medidas de control de la “piratería” que pongan en peligro la esencia misma de la red. Oponerse a esas medidas no implica respaldar la caricatura del “todo gratis”. Es preciso desarrollar un nuevo marco de protección de la industria cultural que tenga en cuenta las particularidades de la era digital y sirva para lo que nació este tipo de legislación: fomentar la práctica de la cultura ofreciendo una compensación económica a los autores.

  11. Esta Reforma debería incluir medidas de acompañamiento que apoyen el desarrollo de nuevos modelos de negocio basados en Internet, así como la mejora de los ya existentes. De no hacerlo, perjudicará la innovación de los sectores afectados y perpetuará un modelo de distribución cultural y de acceso a la información manifiestamente caduco.

  12. Esta reforma de la LPI aparenta ser producto de una dinámica de corruptelas entre lobbies y el poder político, evidenciado por el reciente relevo de los directivos en los principales diarios nacionales y la escenificación de la reforma de la ley presentándola con una foto del presidente de la AEDE junto a la vicepresidenta del Gobierno. Esto pone bajo sospecha a unos y otros, si consideramos la cercanía de procesos electorales.

CONCLUSIÓN

La reforma de esta ley, tal cual se ha redactado, está abocada al fracaso y la auguramos muy corto recorrido, pues no se adecua a la realidad ni cubre las necesidades de los sectores y agentes implicados. Es un freno para el desarrollo de la cultura libre y la industria, inasumible en tiempos de dificultades económicas, en los que es preciso primar la innovación y favorecer el surgimiento de nuevos mercados emergentes, en los que España demuestra un enorme potencial.

Además, contiene innumerables ambigüedades e indefiniciones, que una ley de esta envergadura no puede permitirse, ya que abre la puerta a una aplicación discrecional y a graves efectos colaterales indeseados.

Por todo ello, instamos al Gobierno a reconsiderar y retirar esta reforma y a abrir con todos los sectores afectados el diálogo que estos reclaman desde hace meses para aportar soluciones más adecuadas a la nueva realidad que plantea la sociedad digital.

Al mismo tiempo, hacemos un llamamiento a toda la sociedad para participar, aportar, comprometerse y difundir la campaña de rechazo al #CanonAEDE difundiendo tanto esta declaración como sus actos, acciones e iniciativas.

#canonAEDE


"Copyleft 2014 Fernando Acero Martín. Se permite la copia textual, la traducción y la distribución de este artículo entero en cualquier medio, a condición de que este aviso sea conservado. Se permite la cita. El autor no reclamará ninguna cantidad por el ejercicio de las dos autorizaciones anteriores. No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre."


ACTUALIZACIÓN 27FEB14 A LAS 19:00

Tras mi artículo y la modificación de mi licencia libre, a lo que también se ha subrrogado nuestro estimado ADMIN con el texto "No autorizo a ninguna Entidad de Derechos de Autor a reclamar cantidad alguna en mi nombre", ha comenzado un movimiento o campaña libre y espontánea en la Red, para la modificación de licencias de uso de artículos y blogs en respuesta al Anteproyecto de LPI.

Uno de los casos más elaborados lo tenemos en el Blog de José Sánchez Pardo, que además, añade que la licencia que se podría aplicar con mayores garantías es la CC 3.0 unported.

Excluye la LPI de tu blog con Reconocimiento 3.0 Unported (CC BY 3.0) #CanonAEDE

Igualmente tenemos el blog del músico copyleft, Eme Navarro, que también ha puesto el mismo texto que Kriptópolis en su blog:

Eme says

Hay que señalar, que si de la ecuación del cobro salen los medios tradicionales por la negativa de los agregadores de noticias a enlazarlos, una parte del pastel para reclamar derechos económicos derivados del enlace y/o cita, estaría formada por una gran parte la blogosfera, por considerarse ese derecho a cobrar irrenunciable en la Ley y siempre sería reclamado por una Entidad de Gestión de Derechos de Autor, a la que no pertenecemos ni queremos pertenecer la mayoría de nosotros.

En vista de lo anterior y dado que muchos otorgamos licencias libres a lo que publicamos en Internet, debemos considerar lo injusto que sería que alguien en nuestro nombre se lucrase por nuestro trabajo, sin contar con nosotros y cuando además, nosotros no hemos querido lucrarnos y deseamos que nadie lo haga, para que la información, arte o conocimiento que elaboramos fluya en el mundo real o en virtual con las menores trabas posibles.

"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."

Felices fiestas a todos

IBSN, blog, id
Las leyes de la mecánica cuántica borran la diferencia entre lo animado y lo inanimado, es decir, un átomo de carbono se comporta exactamente igual, desde el punto de vista cuántico, dentro de nuestro cerebro donde se fraguan nuestros recuerdos y pensamientos, que en la mina de un lápiz. Sin embargo, el primero forma parte de la vida y el otro de un objeto inanimado y ambos átomos tienen el mismo origen, el polvo de las estrellas.

Parece evidente que el pensamiento humano, sus ideas y sus recuerdos,  forman parte de ese continuo espacio-tiempo que nos rodea y con ello adquiere una nueva dimensión la afirmación que dice que "el pensamiento del hombre puede cambiar el mundo".

Nuestro pensamiento, como parte integrante y activa de ese continuo espacio-tiempo lo modifica de alguna forma y con ello podría modificar la realidad que nos rodea en nuestro mundo macroscópico. ¿será esa la explicación por el que algunas personas atraen la suerte o la fortuna a sus vidas?. Es probable que así sea y por probar no se pierde nada, ya que además, pensar en positivo y el intentar mejorar lo que nos rodea, nos hará más felices.

Recientes avances en mecánica cuántica y en el estudio del comportamiento de la materia y sus componentes. nos llevan a otras dimensiones, a otras posibilidades maravillosas. que hacen que me pregunte ¿cómo afectan los procesos cuánticos en nuestro cerebro a nuestras vidas macroscópicas? o ¿qué procesos cuánticos hay implicados en nuestros recuerdos, ideas o pensamientos y cuál es el alcance de los mismos?. Con independencia de las respuestas a dichas preguntas, creo que nuestra experiencia nos debe llevar a convencernos de algo claro. Si hay algo pueda cambiar la realidad que nos rodea y que dicho cambio sea para bien, eso son nuestros pensamientos e ideas.

Por lo tanto, lo que más deseo para estas Navidades y para el año que entra, es que vuestras ideas y pensamientos positivos, os ayuden a cambiar el mundo que os rodea y que vuestras vidas sean más prósperas y felices cada día que pase.

Os deseo de corazón unas felices fiestas y un mu próspero año nuevo.
"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."

Libro sobre Cultura Libre Digital

IBSN, blog, id
Estimados amigos, he colaborado en este libro sobre cutura libre digital que se ha editado recientemente por Icaria Editorial S.L. Mi aportación es modesta, con un corto capítulo sobre la neutralidad en la Red.

Aquí está el enlace a la editorial:

Cultura Libre Digital

El libro tiene una licencia libre y se otorgan las siguientes libertades:


  • Copiar, distribuir y comunicar públicamente la obra

  • Remezclar — transformar la obra

  • Hacer un uso comercial de esta obra

Bajo las condiciones siguientes:

  • Reconocimiento — Debe reconocer los créditos de la obra de la manera especificada por el autor o el licenciador (pero no de una manera que sugiera que tiene su apoyo o apoyan el uso que hace de su obra).


  • Compartir bajo la misma licencia — Si altera o transforma esta obra, o se genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta.

Al final de la página de la editorial hay un enlace para bajarse el PDF del libro, para todo aquel que no lo desee comprar.

En él han participado:


@axebra, EDRI, FCForum, Fernando Acero Martín, Jaron Rowan, Rubén Martínez y Simona Levi.

Como justificamos en el libro, lo más importante es que la cultura fluya libremente, por lo que al contrario que postulan otros autores, os ruego que difundáis libremente esta obra. Si alguien se anima y quiere colaborar a la causa, tampoco pongo pegas a que alguien lo compre.

Espero que os guste.

"Copyleft 2013 Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved"
"Copyleft: Creative Commons License Attribution, Non Commercial, Share Alike Fernando Acero Martín. Verbatim copying, translation and distribution of this entire article is permitted in any digital medium, provided this notice is preserved. Quotation is allowed."

Latest Month

July 2014
S M T W T F S
  12345
6789101112
13141516171819
20212223242526
2728293031  

Syndicate

RSS Atom
Powered by LiveJournal.com
Designed by Tiffany Chow