We Missed The Point Of The Arch User Repository

La vidéo analyse la récente attaque malware sur l’AUR, les débats sur son avenir, et insiste sur la nécessité de comprendre que les PKGBUILD sont des scripts bash exécutés sans revue systématique, tout en saluant les premières mesures de durcissement (adoption avec revue, nett...

Voir la source

SYNTHÈSE STRUCTURÉE

Contexte de l’attaque et état actuel de l’AUR

L’intervenant rappelle que l’AUR a subi trois attaques malware, mais que la nouveauté réside dans l’échelle : « des milliers de paquets trouvés d’un coup ». Il souligne que les mises à jour et adoptions de paquets ont été gelées, plaçant l’AUR en mode lecture seule. Il déplore le manque de communication : « si vous allez sur le site de l’AUR, il n’y a aucune indication que les mises à jour sont gelées, pas de bannière, pas d’avertissement ». Cela crée une confusion chez les utilisateurs qui ne suivent pas les listes de diffusion ou Reddit.

Le fonctionnement réel de l’AUR : des scripts bash, pas des paquets vérifiés

L’intervenant explique qu’un PKGBUILD est « juste un script bash » avec des variables et des fonctions nommées (pkgver(), build(), package()). Il compare l’utilisation d’un helper AUR à un curl | bash : « vous utilisez un outil pour télécharger un script, beaucoup de gens ne lisent pas ce script et l’exécutent automatiquement ». Il précise que les commentaires sur la page AUR servent de « système de revue informel », mais que la plupart des paquets n’ont aucun commentaire, surtout les plus obscurs.

La position de l’intervenant : ne pas changer la conception de l’AUR

Il s’oppose à l’idée que l’AUR devrait être modifié en profondeur. Pour lui, la simplicité est une force : « cette simplicité permet à l’AUR d’être si puissant entre de bonnes mains ». Il critique néanmoins l’argument « ce n’est pas la faute de l’AUR » avec une métaphore : « si je conçois une voiture dont les freins ne marchent pas au-delà de 60 km/h, c’est ma faute, parce que j’ai conçu des freins qui ne marchent pas ». Il appelle donc à une prise de responsabilité, sans pour autant sacrifier le modèle.

Les helpers AUR : des outils à utiliser avec prudence

Il distingue pacman pour le système et paru pour l’AUR, mais insiste sur le fait que ces helpers « automatisent juste les étapes manuelles » : télécharger le PKGBUILD, lancer makepkg, installer. Il critique sévèrement les interfaces graphiques comme pamac qui mélangent Flatpak, Snap, AUR et dépôts officiels sans distinction : « ça peut devenir très dangereux très vite ». Il recommande de ne pas les utiliser pour les débutants, sauf à vérifier chaque PKGBUILD dans un navigateur.

Comment vérifier un PKGBUILD avant installation

L’intervenant donne des conseils concrets pour repérer un paquet malveillant :

  • Lire le PKGBUILD et vérifier que les fonctions source, checksum, prepare, build et package suivent les instructions upstream.
  • Se méfier des dépendances inattendues : « si une dépendance n’est pas requise, c’est peut-être un payload malware ».
  • Surveiller les chaînes encodées en base64 : « il n’y a presque jamais de raison qu’un paquet contienne du base64 ».
  • Vérifier les fichiers .install qui exécutent des commandes après installation, mise à jour ou suppression : « ce sont aussi des scripts bash, ils peuvent faire autant de dégâts ».

La confiance : entre mainteneurs et système

Il nuance la question de la confiance : « si vous faites confiance à vos mainteneurs de dépôt, pourquoi pas à un mainteneur AUR ? » Mais il avertit que même un mainteneur de confiance peut être compromis. Il conclut que « laisser la vérification uniquement aux utilisateurs n’est pas la bonne solution », car l’internet a changé : « l’AUR est un vestige d’une époque où l’on faisait confiance aux inconnus, mais cette époque est révolue ».

Les premières mesures de durcissement annoncées

En fin de vidéo, l’intervenant rapporte que l’accès SSH et Git push a été réactivé, mais que l’adoption de paquets orphelins nécessite désormais une demande approuvée par un mainteneur. Les comptes non vérifiés reçoivent un avertissement après 7 jours et sont supprimés après 14 jours. Il salue cette décision : « c’est la chose qui devait arriver, ça va économiser dix fois plus de travail sur l’année ».

CONCEPTS CLÉS

  • PKGBUILD : script bash décrivant comment télécharger, compiler et installer un paquet. Il peut contenir n’importe quelle commande, y compris destructrice.
  • Helper AUR (paru, yay) : outil automatisant le téléchargement et l’exécution des PKGBUILD, mais sans ajouter de sécurité supplémentaire.
  • Paquet orphelin : paquet dont le mainteneur a abandonné la maintenance, pouvant être adopté par un autre utilisateur.
  • Fichier .install : script exécuté à différentes étapes de la vie d’un paquet (installation, mise à jour, suppression), tout aussi dangereux qu’un PKGBUILD.
  • Chaotic-AUR : dépôt communautaire filtrant et compilant des paquets AUR, avec un système de mainteneurs de confiance.

CONCLUSION

L’AUR est un outil puissant mais intrinsèquement risqué, car il repose sur des scripts non vérifiés. L’intervenant appelle à un équilibre : conserver la simplicité du modèle tout en ajoutant des garde-fous (revue des adoptions, vérification des comptes, éducation des utilisateurs). Il conclut que « laisser les utilisateurs seuls face à la vérification n’est pas viable », mais que « changer la conception de l’AUR serait perdre sa force ». Les premières mesures annoncées vont dans le bon sens, mais le chemin est long pour restaurer la confiance.

Du même canal

Tout voir