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.
Ça dépend du parc qu'on gère mais si on a suffisamment de serveurs connectés, à mon avis on peut alimenter "tout seul" une jolie liste. Et puis justement, si on peut faire communauté… et bien on peut choisir "avec qui".
Pour un setup perso, tu peux déjà le faire en connectant tes bouncers à un manageur distant au lieu de local.
Je ne les connais pas, ces gens. Je ne sais pas pourquoi ils décident de bloquer telle ou telle adresse.
Tu te doutes que les blockages des autres ne sont pas reproduit directement chez toi. Pour qu'une IP soit intégrée à la blacklist, t'as différents critères, comme le nombre de remonté de la dite IP, la diversité des AS d'où proviennent ces remontées, etc.
On a encore plein de sysadmin de bonne foi qui bloquent suivant la géolocalisation.
Je crois que les blacklistages manuels ne sont pas remontés, seuls ceux détectés par les scénarios le sont.
Qui me dit que Crowdsec n'applique pas ce genre de bannissement un peu trop large et orienté ?
Pose leur la question, ils te feront une jolie réponse en francais ;)
Je l'ai fait justement au lieu de supposer des trucs au hasard, d'où le paragraphe précédent. Et vu mes logs, il n'y a pas de blocage géographique dans leur liste, ce qui serait de toute facon assez stupide vu l'état du marché de l'IPv4.
Par contre tu peux le faire manuellement dans Crowdsec, et ca ne sera pas transmis à la communauté.
Qui me dit qu'ils n'ont pas décidé, par soutien idéologique, de bannir tel et tel serveur avec qui je n'ai personnellement aucun souci ?
Tu te doutes bien que ce genre de problème est commun à tout le monde, selfhosted comme entreprises. Et tu te doutes que Crowdsec n'a aucun intérêt que ca arrive si ils veulent garder leur crédibilité.
Quand on communique en grand sur le fait d'être open-source, c'est malsain de rajouter des petits caractères pour dire "sauf ce module et ce module".
Libre à toi d'utiliser ou pas la partie proprio, au même titre que tu es libre d'installer ou pas les drivers Nvidia proprio dans une Debian.
Mais du coup, est-ce que tu trouves ca malsaint les distributions qui embarquent le driver nvidia proprio, qui te préviennent et te permettent de les déployer avec le driver libre si tu le souhaites ? Pour toi ce ne sont pas des OS libre du coup ?
Si je ne peux pas le faire tourner en entier chez moi, je ne peux pas avoir confiance en celui qui me le vend comme service
J'ai un doute sur le fait que ca soit la définition de l'open source ca. Par exemple Signal app est open source, tout est dispo, mais tu ne peux pas le faire tourner en l'état chez toi, tu vas avoir besoin de faire quelques modifs avant.
Par contre libre à toi de forker la partie libre de Crowdsec pour pouvoir gérer ta propre communauté de blacklist. C'est aussi ca le libre, ne pas forcément rejeter tout en block parce qu'un petit truc te plait pas, c'est aussi avoir la possibilité de forker et de redistribuer librement les modifications. De ce point de vu là, la partie open source de Crowdsec respecte d'ailleurs les 4 libertés du LL, je ne vois pas spécialement d'openwashing.
Je trouve ca dommage de crier au loup juste parce que tu n'aimes pas le produit.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
( on me soufflera dans l'oreille que les agents peuvent fonctionner de manière autonome … mais où serait l'intérêt ? )
L'intérêt c'est d'avoir un manager centralisé pour plusieurs serveurs, et donc de partager les listes de bloquages avec ses serveurs persos.
On pourrait même envisager que je purges certains blocages, car, dans mon usage, je ne souhaite pas les bloquer. Imaginerions un scénario type censure ?
Tu peux déjà gérer ta whitelist sur ton manager.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Tu veux dire la partie pour gérer les listes communautaires ? Je crois pas, mais d'un autre côté je vois mal le cas d'usage.
D'un côté on ne peut pas avoir de garanti que le code publié serait bien celui qui tourne chez eux.
De l'autre, je vois mal l'intérêt de selfhost mon propre serveur de communauté, les blacklists seraient assez vide. Si je veux partager mes listes de blocages entre l'ensemble des serveurs, je me contenterais de juste déployer les bouncers sur les clients, et de les connecter à un serveur de management central (ca a l'air d'être concu pour). Ou alors c'est pour faire sa propre communauté dans son coin ? Mais casserait un peu l'intérêt de crowdsec pour le coup.
A moins que tu dises ca par rapport à la propriété des blacklists ? Ca serait intéressant de voir si ils comptent traiter les tickets demandant d'importer ses propres black/white/listes (ouverts en 2022).
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Le «100% français», si cela a un sens, est sur… AWS…(voir le lien sebsauvage).
Tu parles de Olvid ? Une recherche ddg de "olvid sebsauvage" ne donne rien, aurais-tu ce fameux lien ?
Cela fait quelques années que Tchap existe et d'un coup il faut 15 jours pour basculer sur Olvid ? Les gros sabots sont en prime.
Olvid est aussi utilisé par la police nationale depuis 1 ou 2 ans, ca débarque pas d'un coup, au hasard (cf wikipedia).
Mais si Thompson est un échec et que Tchap n'est pas privilégié, il y a peut-être une raison non ? Au hasard de l'expérience utilisateur ou des finalités complètement différentes je dirais.
Par exemple, est-ce que Tchap est ouvert aux personnes externes ? Avec un compte Tchap, peut-on parler à n'importe qui sur Matrix ? J'en doute un peu.
Egalement, est-ce que tu trouves que se balader au quotidien avec 2 smartphones et une brique c'est quelque chose de pratique ? Et est-ce la finalité de Theorem d'ailleurs ?
Voir ci-dessous.
Bof bof, tu développes pas plus que ca en quoi "Matrix est le «cas idéal»".
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Tout a fait d'accord, j'ajouterai que Matrix c'est ce qui se fait de mieux au niveau sécurité mais aussi résilience (Attaques DDOS, pannes… ), entre autre car c'est décentralisé (Contrairement aux autres Watsapp, Olvid et Signal).
Permets moi de douter, mais je peux me tromper :
- Si le serveur Matrix auprès duquel tu es enregistré se mange un DDOS, est-ce que tu peux toujours te connecter avec ton compte ?
- Qui te dit que Whatsapp/ Signal & co n'ont pas une archi distribuée au niveau mondial, limitant la possibilité de les DDOS ? Pareil pour les pannes, je serais surpris qu'ils aient une dépendance à une ressource non redondé.
- Est-ce que ton serveur Matrix stocke les messages de son côté de facon permanente ?
- Lorsque tu te connectes depuis un nouveau client sur Matrix, est-ce que tu as accès à l'ensemble des messages échangés avec ce compte par le passé ?
- As-tu un moyen de contrôler les différents clients connecté à ton compte avec Matrix ?
- As-tu une garantie que l'ensemble des serveurs Matrix avec lesquels tu peux être amené à communiquer fonctionnent de facon similaire, soit Synapse ou une autre implémentation de confiance, et non une implémentation proprio ou alors faisant tourner un module violant la vie privée des utilisateurs ?
- As-tu une garantie que le gestionnaire de ton serveur Matrix ne subit pas une pression quelconque extérieure, le contraignant à violer la vie privée de ses utilisateurs, sans possibilité de les en informer ? Si oui, est-ce le cas de toutes les structures ayant les inscriptions ouvertes à tous ?
- Est-ce que les gestionnaires de serveurs Matrix respectent le RGPD ? En a-t-on la garantie ?
- Petits bonus ayant un peu moins de rapport, est-ce que lorsqu'un utilisateur d'un serveur A joint un salon d'un serveur B, celui-ci est-il toujours entièrement répliqué du serveur B au serveur A ? Et est-ce Synapse est toujours un pachyderme trop lourd pour un raspi ?
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Sauf si ton serveur ne traite pas les flux de données des utilisateurs, mais est plutôt comparable à un tracker de torrent, et que les connexions avec lui restent minimales.
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.
[^] # Re: crowdsec
Posté par Astaoth . En réponse à la dépêche reaction, remplaçant de fail2ban. Évalué à 2.
Pour un setup perso, tu peux déjà le faire en connectant tes bouncers à un manageur distant au lieu de local.
Tu te doutes que les blockages des autres ne sont pas reproduit directement chez toi. Pour qu'une IP soit intégrée à la blacklist, t'as différents critères, comme le nombre de remonté de la dite IP, la diversité des AS d'où proviennent ces remontées, etc.
Je crois que les blacklistages manuels ne sont pas remontés, seuls ceux détectés par les scénarios le sont.
Pose leur la question, ils te feront une jolie réponse en francais ;)
Je l'ai fait justement au lieu de supposer des trucs au hasard, d'où le paragraphe précédent. Et vu mes logs, il n'y a pas de blocage géographique dans leur liste, ce qui serait de toute facon assez stupide vu l'état du marché de l'IPv4.
Par contre tu peux le faire manuellement dans Crowdsec, et ca ne sera pas transmis à la communauté.
Tu te doutes bien que ce genre de problème est commun à tout le monde, selfhosted comme entreprises. Et tu te doutes que Crowdsec n'a aucun intérêt que ca arrive si ils veulent garder leur crédibilité.
Libre à toi d'utiliser ou pas la partie proprio, au même titre que tu es libre d'installer ou pas les drivers Nvidia proprio dans une Debian.
Mais du coup, est-ce que tu trouves ca malsaint les distributions qui embarquent le driver nvidia proprio, qui te préviennent et te permettent de les déployer avec le driver libre si tu le souhaites ? Pour toi ce ne sont pas des OS libre du coup ?
J'ai un doute sur le fait que ca soit la définition de l'open source ca. Par exemple Signal app est open source, tout est dispo, mais tu ne peux pas le faire tourner en l'état chez toi, tu vas avoir besoin de faire quelques modifs avant.
Par contre libre à toi de forker la partie libre de Crowdsec pour pouvoir gérer ta propre communauté de blacklist. C'est aussi ca le libre, ne pas forcément rejeter tout en block parce qu'un petit truc te plait pas, c'est aussi avoir la possibilité de forker et de redistribuer librement les modifications. De ce point de vu là, la partie open source de Crowdsec respecte d'ailleurs les 4 libertés du LL, je ne vois pas spécialement d'openwashing.
Je trouve ca dommage de crier au loup juste parce que tu n'aimes pas le produit.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: crowdsec
Posté par Astaoth . En réponse à la dépêche reaction, remplaçant de fail2ban. Évalué à 2.
L'intérêt c'est d'avoir un manager centralisé pour plusieurs serveurs, et donc de partager les listes de bloquages avec ses serveurs persos.
Tu peux déjà gérer ta whitelist sur ton manager.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: crowdsec
Posté par Astaoth . En réponse à la dépêche reaction, remplaçant de fail2ban. Évalué à -1.
Tu veux dire la partie pour gérer les listes communautaires ? Je crois pas, mais d'un autre côté je vois mal le cas d'usage.
D'un côté on ne peut pas avoir de garanti que le code publié serait bien celui qui tourne chez eux.
De l'autre, je vois mal l'intérêt de selfhost mon propre serveur de communauté, les blacklists seraient assez vide. Si je veux partager mes listes de blocages entre l'ensemble des serveurs, je me contenterais de juste déployer les bouncers sur les clients, et de les connecter à un serveur de management central (ca a l'air d'être concu pour). Ou alors c'est pour faire sa propre communauté dans son coin ? Mais casserait un peu l'intérêt de crowdsec pour le coup.
A moins que tu dises ca par rapport à la propriété des blacklists ? Ca serait intéressant de voir si ils comptent traiter les tickets demandant d'importer ses propres black/white/listes (ouverts en 2022).
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Réinventer la roue...à la française et privatrice
Posté par Astaoth . En réponse au journal Le gouvernement français pousse vers Olvid, une solution de messagerie instantanée française. Évalué à 2.
Tu parles de Olvid ? Une recherche ddg de "olvid sebsauvage" ne donne rien, aurais-tu ce fameux lien ?
Olvid est aussi utilisé par la police nationale depuis 1 ou 2 ans, ca débarque pas d'un coup, au hasard (cf wikipedia).
Mais si Thompson est un échec et que Tchap n'est pas privilégié, il y a peut-être une raison non ? Au hasard de l'expérience utilisateur ou des finalités complètement différentes je dirais.
Par exemple, est-ce que Tchap est ouvert aux personnes externes ? Avec un compte Tchap, peut-on parler à n'importe qui sur Matrix ? J'en doute un peu.
Egalement, est-ce que tu trouves que se balader au quotidien avec 2 smartphones et une brique c'est quelque chose de pratique ? Et est-ce la finalité de Theorem d'ailleurs ?
Bof bof, tu développes pas plus que ca en quoi "Matrix est le «cas idéal»".
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Pas libre et pas interopérable
Posté par Astaoth . En réponse au journal Le gouvernement français pousse vers Olvid, une solution de messagerie instantanée française. Évalué à 4.
Permets moi de douter, mais je peux me tromper :
- Si le serveur Matrix auprès duquel tu es enregistré se mange un DDOS, est-ce que tu peux toujours te connecter avec ton compte ?
- Qui te dit que Whatsapp/ Signal & co n'ont pas une archi distribuée au niveau mondial, limitant la possibilité de les DDOS ? Pareil pour les pannes, je serais surpris qu'ils aient une dépendance à une ressource non redondé.
- Est-ce que ton serveur Matrix stocke les messages de son côté de facon permanente ?
- Lorsque tu te connectes depuis un nouveau client sur Matrix, est-ce que tu as accès à l'ensemble des messages échangés avec ce compte par le passé ?
- As-tu un moyen de contrôler les différents clients connecté à ton compte avec Matrix ?
- As-tu une garantie que l'ensemble des serveurs Matrix avec lesquels tu peux être amené à communiquer fonctionnent de facon similaire, soit Synapse ou une autre implémentation de confiance, et non une implémentation proprio ou alors faisant tourner un module violant la vie privée des utilisateurs ?
- As-tu une garantie que le gestionnaire de ton serveur Matrix ne subit pas une pression quelconque extérieure, le contraignant à violer la vie privée de ses utilisateurs, sans possibilité de les en informer ? Si oui, est-ce le cas de toutes les structures ayant les inscriptions ouvertes à tous ?
- Est-ce que les gestionnaires de serveurs Matrix respectent le RGPD ? En a-t-on la garantie ?
- Petits bonus ayant un peu moins de rapport, est-ce que lorsqu'un utilisateur d'un serveur A joint un salon d'un serveur B, celui-ci est-il toujours entièrement répliqué du serveur B au serveur A ? Et est-ce Synapse est toujours un pachyderme trop lourd pour un raspi ?
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Pas libre et pas interopérable
Posté par Astaoth . En réponse au journal Le gouvernement français pousse vers Olvid, une solution de messagerie instantanée française. Évalué à 2. Dernière modification le 02 décembre 2023 à 18:18.
Sauf si ton serveur ne traite pas les flux de données des utilisateurs, mais est plutôt comparable à un tracker de torrent, et que les connexions avec lui restent minimales.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.