Arch Linux

Dernières nouvelles

Nettoyage des anciens dépôts

8 mars 2025

Il y a environ deux ans, nous[NdT: développeurs et utilisateurs de confiance d’Arch] avons fusionné le dépôt [community] dans [extra] dans le cadre de la migration git. Afin de ne pas perturber les configurations utilisateur, nous avons conservé ces dépôts dans un état inutilisé et vide. Nous allons nettoyer ces anciens dépôts le 01/03/2025.

Sur les systèmes où /etc/pacman.conf fait toujours référence à l’ancien dépôt [community], pacman -Sy renverra une erreur lors de la tentative de synchronisation des métadonnées du dépôt.

Les dépôts obsolètes suivants seront supprimés : [community], [community-testing], [testing], [testing-debug], [staging], [staging-debug].

Veuillez vous assurer de supprimer toute utilisation des dépôts susmentionnés de votre /etc/pacman.conf (pour lequel un .pacnew a été fourni avec pacman>=6.0.2-7) !

Article original (en)

Glibc 2.41 corrompt l’installation de Discord

3 février 2025

Nous[NdT: mainteneurs d’Arch] prévoyons de fournir glibc et ses amis vers la version stable plus tard dans la journée, le 3 février. Après l’installation de la mise à jour, le client Discord affichera un avertissement rouge indiquant que l’installation est corrompue.

Ce problème a été résolu dans la version canary de Discord. Si vous comptez sur la connectivité audio, veuillez utiliser la version canary, vous connecter via un navigateur ou la version flatpak jusqu’à ce que le correctif soit disponible dans la version stable de Discord.

Il n’y a eu aucun rapport indiquant que la connectivité de chat (écrite) est affectée.

Article original (en)

Version critique de sécurité rsync 3.4.0

21 janvier 2025

Nous[NdT: mainteneurs d’Arch] souhaitons attirer l’attention sur la version de sécurité rsync 3.4.0-1 décrite dans notre avis ASA-202501-1.

Un attaquant n’a besoin que d’un accès en lecture anonyme à un serveur rsync vulnérable, tel qu’un miroir public, pour exécuter du code arbitraire sur la machine sur laquelle le serveur s’exécute. De plus, les attaquants peuvent prendre le contrôle d’un serveur affecté et lire/écrire des fichiers arbitraires de n’importe quel client connecté. Des données sensibles peuvent être extraites, telles que les clés OpenPGP et SSH, et du code malveillant peut être exécuté en écrasant des fichiers tels que ~/.bashrc ou ~/.popt.

Nous conseillons vivement à toute personne exécutant un démon ou un client rsync antérieur à la version 3.4.0-1 de mettre à niveau et de redémarrer immédiatement ses systèmes. Comme les miroirs Arch Linux sont principalement synchronisés à l’aide de rsync, nous conseillons vivement à tout administrateur de miroir d’agir immédiatement, même si les fichiers de package hébergés sont eux-mêmes signés de manière cryptographique.

Tous les serveurs d’infrastructure et les miroirs maintenus par Arch Linux ont déjà été mis à jour.

Article original (en)

Intervention manuelle pour pacman 7.0.0 et les dépôts locaux requise

15 septembre 2024

Avec la sortie de la version 7.0.0, pacman a ajouté la prise en charge du téléchargement de paquets en tant qu’utilisateur distinct avec des privilèges restreints.

Cependant, pour les utilisateurs disposant de dépôts locaux, cela peut impliquer que l’utilisateur de téléchargement n’a pas accès aux fichiers en question, ce qui peut être résolu en attribuant les fichiers et le dossier au groupe alpm et en s’assurant que le bit exécutable (+x) est défini sur les dossiers en question.

$ chown :alpm -R /path/to/local/repo

N’oubliez pas de fusionner les fichiers .pacnew pour appliquer la nouvelle valeur par défaut.

Pacman a également introduit une modification pour améliorer la stabilité de la somme de contrôle pour les dépôts git qui utilisent des fichiers .gitattributes. Cela peut nécessiter une modification ponctuelle de la somme de contrôle pour les PKGBUILDs qui utilisent des sources git.

Article original (en)

Le service sshd doit être redémarré après la mise à niveau vers openssh-9.8p1

2 juillet 2024

Après la mise à niveau vers openssh-9.8p1, le démon SSH existant ne pourra pas accepter de nouvelles connexions (voir https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/issues/5).

Lors de la mise à niveau d’hôtes distants, assurez-vous de redémarrer le service sshd à l’aide de systemctl try-restart sshd juste après la mise à niveau.

Nous[NdT: Développeurs et Mainteneurs d’Arch Linux] évaluons la possibilité d’appliquer automatiquement un redémarrage du service sshd lors de la mise à niveau dans une future version du paquet openssh-9.8p1.

Article original (en)

Nouvelles plus anciennes

2024-04-15

Résultats de l’élection 2024 du leader d’Arch Linux

2024-04-09

Augmentation de la valeur par défaut de vm.max_map_count

2024-03-30

Le paquet xz contient une porte dérobée

2024-03-21

Migration du hook mkinitcpio et early microcode

2024-01-11

Faire de dbus-broker notre démon D-Bus par défaut

2023-12-04

Migration du Bugtracker vers GitLab terminée

2023-11-03

Les modifications à venir dans les paquets JDK / JRE 21 peuvent nécessiter une intervention manuelle

2023-09-23

Modifications apportées à l’algorithme de hachage de mot de passe par défaut et aux paramètres umask

2023-08-20

la mise à jour de ansible-core >= 2.15.3-1 peut nécessiter une intervention manuelle

2023-08-17

La mise à jour de budgie-desktop >= 10.7.2-6 nécessite une intervention manuelle