Ingeniería, Ciencia, Arte y Negocio

A veces me da por participar en debates estériles simplemente porque me divierten. Aunque, ahora que me doy cuenta, que si me divierten, ya no son tan estériles. He leido cientos de hilos en listas de correo con los típicas comparaciones. Kde vs Gnome, C++ vs C, C++ vs Java, Gtk+ vs Qt, Linux vs Windows…

A día de hoy, o mejor dicho, a día de hace una semana, estaba totalmente convencido que el C++ era mejor que C. Sin embargo ahora no empiezo a tenerlo claro. Y es que, tengo un grave problema, cuanta más experiencia tengo, cuanto más tecnologías diferentes analizo, menos claras tengo las cosas cuando supuestamente debería ser lo contrario.

El caso, es que en estos momentos tengo un proyecto entre manos, para el que necesito crear algún tipo de interfaz gráfico para el usuario. Tenía que elegir unas librerías que me permitieran hacer esto. Mi elección de manera natural estaba clara, elegiría Qt porque es una librería probada sobradamente (KDE la usa en su escritorio) y que además tiene una magnifica documentación. Pero sobre todo, mi inclinación por usar Qt era porque estaban programadas en C++. Sin embargo, mientras he ido madurando la aplicación, he empezado a tener menos claro si debo poner mi aplicación con licencia GPL o no, y aunque no lo tengo decidido aún, con Qt no tengo elección, debe ser GPL. Es cierto que existe otra licencia comercial de Qt que no me obliga a ello, pero los costes no son asumibles por mí en este momento.

Buscando una alternativa, llegué de nuevo a Gtk+. Ya conocía Gtk+ pero la mantenía un poco en la distancia porque estaban realizadas en C, sin embargo tenía una gran ventaja para mi, su licencia era LGPL. Esta licencia me permite hacer con mi código lo que me venga en gana. Es decir, me dar libertad verdadera.

Sé que el tipo de licencia no debería ser un factor a tener muy en cuenta para decidir la tecnología que vas a utilizar para el desarrollo de una aplicación, sin embargo, en esta ocasión decidí echarle un vistazo. Para los que no lo sepan, Gtk+ es a Gnome, lo que Qt es a KDE. Por lo tanto, ni que decir tiene que Gtk+ también es una librería madura.

Gtk no pertenece a ninguna empresa. Qt en realidad, en su versión GPL tampoco, pero sí pertenece a medias entre Trolltech (recientemente adquirido por Nokia) y la Foundación KDE. Sea como sea, y aunque no dudo sobre las buenas intenciones de la Fundación KDE, Qt tiene dueños. Sin embargo Gtk+ no pertenece a nadie. Este es otro factor que me hizo pensar que merecía la pena echarle un ojo.

Sinceramente, aún estoy frotándome los ojos cuando miré el código por dentro. Es un código diseñado con un gusto exquisito, y con una filosofía orientada a objetos, que me gustaría ver en muchos de los programas desarrollados en C++. Ya sabéis la programación orientada a objetos no es una cuestión del lenguaje si no de diseño. Esto queda reflejado de forma patente en el código de las GTK+

Ahora bien, si está pensado con OOP en la cabeza, porqué no usar un lenguaje orientado a objetos. Según algunos de los desarrolladores de Gtk+ y según se puede leer en numerosos sitios de internet a poco que busques por internet, la mayoria de la gente que decide usar C sobre C++ es porque piensan que C++ te obliga a meter una serie de sobrecargas que no son necesarias, y que lleva a la gente que usa el lenguaje a hacer malos diseños. Tampoco les suele gustar mucho el uso de las STL o de las Boosts.

Está claro que, del mal diseño de una aplicación no tiene la culpa el lenguaje si no el que lo diseña. Pero… un lenguaje está claro que te condiciona la forma en la que enfocas un problema. Es más complicado hacer un buen programa en Perl que en Java.

En un hilo de discusión muy famoso, Linus dijo que había elegido C para el desarrollo de Git porque le parece mucha mejor opción. Y dijo también “si elegir C sirve para mantener apartado del proyecto a los programadores de C++, ya es una buena opcion”. Otra de las perlas que soltó fue, que “a cualquier persona que eliga C++ en vez de C para un proyecto, no la quería tener en su proyecto”. Sin duda alguna estas no son maneras de expresarse, pero más allá de esa questión, yo me pregunto ¿tendrá razón?.

Generalizar es un pecado mortal en estos contextos, pero, debido a la naturaleza del lenguaje, quien pensáis que por regla general conoce mejor el funcionamiento de los ordenadores, ¿un programador de C o uno de Java? y ¿entre uno de C y otro de C++?. A pesar de tirarme piedras sobre mi propio tejado, yo creo que por regla general el de C. Y aunque no estoy de acuerdo con Linus en las formas como lo dijo, empiezo a estar de acuerdo en el fondo de lo que dijo.

La gente suele decir, que con C++ se pueden abordar projectos más grandes que con C. Bueno, eso depende. Probablemente ninguna de estas personas haya trabajado en proyectos tan grande como pueden ser Gnome, Evolution o GiMP por poner algunos ejemplos. Sin embargo todos ellos están desarrollados en C. Lo que si te obliga C es a llevar una disciplina que sólo los buenos conocedores de como funciona el software son capaces de llevar a cabo. En C no hay recolección automática de basura, eso lo tiene que hacer el programador, en C++ ocurre lo mismo, pero… en C si te creas un polimorfismo sabes exactamente lo que estás haciendo porque lo hace el propio programador, mientras que en C++ muchos de los paradigmas de la programación orientada a objetos están ocultas en la sintaxis del programa, como debe ser en un lenguaje pensado para el desarrollo orientado a objetos. Lo mismo ocurre con el uso de strings, que en determindas ocasiones cuando son utilizadas en C++ para concatenar, requiere de muchos recursos para hacerlo y es extremadamente lento. Sin embargo, al estar todo oculto, es complicado de que un programador pueda detectarlo.

En definitiva, creo que, en los proyectos donde tan sólo se permite C, la probabilidad de que haya un mal programador es más baja, que en los proyectos donde se desarrolla en C++. También es cierto que un buen programador en C++ suele tener muy claros determinados conceptos sobre la programación orientada a objetos y sobre la programación genérica que no tiene por qué tener un programador en C.

Estoy convencido de que, entre los programadores de las Gtk+ hay muy pocos programadores malos a la vista del código y del diseño. Queda patente una gran formación en la ingeniería del software y unas ideas muy claras de como hacer las cosas bien.

Cuando me hice cargo del mantenimiento del paquete de software libre DDD. Pensé en ponerle un mejor entorno gráfico, ya que actualmente usa Motif que ya no se mantienen a buen ritmo, y pensé en reescribir algunas de las parte en C++. Sin embargo, ahora lo que vamos a hacer es dejar el C, no reescribir nada en C++ y meter Gtk en vez de Qt como tenía pensado. Ya veremos cual es la experiencia.

De hecho, después de ver como está hecho Gtk+, y como está organizado la plataforma de desarrollo de Gnome, me estoy replanteando muchas cosas que hasta hace una semana daba por hecho.

No comments

Suele ser cada vez más normal que se nos requiera a los administradores de sistemas una forma alternativa para acceder a los correos corporativos desde cualquier lugar del mundo, además de usando el cliente de correo. Normalmente esta opción suele ser usar algún tipo de webmail.

Bajo mi punto de vista ésta es sin duda una forma muy cómoda de acceder al correo electrónico, y al mismo tiempo un peligro en potencia. Los usuarios y muchos administradores de sistemas suelen dormir tranquilos cuando instalan este servicio usando https y protegido con un login y un password para cada usuario que tenga cuenta en el servidor. Sin embargo, en mi caso, son numerosos los dolores de barrigua que me produce el pensar que cualquiera desde un ciberbar puede ver los correos de la gente a la que se supone que protejo con el simple hecho de saber la clave del usuario…

Donde actualmente trabajo, existe una gran cantidad de consultores que viajan alrededor de todo el mundo y usan en ocasiones el webmail desde algún ordenador que les proporciona el cliente al que van a prestar la consultoría. Es muy fácil que a un cliente poco avanzado se le ocurra echar un ojo por encima del hombro de mi consultor cuando va a teclear la clave, para luego poder usarla él tranquilamente desde su casa. Un cliente un poco más avanzado podría incluso instalar un keylogger en esa máquina, con lo que el trabajo sería aún más fácil. Entonces… ¿cuál es la solución? La solución pasa por mejorar el sistema de autentificación. Hay que autentificarse no sólo por una clave que sabes, sino que también debes usar un certificado que tienes. Probablemente en tu pendrive, que debes guardar como si fuese tu tarjeta de crédito.

A continuación expongo, paso a paso, cómo instalar un servidor Apache y cómo generar los certificados para los clientes.

En este caso, nosotros mismos seremos la autoridad certificadora (CA) que firmará los certificados del cliente, autoridad que hay que guardar de forma segura y sólo poder acceder a ella los administradores de sistemas. Espero que este mini-manual os sirva de ayuda. Tened en cuenta que tendréis que adaptar los comandos ejecutados para que se ajusten a vuestra estructura de directorio. Esta instalación se ha hecho en una distribución Debian, pero sirve para cualquiera. Antes de instalar Apache tenéis que tener instalados openssl y wget.

Pasos a seguir:

Paso 1: Descargar el servidor web de un lugar de confianza.

wget http://apache.gva.es/httpd/httpd-2.0.55.tar.gz

Para comprobar que es el ejecutable que queremos nos bajamos el md5 y la firma.

wget http://www.apache.org/dist/httpd/httpd-2.0.55.tar.gz.md5
wget http://www.apache.org/dist/httpd/httpd-2.0.55.tar.gz.asc

Para comprobar la firma hay que bajar previamente las claves públicas. Los fuentes te los puedes bajar de la web principal o desde un mirror, pero las claves públicas y la firma debes bajártelas desde el sitio oficial, para estar seguro de que nadie las manipuló.

http://www.apache.org/dist/httpd/KEYS

Usando gnupg importamos las claves y luego comprobamos la firma:

gpg --import KEYS
gpg --verify httpd-2.0.55.tar.gz.asc
jgomez@IT:~/apache-2.2-test$ gpg --verify httpd-2.0.55.tar.gz.asc
gpg: Signature made Mon 10 Oct 2005 03:35:15 AM CEST using RSA key ID 10FDE075
gpg: Good signature from "wrowe@covalent.net"
gpg:                 aka "William A. Rowe, Jr. "
gpg:                 aka "wrowe@lnd.com"
gpg:                 aka "wrowe@apache.org"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 33 16 9B 46 FC 12 D4 01  CA 6D DB D7 DE EA 4F D7

Comprobamos que la firma es correcta. El mensaje que aparece abajo, diciendo que no podemos estar seguros que esa clave sea de esa persona, se debe a que nosotros no la hemos firmado.

Una vez llegados aquí, tenemos nuestros fuentes en nuestro ordenador y además sabemos que nadie los ha manipulado.

Paso 2: Compilación de Apache

Descomprimimos los fuentes:

tar -zxvf httpd-2.0.55.tar.gz
cd httpd-2.0.55

Tenemos que activar mod_ssl y mod_setenvif. Este último módulo es necesario para mantener compatibilidad con algunos navegadores como Internet Explorer.

Para compilar Apache vamos a pasar los siguientes parámetros que necesitamos al configure. Si necesitas tener soporte para más cosas es mejor ir a la documentación oficial de Apache en http://www.apache.org y ver qué módulos debes activar. Así, si quieres soporte para mysql necesitar poner –with-mysql

Yo voy a instalar Apache en un directorio dentro de mi HOME. Utilicé esta linea de configuración:

./configure --prefix=/home/jgomez/apache-installation --with-mpm=prefork
--enable-ssl --enable-setenvif
make
make install

Y ya tenemos nuestro Apache instalado con soporte para SSL.

Si te vas al directorio donde lo instalastes (que en este caso es /home/jgomez/apache-installation) y luego ejecutas ./bin/apachectl start ya tendrás tu servidor funcionando. Puedes conectarte desde esa misma máquina con un navegador escribiendo http://localhost y verás la página de bienvenida de Apache.

Paso 3: Configuración Apache mod_ssl

Ahora vamos a hacer que escuche en el puerto 443 para conexiones seguras. Es decir, para el protocolo https.

Añadimos lo siguiente al fichero conf/httpd.conf:

Listen 443
SSLEngine on
SSLOptions +StrictRequire

SSLProtocol -all +TLSv1 +SSLv3
SSLCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:+HIGH:+MEDIUM

SSLMutex file:/home/jgomez/apache-installation/logs/ssl_mutex

SSLRandomSeed startup file:/dev/urandom 1024
SSLRandomSeed connect file:/dev/urandom 1024

SSLSessionCache shm:/home/jgomez/apache-installation/logs/ssl_cache_shm
SSLSessionCacheTimeout 600

SSLPassPhraseDialog builtin
SSLCertificateFile /home/jgomez/apache-installation/conf/ssl.crt/server.crt
SSLCertificateKeyFile /home/jgomez/apache-installation/conf/ssl.key/server.key

SSLVerifyClient none
SSLProxyEngine off

     AddType application/x-x509-ca-cert      .crt
     AddType application/x-pkcs7-crl         .crl

     SetEnvIf User-Agent ".*MSIE.*" \
     nokeepalive ssl-unclean-shutdown \
     downgrade-1.0 force-response-1.0

NOTA: En el fichero de configuracion del apache, esa linea anterior debe ir sin los \.

Antes de arrancar de nuevo nuestro Apache tendremos que generar los certificados y para eso hacemos:

umask 022
IT:/home/jgomez/apache-installation# mkdir conf/ssl.key
IT:/home/jgomez/apache-installation# mkdir conf/ssl.crt
IT:/home/jgomez/apache-installation# mkdir conf/ssl.crl

Ahora creamos nuestros certificados, que estarán firmados por nosotros mismos. Se supone que nos los tendria que dar alguna empresa tipo VeriSign, pero para lo que nosotros queremos, nos bastamos y nos sobramos.

openssl req -new -x509 -days 30 -keyout
/home/jgomez/apache-installation/conf/ssl.key/server.key -out
/home/jgomez/apache-installation/conf/ssl.crt/server.crt -subj
'/CN=JmGV-Test-Certificate'

(Para más información sobre la sintaxis ir a www.openssl.org)

IT:/home/jgomez/apache-installation# openssl req -new -x509 -days 30
-keyout /home/jgomez/apache-installation/conf/ssl.key/server.key -out
/home/jgomez/apache-installation/conf/ssl.crt/server.crt -subj
'/CN=Kriptopolis-Test-Certificate'
  Generating a 1024 bit RSA private key
  ..++++++
  .......................................++++++
  writing new private key to '/home/jgomez/apache-installation/conf/
  ssl.key/server.key'
  Enter PEM pass phrase:
  Verifying - Enter PEM pass phrase:

Desde ahora cuando arranquéis Apache os pedirá la clave. En realidad es configurable, pero por defecto os lo pedirá.

Una vez arrancado ya podéis conectaros poniendo desde el mismo ordenador, en un
navegador https://localhost

Os saldrán los datos del certificado.

Si es así es que vamos bien.

Ahora vamos a cambiar la configuración, para que cada cliente que se vaya a conectar
a nuestro web tenga que tener un certificado instalado en su navegador.

Paso 4: Hacemos que el servidor nos pida un certificado

Para eso, cambiamos configuración en Apache cambiando los siguientes valores:

SSLVerifyClient require
SSLVerifyDepth 1

Ese valor a 1 significa el numero máximo de intermediarios que aceptamos en el certificado. Si lo ponemos a 1 significa que todos los certificados tienen que estar firmados directamente por el CA que indiquemos. En este caso somos nosotros mismos.

Una vez que hagamos esos cambios y volvamos a rearrancar el servidor, veremos que ya no nos podemos conectar, y eso se debe a que no tenemos instalado ningún certificado en nuestro navegador; por lo tanto no tiene éxito la negociación y nos echa.

Tenemos que indicar Apache cuál es la entidad certificadora. En nuestro caso está en /home/jgomez/apache-installation/conf/ssl.crt/server.crt

Para ello, en httpd.conf añadimos:

SSLCACertificateFile /home/jgomez/apache-installation/conf/ssl.crt/server.crt

Reiniciamos Apache para ver que va todo bien.

Paso 5: Generación de certificados para clientes

Generación de certificados para la gente que queramos que vea nuestra web.

La creación de certificados para el cliente es muy similar a la que seguimos para la generación de certificados para el servidor.

Mediante este comando creamos una clave cliente:

openssl req -new -sha1 -newkey rsa:1024 -nodes -keyout client.key
-out request.pem -subj '/O=Secure/OU=LoGGiK/CN=JmGV'

Eso genera dos ficheros, client.key y request.pem (éste debe ser firmado por la CA, en este caso nosotros). La CA se supone que debe de asegurarse que la información es real antes de firmar nada.

Ahora toca firmarla. Te puedes poner a configurar el fichero openssl.cnf, pero yo lo que hice fue copiar el directorio /usr/lib/ssl/misc/demoCA a mi directorio CA, con lo que me quedó la siguiente estructura:

     jgomez@IT:~$ tree CA
        CA
        |-- demoCA
        |   |-- cacert.pem
        |   |-- careq.pem
        |   |-- certs
        |   |-- crl
        |   |-- index.txt
        |   |-- index.txt.attr
        |   |-- index.txt.old
        |   |-- newcerts
        |   |   `-- 91213828FA1E8EA9.pem
        |   |-- private
        |   |   `-- cakey.pem
        |   `-- serial
        |-- requests
        |   `-- request.pem
        `-- signed
            `-- signed.pem

Una vez ejecutado:

openssl ca -config /usr/lib/ssl/openssl.cnf -keyfile /home/jgomez/
apache-installation/conf/ssl.key/server.key -cert /home/jgomez/
apache-installation/conf/ssl.crt/server.crt -policy
policy_anything -out /home/jgomez/CA/signed/signed.pem -infiles
/home/jgomez/CA/requests/request.pem

Tenemos el fichero signed.pem listo para enviar al cliente.

El cliente por tanto, una vez recibido ese fichero, tendrá en un directorio los
siguientes ficheros:

client.key request.pem signed.pem

Ahora tiene que guardarlo todo en un certificado con formato PKCS#12 y para eso hace:

openssl pkcs12 -export -clcerts -in signed.pem -inkey client.key -out client.p12

Y ya para finalizar hay que cargar el certificado client.p12 en el navegador. Cada
navegador tendrá un procedimiento para hacer esto.

Próximamente realizaré otra serie de artículos donde se expliquen otros métodos que tienen aún más ventajas, como copias de certificados en el servidor, revocación de certificados, etc.

- Estoy absolutamente seguro de que la seguridad absoluta no existe -

No comments

Esto es un tema recurrente y la verdad es que no pretendo convencer a nadie sobre las virtudes o defectos de ninguna de estas librerias gráficas. Entre otras cosas porque no tengo los conocimientos suficientes sobre ninguna de las dos. Ya sé, antes de que alguien envie un comentario sobre mi ignorancia que en realidad Qt es mucho más que unas simples librerías gráficas. Son  también unas librerías para acceder a bases de datos, para funcionalidades de red y para varias cosas más (XML, WebKit, …) pero en este post me voy a centrar en la parte de las Qt que están pensadas para el diseño de interfaces de usuarios.

Con Qt tengo alguna experiencia. He hecho alguna que otra aplicación pequeña con estas librerias y he de decir que tienen muy buena pinta y son realmente intuitivas. Tienen además muy buena documentación, lo cual se agradece mucho cuando empiezas. Sin embargo hay varias razones por las que ahora he decidido probar con Gtk+. Por un lado está la curiosidad que tengo por ver cosas nuevas y que me lleva a no focalizar nunca. Este es un problema que tengo y lo sé. Y por otro lado es el interés repentino que me ha surgido por Gnome.

Aparte de estas dos razones fundamentales, hay otra más, su licencia. Quiero tener mi propia empresa algún día y me gustaría poder utilizar una librería que no me obligara a nada. Ya sé que Qt es GPL v2 y que eso significa el máximo de libertad. Al menos ese es el significado que le da la free software foundation con la que colaboro manteniendo el paquete programa DDD. Sin embargo, esa libertad es una libertad forzada. Es como si cuando tienes 18 años, no sólo te dan la libertad de volver de juerga a las 6 de la mañana si no que además te obligan a que no vuelvas antes de esa hora porque la puerta estará cerrada. Las obligaciones, aunque sean de libertad, hacen que tengas una libertad a medias.

La licencia de Gtk+ es LGPL lo que me permitiría desarrollar software y no liberar el código fuente. A día de hoy, mi intención es liberar el código de mis aplicaciones, pero mi intención también es ganar dinero con la empresa que algún día tendré. En función de las diferentes posibles lineas de negocio que en su momento tenga posibilidad de hacer, decidiré en ultima instancia que hacer con mi código.

Soy un ferviente seguidor del software libre, y a pesar de que en algún momento pueda cerrar código de mis aplicaciones, me comprometo a seguir colaborando con el software libre, liberando otro software o algunas librerias.

Ya se que Qt también me permite hacer software no libre, pero, los recursos de las empresas que empiezan son escasos, y si quiero gozar de todas las ventajas de Qt tendría que comprar al menos 3 versiones para 3 plataformas lo que me dejaría fuera del presupuesto por mucho.

Gtk+ está hecha en C y a mi me gusta C++, pero también parece ser que está hecho en C pero con C++ en la cabeza. Y como un día le oí decir a Alan Cox (que sabe bastante del tema) la programación orientada a objetos no está en el lenguaje, está en tu cabeza.

Voy a dedicar unos meses en hacer algo con Gtk+ para poder decidir con cual de las dos quedarme. Tengo que focalizar, lo sé, pero no me gustaría focalizar en el foco equivocado, y sinceramente, por muchos foros que leo del tipo gtk vs qt, no me queda claro cual es la más apropiada para mis intereses porque en la mayoría de estas discusiones aparecen comentarios subjetivos en función de otros factores que no me interesan.

Ya os contaré cual ha sido mi decisión final y también las razones que me llevan a ella y que por supuesto no tienen por qué ser las mismas que las que os lleve a vosotros a elegir la otra.

No comments