DNI electrónico español en Mageia

Actualización: para Mageia 4, véase DNI electrónico español en Mageia 4. Téngase en cuenta también que el paquete dnie-configurador de Mageia 1 y 2 está obsoleto debido al cambio en la dirección de descarga de uno de los certificados; es necesario usar la versión actualizada de Mageia 4.

Damas y caballeros, regocijaos: habemus soporte para el DNI electrónico español en Mageia.

En el siguiente artículo podréis ver qué hace falta para echarlo a andar, una pequeña recopilación de errores con los que me encontré para que no temáis si también os pasa a vosotros, y finalmente información para empaquetadores y desarrolladores sobre todo el sistema.

¡Vamos allá!

Paquetes

Antes de nada, un detalle importante: por algún extraño motivo que no alcanzo a comprender funciona mucho, pero mucho mejor en Mageia 2 que en Mageia 1. Así que quedaos con esta idea: si tienes Mageia 1 puede que tengas que intentarlo tropecientas veces antes de que una página web te reconozca usando el DNIe. Si tienes Mageia 2 todo funcionará mucho mejor (aunque puede seguir habiendo algún fallo, pero son cuestiones puntuales). Y ahora pasemos a los paquetes en sí que permitirán que funcione el DNIe.

Instrucciones de instalación:

• Si tienes habilitado el repositorio de BlogDrake: instala el paquete dnie-configurador. Éste instalará automáticamente los demás paquetes necesarios.
• Si no tienes habilitado el repositorio de BlogDrake: haz click en los enlaces de debajo e instala, por este orden, libopensc-opendnie/lib64opensc-opendnie (uno u otro según la arquitectura de tu sistema), opensc-opendnie (usa el que corresponda a la arquitectura de tu sistema) y dnie-configurador (independiente de la arquitectura; es el mismo para i586 y x86_64).

Una vez instalados los paquetes, ejecuta el programa dnie-configurador (debería crearse una entrada en el menú para él). Éste se encarga de configurar automáticamente el Firefox y Thunderbird (e implícitamente LibreOffice) del usuario que lo ejecuta para poder usar el DNIe con ellos. Ten paciencia, porque puede pasar cierto tiempo en el que el configurador esté trabajando pero en pantalla no se muestre ninguna información (a no ser, evidentemente, que hayas cancelado la configuración). No te apresures a ejecutarlo de nuevo ;) Y ten en cuenta que si lo ejecutas en una consola podrás ver información de qué va haciendo. Además, si lo ejecutas como root se configurarán el Firefox y el Thunderbird de todos los usuarios del sistema. Una vez ejecutado, si todo fue bien, ya está*. Ya podrás usar el DNIe desde Firefox y Thunderbird (y LibreOffice) ;) En cualquier caso, si tienes curiosidad por saber qué instalaste y por qué, tras los paquetes tienes una pequeña explicación.

Usuarios de GNOME (y puede que otros entornos de escritorio como XFCE): hay un bug en zenity (el programa que usa el configurador para mostrar los diálogos en GNOME y otros entornos) debido al cuál los diálogos son mucho más altos de lo que deberían y pueden llegar a impedir ver los botones de aceptar y cancelar. Si no puedes ver los botones, pulsar Intro aceptará el diálogo, y pulsar Esc lo cancelará.

*Salvo si estás en Mageia 1 que, por algún extraño motivo, a pesar de usar pcscd 1.6.6 el servicio no arranca automáticamente cuando se le necesita (pcscd supuestamente hace eso a partir de las versión 1.6.0) y tendrás que arrancarlo a mano tú mismo si lo vas a usar justo tras instalarlo, sin haber reiniciado antes el sistema. Si ya reiniciaste no hace falta ya que, aunque no arranca automáticamente cuando se le necesita, al menos sí está configurado para arrancar automáticamente en el inicio el sistema. Ciertamente, el DNIe en Mageia 1 está gafado :P

Mageia 1
Sí, ya lo dije, pero no me cansaré de repetirlo: para usar el DNIe hacedlo desde Mageia 2. Si pongo los paquetes para Mageia 1 es simplemente por si alguien con mucha paciencia quiere usarlos, pero ya estáis más que avisados de que pueden ser un dolor (y no saber por qué es más doloroso aún :P ). Por otra parte, quién sabe, igual es algún problema extraño de mi lector de tarjetas, o de mi DNIe, o de la máquina virtual de Qemu/LiveCD (según el caso; probé en ambos con idéntico resultado) y resulta que al resto del mundo os funciona bien ;)
i586

• Paquete rpm de libopensc-opendnie: libopensc3-opendnie-0.12.2-1bdk.mga1.i586.rpm
• Paquete rpm de opensc-opendnie: opensc-opendnie-0.12.2-1bdk.mga1.i586.rpm

x86_64

• Paquete rpm de lib64opensc-opendnie: lib64opensc3-opendnie-0.12.2-1bdk.mga1.x86_64.rpm
• Paquete rpm de opensc-opendnie: opensc-opendnie-0.12.2-1bdk.mga1.x86_64.rpm

noarch

• Paquete rpm de dnie-configurador: dnie-configurador-0.1-1bdk.mga1.noarch.rpm

Mageia 2
i586

• Paquete rpm de libopensc-opendnie: libopensc3-opendnie-0.12.2-1bdk.mga2.i586.rpm
• Paquete rpm de opensc-opendnie: opensc-opendnie-0.12.2-1bdk.mga2.i586.rpm

x86_64

• Paquete rpm de lib64opensc-opendnie: lib64opensc3-opendnie-0.12.2-1bdk.mga2.x86_64.rpm
• Paquete rpm de opensc-opendnie: opensc-opendnie-0.12.2-1bdk.mga2.x86_64.rpm

noarch

• Paquete rpm de dnie-configurador: dnie-configurador-0.1-1bdk.mga2.noarch.rpm

Información sobre los paquetes
«Bueno, ¿y qué es todo esto que instalé?» puedes estar preguntándote. Con suerte a continuación encontrarás la respuesta.

En GNU/Linux, para trabajar con tarjetas inteligentes, se utiliza el proyecto OpenSC. Su principal objetivo son las tarjetas con funciones criptográficas que puedan ser usadas para autenticación, cifrado de correos o firmas digitales. Vamos, como el DNI electrónico. Peeero resulta que, actualmente, OpenSC no tiene soporte "de serie" para el DNI electrónico.

Aquí es donde entra en juego el proyecto OpenDNIe, cuyo objetivo es dar soporte al DNIe utilizando OpenSC. Gracias a su trabajo podemos parchear OpenSC para que sea capaz de "hablar" con los DNI electrónicos. Es decir, que si coges el código de la versión oficial de OpenSC y le aplicas los cambios desarrollados en el proyecto OpenDNIe, lo que obtienes es un OpenSC que hace lo mismo que el OpenSC oficial y, además, también tiene soporte para el DNIe.

«¿Y no sería más lógico integrar esos cambios en OpenSC para que traiga soporte "de serie" para el DNI electrónico?» Sí, claro. Y en ello están ;) Pero por el momento, y hasta que no terminen la integración, no queda más remedio que parchear OpenSC. Y eso es precisamente lo que hace el paquete opensc-opendnie (y su biblioteca libopensc-opendnie): es simplemente una modificación del paquete opensc de Mageia 2 que, antes de compilar, aplica el parche opensc-to-opendnie-0.12.2.

Una vez instalado opensc-opendnie (y su correspondiente biblioteca) nuestro sistema ya podría entenderse con el DNI electrónico. Pero aún faltan más piezas para completar el puzzle. Aunque el sistema ya entienda el idioma en el que habla el DNI electrónico sigue sin poder hablar con él. El DNIe está en Sidney, el sistema en Los Ángeles, y aún no tienen línea de teléfono (o avión, pero ése es otro tema y una referencia a cierta serie de televisión que no viene a cuento :P ). Eso es cosa de pcsc-lite.

El objetivo del proyecto PCSC lite es desarrollar una implementación libre de la especificación PC/SC. Vamos, permitir el envío y la recepción de datos entre ordenador y tarjeta. Una vez instalado pcsc-lite nuestro sistema no sólo podría entenderse con el DNIe, sino que además tendría línea de teléfono con él.

Pero, ¡ay amigo! Tener línea telefónica sirve de poco si no sabemos usar el teléfono. Afortunadamente, aunque sean de distintas marcas, la mayoría de teléfonos funcionan de la misma manera: descuelgas, pulsas los botones que corresponden al número al que quieres llamar y listo. Con los lectores de tarjetas pasa algo parecido. Existe un protocolo, llamado CCID, que especifica cómo pueden ser usados por el sistema. El paquete ccid, que es parte del proyecto PCSC lite, ofrece un controlador que permite utilizar los lectores de tarjetas que implementen el protocolo CCID. Así pues, cuando instalemos dicho paquete nuestro sistema entenderá al DNI electrónico, tendrá línea de teléfono con él y sabrá cómo usar el aparato de teléfono para acceder a la línea telefónica y comunicarse con el DNIe (vale, si la analizamos bien la metáfora no es del todo perfecta, pero me da igual, no soy House :P ).

Podría ocurrir que nuestro lector de tarjetas no siguiese el protocolo CCID. Vamos, como si el sistema cuando fuese a usar el teléfono para hablar con la tarjeta se encontrase que en lugar de 9 botones con los números hay un único botón con un símbolo +. El sistema necesitaría que alguien le explicase cómo puede usar ese teléfono tan extraño para llamar. Es decir, necesitaría unos controladores específicos que le permitiesen usar ese lector de tarjetas. Ese caso queda fuera de la funcionalidad de los paquetes arriba expuestos; habría que ir a la página del fabricante del lector de tarjetas y ver cómo se tienen que instalar dichos controladores. Así pues, lo mejor es adquirir un lector de tarjetas compatible con CCID. Aunque en esa lista no aparece aún, por si alguien lo ve o lo tiene puedo confirmar que el lector Soyntec Nexoos 660 funciona (según parece usa el mismo chip que el MSI StarReader SMART).

«Pero un momento, echa el freno... Estuve mirando sus dependencias ¡y opensc-opendnie no depende ni de pcsc-lite ni de ccid!» Cierto es. Como ya indiqué el paquete opensc-opendnie simplemente es una modificación del paquete opensc de Mageia 2. Éste no tenía entre sus dependencias ni a pcsc-lite ni a ccid, y opensc-opendnie mantiene sus mismas dependencias. ¿Por qué no los incluyeron entre las dependencias? Pues no lo sé, pero imagino que porque, además de hablar por teléfono con la tarjeta, el sistema también puede hablar con ella por telégrafo. Existe otro proyecto, OpenCT, que implementa controladores para diversos lectores de tarjetas. No obstante, actualmente PCSC lite está más avanzado que OpencT y, aunque OpenCT es parte de OpenSC, el propio proyecto OpenSC recomienda usar PCSC lite, y dejar OpenCT únicamente para aquellos (pocos) casos en los que un lector de tarjetas funciona con OpenCT y no con PCSC lite. Y por lo que leí, aunque no recuerdo dónde :( , tener ambos instalados no es una buena idea.

«Vale, entonces, dado que el paquete opensc-opendnie no instala pcsc-lite ni ccid, ¿tengo que instalarlos yo a mano?» No hace falta si también instalas el paquete dnie-configurador, ya que por dependencias también instala todos esos paquetes. El paquete dnie-configurador contiene una pequeña herramienta que configura Firefox y Thunderbird para poder usar el DNI electrónico. Porque sí, instalando opensc-opendnie el sistema se entiende con el DNI electrónico, pero de poco sirve si no tienen nada interesante que decirse.

La configuración que hace no es más que añadir el módulo criptográfico del DNI electrónico a Firefox y Thunderbird (si hay algún perfil para el usuario que ejecuta el configurador, es decir, si Firefox o Thunderbird fueron ejecutados alguna vez por ese usuario) y, en el caso del Firefox, además añade una serie de certificados de la DGP y la FNMT para que no chille al intentar acceder a las páginas de la administración pública. Además, cuando se configura un perfil de Firefox o de Thunderbird, adicionalmente podremos usar el DNIe para firmar documentos en LibreOffice, ya que éste utiliza la configuración de los perfiles de los anteriores para ello.

Ah, y además de instalar por dependencias pcsc-lite y ccid, el paquete dnie-configurador también instala una interfaz gráfica para pinentry, ya que es necesaria a la hora de firmar algo con el DNI electrónico. Si intentásemos firmar algo en Firefox y no tuviésemos interfaz gráfica para pinentry, la firma simplemente fallaría.

Y creo que no se me olvida nada :)

Problemas con Firefox: síntomas y soluciones
Mientras preparaba los paquetes hice bastantes pruebas con el DNIe y el Firefox y me encontré con problemas y errores varios. Por si a alguien le sirven de ayuda, aquí incluyo una serie de síntomas y soluciones para dichos problemas.

• Firefox da error de certificado sin ni siquiera haberte preguntado el pin. Puede que pcscd no esté corriendo, o que no hayas metido la tarjeta en el lector.
• Firefox casca. Si lo ejecutaste en consola verías algo como «firefox: sc.c:475: sc_file_free: La declaración `sc_file_valid(file)' no se cumple.» Es un problema de lectura puntual; vuelve a abrir el Firefox e intenta de nuevo lo que estuvieses haciendo.
• Firefox dice que «El otro extremo de la conexión SSL no puede verificar su certificado. (Código de error: ssl_error_bad_cer_alert)» Otro problema de lectura puntual; cierra la sesión del DNI (la manera más rápida es cerrar el Firefox; sino hazlo desde "Editar->Preferencias->Avanzado->Cifrado->Dispositivos de seguridad") e intenta de nuevo lo que estuvieses haciendo.
• Firefox, tras dar el pin y seleccionar el certificado de firma, dice que «La operación ha fallado porque el token PKCS#11 no ha iniciado sesión. (Código de error: sec_error_token_not_logged_in)» De nuevo, problema de lectura puntual. Misma solución que el anterior.
• Firefox, tras dar el pin y seleccionar el certificado de firma, dice que «Un módulo PKCS #11 ha devuelto CKR_GENERAL_ERROR, indicando que ha sucedido un error no recuperable. (Código de error: sec_error_pkcs11_general_error).» Y otro error de lectura más, que vuelve a solucionarse como los anteriores.
• Puede ocurrir que el Firefox pida el pin, pero luego no encuentre certificados (se pueden ver los certificados del DNI en "Editar->Preferencias->Avanzado->Cifrado->Ver certificados->Sus certificados"). Debe ser algún error de lectura o algo parecido. Simplemente habría que terminar la sesión del DNI y volver a iniciarla. Si en la web de la Seguridad Social pasa eso (metes el pin pero no carga los certificados) la página que te muestra es https://sede.seg-social.gob.es/prdi00/fragments/errores/pag_no_certificado.htm
• Al intentar hacer algo en la web de la Seguridad Social pide el pin, pide que selecciones un certificado pero luego muestra una página de error diciendo «Acceso denegado. Error de comunicaciones. La validez del certificado del usuario no ha podido ser confirmada» (http://w5.seg-social.es/errPluginCRLs/erroresComunicaciones.html) posiblemente le haya dado una pájara. Cierra el navegador y vuelve a probar más tarde :P
• Te equivocaste de certificado y seleccionaste el que no era (por ejemplo, uno de la FNMT en lugar del del DNIe). Y ahora, ¿cómo cambias de certificado a usar? Porque al intentar entrar de nuevo en la página parece que sigue usando el mismo certificado ya seleccionado... Pues no lo tengo claro, la verdad :P La solución más sencilla es que cierres el Firefox y lo vuelvas a abrir :P Sí, es cutre, pero funciona :P

Y una duda que quizás se te presente: ¿se puede meter el DNI en el lector una vez arrancado el Firefox? Pues diría que sí. Al menos en unas pruebas que hice pude verificar mi DNI haciendo eso. En otra, no obstante, Firefox no pudo cargar los certificados tras iniciar sesión con el DNI. ¿Fue un fallo como otro cualquiera, o es que es más propenso a fallar si el DNI se mete una vez arrancado el Firefox? Pues no lo sé. Si alguien hace N experimentos y saca una estadística que nos lo diga :P Actualización: por lo que pude comprobar en mis propias carnes, cuando se usa Firefox 17 el DNI tiene que estar metido en el lector antes de arrancar Firefox. Meterlo una vez arrancado sólo trae dolor, llanto y desesperación (es decir, que no funciona, por si no estaba claro).

Otra actualización: en versiones más actuales (Firefox 24, concretamente) no sólo es posible meter el DNI en el lector una vez arrancado Firefox, sino que a veces es hasta necesario. En ocasiones, una página puede quedarse bloqueada en mitad de una operación (vamos, al autenticarte o firmar algo) y no reaccionar hasta que sacas el DNI del lector. Si lo vuelves a meter, dependiendo de la suerte que tengas, quizás puedas seguir haciendo lo que estabas haciendo. Aunque, otras veces, lo que te encontrarás será un error. Pero, por ejemplo, en la página para comprobar el DNI, aunque la comprobación de la autenticación me funciona a la primera, la comprobación de la firma (que usa un applet de Java) no. Al dar a Firmar texto, y tras unos diálogos, la página no hace nada y en el lector tampoco parpadean las lucecitas. Si saco el DNI me muestra un mensaje de error que dice No se han encontrado en el almacén certificados compatibles con la aplicación, pero si lo meto de nuevo y vuelvo a darle a Firmar texto, tras los diálogos de antes me pide la contraseña, que seleccione un certificado para firmar, me pregunta si permito la firma y... ¡voilá! Texto firmado (todo ello usando el OpenJDK y el plugin icedtea para Firefox; es decir, todo software libre :) ).

Además de todo esto es importante mencionar que sólo puede haber una aplicación accediendo al DNI electrónico en cada momento. No puedes iniciar sesión con el DNI electrónico en Firefox y al mismo tiempo firmar algo en LibreOffice. Creo que esta cuestión puede causar ciertos problemas con los applets de Java que utilizan el DNI electrónico para firmar (ya que tanto Firefox como el applet en sí están usando el DNI), como en el caso citado en el párrafo anterior. Pero aparte de lo ya dicho, casi no tengo experiencias en ese sentido. Lo único más que sé de los applets y las firmas es que en la web de Hacienda no fui capaz de firmar usando OpenJDK :( En ese hilo también comento los problemas que tuve para autenticarme con el DNIe en la web de Hacienda y cómo tuve que acabar pidiendo un certificado de la FNMT con el DNIe y autenticándome con dicho certificado, por si a alguien le sirve de algo.

Ah, y para terminar, una cosa que leí por ahí y que creo que merece la pena mencionar: no desconectéis el lector de tarjetas con el DNI electrónico metido dentro. Sacad antes el DNI electrónico.

Información para empaquetadores/desarrolladores
Antes de nada, aquí están los paquetes fuente. Se usaron los mismos fuentes y spec para Mageia 1 y para Mageia 2*, y a partir del paquete fuente opensc-opendnie se generan tanto opensc-opendnie como libopensc-opendnie.

*Bueno, en el spec del paquete dnie-configurador al compilarlo en Mageia 1 hay que eliminar los parámetros set-key y set-value de la llamada a desktop-file-install, pero es un cambio irrelevante.

• Paquete fuente rpm de dnie-configurador: dnie-configurador-0.1-1bdk.mga2.src.rpm
• Paquete fuente rpm de opensc-opendnie: opensc-opendnie-0.12.2-1bdk.mga2.src.rpm

Como ya indiqué en la sección de los paquetes, por algún extraño motivo en Mageia 1 funciona mucho peor (al menos, en mi experiencia). Podría pensarse que es porque los paquetes son recompilaciones del paquete fuente de Mageia 2 en Mageia 1, y no una modificación del paquete de opensc de Mageia 1, y que por tanto hay algún problema con los paquetes en los que se apoya. Pero incluso recompilando las versiones de Mageia 2 de los otros paquetes (pcsc-lite y ccid) en Mageia 1 los fallos son mucho más frecuentes que en Mageia 2. En su momento hasta modifiqué el propio paquete de Mageia 1 para aplicar los parches de OpenDNIe, y aún así fallaba. En Mageia 2, como ya digo, funciona bien la mayor parte del tiempo. No me preguntéis porque no tengo ni idea de qué puede ser ;)

Una vez dicho esto, pasemos a comentar algunas cosas sobre los paquetes en cuestión.

Paquete opensc-opendnie
Como ya indiqué, el paquete opensc-opendnie no es más que el propio paquete de opensc-0.12.2 de Mageia 2 modificado para que aplique el parche opensc-to-opendnie-0.12.2 antes de compilar el código (y un parche extra para que compile en Mageia 2 debido a un cambio en el comportamiento por defecto del enlazador, pero es un detalle menor). Aquí tenéis un diff entre el archivo spec de opensc y el archivo spec de opensc-opendnie.

Aunque hasta ahora siempre dije que sólo modifiqué el paquete para que aplicase los parches de OpenDNIe antes de compilar, eso no es del todo cierto. También tuve que jugar con el nombre del paquete y las declaraciones de dependencias y conflictos. Lógicamente, si está instalado el paquete opensc no puede estar instalado el paquete opensc-opendnie, y viceversa. No obstante, el paquete opensc-opendnie añade funcionalidad, pero hasta donde yo sé no afecta al resto del funcionamiento del proyecto. Es decir, que los paquetes que dependen de opensc pueden usar opensc-opendnie (o, insisto, eso creo).

Así pues, he aquí la situación: quiero que el paquete opensc-opendnie pueda sustituir al paquete opensc de manera que si se instala el primero se desinstale el segundo, pero que aún así se puedan seguir instalando igualmente los paquetes que dependen del segundo. Además, si se publicase una nueva release del paquete opensc el paquete opensc-opendnie no debería actualizarse a ella de manera automática, y si se instalase explícitamente debería avisar de que hay que desinstalar el paquete opensc-opendnie para poder instalar el paquete opensc.

La cosa es un poco más complicada aún si cabe, ya que, como veríais, opensc y opensc-opendnie generan, además de su propio paquete, un subpaquete para la biblioteca y un subpaquete devel, libopensc3/libopensc3-opendnie y libopensc-devel/libopensc-opendnie-devel. Ahora bien, en el repositorio de Mageia no hay ningún paquete que dependa de libopensc3 ni libopensc-devel.

Intenté usar números de serie para el paquete con la etiqueta "Serial", pero al establecer los conflictos como "Conflicts: " rpmbuild decía que «Elementos de dependencias deben iniciar con un valor alfanumérico, '_' o '/': Conflicts: opensc <S 1» (o, en inglés, «Dependency tokens must begin with alpha-numeric, '_' or '/'»). ¿Por qué números de serie? Porque podría gestionar sin problemas las actualizaciones del paquete opensc-opendnie, y al mismo tiempo el paquete siempre sería más moderno que su homónimo opensc, al menos según Maximum RPM: Taking the Red Hat Package Manager to the Limit, donde se indica que «RPM considera un paquete con número de serie como más moderno que un paquete sin número de serie».

Mi enfoque actual, con mis cuasi-nulos conocimientos de empaquetado, es que el paquete opensc-opendnie incluya un Provides: %{originalname} = %{version}-%{release} (donde originalname es opensc), un Conflicts: %{originalname} < %{version}-%{release} y un Conflicts: %{originalname} > %{version}-%{release}. No puedo hacer que el conflicto sea con opensc-0.12.2 a secas, ya que como el propio paquete opensc-opendnie provee opensc-0.12.2 (para poder reemplazar a éste de cara a sus dependencias) tendría un conflicto consigo mismo y se negaría a instalarse.

Como el paquete provee opensc las dependencias de dicho paquete se pueden instalar sin problemas junto al paquete opensc-opendnie (y, de hecho, se puede sustituir opensc por opensc-opendnie sin afectar a sus dependencias). Por otra parte, aunque provea la funcionalidad de opensc, dado que el paquete se llama opensc-opendnie entiendo que no se actualizaría automáticamente a una nueva versión del paquete opensc si se publicase. Y como se declara que causa conflictos con el paquete opensc al intentar instalar éste de manera explícita avisa del problema. Dado que la release está definida en la forma "Nbdk" (donde N es un número) cualquier paquete opensc del repositorio oficial crearía conflictos con el de BlogDrake.

Por su parte, el subpaquete libopensc3-opendnie causa conflictos tanto con opensc, como con libopensc3, como con libopensc-devel. De esta manera se evita que al instalar opensc se sustituya opensc-opendnie pero se siga usando la biblioteca libopensc3-opendnie, y lo mismo al instalar libopensc-devel.

Hasta aquí todo muy bien. El problema llega al crear un nuevo paquete opensc-opendnie con una release superior, por ejemplo, 2bdk. Si teniendo instalados los paquetes de la release 1bdk se intenta instalar opensc-opendnie-0.12.2-2bdk urpmi se queda tonto. Aparentemente entra en un bucle infinito... Curiosamente si, en cambio, se intenta instalar libopensc3-opendnie-0.12.2-2bdk, u opensc-opendnie-0.12.2-2bdk junto a libopensc3-opendnie-0.12.2-2bdk, todo funciona como se espera. Quizás estemos ante un bug de urpmi pero, sintiéndolo mucho, ahora mismo no tengo tiempo de preparar un caso de prueba básico con el que presentar el problema e informar de ello :(

Paquete dnie-configurador
El paquete dnie-configurador únicamente incluye un script para configurar Firefox y Thunderbird, así como un archivo .desktop para ejecutar fácilmente el script desde el menú. Para el script me basé en el incluido en dnie-0.1-2bdk2010.1.i586.rpm, aunque con más gestión de errores, un informe de configuración más extenso, un sistema de diálogos extra, algún certificado más, refactorizaciones... Pero vamos, que sigue siendo un configurador muy simple y mejorable, así que si alguien quiere, ya sabe ;) Eso sí, que tenga en cuenta que era mi primer programa "serio" en Bash, así que que no se asuste mucho de lo que pueda ver :P Al menos intenté documentarlo todo bien ;)

Además de eso, merece la pena mencionar que el paquete dnie-configurador instala tanto kdialog, como zenity, como Xdialog, cuando únicamente necesita que esté instalado uno para mostrar diálogos. Este tema se discutió en ¿Cómo crear un paquete que dependa bien del paquete X, bien del paquete Y? Si a alguien le apetece solucionarlo, adelante ;)

Paquetes devel
Finalmente, y por si alguien los necesitase (que no creo, pero por ponerlo todo), aquí están los paquetes devel de libopensc-opendnie. Si estás leyendo esto y no sabes si necesitas los paquetes devel, ya te lo digo yo: no los necesitas :P Estos paquetes únicamente se necesitan se vas a desarrollar una aplicación que use opensc-opendnie:

Mageia 1
i586

• Paquete rpm de libopensc-opendnie-devel: libopensc-opendnie-devel-0.12.2-1bdk.mga1.i586.rpm

x86_64

• Paquete rpm de lib64opensc-opendnie-devel: lib64opensc-opendnie-devel-0.12.2-1bdk.mga1.x86_64.rpm

Mageia 2
i586

• Paquete rpm de libopensc-opendnie-devel: libopensc-opendnie-devel-0.12.2-1bdk.mga2.i586.rpm

x86_64

• Paquete rpm de lib64opensc-opendnie-devel: lib64opensc-opendnie-devel-0.12.2-1bdk.mga2.x86_64.rpm

¡Y aquí, al fin, se acaba un nuevo ladrillazo producto de la factoría Kalvy!