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.
Des impressions basées sur une lecture rapide de la doc et les feedbacks de chercheurs en infosec. C'est toujours mieux que de supposer au hasard en se basant sur rien.
Matrix, Jami, etc. Je préfère largement avoir un client libre ET un serveur libre.
Oui bien sûr. Tu as la preuve que le serveur Matrix auquel ton client se connecte soit synapse déjà ? Ou dans le cas d'un setup autohébergé, les serveurs auxquels ton synapse communique.
Pour Matrix en particulier, toutes les specs sont dispos pour que n'importe qui puisse écrire son propre serveur, et que ca soit transparent pour le client (ce qui est le cas ici par exemple ) : ca c'est idéal.
Par contre il n'y a aucune obligation que les serveurs déployés soient une de ces implémentations, du coup n'as strictement aucune garantie que le code qui tourne côté serveur soit libre. Ca peut tout à faire être une implémentation bien proprio, sans que tu le saches. Ou alors ca peut être un synapse, dont les gestionnaires ont été contactés par la DGSI pour une obligation d'y déployer un petit module bien opaque.
On retombe donc dans la même situation qu'avec n'importe quel client de messagerie instantanée : la sécurité et la vie privée ne peuvent être garanties que par les protocoles applicatifs et les clients, car tu n'as strictement aucune garantie que les serveurs avec lesquels tu communiques soient ce qu'ils prétendent être.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
En IDS/IPS système, opensource, codé en C et qui doit avoir plus de 10 ans (mais toujours maintenu), il y a Ossec aussi. Que ca soit à ses débuts, quand ca appartenait à Trend Micro, ou maintenant, il y a toujours eu une version sous GPL2.
Y a-t-il une raison spéciale pour ne pas du tout en parler ?
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
C'est une très bonne question. Tout a l'air d'être dispo sur leur github, et la version payante pour entreprise sert à apporter un support, et à avoir la possibilité de ne pas participer à la communauté de blacklist.
Crowdsec n'est pas comparable à un f2b dans le sens où t'as la partie communauté qui est présente. J'imagine que les versions payantes sont là pour financer le développement déjà (et ca se voit, crowdsec a une interface plus aboutie que f2b), la partie serveur pour partager les blacklists communautaires, et t'as également un dépôt de modules (j'en ai vu aucun payant) un peu comme grafana.
Si je veux un truc utilisable dans une infra
Tu peux utiliser la version gratuite dans une infra avec tout tes bounceurs qui parlent à un même serveur centrale dans la version gratuite, il me semble.
Le problème c'est pas que ce soit le produit d'une entreprise, le problème c'est que ce type d'entreprise ne fait pas de l'opensource par conviction, mais juste par intérêt pour la communication (c'est tendance).
On peut ramener le problème dans l'autre sens aussi. Quand on a ses petits serveurs selfhostés, avoir un f2b qui demande moins de temps de setup (les filtres par défaut ne me conviennent pas), avec des blacklists communautaires toutes faites, une interface cli propre et simple à utiliser, opensource et audité, avec des modules libres pour les différents services qui peuvent tourner, ca reste toujours intéressant.
Peut-être que dans 5 ans leur version communautaire sera moins intéressante ou proprio. Mais pour l'instant elle fait l'affaire, comme f2b a pu l'être en son temps.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Pour un petit serveur autohébergé dont on ne veut pas s'occuper, c'est parfait : crowdsec consomme très peut de ressource, pour l'installation il suffit littéralement de copier-coller les 2 commandes de la doc, et la commande de management ''cscli'' a tendance à très facilement afficher l'aide pour aider.
Pour avoir pu échanger avec leur équipe, ils sont très friand de retours pour voir ce qu'ils pourraient améliorer pour simplifier la vie des gens (la doc, les petits textes d'aide, l'interface, etc).
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
On est d'accord. Mais il n'en reste pas moins que la partie libre est tout à fait utilisable sans, contrairement à Signal, par exemple. Et le protocole d'interrogation du serveur est ouvert et documenté, il est donc tout à fait possible d'en (faire) redévelopper un (et éventuellement le libérer) si on le veux.
A noter que le code source du serveur de Signal est dispo sur Github pour qui veut jouer avec. Mais Signal a été très clair sur sa volonté de ne pas être fédéré. Est-ce que du coup le fait que la partie serveur soit publiée sur Github aide vraiment à savoir ce qui tourne sur leurs serveurs ? Mais d'un autre côté, vu les protocoles applicatifs utilisés et le fonctionnement des clients, est-ce nécessaire ?
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
Mais le propriétaire ne pourra apporter cette confiance tandis que le libre potentiellement. Ce dernier est une condition nécessaire mais pas forcément suffisante. Le privateur est rédhibitoire.
Dans le cas d'un serveur sous licence libre, tu n'as strictement aucune garantie que le code tournant sur le serveur est celui qui a été publié. Je préfère largement avoir un client et des specs ouvertes et auditables, validant l'absence de besoin de faire confiance aux serveurs.
Néanmoins, dans le cas de Olvid, j'ai la sensation qu'il utilise autant ses serveurs qu'un réseau torrent. Le besoin de confiance dans le serveur serait du coup assez secondaire.
Je vois pas trop le rapport avec mon commentaire. Mais Tchap est en place depuis plus longtemps qu'Olvid pour la fonction publique. Il n'y a pas eu d'annonce, publique, à un aussi haut niveau du gouvernement et aussi impérative pour l'utilisation de Tchap.
Je faisais référence à nos dernières évolutions législatives sur les backdoors dans les messageries chiffrées, au niveau européen courant 2023. C'est plus facile à imposer à des structures privées européennes.
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.
[^] # 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é à 6.
Des impressions basées sur une lecture rapide de la doc et les feedbacks de chercheurs en infosec. C'est toujours mieux que de supposer au hasard en se basant sur rien.
Oui bien sûr. Tu as la preuve que le serveur Matrix auquel ton client se connecte soit synapse déjà ? Ou dans le cas d'un setup autohébergé, les serveurs auxquels ton synapse communique.
Pour Matrix en particulier, toutes les specs sont dispos pour que n'importe qui puisse écrire son propre serveur, et que ca soit transparent pour le client (ce qui est le cas ici par exemple ) : ca c'est idéal.
Par contre il n'y a aucune obligation que les serveurs déployés soient une de ces implémentations, du coup n'as strictement aucune garantie que le code qui tourne côté serveur soit libre. Ca peut tout à faire être une implémentation bien proprio, sans que tu le saches. Ou alors ca peut être un synapse, dont les gestionnaires ont été contactés par la DGSI pour une obligation d'y déployer un petit module bien opaque.
On retombe donc dans la même situation qu'avec n'importe quel client de messagerie instantanée : la sécurité et la vie privée ne peuvent être garanties que par les protocoles applicatifs et les clients, car tu n'as strictement aucune garantie que les serveurs avec lesquels tu communiques soient ce qu'ils prétendent être.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
# OSSEC, un F2B en C sous GPL2
Posté par Astaoth . En réponse à la dépêche reaction, remplaçant de fail2ban. Évalué à 5.
En IDS/IPS système, opensource, codé en C et qui doit avoir plus de 10 ans (mais toujours maintenu), il y a Ossec aussi. Que ca soit à ses débuts, quand ca appartenait à Trend Micro, ou maintenant, il y a toujours eu une version sous GPL2.
Y a-t-il une raison spéciale pour ne pas du tout en parler ?
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é à 3.
C'est une très bonne question. Tout a l'air d'être dispo sur leur github, et la version payante pour entreprise sert à apporter un support, et à avoir la possibilité de ne pas participer à la communauté de blacklist.
Crowdsec n'est pas comparable à un f2b dans le sens où t'as la partie communauté qui est présente. J'imagine que les versions payantes sont là pour financer le développement déjà (et ca se voit, crowdsec a une interface plus aboutie que f2b), la partie serveur pour partager les blacklists communautaires, et t'as également un dépôt de modules (j'en ai vu aucun payant) un peu comme grafana.
Tu peux utiliser la version gratuite dans une infra avec tout tes bounceurs qui parlent à un même serveur centrale dans la version gratuite, il me semble.
On peut ramener le problème dans l'autre sens aussi. Quand on a ses petits serveurs selfhostés, avoir un f2b qui demande moins de temps de setup (les filtres par défaut ne me conviennent pas), avec des blacklists communautaires toutes faites, une interface cli propre et simple à utiliser, opensource et audité, avec des modules libres pour les différents services qui peuvent tourner, ca reste toujours intéressant.
Peut-être que dans 5 ans leur version communautaire sera moins intéressante ou proprio. Mais pour l'instant elle fait l'affaire, comme f2b a pu l'être en son temps.
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é à 3.
Pour un petit serveur autohébergé dont on ne veut pas s'occuper, c'est parfait : crowdsec consomme très peut de ressource, pour l'installation il suffit littéralement de copier-coller les 2 commandes de la doc, et la commande de management ''cscli'' a tendance à très facilement afficher l'aide pour aider.
Pour avoir pu échanger avec leur équipe, ils sont très friand de retours pour voir ce qu'ils pourraient améliorer pour simplifier la vie des gens (la doc, les petits textes d'aide, l'interface, etc).
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é à 6.
A noter que le code source du serveur de Signal est dispo sur Github pour qui veut jouer avec. Mais Signal a été très clair sur sa volonté de ne pas être fédéré. Est-ce que du coup le fait que la partie serveur soit publiée sur Github aide vraiment à savoir ce qui tourne sur leurs serveurs ? Mais d'un autre côté, vu les protocoles applicatifs utilisés et le fonctionnement des clients, est-ce nécessaire ?
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é à 5.
Dans le cas d'un serveur sous licence libre, tu n'as strictement aucune garantie que le code tournant sur le serveur est celui qui a été publié. Je préfère largement avoir un client et des specs ouvertes et auditables, validant l'absence de besoin de faire confiance aux serveurs.
Néanmoins, dans le cas de Olvid, j'ai la sensation qu'il utilise autant ses serveurs qu'un réseau torrent. Le besoin de confiance dans le serveur serait du coup assez secondaire.
Je faisais référence à nos dernières évolutions législatives sur les backdoors dans les messageries chiffrées, au niveau européen courant 2023. C'est plus facile à imposer à des structures privées européennes.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.