Journal FSF & SecureBoot

Posté par  (Mastodon) .
Étiquettes :
37
1
juil.
2012

La Free Software Fondation vient de publier un papier sur la problématique du SecureBoot. C'est à lire ici.

Après un bref rappel sur l'historique de leurs positions et actions sur ce sujet, après quelques paragraphes sur les problèmes philosophiques et les concrets posé par ce système (retrait du droit de contrôle de son matériel si certaines conditions ne sont pas remplis), la FSF prends position sur les choix des deux grandes distributions qui déjà fait connaitre les directions qu'elles prennent respectivement. Puis termine par un ensemble de recommandations et de propositions d'aide.

Sans surprise, la FSF tacle sévèrement Canonical.

  • # Anti-canonical primaire

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

    Sans surprise, la FSF tacle sévèrement Canonical.

    Ça dit surtout que chez Canonical il y a une crainte infondée comme quoi le support de Secure Boot n'est pas compatible avec la GPLv3.

    Our main concern with the Ubuntu plan is that because they are afraid of falling out of compliance with GPLv3, they plan to drop GRUB 2 on Secure Boot systems, in favor of another bootloader with a different license that lacks GPLv3's protections for user freedom. Their stated concern is that someone might ship an Ubuntu Certified machine with Restricted Boot (where the user cannot disable it). In order to comply with GPLv3, Ubuntu thinks it would then have to divulge its private key so that users could sign and install modified software on the restricted system.

    This fear is unfounded and based on a misunderstanding of GPLv3.

    Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

    • [^] # Re: Anti-canonical primaire

      Posté par  . Évalué à 6.

      Et quand on lit la suite :

      We have not been able to come up with any scenario where Ubuntu would be forced to divulge a private signing key because a third-party computer manufacturer or distributor shipped Ubuntu on a Restricted Boot machine. In such situations, the computer distributor—not Canonical or Ubuntu—would be the one responsible for providing the information necessary for users to run modified versions of the software

      On comprend que le problème est bien là et que, même si ce n'est pas Cannonical directement, ce sont ses partenaires qui devront diffuser leur clef privé.

      Après, lire que :

      No representative from Canonical contacted the FSF about these issues prior to announcing the policy. This is unfortunate because the FSF, in addition to being the primary interpreter of the license in question, is the copyright holder of GRUB 2, the main piece of GPLv3-covered software at issue.

      On comprend qu'ils ne veulent pas discuter avec la FSF si c'est pour donner des avis pareils.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Anti-canonical primaire

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

        Peut etre que même si la peur est infondé, les fabricants sont trop frileux pour tenter ?

        Ou peut etre que c'est pour préparer des tablettes arm ou les fabricants demandent à ne pas pouvoir changer l'OS, ou plutot, la ou divers partenaires, genre powervr, genre SACEM/MPAA/ ou Sony/Vivendi, etc, demande à ne pas pouvoir accéder à l'OS, cf PS3/OtherOS, cf verrouillage de l'iphone.

        je doute que Canonical rentre dans ce business, mais en même temps, faut bien manger et pour ça, faut avoir les comptes à l'équilibre. Le focus est en ce moment sur les applications pour le software center, donc pouvoir dire "on a un systéme sans piratage" est à mon avis un argument commercial puissant, et je peux comprendre, que même si Canonical ne veuille pas, des partenaires moins orienté "respect du libre" peuvent le vouloir, et demande rà Canonical une base pour le faire.

      • [^] # Re: Anti-canonical primaire

        Posté par  . Évalué à 3.

        Relis tout plus attentivement.

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 0.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Anti-canonical primaire

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

          Il est dit que les vendeurs de machines ou le secure boot est présent devront fournir aux utilisateurs les informations pour exécuter un autre système, pas qu'il doivent diffuser leur clé privée

          Ce n'est pas la lecture communément admise de la GPLv3 (qui avait pour but explicite d’empêcher la Tivoisation, on touche bien à ce problème).
          La, de ce que tu dis, permettre de désactiver SecureBoot suffirait à remplir les conditions de la GPLv3 (ça tombe bien, c'est obligatoire pour les machines x86 certifiées Win8)? la FSF est-elle prête à mettre ça par écrit? Ils ont intérêt à bien l'expliciter car c'est une raison classique de ne pas aimer la v3 de la GPL (et les avocats de Canonical le pensent), et personnellement j'ai du mal à voir comment la GPLv3 change suivant le matériel sur lequel le logiciel tourne (la licence est sur le logiciel, pas la machine). Va falloir faire une GPLv3.1 pour expliciter tout ce bordel… La parole de la FSF ne suffit pas.

          • [^] # Commentaire supprimé

            Posté par  . Évalué à 3.

            Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Re: Anti-canonical primaire

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

              OK, je n'arrive pas (mais je ne suis pas juriste) à trouver une façon qui ferait que juste filer une option pour désactiver SecureBoot n'irait pas.

              Mais du coup ça m'amène à des questions :
              - En quoi alors la méthode de Canonical est "pas bien" de leur point de vue? On peut (si on veut) faire tourner autre chose.
              - Pourquoi la FSF prend les gens à rebrousse-poil en faisant semblant de ne pas comprendre le problème du point de vue de Canonical? que ce soit Canonical ou le distributeur, tout le monde s'en fout, le problème est la.
              - Ah si ça coince toujours : Si Canonical ne fournit que son CD téléchargeable signé, et que le distributeur ne fournit que son ordinateur physique, qui doit faire quoi? Si on dit que c'est le distributeur du matériel, il va dire "va te faire voir" puisqu'il n'a aucun code sous GPL. Donc il peut avoir la crainte que Canonical n'ayant pas le pouvoir de débloquer SecureBoot sur la machine de l'utilisateur, il devrait filer sa clé pour faire tourner une version modifiée, ce qui n'est pas acceptable. Bref, c'est quoi "User product"? Si dans le cas de la fourniture d'un simple CD, c'est le CD, ben ça coince car du coup la seule possibilité pour se conformer à la licence est de filer la clé privée. Et si ce n'est pas le cas, alors la "protection" de la GPLv3 serait inefficace… Car personne ne serait obligé que le "couple" matos+OS soit modifiable. Bref, je comprend la crainte, car Canonical ne fait pas que être sous-traitant d'un distributeur, mais il distribue aussi son CD seul.

    • [^] # Re: Anti-canonical primaire

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

      En même temps, Canonical cherche à se mettre à la même position que Microsoft, à savoir avoir sa clé mais sur les machines vendus avec Ubuntu pré-installé.

      Même si plein de gens l'ont demandé ( et il faut reconnaitre ça à Canonical, écouter la demande des gens vis à vis d'une demande d'alternative à Microsoft/Verisign ), ça change rien à la problématique d'avoir une boite privé qui gére ça, à plus forte raison une boite privé qui cherche à être à l'équilibre.
      D'ailleurs, la FSF le dit ;
      "3) avoiding requiring or encouraging users to trust Microsoft or any company which makes proprietary software;"

      ( khof landscape khof )

      Au passage, je suis pas sur de l'exactitude du papier de la FSF sur le fait de retirer les clés qui bloquerait le démarrage de Fedora. Si tu as aucune clé à vérifier dans le firmware, alors ça veut dire que tu as désactivé secureboot ( ou que le fabriquant est limite con ), car sinon, tu ne peux plus rien démarré. Si quelqu'un rends sa machine incapable de démarrer, il va faire jouer la garantie, et ça coute des sous au fabricant.

      D'ailleurs, je suis sur que si les gens commencent à acheter des cartes méres, puis à les rendre sous pretexte de "ça fait pas booter mon windows ou mon linux", les fabriquants vont vite comprendre, aussi vite que la FNAC avec les cd de musique qui n'en sont pas. mais bon, je comprends bien que ça requiert plus de temps que de se plaindre sur les ml ou que de signer une pétition sur le web.

      • [^] # Re: Anti-canonical primaire

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

        mais bon, je comprends bien que ça requiert plus de temps que de se plaindre sur les ml ou que de signer une pétition sur le web.

        Ou que d'acheter directement du matériel qui fonctionne.

        • [^] # Re: Anti-canonical primaire

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

          Ça depend de l'impact que tu veux avoir. Je pense qu'il est plus facile de faire un impact sur les chiffres qu'un fabriquant veut faire baisser ( ie les retours de matos ) que sur les chiffres qu'un fabricant veut faire grimper ( ie, les ventes de matos ).

          Parce que si jamais les ventes montent, il y a des tas d'explications. Si jamais les retours montent, y en a beaucoup moins. Donc le message passe plus facilement. Et de surcroit, au vue des volumes, je dirais qu'il est aussi plus facile d'avoir un impact visible sur des chiffres plus petits ( vu qu'il y a moins de retours que de vente, par définition ).

          Ensuite, c'est couteux ( genre le prix d'une carte mére au pire ), mais vu le nombre de gens qui ont réclamés la création d'une CA indépendante notament sur slashdot ( càd d'engager pas mal d'argent en assurance et en process administratif ), j'ose croire qu'ils ne préchent pas que pour dépenser l'argent des autres pour lutter pour leur conviction, car ça serait totalement hypocrite de leur part.

  • # Pour les moins anglophones …

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

    … peut-être que quelques lignes de commentaires supplémentaires auraient étés bienvenues dans ce journal.

    La traduction très libre de l'un des arguments clef de la FSF :
    Les promoteurs de secureboot prétendent sécuriser nos ordinateurs en ne les autorisant à faire tourner que les logiciels qu'ils approuvent. C'est aller bien vite quant à la nécessité que nous éprouverions d'être protéger par eux ; nos ordinateurs devraient avoir la possibilité d’exécuter des logiciels approuvés par nous, ou par des tiers ayant notre confiance. Et ce dernier liens de confiance ne devrait pas être graver dans le marbre (matériaux qu'emploient les libristes en lieu et place de silicium :-) des machines. Au contraire il est indispensable que l'utilisateur final ai toute liberté de choix quant aux entités auxquelles ils accordent leur confiance.

    Précisons aussi que la FSF propose de signer une pétition pour la liberté d'installer des logiciels libres.

    L'argument de faire confiance à microsot pour protéger nos systèmes, s'il n'était pas présenté dans un tel contexte, n'aurait-il pas de quoi se faire tordre de rire même les pires bigots du culte de Guillaume Porte ? Même monsieur Toutlemonde ne l'ignore pas : pour qu'un système commercialisé par l'ogre de Redmond fonctionne correctement pendant quelques mois il est nécessaire de procéder à nombre de manœuvres : installations de multiples protections élaborées et coûteuses, ainsi que des réglages ésotériques d'un spécialistes (souvent un neveu adepte de facebook), voire même éviter d'essayer de trouver des logiciels répondant à ses besoins car en installer trop plombe inéluctablement le système.

    « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

  • # Ce qui m'inquiète le plus...

    Posté par  . Évalué à 1.

    … n'est pas tant UEFI que les BIOS qui verront le jour avec l'impossibilité de le désactiver.

Suivre le flux des commentaires

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