Arch Linux signe ses paquets !

Posté par  . Édité par Florent Zara. Modéré par Nÿco. Licence CC By‑SA.
Étiquettes : aucune
24
5
juin
2012
Arch Linux

Le reproche souvent fait à Arch Linux était l’absence de vérification de signature de ses paquets. Eh bien, quelques mois après le dixième anniversaire de cette distribution, c’est réglé.

NdM : merci à Arthur Accroc pour son journal.

Cela fait un certain temps que c’était « sur le feu », avec des discussions entre les développeurs, la mise au point de la solution retenue, de la chaîne de signatures et la signature des paquets des dépôts.

Si vous avez déjà une Arch Linux, comme d’habitude elle ne modifie pas les fichiers de configuration à l’insu de l’administrateur ; ce sera donc à vous de reprendre dans votre fichier de configuration /etc/pacman.conf les modifications de la nouvelle version (enregistrée sous le nom pacman.conf.pacnew ; meld` est votre ami) pour que cette fonctionnalité soit activée.

Logiquement, si vous installez depuis la « core image » actuelle, ce devrait être le cas aussi, mais si vous installez depuis la « netinstall image », la vérification des paquets sera peut-être activée directement…

Aller plus loin

  • # elle ne modifie pas les fichiers de configuration à l’insu de l’administrateur

    Posté par  . Évalué à 5.

    elle ne modifie pas les fichiers de configuration à l’insu de l’administrateur

    C'est vrai ça ? ça doit être très lourd de maintenir une Arch Linux en état de fonctionnement au fil des mises à jour.

    Sur Debian, et probablement d'autres, ça fonctionne de la façon suivante:

    • Si le fichier de config n'a pas été modifié par l'admin, il est remplacé par la nouvelle version
    • Sinon, le système laisse le choix à l'admin (remplacer, garder la version actuelle, comparer, etc)

    Du coup je laisse la distribution s'occuper des fichiers de config dont je ne m'occupe pas moi même (95% des fichiers dans /etc), et pour le reste la distrib me prévient.

    • [^] # Re: elle ne modifie pas les fichiers de configuration à l’insu de l’administrateur

      Posté par  (site web personnel) . Évalué à 3.

      C'est pas très compliqué, il suffit de suivre:
      http://www.archlinux.org/news/

      Sinon, il se passe la meme chose avec Arch, il y'a un fichier .pacnew en cas de mise à jour à faire…

    • [^] # Re: elle ne modifie pas les fichiers de configuration à l’insu de l’administrateur

      Posté par  . Évalué à 2. Dernière modification le 05 juin 2012 à 15:52.

      Les nouvelles versions des fichiers de configuration sont installés mais en ajoutant l'extension .pacnew pour ne pas écraser la configuration existante. Après c'est à l'administrateur de la machine de mettre à jour ou non le fichier existant.

      Édition : grillé !

    • [^] # Re: elle ne modifie pas les fichiers de configuration à l’insu de l’administrateur

      Posté par  . Évalué à 2. Dernière modification le 05 juin 2012 à 15:54.

      Lors de la mise à jour, pacman prévient qu'il y a un nouveau fichier de configuration et demande à l'utilisateur de manuellement fusionner les fichiers.

      C'est un peu fastidieux parfois — bien qu'au final les mises à jour des fichiers de configuration soient rares — mais cela permet de vérifier ses fichiers.

      Pour ma part, je crée un patch avec la commande diff, regarde les modifications (en gardant les paramètres personnalisés) et applique le patch, c'est très rapide.

    • [^] # Re: elle ne modifie pas les fichiers de configuration à l’insu de l’administrateur

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      C'est vrai ça ? ça doit être très lourd de maintenir une Arch Linux en état de fonctionnement au fil des mises à jour.

      Pas tant que ça non. À chaque upgrade il convient de consulter le log des paquets installés et mis à jour. Lorsqu'un fichier de configuration est mis à jour, pacman te prévient, à toi ensuite d'aller faire un diff pour reporter les changements (mineurs la plupart du temps).

      Lorsqu'une modification est majeure, il y a souvent une news en rapport sur la page d'accueil archlinux.org.

      Et si comme tout bon utilisateur barbu de distrib en rolling release tu tiens à conserver un système up-to-date, en sachant exactement ce qui est installé et comment ça marche, alors une mise à niveau par semaine ne te prendra ordinairement que 5 petites minutes maximum…

    • [^] # Re: lourd à maintenir

      Posté par  (site web personnel) . Évalué à 4.

      Je viens juste de découvrir la gestion courante des fichiers de configuration. (j’avais fait mon installation sur le pouce avant un départ à l’étranger, donc je ne me suis que peu pris le temps d’éplucher la documentation non liée à l’installation elle-même)

      N’ayant donc touché à rien depuis 4 mois, je me suis donc retrouvé avec le total énorme de… 4 fichiers à mettre à jour manuellement :
      — /etc/locale.gen pour une poignée de localisations ajoutées
      — /etc/mkinitcpio.conf pour quelques commentaires mis à jour et un ajout mineur (pour ma configuration, même si ça semble important pour d’autres)
      — /etc/pacman.d/mirrorlist pour de nombreuses modifications au niveau des serveurs disponibles (c’est le seul que je regrette de ne pas avoir mis à jour plus tôt, d’autant que ça m’a permis de nettoyer une petite bêtise que j’avais commise à l’installation)
      — /etc/rc.conf (le fichier de configuration principal) pour quelques commentaires changés et de légères modifications de la configuration par défaut

      Donc, concrètement, c’est pas si horrible que ça. ;-)
      (je suppose qu’il doit donc aussi y avoir une gestion comme sous Debian)

    • [^] # Re: elle ne modifie pas les fichiers de configuration à l’insu de l’administrateur

      Posté par  . Évalué à 8. Dernière modification le 05 juin 2012 à 16:58.

      man pacman 

      Handling Config Files

Pacman uses the same logic as rpm to determine action against files that are designated to be backed up. During an upgrade, 3 md5 hashes are used for each backup file to determine the required action: one for the original file installed, one for the new file that’s about to be installed, and one for the actual file existing on the filesystem. After comparing these 3 hashes, the follow scenarios can result:

original=X, current=X, new=X
All three files are the same, so overwrites are not an issue. Install the new file.

original=X, current=X, new=Y
The current file is the same as the original but the new one differs. Since the user did not ever modify the file, and the new one may contain improvements or bugfixes, install the new file.

original=X, current=Y, new=X
Both package versions contain the exact same file, but the one on the filesystem has been modified. Leave the current file in place.

original=X, current=Y, new=Y
The new file is identical to the current file. Install the new file.

original=X, current=Y, new=Z
All three files are different, so install the new file with a .pacnew extension and warn the user. The user must then manually merge any necessary changes into the original file.

      • [^] # Rectification

        Posté par  . Évalué à 2.

        original=X, current=X, new=Y
        The current file is the same as the original but the new one differs. Since the user did not ever modify the file, and the new one may contain improvements or bugfixes, install the new file.

        Très bonne remarque de quelqu’un qui ne lit pas les man en diagonale (et qui laisse peut-être des fichiers de configuration non modifiés…).

        Donc, si on fait une installation fraîche, on doit logiquement se retrouver avec la vérification de la signature des paquets activée. Tant mieux, mais dans ce cas, on a intérêt à accepter les clés maitresses !

        Enfin pour être sûr du comportement exact, il faudrait prendre le temps d’essayer une installation…

        Quand j’ai écrit mon journal, j’ai privilégié la fraîcheur à la qualité (c’est pour ça que j’avais juste posté un journal plutôt que de proposer une dépêche), mais j’ai essayé de mettre le conditionnel ou « peut-être » pour les choses dont j’étais le moins sûr.

        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

        • [^] # Re: Rectification

          Posté par  . Évalué à 1.

          " j’ai privilégié la fraîcheur à la qualité "

          comme la plupart des sites de news, et c'est pour ca que les sites de news, c'est souvent de la **** style awesome sensational new you-must-get-that

          désolé :)

        • [^] # Re: Rectification

          Posté par  . Évalué à 1.

          Donc, si on fait une installation fraîche, on doit logiquement se retrouver avec la vérification de la signature des paquets activée. Tant mieux, mais dans ce cas, on a intérêt à accepter les clés maitresses !

          Non, parce que, malheureusement, la configuration par défaut est SigLevel = Never.

          • [^] # Re: Rectification

            Posté par  . Évalué à 1.

            t'as pas tout suivit toi :Þ
            C’est justement l'objet de la dépêhe, le passage de Never à PackageRequired par défaut.

            Mais bon, je suis d'accord, c'est très mal expliqué dans la dépêche.

            • [^] # Re: Rectification

              Posté par  . Évalué à 2. Dernière modification le 06 juin 2012 à 07:24.

              C’est justement l'objet de la dépêhe, le passage de Never à PackageRequired par défaut.

              Mais bon, je suis d'accord, c'est très mal expliqué dans la dépêche.

              Vu que les utilisateurs d’Arch allaient forcément être au courant, j’ai essayé de faire quelque chose de compréhensible pour les autres (et comme je l’ai dit, ça ne devait être qu’un journal, ce n’est pas moi qui ait décidé de le passer en dépêche).
              Je n’ai pas vu de manière évidente comment leur présenter « grande nouvelle : Arch Linux vérifie maintenant les signatures déjà existantes par défaut mais pas par défaut (il faut fusionner les modification du fichier de config)… mais c’est une grande nouvelle » sans simplifier un peu. :-)

              Quoiqu’il en soit, l’activation par défaut de la vérification est l’aboutissement de tout le travail de fond des développeurs pour concevoir, développer et mettre en place ce mécanisme (plus une période de test avant de le mettre par défaut).

              À un autre sujet, une petite nouvelle fraîche : Firefox et Thunderbird 13 sont dans les dépôts.

              « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

              • [^] # Re: Rectification

                Posté par  . Évalué à 1.

                Ce n'était pas une critique personnelle, j'ai bien vu que c'était un journal transformé en dépêche :). En plus, contrairement à toi, j'ai pas pris la peine de rédiger une news. Enfin, c'était pour pas que Arcaik se sente agressé non plus que j'ai fait cette remarque.

                • [^] # Dépêches

                  Posté par  . Évalué à 2.

                  En plus, contrairement à toi, j'ai pas pris la peine de rédiger une news.

                  Et c’est dommage : à voir ce commentaire, tu aurais pu en faire une bonne…

                  À la décharge des modérateurs (pour avoir passé directement en dépêche un journal juste correct… pour un journal), viser une dépêche de qualité, ça peut causer une longue stagnation dans la tribune de rédaction.
                  À partir de là, comme moi pour le journal, ce sont eux qui choisissent de privilégier la fraîcheur ou la qualité…

                  « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

    • [^] # Re: elle ne modifie pas les fichiers de configuration à l’insu de l’administrateur

      Posté par  . Évalué à 1. Dernière modification le 05 juin 2012 à 21:00.

      C'est vrai ça ? ça doit être très lourd de maintenir une Arch Linux en état de fonctionnement au fil des mises à jour.

      Pas du tout 

      #!/bin/bash
# pacnew-update - merge *.pacnew files with original configurations with meld

pacnew=$(find /etc -type f -name "*.pacnew")

for config in $pacnew; do
  # Merge with meld
  gksu meld ${config%\.*} $config &
  wait
done

      (moi pas comprendre balise code ? ``` marche pas…)

      mise a jour de 10 fichiers de configuration sur plus de 2 ans d'upgrade …..

    • [^] # Re: elle ne modifie pas les fichiers de configuration à l’insu de l’administrateur

      Posté par  . Évalué à 1.

      en fait vu que les configs cassent rarement la compatibilitée, y a quasiment jamais besoin de mettre a jour ;-)

    • [^] # Re: elle ne modifie pas les fichiers de configuration à l’insu de l’administrateur

      Posté par  . Évalué à 1.

      J'utilise Mercurial pour suivre mon /etc/. Un petit .hgignore permet d'éliminer quelques fichiers trop remuants, mtab par exemple.
      Soir bon.

  • # Mieux que les autres

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 05 juin 2012 à 17:45.

    Là où Archlinux (surtout pacman en fait) innove c'est qu'il vérifie la chaîne de signature complète des paquets. Les packages manager comme apt utilisent gpgv qui suppose que toutes les clefs publiques importées dans votre keyring sont de confiance (source man page). C'est, à mon avis, pas très efficace parce que si on nous donne une clef au nom d'un développeur, rien ne nous garanti que c'est la bonne sans faire des recherches contraignantes.

    Pacman utilise gpgme qui vérifie toute la chaîne. J'importe les 5 master keys que je vérifie autant que possible, après les développeurs ont leurs clef signées par au moins 3 des 5 master keys, condition pour faire confiance à une clef.

    Donc super arch !

    • [^] # Re: Mieux que les autres

      Posté par  . Évalué à 1.

      tout a fait, ca permet de "trust" des packets signés par mr tout-le-monde et pas juste ce qui viens des mirroirs officiels.

      et c'est pour ca que la mode de signature/verification de arch, c'est bien. d'ailleurs, gpg est prévu pour fonctionner comme ca.

  • # #old et trompeur

    Posté par  . Évalué à 4.

    Ça fait 6 mois que archlinux signe les paquets…
    Voir cette news pour les sources.

    Ce qui est récent, c'est que pacman vérifie les signatures par défaut, alors que jusqu'a présent il fallait que l'utilisateur active l'option dans /etc/pacman.conf

  • # Quelques liens sur le sujet

    Posté par  . Évalué à 9. Dernière modification le 05 juin 2012 à 22:49.

    Au passage, j'en profite pour poster quelques liens marquants :

    Le troll

    L'implémentation

    Et pour finir

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.