parce que je m'attends à ce que le gestionnaire de paquet m'avertisse au préalable si ça va tout casser.
J'ai pas ca sous Arch, FreeBSD ou même une Debian un peu ancienne, ce n'est pas une feature obligatoire d'un gestionnaire de paquets.
D'ailleurs sur des Debian 12, j'ai rencontré le cas où enlever un paquet propre de la distribution supprime la moitié de l'OS, sans avoir de gros message disant que ca va tout casser. Pourtant l'environnement en question est considéré comme un de ceux qui garantisse le plus la sécurité et la vie privée de l'utilisateur (si bien utilisé).
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Mais du coup, une distribution reste dépendante aux dépôts logiciels ou miroirs qui sont configurés dedans. Qui sont dans 99% des cas hors de portées des utilisateurs.
Pire encore, pour accéder à ces dépôts, les distributions sont dépendantes de serveurs DNS externes (même si on a son propre résolveur DNS local, il est soit récursif ou forwarder, donc transmet les requêtes à l'extérieur), aux infras de FAI, etc. Du coup il y a toujours une dépendance à des services hors de contrôle de l'utilisateur.
Je suis entièrement d'accord avec toi sur le fait que dans tout les cas, peut importe les licences, les services en dehors du contrôle de l'utilisateur, et c'est bien là un de mes propos. Cette dépendance ne rend pas les distributions moins libres, du coup pourquoi dans ce cas, cette intégration de Snap rend Ubuntu non-libre ?
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Sachant qu'une grosse partie des LL sont disponibles uniquement via Github, tu es du coup quand même dépendant d'un service propriétaire, même pour télécharger les tar.gz ou les codes sources. Est-ce que à cause de cette dépendance obligatoire à Github ces logiciels sont non-libres du coup ?
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Par contre elles permettent quasiment toutes de changer ce serveur et même de s'en faire un en local.
Les données des miroirs proviennent soit de d'autres miroirs, soit des dépôts officiels de la distribution. Dans le cas (improbable, certes) où les dépôts officiels tournent sous IIS, peu importe l'existence de d'autres miroirs, la distribution reste dépendante de serveurs proprio. Est-elle non libre dans ce cas ?
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Je ne sais pas trop. Nos distributions préférées sont dépendantes de leurs serveurs de dépôts. Rien n'indique que ce ne soient pas des Windows servers + IIS. Ca n'en fait pas pour autant des distributions non-libres.
De même, il y a un sacré nombre de projets libres dont le centre de distribution initial est uniquement Github, ce qui les rend dans une certaine mesure dépendant de cette plateforme. Est-ce que ca en fait des logiciels proprio du coup ?
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Ou alors qu'est-ce qui empêche de virer Snap d'Ubuntu et de l'utiliser juste avec ses dépôts ? Ca fait plus de 10 ans que je n'ai pas utilisé Ubuntu, j'ai surement raté 2-3 trucs, mais il me semble qu'ils ont toujours des dépôts et que ca reste une distribution Gnu/Linux/Systemd. Du coup le fonctionnement d'une Ubuntu n'est pas dépendante de la présence un gestionnaire de Snap.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Bah apparemment, d'après certains par ici, fournir une stack logiciel libre avec un ou 2 composants proprio facultatif, c'est faire de l'openwashing (genre ici par exemple).
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Posté par Astaoth .
En réponse au journal snap : de pire en pire..
Évalué à -7.
Dernière modification le 28 janvier 2024 à 11:21.
Est-ce que tu crois 1s qu'il y a quelqu'un qui travaille en se satisfaisant de te pourrir la vie ?
Franchement, parfois la question se pose. Quand on voit le nombre de bugs qu'on peut rencontrer en 15 min d'utilisation de Plasma ou le nombre d'utilisateurs qui n'arrivent pas à quitter Vi …
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Le TPM gére le démarrage d'un PC, utiliser une carte à puce sur un raspberry pi n'en fait pas un TPM.
Je ne parle pas de cartes à puces, mais bien de TPM. Leurs gestion est d'ailleurs intégré à U-Boot pour rpi.
Ce qui gère le démarrage d'un PC n'est pas la TPM mais l'UEFI (ou équivalent sur ARM). C'est lui qui détecte le matériel, présente des interfaces standards à l'OS, amorce le bootloader, etc.
Un PC et un programme ne sont pas du tout déterministes.
Si, juste si, c'est le principe même d'un ordinateur et d'un programme non quantique.
La vitesse d’exécution s'ajuste selon la température et la charge, ces petits changements entrainent aussi des modifications d'utilisation des caches ce qui augmentent encore les différences. A voir si ces métriques sont encore utilisés, mais il était surtout question de hash et de signature.
Déterministe ne veut pas dire qui a strictement la même exécution tout le temps, mais qu'avec les mêmes conditions initiales, l'exécution doit être identique à chaque fois.
Les variations liées aux facteurs environnementaux tel que la température et l'humidité sont inclus dans les marges de tolérances prévus par les UEFI/TPM. Tout autre facteur environnemental, tel que des températures extrêmement froides ou de fortes perturbations électromagnétiques ne sont pas des variations environnemental standard, en dehors d'ecosystèmes très spécifiques et contrôlés par ailleurs. Le fait que ces environnements puissent faire passer les UEFI/TPM en dehors des marges prévus est justement souhaités, car en dehors d'environnements spécifiques, ils indiquent un facteur extérieur humain visant à altérer le boot du système.
A l'origine, la root key du TPM ne devait pas être sous le contrôle de l'utilisateur.
Nous ne sommes pas "à l'origine", mais en 2024. A l'origine la cryptographie a été créée à des fins militaires, et ne devait pas être rendue disponible au grand public. Pourtant actuelle, tout le monde utilise de la cryptographie, doit-on en conclure par cela que tout le monde fait parti de l'armée d'une façon ou d'une autre ?
La spécification TPM proposait de vérifier toutes la chaines d’exécution et pas seulement le boot.
Sur des systèmes à fort besoins de sécurités, c'est franchement pas déconnant. Sur du matériel généraliste, d'aucun a dû s'apercevoir que c'était se tirer une balle dans le pied.
Quoiqu'il en soit ce n'est pas le cas à l'heure actuelle. Nous ne sommes pas en 2005, l'informatique a très largement évolué depuis, qu'on le veuille ou non. Rester sur des possibilités de 2005 qui ne se sont pas réalisées (grâce à l'incroyable travail de l'EFF entre autre) presque 20 ans plus tard, c'est assez dommage. Très franchement, à la lecture de son article sur PixieFail, j'ai dû mal à croire que Cory Doctorow ait un bagage technique important.
Encore une fois, le fait d'avoir trouvé cette attaque sur les UEFI, attaque sans strictement aucun rapport avec les TPM, ne démontre strictement en rien que cette attaque n'existe pas sur les BIOS. BIOS qui, encore une fois, ont exactement le même genre d'accès au matériel que les UEFI. Et actuellement, il est probable d'avoir exactement la même attaque de possible sur Coreboot qui est sous développement libre.
Donc encore une fois, utiliser PixieFail pour taper sur les TPM, c'est comme parler de la culture du riz en Asie pour justifier que sa plante grasse sur son balcon en France ne pousse pas bien.
Par contre, si quelqu'un a une alternative à l'utilisation de TPM et Secure Boot pour résoudre le problème de "l'evil maid attack", n'hésitez pas à en faire une publication, ca peut valoir de l'or.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
"Cory Doctorow, né le 17 juillet 1971 à Toronto en Ontario, est un blogueur, journaliste et auteur de science-fiction canado-britannique."
Je ne vois pas de bagage technique dans son CV, du coup je doute de la pertinence d'utiliser ses propos comme référence sur un sujet assez technique et méconnu. En particulier quand il compare la TPM à un composant de vaisseau interstellaire qui mène à l'explosion de celui-ci, dans un film de science-fiction.
La TPM n'est toujours pas une techno de surveillance comme tu le sous-entends. C'est une réponse à "l'evil maid attack", la seule possible à l'heure actuelle. Je t'encourage très fortement à lire la page wikipedia à son sujet.
En dehors d'une surveillance permanente de l'équipement, les seules facons de contrecarrer cette attaque, et donc toute modification de la chaine de boot qui ne peut pas être chiffré sur un volume LUKS c'est de signer les composants logiciels, et de mesurer leurs temps d'exécutions. Un PC et un programme étant déterministes, tant que le bootloader n'est pas modifié, la durée d'exécution de chacune de ses étapes doivent être strictement identique d'un boot à l'autre. Un changement de durée d'exécution indique une modification du bootloader. Contrairement à ce qu'a écrit ton auteur de SF préférée, la TPM ne surveille pas l'ensemble des logiciels qui tournent sur le PC, mais uniquement ceux de la phase de boot, quand le SecureBoot est actif.
La TPM ne serait une technologie de surveillance de l'utilisateur que si ses fonctionnalités ne pouvaient pas être désactivées (et on peut allègrement passer outre la TPM en désactivant le secure boot, encore une fois), si elle stockait les infos de chaque boot (c'est pas le cas, elle compare les durées d'exécutions et des signatures seulement, sans plus, et je doute un peu qu'elle ait les capacités de stockage pour stocker les données de tout les boots d'un PC), et si elle transmettait ces informations à des acteurs extérieurs (c'est toujours pas le cas, la TPM n'a pas de stack réseau). Et avant de faire un lien bancale entre la TPM et l'UEFI, il est totalement possible de trouver des TPM externe, qu'on utiliserait sur un raspi qui n'a pas d'UEFI. L'hypothèse que la TPM a été créé comme un dispositif de surveillance de l'utilisateur est donc erronée. Mais tout ceci n'a toujours aucun rapport avec l'attaque de l'article de Ars Technicas.
l’implémentation matériel d’un logiciel tournant hors de portée des utilisateur
Même un firmware de hardware libre reste hors de porté de l'utilisateur, en particulier de ceux n'ayant aucun bagage technique. Mais si les firmwares qui proposent des interfaces standardisés par des normes ISO pour les OS et drivers n'existaient pas, l'utopie d'avoir des OS indépendants de grosses sociétées resterait une fiction. Pour en avoir une vague idée, souvenons-nous de la sombre époque de ndiswrapper pour le wifi, et imaginons un seul instant être dans la même situation pour l'accès aux volumes de stockages par exemple.
Mon expression reste toujours aussi médiocre. Pour comprendre il vaudra mieux lire l’article. Permettez-moi d’ajouter que, par ailleurs, je n’ai pas de connaissances importantes en matière de firmware, et que donc mon propos ne fait que rapporter celui d’autrui. Mon jugement technique n’a que peu de valeur dans le domaine que nous discutons.
Au vu du contenu de son article, c'est également le cas de Cory Doctorow. Le problème est qu'il a pris des morceaux d'info ici et là, sans vraiment les comprendre, et au lieu de creuser le sujet, il les a assemblé à la facon d'un blogueur, journaliste et auteur de science-fiction. Malheureusement pour lui, nous ne sommes pas dans un roman de science-fiction, la TPM n'a pas les buts et fonctionnalités qu'il décrit, et les scénarios catastrophes qu'il mentionne restent … de la fiction.
Renseigne-toi vraiment sur ce qu'est une TPM, mets en place un secure boot, et testes les scénarios catastrophe de ton auteur préféré (lorsque possible) pour voir si ils sont réalistes ou non (par exemple, essaye d'avoir un ad-blocker dans ton navigateur web et vois si la TPM t'en empêche avec un secure boot actif).
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Je ne suis pas sûr de comprendre le rapport entre l'attaque découverte et le contenu du journal.
L'attaque exploite une chaine de vulnérabilité sur les boots PXE et l'IPv6 de l'UEFI. Je ne suis pas sûr de comprendre le rapport avec les TPM du coup.
D'après Wikipedia, "Trusted Platform Module (TPM) was conceived by a computer industry consortium called Trusted Computing Group (TCG)." et "Members include Intel, AMD, IBM, Microsoft, and Cisco.". Du coup les TPM n'ont pas été créées juste par Microsoft.
Les TPM en tant que telles ne servent qu'à stocker des clefs et signatures cryptographiques, et il est totalement possible de les effacer et d'y mettre les siennes. C'est long et pénible, mais faisable sous le contrôle de l'utilisateur qui souhaite avoir son propre set de clefs et signatures. Si l'utilisateur ne veut pas s'embêter avec ca, il peut aussi juste désactiver le Secure Boot, comme à l'époque des BIOS. Du coup je ne vois pas trop le rapport avec les DRM.
Le journal fait mention de dispositifs de surveillance dans les ordis modernes après avoir parlé d'UEFI, de TPM et de cette nouvelle attaque.
Pour rappel, les TPM et UEFI n'ont rien à voir avec des dispositifs de surveillance. La fonction d'une TPM est de répondre à ce problème très bête et très dur à résoudre de "l'evil maid attack".
L'UEFI a été créé pour remplacer un BIOS vieillissant (il me semble que, un compatible-PC, à l'étape du BIOS, émule littéralement un IBM PC d'il y a 40 ans ; ca devient un peu long de compter quelques dizaines de Go de RAM pendant un POST), dont les mises à jours sont plus que scabreuses (en cas de plantage d'une maj, il faut remplacer la puce du BIOS par une nouvelle, flashée avec le firmware), et créé à une époque où les besoins en sécurités étaient différents.
Les buts et fonctionnalités initiales de l'UEFI sont plus ou moins les mêmes que celui des BIOS : être une interface basique d'exploitation du matériel et lancer le bootloader. Bien évidement qu'un UEFI peut exploiter le matériel, exactement de la même facon q'un BIOS peut le faire. D'ailleurs les boots PXE ne sont pas apparu avec les UEFI, donc rien ne dit que cette attaque n'existait pas avec les BIOS, mais n'a pas été découverte officiellement. On a d'ailleurs pas attendu les UEFI pour trouver des attaques sur les firmwares, je me souviens d'une histoire de disques durs d'il y a quelques années à ce sujet.
Ce journal parle enfin d'éthique sur les firmwares, et semble sous-entendre que les UEFI ne sont pas éthiques. Au vu de l'évolution de la recherche en sécurité durant la dernière décade, et des fonctions très similaires entre les BIOS et UEFI, est-ce que l'absence d'attaque connue de ce type sur les BIOS implique nécessairement leur impossibilité ? Et quel rapport avec l'éthique en fait ?
Pour rappel, la chaine de vulnérabilité nécessaire à cette attaque est disponible sur au moins un UEFI open-source, l'implémentation de référence d'Intel (sous licence BSD). Si j'ai bien compris la page wikipedia de EDK II (l'UEFI de Intel), il fait maintenant parti de Coreboot, la stack libre visant à remplacer les BIOS et UEFI. Mais peut-être que Coreboot n'est pas un projet éthique dans son principe ? D'ailleurs, serait-il plus éthique de ne pas avoir un firmware s'occupant de l'initialisation du matériel, du lancement du bootloader et présentant une interface standardisé du matériel à l'OS, et donc de devoir dépendre du bon vouloir des fabriquant de cartes mères ?
Et enfin, cette attaque nécessite une chaine de vulnérabilité assez importante (9 vulnérabilités du coup), et a comme pré-requis d'avoir le PXE actif, et peut-être aussi de l'IPv6 (sur certains UEFI, on peut choisir d'avoir du PXE uniquement en v4 ou v6). Cette vulnérabilité semble donc assez simple à mitiguer pour un particulier. Pour les UEFI virtuels, une mise à jour de l'hyperviseur corrigera les vulnérabilités ; pour les UEFI matériels, une mise à jour, faisable depuis l'OS pourra également bloquer l'attaque. Avec un BIOS, ce genre de patch serait beaucoup plus pénible à appliquer sur les environnements physiques, car il ne pourrait se faire que manuellement, en démarrant non pas l'OS mais directement le firmware de màj du BIOS, avec toujours le risque que si la màj se vautre, il faut remplacer la carte mère.
En conclusion, je trouve qu'utiliser un article sur une attaque d'un composant matériel pour dire que celui-ci ainsi qu'un autre composant matériel (pas impacté par l'attaque) sont des techno de surveillance, voir des backdoors, c'est assez peu éthique je trouve.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Ca concerne toutes les implémentation d'UEFI ayant ces vulnérabilités.
"The nine vulnerabilities that comprise PixieFail reside in TianoCore EDK II, an open source implementation of the UEFI specification. The implementation is incorporated into offerings from Arm Ltd., Insyde, AMI, Phoenix Technologies, and Microsoft.".
J'imagine qu'on peut supposer qu'un UEFI open source peut largement être utilisé dans le monde de l'hypervision, et notamment des hyperviseurs open-sources.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Une de ces fameuses caméras qui se retrouve en ligne après ?
NB : ce site ne recense aucune caméra situé à l'intérieur d'un appartement normalement, mais d'autres le font. C'est d'ailleurs très amusant de faire aboyer une caméra dans un commerce.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Avec le Thinkpad E15 du boulot sous W10, j'étais obligé de le débrancher le soir, sinon il s'allumait pendant la nuit, pour installer des mises à jours que finalement il n'installait pas, et rester allumer toute la nuit. Au matin, j'avais largement de quoi tenir toute la matinée sans problème.
Sous QubesOS (pas réputé avoir la meilleure gestion énergétique et l’hibernation est impossible avec), je peux laisser l'ordi en veille toute la nuit, j'aurais quand même de la batterie le lendemain, sur un Dell avec un Intel gen10.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Il faut juste savoir designer un pcb, un chassis (en suppossant que les côtes sont dispos), savoir fabriquer ces modules, mais aussi avoir le temps et l'outillage pour le faire.
Pour les gens qui souhaitent avoir 2 ports USB-A par module, il faut aussi juste des modules plus larges, les actuels ayant l'air un peu petit pour en mettre plusieurs. Ca veut aussi dire un nouveau châssis.
Ce "rien" est assez épais quand même, je préfèrerais leur acheter directement des modules un peu plus complets. Néanmoins c'est intéressant d'avoir la confirmation que ca soit des ports USB-C, ca rend le concept quand même assez intéressant, à moyen terme.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
C'est bien le nombre de ports qui me dérange. Il y a d'ailleurs des choses que j'ai du mal à comprendre : autant, un module qui ne propose qu'un seul USB-C, ca se comprend pour une question de bande passante (et encore, faire un double usb-C avec un qui ne fasse que de la charge, et un qui permette tout le reste + éventuellement la charge, ca devrait largement être possible et pas tellement plus cher à fabriquer), pareil pour le hdmi, la taille du connecteur doit limiter les possibilités. En revanche, le module qui propose juste un jack est assez surprenant : ca ne prend pas beaucoup de bande passante, ni de place, c'est un peu dommage du coup. Il aurait peut-être été possible de mettre un usb-a en plus avec par exemple.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Ce n'est justement pas toujours possible à utiliser. Et personnellement, je trouve que passer d'un pc qui a une connectique complète à un auquel il manque la moitié des ports, c'est une régression sur le design, pas une progression.
Si je voulais un pc portable avec un minimum de connectique pour maximiser la portabilité, je prendrais plutôt un GPD Win Max 2 ou équivalent de 10" ou moins.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
J'avais hésité à prendre un framework, mais j'aimerais avoir au moins un RJ45, 3 USB-A, un USB-C et une prise chargeur séparée/HDMI/USB-C en plus, dans un petit format. Mais bon, apparement le marketing moderne ne veut plus utiliser d'USB-A ni de RJ45, je suis obligé de rester sur des laptops avec des intel gen10 max pour avoir ca.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
En fait, t'as 2 types de démarchage par téléphone en France : le légal et le pas légal.
Le légal ne peut se faire que depuis des préfixes précis, dispo ici (faire un ctrl+f > "démarcheurs"). On les ajoute vite fait dans un truc comme ca (bien ajouter les préfixes en 01xxx mais aussi ceux en +331xxx) et on en entend plus jamais parler.
Le pas légal se fait pas mal en usurpant des no de tel mobiles. En ce moment, ils font des scams sur l'énergie. Le but est de faire signer un contrat qui dit qu'on paye très cher pour rien avoir, le tout depuis un no mobile usurpé (quand on rappelle après, il arrive souvent qu'il ne soit pas attribué), et avec des données acquises illégalement. Celui-là, faudrait prendre le temps de creuser un peu, il doit y avoir moyen de faire un truc légal. Mais bon, depuis que je leur ai dit que c'était une boite de scams, ils rappellent plus bizarrement.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Posté par Astaoth .
En réponse au journal Youtube embed in Youtube.
Évalué à 10.
Dernière modification le 16 décembre 2023 à 01:25.
Il y a aussi Freetube, un client lourd qui peut passer par invidious (ou pas, c'est au choix), n'affiche pas les pubs, intègre SponsorBlock, gérant les abonnements en local sans avoir de compte, et dispo dans les dépôts ou en flatpak.
Les données peuvent s'exporter/importer facilement, il parait d'ailleurs que les exports sont compatibles avec NewPipe.
Néanmoins cette extension c'est une bonne idée, ca fait un bon complément pour regarder rapidement une vidéo dans un butineur.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Ouais il est assez imposant, et intimidant. On peut quand même faire un setup standalone, de mémoire l'installeur est assez simplifié pour faire ca simplement. Par contre, je crois que pour faire des filtres customs c'était un peu plus pénible que f2b, du coup je l'ai jamais trop utilisé. Mais ca a pu évoluer depuis, j'avais regardé ca y a 7-8 ans.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Pas tous libre
Posté par Astaoth . En réponse au journal snap : de pire en pire.. Évalué à 3.
J'ai pas ca sous Arch, FreeBSD ou même une Debian un peu ancienne, ce n'est pas une feature obligatoire d'un gestionnaire de paquets.
D'ailleurs sur des Debian 12, j'ai rencontré le cas où enlever un paquet propre de la distribution supprime la moitié de l'OS, sans avoir de gros message disant que ca va tout casser. Pourtant l'environnement en question est considéré comme un de ceux qui garantisse le plus la sécurité et la vie privée de l'utilisateur (si bien utilisé).
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Pas tous libre
Posté par Astaoth . En réponse au journal snap : de pire en pire.. Évalué à 0.
Mais du coup, une distribution reste dépendante aux dépôts logiciels ou miroirs qui sont configurés dedans. Qui sont dans 99% des cas hors de portées des utilisateurs.
Pire encore, pour accéder à ces dépôts, les distributions sont dépendantes de serveurs DNS externes (même si on a son propre résolveur DNS local, il est soit récursif ou forwarder, donc transmet les requêtes à l'extérieur), aux infras de FAI, etc. Du coup il y a toujours une dépendance à des services hors de contrôle de l'utilisateur.
Je suis entièrement d'accord avec toi sur le fait que dans tout les cas, peut importe les licences, les services en dehors du contrôle de l'utilisateur, et c'est bien là un de mes propos. Cette dépendance ne rend pas les distributions moins libres, du coup pourquoi dans ce cas, cette intégration de Snap rend Ubuntu non-libre ?
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Pas tous libre
Posté par Astaoth . En réponse au journal snap : de pire en pire.. Évalué à 2.
Oui je vois, mais du coup avoir son propre dépôt n'enlève pas la dépendance aux dépôts de la distribution ;)
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Pas tous libre
Posté par Astaoth . En réponse au journal snap : de pire en pire.. Évalué à 2.
Sachant qu'une grosse partie des LL sont disponibles uniquement via Github, tu es du coup quand même dépendant d'un service propriétaire, même pour télécharger les tar.gz ou les codes sources. Est-ce que à cause de cette dépendance obligatoire à Github ces logiciels sont non-libres du coup ?
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Pas tous libre
Posté par Astaoth . En réponse au journal snap : de pire en pire.. Évalué à 3.
Les données des miroirs proviennent soit de d'autres miroirs, soit des dépôts officiels de la distribution. Dans le cas (improbable, certes) où les dépôts officiels tournent sous IIS, peu importe l'existence de d'autres miroirs, la distribution reste dépendante de serveurs proprio. Est-elle non libre dans ce cas ?
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Pas tous libre
Posté par Astaoth . En réponse au journal snap : de pire en pire.. Évalué à 1.
Je ne sais pas trop. Nos distributions préférées sont dépendantes de leurs serveurs de dépôts. Rien n'indique que ce ne soient pas des Windows servers + IIS. Ca n'en fait pas pour autant des distributions non-libres.
De même, il y a un sacré nombre de projets libres dont le centre de distribution initial est uniquement Github, ce qui les rend dans une certaine mesure dépendant de cette plateforme. Est-ce que ca en fait des logiciels proprio du coup ?
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Pas tous libre
Posté par Astaoth . En réponse au journal snap : de pire en pire.. Évalué à 2.
Ou alors qu'est-ce qui empêche de virer Snap d'Ubuntu et de l'utiliser juste avec ses dépôts ? Ca fait plus de 10 ans que je n'ai pas utilisé Ubuntu, j'ai surement raté 2-3 trucs, mais il me semble qu'ils ont toujours des dépôts et que ca reste une distribution Gnu/Linux/Systemd. Du coup le fonctionnement d'une Ubuntu n'est pas dépendante de la présence un gestionnaire de Snap.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Pas tous libre
Posté par Astaoth . En réponse au journal snap : de pire en pire.. Évalué à 4.
Bah apparemment, d'après certains par ici, fournir une stack logiciel libre avec un ou 2 composants proprio facultatif, c'est faire de l'openwashing (genre ici par exemple).
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: ouaip
Posté par Astaoth . En réponse au journal snap : de pire en pire.. Évalué à -7. Dernière modification le 28 janvier 2024 à 11:21.
Franchement, parfois la question se pose. Quand on voit le nombre de bugs qu'on peut rencontrer en 15 min d'utilisation de Plasma ou le nombre d'utilisateurs qui n'arrivent pas à quitter Vi …
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Info périmée ?
Posté par Astaoth . En réponse au journal Piratage de Free-Work. Évalué à 3.
Du coup logique que certains aient pas été averti, surtout si ils se sont inscrits après le piratage xD.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Un journal très orienté
Posté par Astaoth . En réponse au journal De la supériorité des choix éthiques — une brève histoire de TPM, UEFI, et failles incontrôlables. Évalué à 5. Dernière modification le 19 janvier 2024 à 18:31.
Je ne parle pas de cartes à puces, mais bien de TPM. Leurs gestion est d'ailleurs intégré à U-Boot pour rpi.
Ce qui gère le démarrage d'un PC n'est pas la TPM mais l'UEFI (ou équivalent sur ARM). C'est lui qui détecte le matériel, présente des interfaces standards à l'OS, amorce le bootloader, etc.
Si, juste si, c'est le principe même d'un ordinateur et d'un programme non quantique.
Déterministe ne veut pas dire qui a strictement la même exécution tout le temps, mais qu'avec les mêmes conditions initiales, l'exécution doit être identique à chaque fois.
Les variations liées aux facteurs environnementaux tel que la température et l'humidité sont inclus dans les marges de tolérances prévus par les UEFI/TPM. Tout autre facteur environnemental, tel que des températures extrêmement froides ou de fortes perturbations électromagnétiques ne sont pas des variations environnemental standard, en dehors d'ecosystèmes très spécifiques et contrôlés par ailleurs. Le fait que ces environnements puissent faire passer les UEFI/TPM en dehors des marges prévus est justement souhaités, car en dehors d'environnements spécifiques, ils indiquent un facteur extérieur humain visant à altérer le boot du système.
Nous ne sommes pas "à l'origine", mais en 2024. A l'origine la cryptographie a été créée à des fins militaires, et ne devait pas être rendue disponible au grand public. Pourtant actuelle, tout le monde utilise de la cryptographie, doit-on en conclure par cela que tout le monde fait parti de l'armée d'une façon ou d'une autre ?
Sur des systèmes à fort besoins de sécurités, c'est franchement pas déconnant. Sur du matériel généraliste, d'aucun a dû s'apercevoir que c'était se tirer une balle dans le pied.
Quoiqu'il en soit ce n'est pas le cas à l'heure actuelle. Nous ne sommes pas en 2005, l'informatique a très largement évolué depuis, qu'on le veuille ou non. Rester sur des possibilités de 2005 qui ne se sont pas réalisées (grâce à l'incroyable travail de l'EFF entre autre) presque 20 ans plus tard, c'est assez dommage. Très franchement, à la lecture de son article sur PixieFail, j'ai dû mal à croire que Cory Doctorow ait un bagage technique important.
Encore une fois, le fait d'avoir trouvé cette attaque sur les UEFI, attaque sans strictement aucun rapport avec les TPM, ne démontre strictement en rien que cette attaque n'existe pas sur les BIOS. BIOS qui, encore une fois, ont exactement le même genre d'accès au matériel que les UEFI. Et actuellement, il est probable d'avoir exactement la même attaque de possible sur Coreboot qui est sous développement libre.
Donc encore une fois, utiliser PixieFail pour taper sur les TPM, c'est comme parler de la culture du riz en Asie pour justifier que sa plante grasse sur son balcon en France ne pousse pas bien.
Par contre, si quelqu'un a une alternative à l'utilisation de TPM et Secure Boot pour résoudre le problème de "l'evil maid attack", n'hésitez pas à en faire une publication, ca peut valoir de l'or.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Un journal très orienté
Posté par Astaoth . En réponse au journal De la supériorité des choix éthiques — une brève histoire de TPM, UEFI, et failles incontrôlables. Évalué à 3.
"Cory Doctorow, né le 17 juillet 1971 à Toronto en Ontario, est un blogueur, journaliste et auteur de science-fiction canado-britannique."
Je ne vois pas de bagage technique dans son CV, du coup je doute de la pertinence d'utiliser ses propos comme référence sur un sujet assez technique et méconnu. En particulier quand il compare la TPM à un composant de vaisseau interstellaire qui mène à l'explosion de celui-ci, dans un film de science-fiction.
La TPM n'est toujours pas une techno de surveillance comme tu le sous-entends. C'est une réponse à "l'evil maid attack", la seule possible à l'heure actuelle. Je t'encourage très fortement à lire la page wikipedia à son sujet.
En dehors d'une surveillance permanente de l'équipement, les seules facons de contrecarrer cette attaque, et donc toute modification de la chaine de boot qui ne peut pas être chiffré sur un volume LUKS c'est de signer les composants logiciels, et de mesurer leurs temps d'exécutions. Un PC et un programme étant déterministes, tant que le bootloader n'est pas modifié, la durée d'exécution de chacune de ses étapes doivent être strictement identique d'un boot à l'autre. Un changement de durée d'exécution indique une modification du bootloader. Contrairement à ce qu'a écrit ton auteur de SF préférée, la TPM ne surveille pas l'ensemble des logiciels qui tournent sur le PC, mais uniquement ceux de la phase de boot, quand le SecureBoot est actif.
La TPM ne serait une technologie de surveillance de l'utilisateur que si ses fonctionnalités ne pouvaient pas être désactivées (et on peut allègrement passer outre la TPM en désactivant le secure boot, encore une fois), si elle stockait les infos de chaque boot (c'est pas le cas, elle compare les durées d'exécutions et des signatures seulement, sans plus, et je doute un peu qu'elle ait les capacités de stockage pour stocker les données de tout les boots d'un PC), et si elle transmettait ces informations à des acteurs extérieurs (c'est toujours pas le cas, la TPM n'a pas de stack réseau). Et avant de faire un lien bancale entre la TPM et l'UEFI, il est totalement possible de trouver des TPM externe, qu'on utiliserait sur un raspi qui n'a pas d'UEFI. L'hypothèse que la TPM a été créé comme un dispositif de surveillance de l'utilisateur est donc erronée. Mais tout ceci n'a toujours aucun rapport avec l'attaque de l'article de Ars Technicas.
Même un firmware de hardware libre reste hors de porté de l'utilisateur, en particulier de ceux n'ayant aucun bagage technique. Mais si les firmwares qui proposent des interfaces standardisés par des normes ISO pour les OS et drivers n'existaient pas, l'utopie d'avoir des OS indépendants de grosses sociétées resterait une fiction. Pour en avoir une vague idée, souvenons-nous de la sombre époque de ndiswrapper pour le wifi, et imaginons un seul instant être dans la même situation pour l'accès aux volumes de stockages par exemple.
Au vu du contenu de son article, c'est également le cas de Cory Doctorow. Le problème est qu'il a pris des morceaux d'info ici et là, sans vraiment les comprendre, et au lieu de creuser le sujet, il les a assemblé à la facon d'un blogueur, journaliste et auteur de science-fiction. Malheureusement pour lui, nous ne sommes pas dans un roman de science-fiction, la TPM n'a pas les buts et fonctionnalités qu'il décrit, et les scénarios catastrophes qu'il mentionne restent … de la fiction.
Renseigne-toi vraiment sur ce qu'est une TPM, mets en place un secure boot, et testes les scénarios catastrophe de ton auteur préféré (lorsque possible) pour voir si ils sont réalistes ou non (par exemple, essaye d'avoir un ad-blocker dans ton navigateur web et vois si la TPM t'en empêche avec un secure boot actif).
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
# Un journal très orienté
Posté par Astaoth . En réponse au journal De la supériorité des choix éthiques — une brève histoire de TPM, UEFI, et failles incontrôlables. Évalué à 10. Dernière modification le 19 janvier 2024 à 03:08.
Je ne suis pas sûr de comprendre le rapport entre l'attaque découverte et le contenu du journal.
L'attaque exploite une chaine de vulnérabilité sur les boots PXE et l'IPv6 de l'UEFI. Je ne suis pas sûr de comprendre le rapport avec les TPM du coup.
D'après Wikipedia, "Trusted Platform Module (TPM) was conceived by a computer industry consortium called Trusted Computing Group (TCG)." et "Members include Intel, AMD, IBM, Microsoft, and Cisco.". Du coup les TPM n'ont pas été créées juste par Microsoft.
Les TPM en tant que telles ne servent qu'à stocker des clefs et signatures cryptographiques, et il est totalement possible de les effacer et d'y mettre les siennes. C'est long et pénible, mais faisable sous le contrôle de l'utilisateur qui souhaite avoir son propre set de clefs et signatures. Si l'utilisateur ne veut pas s'embêter avec ca, il peut aussi juste désactiver le Secure Boot, comme à l'époque des BIOS. Du coup je ne vois pas trop le rapport avec les DRM.
Le journal fait mention de dispositifs de surveillance dans les ordis modernes après avoir parlé d'UEFI, de TPM et de cette nouvelle attaque.
Pour rappel, les TPM et UEFI n'ont rien à voir avec des dispositifs de surveillance. La fonction d'une TPM est de répondre à ce problème très bête et très dur à résoudre de "l'evil maid attack".
L'UEFI a été créé pour remplacer un BIOS vieillissant (il me semble que, un compatible-PC, à l'étape du BIOS, émule littéralement un IBM PC d'il y a 40 ans ; ca devient un peu long de compter quelques dizaines de Go de RAM pendant un POST), dont les mises à jours sont plus que scabreuses (en cas de plantage d'une maj, il faut remplacer la puce du BIOS par une nouvelle, flashée avec le firmware), et créé à une époque où les besoins en sécurités étaient différents.
Les buts et fonctionnalités initiales de l'UEFI sont plus ou moins les mêmes que celui des BIOS : être une interface basique d'exploitation du matériel et lancer le bootloader. Bien évidement qu'un UEFI peut exploiter le matériel, exactement de la même facon q'un BIOS peut le faire. D'ailleurs les boots PXE ne sont pas apparu avec les UEFI, donc rien ne dit que cette attaque n'existait pas avec les BIOS, mais n'a pas été découverte officiellement. On a d'ailleurs pas attendu les UEFI pour trouver des attaques sur les firmwares, je me souviens d'une histoire de disques durs d'il y a quelques années à ce sujet.
Ce journal parle enfin d'éthique sur les firmwares, et semble sous-entendre que les UEFI ne sont pas éthiques. Au vu de l'évolution de la recherche en sécurité durant la dernière décade, et des fonctions très similaires entre les BIOS et UEFI, est-ce que l'absence d'attaque connue de ce type sur les BIOS implique nécessairement leur impossibilité ? Et quel rapport avec l'éthique en fait ?
Pour rappel, la chaine de vulnérabilité nécessaire à cette attaque est disponible sur au moins un UEFI open-source, l'implémentation de référence d'Intel (sous licence BSD). Si j'ai bien compris la page wikipedia de EDK II (l'UEFI de Intel), il fait maintenant parti de Coreboot, la stack libre visant à remplacer les BIOS et UEFI. Mais peut-être que Coreboot n'est pas un projet éthique dans son principe ? D'ailleurs, serait-il plus éthique de ne pas avoir un firmware s'occupant de l'initialisation du matériel, du lancement du bootloader et présentant une interface standardisé du matériel à l'OS, et donc de devoir dépendre du bon vouloir des fabriquant de cartes mères ?
Et enfin, cette attaque nécessite une chaine de vulnérabilité assez importante (9 vulnérabilités du coup), et a comme pré-requis d'avoir le PXE actif, et peut-être aussi de l'IPv6 (sur certains UEFI, on peut choisir d'avoir du PXE uniquement en v4 ou v6). Cette vulnérabilité semble donc assez simple à mitiguer pour un particulier. Pour les UEFI virtuels, une mise à jour de l'hyperviseur corrigera les vulnérabilités ; pour les UEFI matériels, une mise à jour, faisable depuis l'OS pourra également bloquer l'attaque. Avec un BIOS, ce genre de patch serait beaucoup plus pénible à appliquer sur les environnements physiques, car il ne pourrait se faire que manuellement, en démarrant non pas l'OS mais directement le firmware de màj du BIOS, avec toujours le risque que si la màj se vautre, il faut remplacer la carte mère.
En conclusion, je trouve qu'utiliser un article sur une attaque d'un composant matériel pour dire que celui-ci ainsi qu'un autre composant matériel (pas impacté par l'attaque) sont des techno de surveillance, voir des backdoors, c'est assez peu éthique je trouve.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: du dur ou du cloud
Posté par Astaoth . En réponse au journal De la supériorité des choix éthiques — une brève histoire de TPM, UEFI, et failles incontrôlables. Évalué à 6.
Ca concerne toutes les implémentation d'UEFI ayant ces vulnérabilités.
"The nine vulnerabilities that comprise PixieFail reside in TianoCore EDK II, an open source implementation of the UEFI specification. The implementation is incorporated into offerings from Arm Ltd., Insyde, AMI, Phoenix Technologies, and Microsoft.".
J'imagine qu'on peut supposer qu'un UEFI open source peut largement être utilisé dans le monde de l'hypervision, et notamment des hyperviseurs open-sources.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Camera cachée
Posté par Astaoth . En réponse au journal J’ai fait fuir les voleurs (trop forte !?). Évalué à 5.
Une de ces fameuses caméras qui se retrouve en ligne après ?
NB : ce site ne recense aucune caméra situé à l'intérieur d'un appartement normalement, mais d'autres le font. C'est d'ailleurs très amusant de faire aboyer une caméra dans un commerce.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Batterie
Posté par Astaoth . En réponse au journal Laptop Frame.Work 13 pouces. Évalué à 3.
Avec le Thinkpad E15 du boulot sous W10, j'étais obligé de le débrancher le soir, sinon il s'allumait pendant la nuit, pour installer des mises à jours que finalement il n'installait pas, et rester allumer toute la nuit. Au matin, j'avais largement de quoi tenir toute la matinée sans problème.
Sous QubesOS (pas réputé avoir la meilleure gestion énergétique et l’hibernation est impossible avec), je peux laisser l'ordi en veille toute la nuit, j'aurais quand même de la batterie le lendemain, sur un Dell avec un Intel gen10.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: On aimerait pas tous la même chose
Posté par Astaoth . En réponse au journal Laptop Frame.Work 13 pouces. Évalué à 4.
Il faut juste savoir designer un pcb, un chassis (en suppossant que les côtes sont dispos), savoir fabriquer ces modules, mais aussi avoir le temps et l'outillage pour le faire.
Pour les gens qui souhaitent avoir 2 ports USB-A par module, il faut aussi juste des modules plus larges, les actuels ayant l'air un peu petit pour en mettre plusieurs. Ca veut aussi dire un nouveau châssis.
Ce "rien" est assez épais quand même, je préfèrerais leur acheter directement des modules un peu plus complets. Néanmoins c'est intéressant d'avoir la confirmation que ca soit des ports USB-C, ca rend le concept quand même assez intéressant, à moyen terme.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: On aimerait pas tous la même chose
Posté par Astaoth . En réponse au journal Laptop Frame.Work 13 pouces. Évalué à 4. Dernière modification le 19 décembre 2023 à 21:28.
C'est bien le nombre de ports qui me dérange. Il y a d'ailleurs des choses que j'ai du mal à comprendre : autant, un module qui ne propose qu'un seul USB-C, ca se comprend pour une question de bande passante (et encore, faire un double usb-C avec un qui ne fasse que de la charge, et un qui permette tout le reste + éventuellement la charge, ca devrait largement être possible et pas tellement plus cher à fabriquer), pareil pour le hdmi, la taille du connecteur doit limiter les possibilités. En revanche, le module qui propose juste un jack est assez surprenant : ca ne prend pas beaucoup de bande passante, ni de place, c'est un peu dommage du coup. Il aurait peut-être été possible de mettre un usb-a en plus avec par exemple.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: On aimerait pas tous la même chose
Posté par Astaoth . En réponse au journal Laptop Frame.Work 13 pouces. Évalué à 6.
"On aimerait pas tous la même chose"
Ce n'est justement pas toujours possible à utiliser. Et personnellement, je trouve que passer d'un pc qui a une connectique complète à un auquel il manque la moitié des ports, c'est une régression sur le design, pas une progression.
Si je voulais un pc portable avec un minimum de connectique pour maximiser la portabilité, je prendrais plutôt un GPD Win Max 2 ou équivalent de 10" ou moins.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
# On aimerait pas tous la même chose
Posté par Astaoth . En réponse au journal Laptop Frame.Work 13 pouces. Évalué à 5.
J'avais hésité à prendre un framework, mais j'aimerais avoir au moins un RJ45, 3 USB-A, un USB-C et une prise chargeur séparée/HDMI/USB-C en plus, dans un petit format. Mais bon, apparement le marketing moderne ne veut plus utiliser d'USB-A ni de RJ45, je suis obligé de rester sur des laptops avec des intel gen10 max pour avoir ca.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Si dérangeant que ça ?
Posté par Astaoth . En réponse au journal Gérer les démarcheurs téléphoniques. Évalué à 4.
Jpense que pour faire ca, faut les faire appeler un 0899 : non seulement ils perdent leurs temps, mais en plus ils nous payent pour ca :D
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: filtrer des débuts de numéros ?
Posté par Astaoth . En réponse au journal Gérer les démarcheurs téléphoniques. Évalué à 2.
Ceux qui passent sont ceux qui commencent par +331xxxx au lieu de 01xxx. Faut bloquer les 2 préfixes.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
# Démarchage légal et pas légal
Posté par Astaoth . En réponse au journal Gérer les démarcheurs téléphoniques. Évalué à 6.
En fait, t'as 2 types de démarchage par téléphone en France : le légal et le pas légal.
Le légal ne peut se faire que depuis des préfixes précis, dispo ici (faire un ctrl+f > "démarcheurs"). On les ajoute vite fait dans un truc comme ca (bien ajouter les préfixes en 01xxx mais aussi ceux en +331xxx) et on en entend plus jamais parler.
Le pas légal se fait pas mal en usurpant des no de tel mobiles. En ce moment, ils font des scams sur l'énergie. Le but est de faire signer un contrat qui dit qu'on paye très cher pour rien avoir, le tout depuis un no mobile usurpé (quand on rappelle après, il arrive souvent qu'il ne soit pas attribué), et avec des données acquises illégalement. Celui-là, faudrait prendre le temps de creuser un peu, il doit y avoir moyen de faire un truc légal. Mais bon, depuis que je leur ai dit que c'était une boite de scams, ils rappellent plus bizarrement.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Sinon...
Posté par Astaoth . En réponse au journal Youtube embed in Youtube. Évalué à 10. Dernière modification le 16 décembre 2023 à 01:25.
Il y a aussi Freetube, un client lourd qui peut passer par invidious (ou pas, c'est au choix), n'affiche pas les pubs, intègre SponsorBlock, gérant les abonnements en local sans avoir de compte, et dispo dans les dépôts ou en flatpak.
Les données peuvent s'exporter/importer facilement, il parait d'ailleurs que les exports sont compatibles avec NewPipe.
Néanmoins cette extension c'est une bonne idée, ca fait un bon complément pour regarder rapidement une vidéo dans un butineur.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: OSSEC, un F2B en C sous GPL2
Posté par Astaoth . En réponse à la dépêche reaction, remplaçant de fail2ban. Évalué à 2.
Ouais il est assez imposant, et intimidant. On peut quand même faire un setup standalone, de mémoire l'installeur est assez simplifié pour faire ca simplement. Par contre, je crois que pour faire des filtres customs c'était un peu plus pénible que f2b, du coup je l'ai jamais trop utilisé. Mais ca a pu évoluer depuis, j'avais regardé ca y a 7-8 ans.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.