Almería bid for hosting GUADEC in 2018

Well, «Alea iacta est». The deadline for biding to host GUADEC 2018 closed 4th Jun. And we proposed Almería.

GUADEC is the annual developers conference in the European zone, but with common attendants from Asia and North-South America, of the GNOME Project. This is another step to promote Almería as an international technology place and to estimulate new local techies, approaching students and proffesionals to world-class development communities and to the ethos and practice of opensource development. In the age of a «Github portfolio» as a CV resume for developers, the practice in opensource development it’s probably the best to train new programmers, to enhance their employability, and the learning of development practices along veteran programmers and mature communities. And it’s important to show how opensource software is a key component for our digitally connected society.

Again our legal instrument, absolutely key to these activities, is the UNIA CS students association at the University of Almería. The same association I helped fund in 1993 lives a new golden age thanks to a new group of entusiast members. Their support and collaboration made possible to host PyConES 2016, which, as far as we know, has been the biggest software development conference never made in our city. This conference has been a moral milestone for us and now we feel we can, at least, be hosts of other world-class conferences with the appropiate quality. And another key component of these proposals is the current university campus endownment and the support of the present university gobernm team to which we are grateful for their help and support. This is another step to increase the projection of the University of Almería as an international knowledge hub.

Finally I want to express my hope to do a significative contribution to the GNOME project, which I’m related to for more than a decade. Hopefully for 2018 I would have updated my pending GNOME packages in Fedora 🙈

So, here it is, the Almería candidacy to host GUADEC 2018.

Syndicated 2017-06-05 22:00:00 from Ismael Olea

Sobre OSL-UNIA

Por puro descuido no he hablado aqui del trabajo que estamos haciendo en la Oficina de Software Libre de UNIA para la Universidad de Almería. En parte es otra de mis bravuconadas burras, otro intento de forzar la máquina social con aspiraciones de progreso. Por otro creo realmente que es una actividad interesante, otro paso para contribuir a la modernización de la Universidad de Almería y la expansión de conocimientos y aptitudes para los estudiantes de informática y otros estudios tecnológicos en esta universidad. También creemos que nuestra aproximación es relativamente novedosa, aunque hay mucho más que podría hacerse.

En la práctica las actividades que estamos llevando a cabo consisten en:

• prácticas de empresa curriculares
• congresos

y en cuanto a congresos, llevamos una racha magnífica:

• organizado el congreso nacional PyConES 2016
• organizando el congreso internacional Akademy 2017
• organizando el congreso nacional GeoCamp 2017
• postulación para el congreso internacional GUADEC 2018

y hay algún otro más en consideración.

En ningún caso nada de esto podría ser realidad sin el compromiso de la asociación UNIA y el apoyo de la propia Universidad de Almería.

Otra líneas de trabajo que debemos desarollar son:

• cursos y talleres de tecnologías opensource;
• promover la participación de estudiantes en convocatorias como Google Summer of Code; se da la buena fortuna de que en Almería hay dos proyectos software que participan como anfitriones: P2PSP y MRPT;
• promover la participación en concursos universitarios de programación como el certamen de proyectos libres de la UGR y el concurso universitario de software libre;
• promover que prácticas de asignaturas, proyectos de fin de grado y de doctorado se realicen como proyectos opensource o, aún mejor, en comunidades de desarrollo ya existentes.

Si tenéis interés en saber más o participar dirigíos por favor a nuestro subforo de discusión.

En fin, estamos trabajando en ello.

Syndicated 2017-04-16 22:00:00 from Ismael Olea

@firma ahora es AutoFirma

Esta nota es sólo de interés para españoles interesados (necesitados) en relacionarse con la administración pública española. En realidad apenas es un recordatorio de que, hasta donde he comprobado, la anteriormente conocida como cliente @Firma (o Afirma) en sus últimas versiones se denomina AutoFirma.

La respuesta a la consulta al Observatorio eAdmon tampoco me ha sido clara.

No queda nada claro en ninguna de las referencias que he encontrado, pero lo que me ha dado luz en el asunto es repasar el código fuente de AutoFirma.

Repaso de mi búsqueda:

• el cliente hasta ahora comúnmente usado se llama @Firma
• y se supone que el sitio en el que poder colaborar en el desarollo o donde al menos se puede descargar el código fuente de @Firma es en Github.
• sin embargo en el Portal de administración electrónica explican que @Firma está descartado en favor de AutoFirma
• ah, y ojo que el enlace para la descarga de la versión Linux es realmente a un paquete .deb… #OjOCuidado
• pero al revisar más en detalle el mencionado repositorio Github aparecen referencias que podrían significar que la base de código es la misma para @Firma que para AutoFirma.
• de hecho, repasando en en la página de @Firma en la web del CTT parecen usarse indistintamente las referencias a @Firma y a Autofirma aunque también hay un enlace claramente a un fichero con el código fuente de AutoFirma 1.5 y con referencia explícita a ser publicado con las licencias EUPL y GPL (aunque en esa página no especifica las versiones).
• pero repasando el código fuente sí aparecen cabeceras con información precisa: GPLv2+ y EUPL v1.1+

Conclusión: vamos, que casi seguro que sí, que lo que antes se llamaba @Firma (o afirma según el caso) ahora se llamaría oficialmente AutoFirma aunque el repositorio de desarrollo sigue siendo el mismo.

Dicho todo esto por si a alguien le es útil esta info cuando esté dando tumbos desde los buscadores. Que ojalá les sirva.

Syndicated 2017-01-30 23:00:00 from Ismael Olea

«¡Brindis por Ceres!»

Parece que fue ayer cuando la FMNT-RCM solicitó la inclusión de su certificado raiz en el sistema de distribución de certificados raiz de CA CA/Browser Forum de su oficial autoridad de certificación (CA en inglés) en España CERES. Bueno, en realidad no fue ayer, fue el 26 de mayo de 2008:

pero lo que sí fue ayer 25 de enero de 2017, es la resolución exitosa del procedimiento:

Sólo ha tomado 3167 días para una de las instuciones más importantes de España y uno de los proyectos de migración a la economía digital más importantes del país que ha sido la obligada, y convengo que necesaria, adopción de las prácticas de comunicaciones digitales seguras al menos en la relación con las administraciones del estado. Pero para el usuario la experencia ha sido con frecuencia frustrante y el que más y el que menos hemos padecido problemas: desde la no inclusión de serie en el software que usamos del certificado raiz a las endiabladas configuraciones de los servicios de cada administración que con frecuencia hacían incompatible una configuración de tu navegador entre ellas. Y todo ello sin contar con la peor experiencia aún que ha sido la de la adopción del DNIe. Personalmente hace tiempo que renuncié a usar el DNIe.

¿Tan difícil era hacerlo antes? Estoy convencido de que se trata de un proceso muy riguroso pero, diablos, estamos hablando de la Real Casa de la Moneda, no de cualquier departamento escondido. Estamos hablando del certificado raiz que, en teoría, debería usar la Agencia Tributaria, que podemos concluir que como recaudador tiene las más imperiosas necesidades en mantener el mejor, más accesible y económico portal electrónico con el ciudadano aunque sólo sea para el mayor beneficio de las arcas del estado. Tanto es así que para ser más operativo la Agencia Tributaria a partir de cierto momento adoptó los certificados emitidos por Camerfirma, que si bien son reconocidos por el estado son gestionados por el Consejo Superior de Cámaras de Comercio que entiendo es una entidad semi privada.

Por muy prestigiosa y loable entiendo que Camerfirma no es una organización completamente estatal y en mi opinión, aparte de la apreciación estética por la incongruencia, es el epítome de los problemas del desarrollo e implantación de la administración electrónica en España, a pesar de los recursos aportados y el esfuerzo bienintencionado de los funcionarios que han puesto todo su corazón en un avance tan importante.

Aunque tampoco todo el monte es orégano, como puede apreciarse en el certifcado usado en la Aplicación Web Prestadores de Servicios de Certificación:

En fin, bueno es si bien acaba, que 3167 días no son nada.

Las comparaciones son odiosas

Y bueno, sí yo también, como diría República Gorila sí que estoy un poquito lleno de odio y sí, podemos intentar comparar la duración de diferentes procedimientos de admisión a través del servicio Bugzilla de Mozilla:

Y por brevedad sólo elegiremos algunas firmas reconocidas oficialmente en España:

Camerfirma

• Entrada 562395
• registro: 2010-04-28
• resolución: 2010-12-02
• duración: 219 días

Agencia de Tecnología y Certificación Electrónica

• Entrada 653761
• registro: 2011-04-29
• resolución: 2011-07-31
• duración: 94 días

Consorci AOC (CAtCert)

• Entrada 707995
• registro: 2011-12-06
• resolución: 2012-01-17
• duración: 43 días

EDICOM

• Entrada 550521
• registro: 2010-03-05
• resolución: 2010-03-29
• duración: 130 días

En fin. La lista no es exhaustiva aunque me ha parecido comprobar que hay varias AC reconocidas que o no han pasado por el proceso o sencillamente siquiera lo han solicitado. En cualquier caso felicitamos al campeón de nuestra somera investigación, el equipo de CATCert que ha sido capaz de resolver en 43 días lo que a nuestra referente FNMT ha tomado, insistimos, 3167 días.

Otros asuntos en el tintero

Me quedo sin más tiempo para extenderme como quisiera verificando el estado de las siguientes cuestiones pendientes:

• ¿Está reconfigurado por fin el servicio de renovación de los certificados FNMT para que pueda usar, por ejemplo, las versiones recientes de navegadores (observemos que la primera versión de Firefox que incorpora de serie el certificado es la 53.0a). Personalmente hace unos meses me encontré con la imposibilidad de poder renovar mi certificado usando una configuración que desactive cosas como el inseguro protocolo SSL3, práctica habitual en cualquier navegador moderno.
• El servicio OCSP de Ceres, ¿está por fin públicamente accesible sin pagos?

Convocatoria

Pero alegremos los corazones. Desde mi modesta tribuna convoco a todos los españoles a celebrar este pequeño paso para la humanidad pero un paso de gigante para Ceres-FMNT brindando por tan feliz suceso:

PS: Sergio de los Santos parece que profundizó mucho más en los progresos técnicos del proceso de aprobación en la increíble historia de Firefox y el certificado raíz de la FNMT.

Syndicated 2017-01-25 23:00:00 from Ismael Olea

Creando un servicio personal de OpenVPN

He decidido, por fin, crear mi propio servicio VPN. Los motivos principales son poder asegurar navegación privada y cercionarme que uso un servicio de confianza 100% auditado… por mi.

Requisitos

• servicio OpenVPN
• usando docker
• servidor Centos 7
• reutilizando alguna configuración existente
• pero sin reutilizar imágenes publicadas en el Docker Hub, por celo en la seguridad
• poder conectar desde máquinas Linux y teléfonos Android

La configuración elegida es una creada por Kyle Manna: https://github.com/kylemanna/docker-openvpn/ ¡Gracias Kyle!

Procedimiento de instalación y configuración del servidor

En este caso usamos CentOS 7, pero como no está disponible docker-compose he tenido que retro-portarlo y lo tenéis disponible en un repositorio específico.

Preparación:

  cd /etc/yum.repos.d ; wget https://copr.fedorainfracloud.org/coprs/olea/docker-compose/repo/epel-7/olea-docker-compose-epel-7.repo
yum install -y docker docker-compose
yum install -y docker-lvm-plugin.x86_64 docker-latest.x86_64
yum upgrade -y
groupadd docker
usermod -G docker -a USUARIO
echo "VG=sys" > /etc/sysconfig/docker-storage-setup
docker-storage-setup
systemctl enable docker
systemctl start docker

Si docker ha podido arrancar entonces probablemente está listo para empezar a trabajar.

Obviamente también hay que configurar el DNS del servicio VPN.MISERVIDOR.COM en el servidor correspondiente.

Entrando en materia:

  mkdir servicio-VPN.MISERVIDOR.COM
cd servicio-VPN.MISERVIDOR.COM
git clone https://github.com/kylemanna/docker-openvpn
cat <<EOF > docker-compose.yml
version: '2'
services:
    openvpn:
        build:
            context: docker-openvpn/
        cap_add:
            - NET_ADMIN
        image: Mi-ID/openvpn
        ports:
            - "1194:1194/udp"
        restart: always
        volumes:
            - ./openvpn/conf:/etc/openvpn
EOF

Y continuando con las instrucciones indicadas:

• construimos localmente la imagen docker desde cero de una sola vez:

  docker-compose run --rm openvpn ovpn_genconfig -u udp://VPN.MISERVIDOR.COM

• iniciamos la AC local propia (se nos pedirá la contraseña de la clave privada):

  docker-compose run --rm openvpn ovpn_initpki

• finalmente lanzamos el contenedor:

  docker-compose up -d openvpn

Procedimiento de altas de usuarios

• Alta del usuario:

  docker-compose run --rm openvpn easyrsa build-client-full USUARIO nopass

• generación de la configuración local de OpenVPN para el mismo usuario:

  docker-compose run --rm openvpn ovpn_getclient USUARIO > USUARIO.ovpn

• Este fichero lo copiaremos a nuestra máquina porque es el que nos habilitará el acceso VPN.

Problema importando configuraciones de OpenVPN y NetworkManager

Personalmente me he encontrado el problema varias veces de que el GUI de configuración de NetworkManager no es capaz de importar los certificados criptográficos al configurar una conexión VPN importando ficheros ovpn. Tras investigarlo varias veces he concluido que se debe a un bug documentado que en mi caso no está resuelto en NetworkManager-openvpn-gnome-1.0.8-2.fc23 pero sí en NetworkManager-openvpn-gnome-1.2.4-2.fc24.

Si aún os encontráis con ese problema habría dos alternativas: o actualizar a una versión reciente de NM o conectarse manualmente desde el CLI:

  sudo /usr/sbin/openvpn --config USUARIO.ovpn

Syndicated 2016-12-21 23:00:00 from Ismael Olea