¿Para qué sirve AUR?

Como ya he mencionado en el pasado, las distribuciones GNU/Linux están conectadas a un repositorio de paquetes, que es un bazar donde puedes encontrar todo tipo de programas para tu ordenador, que instalas con un comando a través de tu gestor de paquetes en la terminal, o mediante una herramienta gráfica como KDE Discover o GNOME Software.

Sin embargo, una de las características típicas de los repositorios de las distribuciones GNU/Linux es que el software que encuentras ahí tiene cierto grado de oficialidad. Los paquetes han sido probados para asegurarse de que funcionen en la versión de GNU/Linux que estés utilizando, y además se proporcionan pre-compilados para que sea tan rápido como descargar el paquete y extraer.

Como alternativa, AUR es el Arch User Repository. Es otro repositorio, pero en este caso contiene paquetes preparados por la comunidad. Cualquier persona puede contribuir con su propio paquete, y lo normal es que esos paquetes están mantenidos por personas que no formen parte de Arch, sino que sean también participantes de la comunidad. En algunos casos puede ser la misma persona que fabrica el programa, y típicamente será alguien que, en cualquier modo, al menos lo utilice.

¿Qué diferencia hay?

Los paquetes que encuentras en AUR se diferencian de los que te vas a encontrar en el repositorio central de tu distribución por al menos las siguientes diferencias.

• La principal diferencia es que en el caso de AUR, lo que te descargas es la receta, también conocida como PKGBUILD. Este es el script que se usa para fabricar un paquete desde el código fuente. El proceso es casi automático, porque puede descargar las dependencias necesarias para fabricar el paquete, y como resultado obtienes un archivo de tipo .pkg.tar.zst, que puedes instalar con Pacman. En otras palabras: mientras que del repositorio principal de Arch te descargas un paquete pre-compilado en los propios servidores de Arch, y por lo tanto, más rápido de instalar, con AUR el paquete lo compilas tú en tu máquina, usando tiempo y recursos.

• Otra es que no tiene por qué estar probado que funcione. En otras palabras: un paquete que instalas con pacman desde los repositorios centrales de Arch debería instalar y ejecutar bien, porque alguien ha probado que funcione. Sin embargo, los repositorios AUR se basan en la vigilancia continua de la comunidad. Lo normal es que un paquete se instale bien, pero a veces el programa puede cambiar y las instrucciones para fabricar el paquete pueden quedar obsoletas. Por suerte, modificar un PKGBUILD tampoco es muy dificil, así que si tienes experiencia manteniendo shell scripts, es incluso posible que puedas corregirlo con tu editor de textos tras leer las instrucciones actualizadas, y así poderlo instalar.

• Y la otra más importante, es que no son paquetes verificados. Esto es importante en temas de seguridad. Cuando instalas un paquete desde el repositorio central de Arch Linux, no sólamente está pre-compilado en los servidores de Arch. Al prepararse en un entorno especial y restringido, y al llevar firmas, es más dificil que se cuele malware en un paquete (no imposible, como aprendimos durante el drama de XZ, aunque por suerte en el caso de Arch Linux era imposible ejecutar la parte de código comprometida). Sin embargo, en el caso de AUR, las recetas las usas bajo tu propia responsabilidad.

Con esto no quiero decir que usar AUR sea malo. Al contrario, AUR es parte de lo que hace que la experiencia de usar una distribución basada en Arch sea tan buena. Hay una comunidad activa que se ocupa de proporcionar instrucciones de integración de casi cualquier paquete que se te ocurra, para que puedas instalarlo en tu sistema usando el gestor de paquetes, con las ventajas que eso aporta, en vez de tener que hacerlo a mano usando métodos que no permiten al sistema luego administrar los archivos del programa.

¿Es seguro usar AUR?

AUR es a menudo seguro de usar. Por lo general, si instalas un paquete popular desde AUR, incluso si no sabes verificar estas cosas, puedes asumir que colectivamente la comunidad está bastante pendiente de estos temas, y que hay suficientes ojos mirando que no pase nada raro.

Sin embargo, como digo, esto pasa con los paquetes populares. Existen muchos paquetes que no tienen votos, ni popularidad, y en algunos casos, ni siquiera maintainer. El maintainer es la persona que está a cargo de un paquete de AUR. Cualquier persona puede volverse maintainer, y aunque lo normal es que lo mantenga una persona que lo usa activamente (y que por eso tiene interés en que la receta funcione bien), podría ocurrir que un paquete quede huérfano (es decir, sin maintainer) y alguien se aproveche de la situación para adoptarlo y modificarlo de forma maliciosa. Esto pasó en 2018 con un paquete que instalaba Acrobat Reader para Linux y un par de paquetes más. La persona involucrada en la publicación del malware fue expulsada del sistema AUR, pero pegó un buen susto.

Lamentablemente, la interfaz web de AUR tampoco te dice si un paquete ha cambiado de maintainer hace poco, aunque en mi opinión, debería. Sí es verdad que a veces los comentarios de un paquete en la página web pueden contener información interesante. No está de más revisar antes de instalar nada y confirmar que no hay nadie dando la voz de alarma.

En cualquier caso, dado que AUR no aporta ningún tipo de garantías, dejándote a ti como responsable de lo que sea que instales, cuando te animes a usar AUR, hay un par de consejos que deberías tener en cuenta.

1. Uno es que, aunque tengas un buen frontend para instalar paquetes desde AUR (yo uso yay en este momento, por ejemplo), deberías aprender a usar el comando makepkg, por lo que pueda pasar. Todas las instalaciones de Arch Linux traen makepkg, que es el programa que sirve para convertir una receta en formato PKGBUILD a paquete compilado que puedes instalar con Pacman.
2. Otro es que leas la receta que estás a punto de ejecutar. En otras palabras, que revises el contenido del archivo PKGBUILD antes de fabricar la receta. Lo normal es que tu frontend te pregunte si quieres hacer esto. Por ejemplo, yay lo hace. No deberías saltarte este paso, y deberías inspeccionar como mínimo que no se descarguen archivos sospechosos desde otras fuentes que no sean la de la página del programa oficial. Cuantos más conocimientos tengas de shell scripting, mejor. Si sabes cómo fabricar scripts, deberías leerte el script completo y vigilar que entre los pasos de compilación del paquete o de instalación no haya algo sospechoso.