Ingeniería, Ciencia, Arte y Negocio

La verdad es que me aburre bastante oir a la gente quejándose constantemente del intrusismo laboral que existe en la informática, pero que sin embargo no mueven un dedo para resolver el problema. Creo que para algunos, es la excusa perfecta en la que escudarse para explicar su mala situación laboral y su bajo salario, cuando el problema, posiblemente sea otro.

Recuerdo que trabajando en una empresa, hace algún tiempo, uno de los empleados, compañero mío, se quejaba a su jefe diciendo que estaba descontento con su salario y que él se merecía mucho más. Mi jefe le respondió:

Si crees que te mereces más ve a otra empresa donde valoren tus conocimientos y te paguen como te mereces. Si de verdad vales lo que crees no te costará mucho encontrarla

8 años más tarde, sigue trabajando en esta misma empresa.

El problema del intrusismo laboral no es algo que afecte tan sólo a la informática. Tan sólo hay que sentarse delante de la tele 10 minutos para darse cuenta la cantidad de personajes que hacen de periodistas sin ni tan siquiera saber como llegar a la Facultad de Periodismo.  Sin embargo no he oido al periodista Jose María García quejarse del intrusismo que hay en el periodismo. Estuve durante 3 años trabajando en el diario El Mundo, y precisamente los que más se quejaban de este intrusismo eran los periodistas que se limitaban a hacer copy & paste de las noticias que llegaban de las agencias.

Si eres informático y te quejas constantemente del intrusismo laboral, quizás sea porque abusas tambien del copy & paste de la informática.

Algunos argumentan que hay informáticos que terminan la carrera y no tienen ni idea. Y bueno, aunque no me gustaría que esto fuese así, tengo que reconocerlo. He visto licenciados en informática que no sabían enviar un email. De todas formas, no voy a hablar de eso, porque tambien hay cirujanos a los que le cuesta encontrar el apendice, o a abogados que n0 saben de las leyes fundamentales por la que se rigen los pueblos. Estos abogados, como tantos informáticos, estudiaron Derecho Romano para aprobar el exámen y a otra cosa mariposa.

El sector de la informática no está regulado, y mientras se regula o no, tenemos que aceptar las reglas del juego. Después de todo, esto ya se sabía antes de que empezaramos a estudiar la carrera. Las cosas están así y los informáticos tenemos que dejar de llorar, patalear y hacer frente a la situación actual. Y no me refiero a crear colegios oficiales, con los que SI estoy de acuerdo y que creo que deberían existir. Pero me refiero a otro tipo de acciones.

Soy de la opinión de que en la Informática hay que estar por vocación y no por ambición (hoy en día estar por ambición no tiene sentido). Durante unos años, nos vendieron la moto de que un Ingeniero Informático tenía trabajo seguro y que además ganaría 500.000 de las antiguas pesetas antes de terminar la carrera. Y me refiero a las antiguas pesetas, a la de los años 90.  El hecho de que en nuestra profesión exista intrusismo laboral, nos obliga a ser buenos profesionales, cosa a la que no están obligado ni los médicos, ni los notarios, ni los abogados.  Con estos profesionales no podemos competir por mucho que nos gusten las leyes o la medicina. De hecho, estoy totalmente convencido que por mi experiencia en seguridad y por mis conocimientos sobre leyes acerca del mundo digital, estoy en mejor disposición para defender a un acusado por un supuesto acceso no autorizado a un ordenador, de manera mucho más efectiva que un abogado tracicional, sin embargo yo no puedo defenderlo, porque paradojicamente la ley me lo impide.

¿Entonces, que puedo hacer para mejorar mi situación como informático?. Muy fácil, tenemos que ser mejores profesionales que los que usan la informática como una salida de emergencia. Tenemos que conseguir tener más conocimientos y experiencia que los que puedan conseguir leyendo el Thinking in Java, o yendo a un curso de programación de Microsoft. Pero para conseguir esto, hay que estar en la Informática con un interés real por mejorar.

A lo largo de mi carrera he entrevistado a muchos candidatos para un puesto de trabajo. Un puesto de ingeniero de software, de arquitecto de software, o de bases de datos, etc. He entrevistado a Licenciados en Informática que no tenian un ordenador en casa. Raro será que esa persona sea contratada por mi. La mayoría de las cosas que nos puede hacer diferenciarnos del resto de los ‘intrusos’ es aprovechar los conocimientos adquiridos en la carrera de informática para ir más allá, y eso se consigue con dedicación, entusiasmo y tiempo.

Un problema grave que tenemos, es que en España, no hay muchas empresas que requieran de personal cualificado, y les vale con contratar a un puñado de “picacódigos”, que abusan de la técnica del copy paste y que hacen programas lentos, inestables, y dificil de mantener.

¿Contrataríais a Calatrava para que os diseñara una casa de perro? Probablemente os la haríais vosotros mismos a pesar de no ser arquitectos. Pues resulta que en informática, en España, la mayoría de las cosas que quieren hacer son casitas de perro. Eso hace que los Ingenieros Informáticos se acomoden en puestos aburridos, donde ganan muy poco y en los que además te vas oxidando. Mucho más si no tienes un ordenador en casa donde poder ir más allá. ¿Quieres seguir construyendo casas de perro toda tu vida? ¿Se queja Calatrava de la gente que diseña las casitas de perro?

Yo lo que os recomiendo es que busqueis algo que os guste dentro de la informática y os especialiceis, que seais el Calatrava de la neurocomputación o del reconocimiento de visión artificial, o de la programación de sistemas empotrados, o del diseño de software a gran escala, o de la domótica o de lo que querais, pero que cuando una empresa necesite a un especialista en vuestro campo, que no haya ningún médico, abogado, periodísta, o notario que os pueda quitar el puesto.

Estamos obligados a ser los mejores en esta profesión. Por supuesto, a mi me gustaría que no existiera el intrusismo. Pero la realidad es la que es, y no voy a permitir que por ese problema, yo no pueda trabajar en lo que más me guste, pudiendo llevar a casa al final de mes un dinero suficiente como para vivir tranquilo.

Os animo a que hagais lo mismo, y seais los mejores profesionales que podais ser. Trabajad, formaros, y luego vendrán los premios. Está bien pedir la regulación de la profesión o la creación de los colegios profesionales, pero mientras tanto el tiempo pasa, y la vida continua. No vale usar el intrusismo como excusa de nuestra mala reputación o de nuestros bajos salarios. Simplemente, esa no es la solución.

4 comments

Bueno, se acabó la época estival y ya es hora de salir del aletargamiento propio de los largos día de calor que se sufren en Málaga para dar paso a un poco de acción. Aunque sé que no lo voy a cumplir, intentaré a partir de ahora, actualizar este blog con más asiduidad.

Durante este verano he estado leyendo varios artículos, numerosas webs y algunos libros. Debido a esto, me encuentro ahora con nuevas inquietudes sobre las que me gustaría profundizar. Me gustaría avanzar en mis conocimientos de programación concurrente al mismo tiempo que me gustaría intentar sacar partido a CUDA para conseguir ganar potencia de cálculo. Siempre me ha gustado la representación gráfica por ordenador y este verano he adquirido un libro sobre OpenGL. Quizás sea momento de poner todo esto en práctica.

Para contar con un buen entorno de trabajo he actualizado mi ordenador y he comprado las siguientes componentes:

- Procesador Intel 2 Quad Core

- Placa que lo soporta

- 2 Gb de RAM con la intención de actualizar a 4 u 8. No me gusta 6 (no es potencia de 2)

- Tarjeta gráfica NVIDIA GeForce 8500 GT de 1G

El software que he instalado es una distribución Ubuntu de 64bits con la intención de poder utilizar los compiladores y herramientas de Intel que estan disponibles para gratuitamente para linux si no se hace uso comercial.

Durante los próximos post, iré escribiendo los experimentos que vaya haciendo asi como los resultados obtenidos.

2 comments

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.

1 comment

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

C++ es sin duda alguna mi lenguaje de programación favorito. Por un lado tengo acceso a bajo nivel, me da el control absoluto sobre el ordenador y al mismo tiempo me permite hacer software fácilmente mantenible. A me gusta decidir cuando liberar la memoria.

El ensamblador me permitiría quizas tener más control sobre el hardware y podría decirle a mi ordenador excatamente que hacer y como hacerlo. Sin embargo, veo muy complicado hacer un programa con 200.000 lineas y que fuese fácilmente mantenible en ensamblador. Ni que decir tiene, el problema que tendría la detección de errores y su resolución. Es por eso, por lo que C++ es mi lenguaje principal.

C++ sin embargo tenía un inconveniente si lo comparamos con otros lenguajes como Java. Java tiene dentro de su estandar una gran cantidad de librería que hacían la vida más fácil al programador. Sin embargo, esto está cambiando y con el nuevo estandar que se espera sea liberado este año, esto ya va a cambiar. El nuevo estandar C++09 constará de una gran cantidad de librerías estandar que harán la vida más fácil tambien al programador de C++.

Si quieres ver en que estado se encuentra el nuevo estandar , lo puedes hacer consultando un documento que se genera cada vez que se toman decisiones importantes en la evolución del nuevo estandar.

Si quieres estar al día de lo que se está haciendo al respecto, podeis ver este documento.

Algunos compiladores como g++ ya tienen implementada la TR2. Mucho antes que incluso Visual Studio 2008

1 comment

Durante mucho tiempo he pensado en devolver a la comunidad del software libre, parte de lo que ésta me ha dado a mi. Sin embargo, el tiempo es un bien escaso y es complicado dedicar mucho tiempo a otras tareas que no sean las obligaciones diarias.

Hace un mes decidí en dar un paso más y leer en la pagina de GNU como podría ayudar. Ví que uno de los programas que estuve usando durante un tiempo, ya no se mantenía por falta de tiempo de su encargado principal, así que solicité hacerme cago de él. Al parecer había otras personas interesadas en ello, y tras 1 mes parece ser que al final me lo han asignado a mí. El programa es un front-end para gdb, llamado DDD.

Ayer recibí la comunicación del mismísimo Richard M. Stallman donde me comunicaban su decisión.

I hereby appoint you as the new maintainer of ddd.

Being a package maintainer is a relationship between you personally and the GNU Project. The maintainer or maintainers are the ones who take the overall responsibility for the work done on the package.

If you recruit others to contribute to the package (and some packages have hundreds of contributors), they work under your supervision.

Para mí es todo un honor poder formar parte de la comunidad de software libre GNU. Y espero hacer un buen trabajo en lo que respecta a programa DDD. Uno de los programas que bajo mi punto de vista, más necesita el sistema operativo GNU/Linux

1 comment